Two months of an AI chief of staff: the rules that survived

My assistant runs on a constitution: a Markdown file every session reads before doing anything, a log of architecture decisions it may not deviate from without a new one, and a corrections file it must apply before it starts. The credential model is the one I described in the charter post; the rule about not inferring approval from silence is the one I broke once on a live call. After two months and sixty-six decision records, some rules have been rewritten, a few were dropped, and a small set has been tested by a real failure and held. Those are the ones worth writing down.

1. Truth lives in files, and a fact is not a fact until it is committed

Every new fact goes into a file with a provenance comment before the assistant answers about it, and every edit is a git commit with a message that says what changed and why. Not "for tidiness": the commit is the audit trail, the trigger for the search index, and the thing that makes a session's work reviewable after the fact.

The test came from the search side. The vault search returns pointers — path and line range — and the rule is that a pointer is not a source: read the range before citing. Twice this month the snippet was right and the passage, read whole, said something different. A rule that costs one file read per claim and prevents that is cheap.

2. Ask first — for judgments, not for facts

The early version of this rule was "ask before acting", and it produced an assistant that asked me what time my meeting was. The version that survived distinguishes two things. A missing fact — you know what is being asked, only the value is unknown — is looked up, never asked; the calendar, the task list, the people directory, then search. An ambiguous request — no object, two plausible readings, "push it back an hour" with nothing to push — gets one short question, and never a guess.

The tie-breaker that made it usable: if I found the answer, would I know it was the right thing? If no, ask. Acting on a guess costs more than a question.

3. The calendar is immutable; corrections are new entries

Meeting notes, daily logs, delivered briefs: once written, never edited. A wrong attribution in a transcript, a summary generated before the speakers were named, a diarization that merged two people — each of those happened this month, and each was fixed with a new dated entry next to the original, linking to it, saying what it corrects and why.

This rule was the one I most wanted to break. The original note was wrong, I had the right version, and the tidy thing was to overwrite. But the original is the evidence: of what the pipeline produced, of what I saw when I saved it, of what was believed for the twelve hours before the correction. A correction that deletes its own evidence is a different kind of record. When my own correction turned out to be wrong a minute later — it was — the second correction was easy to write because the first was still there.

The build pipelines now respect the rule too: the meetings app cannot edit a saved note; it can only write a dated correction beside it.

4. Every action gets exactly one credential, and the assistant holds none

The main agent has no external credentials at all. Each outward capability — reading mail, mirroring messages, posting to a channel, placing a call, accepting audio from the watch — is a separate narrow service with a charter that says what it may do and how to stop it, and its own key.

This month the rule got a corollary. When the watch app grew a second capability — asking questions of the vault by voice, next to uploading recordings — the question was whether to reuse the token already baked into the app. Same token means one leak opens both. The upload endpoint can only add audio; the question endpoint can read everything the read-only executor can read. Two tokens, one more line in a config file. The blast radius of a lost watch is now "someone can add audio to a queue I review".

5. Decision records before structure, with a "reverse if"

A new folder, a new service, a schema change, a change to the constitution: a decision record first, with context, the decision, and a line that says under what conditions to reverse it. Approved before execution, appended to a raw log that is never edited, indexed in a digest.

The "reverse if" line is the part that earns its keep. Two months in, several records have their reversal conditions half-met — a fallback path that will be replaced when a companion app exists, a summary step that reverses "if it puts words on people who did not say them" — and the conditions being written down is what makes the conversation about them short.

The digest is guarded by a git hook: a raw entry staged without its digest line is refused. That hook has fired at me more than once this week, and it was right every time.

6. Say "I don't know", with what you looked at

Nothing is fabricated. If no file and no service stands behind a claim, the answer is "I don't know", followed by where the assistant looked and what it did not find. Estimates are labelled as estimates; a number "ending in" four digits has no country code and is not given one.

The failure this rule prevents is not the dramatic one. It is the plausible sentence — a date, an amount, a name — that reads like knowledge and is a guess. The rule costs nothing when the assistant knows, and everything it should when it does not.

7. Every brief line must demand a response

The daily brief is not a summary. Each line is something I have to decide, answer, or do; everything merely interesting goes to a weekly digest. A brief that reads like a newsletter gets skimmed; a brief where every line is a question gets answered.

Notable changes the assistant made to its own files are surfaced in the next brief. That is the loop that makes rule 1 reviewable without me reading git logs.

8. Before a service goes live: where does its data land, and who backs it up

A late addition. Before any new service, mirror, database or container goes live: its data must live under one of three known directories, and any database needs a consistent-export step in the nightly backup script. Missing either, the service is not done, and the decision record says so.

It was written after a database landed in a Docker volume nobody was snapshotting; since then every new service has had to answer the question in its decision record, and the answer has been a minute of work each time.

What was reversed

Two records were reversed by later ones, on purpose and in writing. The meeting recorder was scoped as "transcript and audio only — no summary, no task extraction", so that capture stayed zero-AI; a month of reading raw transcripts reversed that into a summary step that runs before the note is saved, with the caveat that action-item owners come from diarizer labels and are never assigned without a human. And "tool calls are compact JSON" started as a strict format and became a generation rule with a tolerant parser, after a pretty-printed call broke a strict one. Both reversals cite the record they overturn.

Why these

Every rule on this list has a failure behind it — a wrong name in a transcript, a token that could have opened two doors, a note I wanted to overwrite, a database nobody was backing up. The rules that were written from principle in August and never tested are still in the file too. I trust these more.

Receipts

• 66 architecture decision records in two months; raw log append-only, digest index guarded by a commit hook.
• Corrections this month written as new dated entries: three meeting notes, one of them corrected twice.
• Credentials held by the main agent: zero. Separate credential files for separate capabilities: ten.