Adopt the charter

Before you start

Before you start: you need three things you made this week, and you don't have to open any of them; your agents read them for you. Your brief from Lesson 4 and your three priorities from the hire lesson, because the charter's first line is what your organization is for, and that comes from those two. And the Chief of Staff you hired, because it's the first agent that will work under what you adopt, and it's the one that calls in the Steward for you. The charter and your Charter Steward are already in your workbench.

Start or resume this lesson

The Professor explains the concepts. Chief arranges the Charter Steward's work. You decide what to adopt. If you are using a fictional organization, you still make the actual decision about this exercise.

Why the full read comes now

A charter at the start of the week would have been abstract. Now its rules refer to things you've seen: Chief routing a job, a Writer leaving a fact unresolved, a reviewer returning findings, and you choosing what information may be used.

The charter answers “May we?” A skill explains “How?” The work order and workflow explain “Which agent, then which?” Review and evaluation ask “Was the work good enough?” One document doesn't need to do all four jobs.

In business terms

You already know how a company keeps itself in order. The owner signs. One document says how the place works. Every employee has a job description under it. And a company secretary keeps the paperwork straight and checks it still matches, without ever deciding anything.

Your organization has the same four pieces.

How to read the picture. On the left, a company. On the right, yours. The green box is the charter. The dashed box is your Charter Steward. It's dashed because it holds no authority: it keeps the charter and the agent roster, checks they still match, and records what you decide.

What's running underneath

Before you read the rules, look at what they're rules for. When your organization does a job, four layers are at work.

The model is the rented brain. It thinks when an agent thinks. The harness is the program, Claude Code or Codex, also rented: it opens your folder, runs the agent, and hands it its tools. Your agents are files. When you call in your Chief of Staff, the harness reads that file and works as that agent. The charter states the organization's rules; it does not override app permissions. The agents and the charter are yours.

How to read the picture. Follow the arrows down, from the paper you own to the program you rent. Two of them are labeled differently. The harness obeys the settings with no judgment at all. It follows everything else, your agents' files included, the way a good employee follows instructions: almost always. Hold onto that difference. It's the point of this lesson.

Read the agreement, not just its title

The full charter has a rule about its own rules: each clause needs a named implementation or review target. In plain language: point to where the rule is applied or checked. The original charter calls this a compile target.

: a role instruction, selected input, permission setting, review, or human decision.

That target may be implemented, manually checked, or still missing. Naming it doesn't prove it works, and adopting the charter does not automatically generate app settings.

Seven rules that keep the organization useful

1. No agent without an accountable owner and a recurring job.
2. No new agent when a reusable skill is enough.
3. No duplicate responsibility without a written reason.
4. No access beyond the job.
5. No autonomy without evidence for the particular action.
6. No forgotten roles: review whether to keep, retrain, merge, restrict, promote, or retire them. Insufficient evidence is a valid finding before deciding.
7. No new department until a useful workflow justifies it.

That rule above the four parts, every rule names what carries it out, applies to all seven; it isn't an eighth item.

Two app formats for one role aren't two agents. The five-profile authorship exercise later in the course is practice in designing roles, not a rule that every real job needs five.

Finally, read the adoption record: the accountable human, exact decision, date, reviewed version, amendment or unresolved question, and the actual saved revision. An old example adoption date isn't your decision.

Who reads it. Two agents read the whole charter before every job: your Chief of Staff, when it decides where a job goes, and your Charter Steward, when it checks the files against it. The other six carry their own rules in their own files, and the Steward's check is what keeps those files honest. Until today the two have been reading the draft.

Now read the full charter. Top to bottom, once. It's short. Each rule sits in a table beside the thing that makes it more than words. Open it in your workbench: course/workforce/student-authoring/workforce-charter.md.

A rule, an observed action, and a technical restriction

A sentence is not a lock

Here's the idea this lesson turns on. Writing "sending and publishing are the Director's decision" in your charter changes nothing on your computer. The charter is a document. Every line in it is a sentence.

A rule can have three things behind it:

So where are the locks? Not in the charter. On Claude Code, an agent can only use the tools listed in its file. The declared tool list and narrower written scope are evidence to inspect, not proof that every alternate route is blocked. A general-purpose tool may have broader capability than its written scope. Check the actual supported app controls and safe test evidence. On Codex, distinguish written limits from whatever sandbox is actually configured.

That leaves a gap. The charter says what should be true. The tool lists and settings decide what is true. Somebody has to check the two still agree. That's your Charter Steward. It reads the charter, reads the files where the locks live, and prints every place they disagree. In its own words: the charter is a lock only if something checks it.

So why write a charter at all? Because without it there's nothing to check the locks against. You'd have settings someone chose, and no statement of what you meant. And for every rule that matters, you can now ask the useful question: which of the three does this one have today?

These are three different kinds of evidence:

Your Chief of Staff reads the charter before routing work. The Charter Steward reads it to compare the agreement with the setup. Specialists such as YGM, Kansa, Echo and the Librarian receive the relevant rules through their own instructions and Chief's work order; they don't reread the whole charter for every job. The Professor uses the template when teaching requires it. Rules reach the work through those instructions, the supplied information, actual app controls and checks after changes.

How a rule gets into an agent

A rule in the charter doesn't reach an agent by itself. Somebody has to put it somewhere the agent will meet it. There are three places to look.

1. Claude Code's or Codex's settings, and the seat that ran. A supported control may prevent a particular tool call. Inspect the tool declarations, installed settings and runtime permissions in the actual app. The source design describes denied web actions and some approval prompts; missing settings cannot enforce them. Written scope restrictions, including restrictions on a general-purpose tool, are not proof of runtime enforcement. Ask which control was actually configured and tested.

   In plain words: this is the only one of the three where a rule becomes a lock.

2. The agent's file. Every agent's file says what it's responsible for, which tools it may use, what it reads, and when it stops. This is where most of your charter lives day to day, as instructions. When you build or change an agent in Week 3, check its file against the charter before you use it. If a change would let it do more than the charter allows, that's your decision to make. Saving the file doesn't grant it.
3. Your Charter Steward's check, after anything changes. Ask for it, and the Steward compares the charter with your agent roster, your settings and every agent's file. It flags an agent nobody registered, a tool an agent holds that the charter keeps with you, and a file that doesn't match the roster. You read what it found before anything changes.

What isn't automatic yet. None of this runs by itself. The charter doesn't write the settings. The Steward doesn't check every night. Nothing refuses an agent because it isn't registered. Today you ask for the check, and you read what comes back.

Read the picture. One rule from your charter, the one you met in Lesson 1, and the three places it lives. Left to right: the settings and the missing tool (a lock), the agent's own file (words), the Steward's check (what catches a lock that's been opened). Underneath, the same three places for a rule that only needs words.

What takes precedence

People will ask this, and they're right to: if Claude Code or Codex has permissions and the charter has rules, which wins when they disagree?

The program wins. Every time. A charter is not a higher setting that overrides Claude Code or Codex. It says what you intend. Claude Code or Codex does what its settings and the agent's tool list allow, whatever your charter says. To turn part of your charter into a lock, someone has to set the control, and then test it.

The controls, in plain words. A deny is a refusal. An ask is a stop for your yes. An allow lets one specific thing through. The source design includes denied web actions and approval prompts for some commands. Confirm which settings are installed and tested in your app; the lesson does not establish those controls are active.

Try the difference. Two checks, with your Chief of Staff.

1. A style rule. "Don't say 'reach out.'" Ask for a short brief and read it. Did it follow? That's a sentence at work: followed, almost always.
2. A rule that matters, like sending. Don't ask an agent to send a live message to find out. Open its file and read its tool list. Is there anything on it that could send? A tool-list inspection establishes declared capability, not a tested restriction on every route. If you can't tell, write "untested."

For every rule that matters: name the rule, say where it lives, and say what evidence you have. A missing lock is something to build. It isn't a reason to drop the rule.

Meet the Charter Steward

The Charter Steward reviews the agreement, roster, and declared permissions; records your decisions; and prepares material for review. It does not decide for you or silently repair a mismatch.

Drift means a difference between the agreed rules and the current setup. For example, a role may be configured with a capability that the charter does not allow. The check reports that difference; you decide what should change.

The Steward's agent-roster printout can establish a name, a job, and an instruction file where those are recorded. It cannot establish an accountable owner or reviewed responsibility merely because a row exists. Those need their own evidence. Its drift check compares selected files with the charter and lists what it did not check. Zero findings means no mismatch was found within that comparison, not that every control is proven.

When no root charter has been adopted, the Steward must report that. Its live drift check against an adopted agreement cannot be claimed yet. Reviewing the proposed wording is still useful and remains a different activity.

Try it

You're reading this last on purpose. On Monday it would have been abstract. Today every line points at something you did this week.

1. Read the full charter. Top to bottom, once.
2. Meet your Charter Steward and get the agent roster.
3. Change one rule, the proper way. You propose any business-fit change with The Professor. You decide, and the approved wording is recorded.
4. Adopt it. Your decision is the adoption. A saved version, the founding commit, is the receipt.
5. Have the Steward check the version you adopted.

Read the picture. Three lanes: you, your Chief of Staff, Gigawatt. Follow the numbers down. You never talk to Gigawatt; your Chief of Staff carries your words out and the answer back. Two messages, one yes.

Read the picture. One change, start to finish. On the left, the rule as it stands. In the middle, the new wording with its reason. On the right, your decision, then what gets filed.

Why the founding commit matters

Git is the record book. A commit preserves a version locally; its message explains the change; the history lets you compare versions later. In this course, the founding commit records the adoption you approved. It doesn't supply that approval for you.

The final record should distinguish the proposed charter, your decision, the applied root version, the local commit, any approved remote copy, and the Steward's subsequent findings. The source design includes a Claude Code startup drift check when a session starts or is cleared. Package layout alone does not establish which settings are active in an installed workbench.

It adds a summary for Chief to report, with findings under Needs you. The check reports differences; it does not repair them or block the session. If no result appears, don't assume it passed: ask for the Steward's report. This Claude hook does not establish an equivalent automatic check in Codex.

The Charter Steward owns drift comparison; the Technical Operator setup procedure also runs the drift script as its final step. In the Week 1 hire, the Technical Operator makes the approved naming change behind Chief of Staff and then runs drift; students do not open a Technical Operator conversation. Keep ‘not checked’ distinct from ‘no findings.’ Neither check automatically turns charter clauses into app settings.

Before you finish

You can explain what the charter governs, how it differs from app settings, and how one clause reaches the work. You have inspected the Steward's actual return and made your own decision. Where adoption succeeded, you can find the applied root version, its record, and the follow-up check. Missing implementation stays visible.