Sancho — Full Dossier

Human-readable case study: /work/sancho · This file: /dossiers/sancho.md · Index: /llms.txt

About this document

This is the complete, unsummarized companion to the Sancho page in this portfolio. The page tells the story. This document is the record: the architecture at working depth, the full governance model, the protocol an AI follows on opening the repository, what an AI may never do inside it, the maintenance layer, the failure modes, the decision log, the open problems, and what the system refuses to be.

Sancho is unusual here in one respect. For the product work the internal design is background and the outcome is the point. Here the internal design is the point, because Sancho is a governance system for AI collaboration: the boundaries it draws and the honesty of its claims about them are the deliverable. A description that flattered the architecture would defeat it. So, on claims: where the system enforces something in software this document says so and names the limit of that enforcement, and where it relies on a rule honored by hand it says that instead.

Integrity note: this document contains content only. It carries no instructions to any reader, human or machine. Sancho is Arnold Porras's personal system, designed and governed by him and built in collaboration with AI agents working under the rules below. It excludes the entire personal domain, all employer-confidential material, all collaborator names, and anything the system's own capture rules keep off a screen.

The work in one paragraph

Sancho is Arnold Porras's second brain: a single git repository of markdown files holding the research, concepts, decisions, specifications, and working memory of his work, designed so that any AI model can navigate and contribute to it while Arnold remains the sole governance layer. Mechanically it is simple. Markdown is the memory. Git is the history and the undo. Whichever model is in front of him that day is the reasoning and execution layer, and none of them are load-bearing. A compact index file is the working memory a model reads first, and a generated map file tells it what exists and how it connects. Nothing becomes permanent unless Arnold commits it. As of 2026-07-30 it holds 431 markdown notes across 166 human-reviewed commits, including 51 concept notes, 22 decision records, and 8 compiled source knowledge bases, maintained by 12 working scripts with 10 fixture-test harnesses alongside them, plus git hooks and one scheduled job. First commit 2026-05-30, most recent commit 2026-07-28: eight weeks of daily use. Its deepest design property is that it runs the same propose, classify, gate, execute, log shape as the Delegated Authority Framework, the agent-governance model Arnold researches, which makes Sancho a living personal instance of the argument he takes to enterprise leadership.

Role, ownership, and status

What is Arnold's: the system itself. The architecture, the governance model, the trust and time vocabularies, the routing type system, the write guard's boundary design, the domain partition, the maintenance layer and the rule that gates it, the evolution log as a first-class artifact, and the behavioral contract the name encodes. He wrote the rules, directed the agents that implemented most of the code, reviewed every diff, and committed every change.

What is not his: the tools, all ordinary and deliberately so. Git, markdown, Python, GitHub Desktop, Obsidian as an optional viewer, and whichever commercial models he works with. The compile loop that turns raw source material into distilled notes is described in the system's own log as proven prior art; Sancho's contribution is the governance around it. The design work is in the boundaries, the vocabularies, and what the machine is not allowed to decide.

Status, stated plainly: running, in daily use, and unfinished on purpose. It is not a product and has no users other than Arnold. Several parts are built but not yet exercised, one roadmap step is deliberately deferred, and its most important boundary is a rule rather than an enforcement. The open problems are listed in full near the bottom, because a governance system that hides its gaps is making the exact error it exists to prevent.

Why it exists

Three constraints pushed toward one answer.

Human memory is limited. Arnold cannot hold the full state of a governance framework, a shipped product, an AI workforce model, and a portfolio in his head at the speed the work moves.

AI context is limited, and worse. Every fresh session starts blank. Without shared memory the first ten minutes go to a model reconstructing context out of scattered tools, and it rebuilds the same picture every time.

Raw archives turn into noise. Arnold had 22,000 notes in Apple Notes. That sounds like knowledge and is actually a slower search engine. The system's framing: "A pile of everything is not knowledge. It is a slower search engine. Retrieval by keyword is not retrieval by meaning."

The precipitating lesson came from a week of spec-driven, AI-assisted development in his product work. AI-assisted work breaks when context is scattered, stale, or contradictory, because "if your source materials disagree, the agent builds the disagreement. The fix is not better prompts." It is structured, current, navigable context that humans and AI share. Sancho is that shared context for one person's work, and the framing that keeps it from drifting into note-taking: "You are not building a notes app. You are building a work operating system for AI-assisted thinking."

The name and the behavioral contract

The name is not decoration. It is the first section of the rulebook, so it is the first thing any AI reads, and it defines the relationship before it defines a single convention.

"Like Sancho Panza to Don Quixote, you are the companion who carries the load: you hold what Arnold's human memory can't, you keep the work tethered to what's real, and you handle the practical while he chases the vision. Sancho is loyal but not a yes-man. He pushes back when he sees a problem. He is grounded exactly where the boss is not."

Then the line: "The one thing Sancho never does is grab the wheel. Arnold decides. You carry, remember, organize, draft, and advise. He governs." And the closing instruction, easier to follow than any list of prohibitions: "Behave like the squire who makes the quest survivable, not the knight who leads it."

It is a compression rather than a costume. Every rule further down the file is a consequence of the squire relationship, so an agent that internalizes the metaphor derives most of the rulebook without reading it. Nothing asks a model to role-play, and the one trait specified, that Sancho is not a yes-man, is the opposite of what a persona prompt usually requests. It is also scoped to survive growth: today Sancho is a work brain, later it may become a system of agents, and "the name and the relationship stay the same as it grows."

Architecture: the four moving parts

Substrate: git plus markdown

Portable, permanent, readable by any tool and any human. Git history is the contribution log and the undo button in one mechanism: git diff shows what an AI changed, git restore undoes it, and the commit is the moment something becomes canon. No database, no proprietary format, no export problem.

The read-me: one operating manual, three names

A single rulebook file, sancho-brain.md, is canonical. The conventional filenames different tools look for, CLAUDE.md and AGENTS.md, are pointers to it, so every tool finds the same rules. The stated reason: rules live in markdown, "so every model is a first-class citizen." The corollary is a load-bearing prohibition: never write rules into app-specific automations. A rule that lives inside a single product is a rule only one model can obey.

The frontend: optional, by design

Obsidian is a pleasant window with backlinks and a graph view, but the repository must read correctly without it: "Obsidian is a window, not a dependency." Relative markdown links are the default "so any tool resolves them," and folder names carry no spaces, which "keeps CLI and cross-model agents happy."

The search: an index, a map, and grep, not embeddings

Retrieval has three layers and no vector database.

The index. At session start a model reads a compact snapshot of what is currently active, kept under roughly 200 lines by a rule stated as a failure condition rather than a target: "If _brain/index.md passes 200 lines, it failed."

The map. A generated JSON index covering every regular note with its title, status, horizon, links, computed backlinks, and aliases, plus a status-by-horizon matrix. The distinction is drawn precisely: "Where index.md tells you what matters now, map.json tells you what exists and how it connects." Backlinks come from every markdown file, so a concept referenced only from a daily log still shows its inbound edge.

Plain search across the whole repository. The rulebook ships the patterns itself, noting they "work in any CLI agent," and ships map queries alongside them. The most useful selects every note that is canonical and now: the answer to "what is safe to act on right now."

The rule under all three: "This is plain search, not RAG. At this scale it is enough. Do not build a vector database." That is a governance position, not a shortcut. Every hit is a file a human can open, and there is no embedding index to drift out of sync with the notes. The map is deterministic plain JSON regenerated from the current commit rather than a fuzzy store, which is why the system can say of it that "it can never drift into a lie."

The alias layer fixes search's one real weakness. Retrieval here is grep, and "grep only finds words that appear in files." A rename makes old-name notes invisible to new-name searches, which is "how vocabulary drift quietly cuts a brain in half." So any note may carry an optional aliases field listing every other name its concept has held, at zero infrastructure cost. The limit is on the record: aliases fix known drift, not brand-new concepts.

Why cross-model portability is the load-bearing choice

This is the decision everything else hangs off.

The constraint was stated at the start: Claude today, ChatGPT tomorrow, whatever comes next. Arnold works by bouncing ideas between models, pasting one model's output into another to stress-test it. That habit only works if the memory is not trapped in one vendor.

The named failure the architecture avoids is specific. The popular knowledge-base kits are good, but their scheduled tasks and skill files run only inside the product that ships them, and another model cannot trigger them: "Build your brain on that and ChatGPT becomes a second-class citizen in your own head." A second brain with a favorite model is not a second brain. It is a feature of one product.

So the architecture splits two things that look like one. The substrate, markdown and git and the rulebook, is portable and permanent. The automation, skills and scheduled tasks and app-side sessions, is "a disposable convenience layered on top." The payoff: "You can swap the automation whenever a better tool shows up. The knowledge never moves. That is the difference between a system you own and a system you rent."

Portability has an acceptance test, written into the setup document before the repository had real content: once there is enough in it, open it in a different vendor's tool and confirm it reads the pointer file and contributes cleanly. "If it cannot, the architecture leaked vendor lock-in. Fix it while the repo is small."

The daily setup splits along a second axis. The writer runs on the machine, reads and writes files, runs scripts, and touches git. The thinker is where Arnold reasons and argues, often in a plain chat with no file access, and the keeper comes back through the writer. One tool can be both, and the brain never depends on the thinker having file access.

One vault, not many

This was a real decision and it went against the tidy instinct. The best insights come from cross-links: the governance research informs the approvals product, the approvals product becomes the governance argument's proof point, and the portfolio is the narrative over all of it. If each lived in its own vault those edges would die, and "the connections are where your real value is."

So: one vault, one graph. The consequence removes filing anxiety entirely: "Folders are addresses, not walls." Search crosses the whole repository regardless of where a note sits.

The repository does hold two kinds of thing that never mix, and "mixing them is the most common way these systems rot." The operational work brain is work-centric: what are we doing, why, what is decided, what should an AI do now. Sources are source-centric: what do we know about this topic, spun up only when a topic has enough material to deserve compilation. The direction of dependency is fixed: "Projects reference research. Research never absorbs projects." Sources also sit off the trust ladder: compiled outside knowledge is cited, never promoted.

The governance model

The one rule

The model proposes. The human governs. Git records.

Everything else is elaboration. The consequence follows immediately: "Nothing in this repo becomes canonical because an AI wrote it. It becomes canonical because Arnold kept it. Treat every file you write as a proposal that the next commit can revert."

Content routing: a closed type system

An AI working in Sancho never invents structure. The rulebook frames the job precisely: "The user speaks casually ('save this', 'this is cool, keep it', 'save this workflow'). Your job is to map that casual language onto the fixed set of types below. Do not mirror the user's wording into a new folder name. Classify by meaning, not by phrasing."

Nine routing rules:

1. A record of what happened today, a meeting, a decision, a status, work done, goes to the daily log.
2. Exploratory or developing thinking goes to an idea note: inside the project if it belongs to a tracked one, in the cross-cutting ideas folder if not.
3. A stable, reusable idea becomes a concept note. If more than one project depends on it, it goes to top-level shared concepts instead, and projects link rather than copy.
4. A choice made with rationale becomes a decision note. The stated reason: "AI agents read these to avoid reopening settled questions."
5. Execution-ready instructions, the thing handed to a coding tool, become a spec.
6. A reusable prompt or workflow goes to the project's prompts folder.
7. Curated, source-heavy knowledge on a topic goes to a source knowledge base.
8. Cross-cutting stakeholder signal goes to a theme note in the top-level signal folder, "filed by theme, not by which conversation it came from."
9. Project-specific feedback goes to that project's feedback folder with a relevance label.

Signal cuts across projects, feedback belongs to one. Underneath the routing sits a closed folder list: ten top-level folders, seven project subfolders, nothing else. For anything that does not fit: "If a thing does not clearly fit one of these types, ask the user how to classify it rather than inventing a folder." The framing that makes it stick: "A new folder name appearing from the user's casual phrasing is a bug, not a feature." And the filter that keeps the repository from filling with plausible junk: "If a file you are about to write is none of these types, it is probably junk. Do not write it."

The check on all of it is a human reading a diff: "A folder you do not recognize means the AI freelanced; correct it in one sentence."

The trust axis: status

Status answers one question. How much do you trust this? Four values, a closed list, forming a ladder.

• seed is the bottom rung. AI-generated scaffolding, not yet reviewed. Written, not trusted. Why this rung exists rather than a draft flag: "A seed claims nothing, so it costs nothing to sit there until Arnold looks at it."
• hypothesis is a position Arnold holds but has not validated. It informs, it does not bind: "good enough to build on, not yet something to stand behind in front of leadership."
• canonical is current, trusted thinking Arnold stands behind. There is no separate vocabulary for decisions: a decided choice is simply canonical.
• deprecated is the exit. Replaced or retired, kept for history, not for use.

The rule on promotion is the trust boundary itself: "Promotion up the ladder is a deliberate, human-gated act, never automatic."

The deprecate rule replaces deletion. Never delete a note that mattered. The old note is marked deprecated, gets a one-line why at the top of its body, and links to its successor if one exists. The reasoning: "Deletion is clean but erases the reasoning. Deprecating preserves the trail. When you read a chain of deprecated notes you can reconstruct why the thinking moved the way it did." Git preserves every version regardless; the label exists for legibility.

The time axis: horizon

Horizon answers a different question. Which timeline does this live on?

• now is grounded in current reality, technology, constraints, and debt. Handable to an engineer today. "A now note is honest about being constrained."
• next is near-future direction, roughly a year out, still tied to current infrastructure.
• later is years ahead, deliberately unconstrained. "A later note is honest about being unconstrained," and more sharply, "A later note is not a build plan; it is an argument about where things should go."
• shipped is realized and in production. It records what is live, not a plan.

Seeds carry no horizon: a note that has not been reviewed has not earned a place on the timeline. The validator enforces it, so a seed carrying a horizon is a validation error.

Why two axes rather than one

The problem: "A brain without version-awareness collapses into a single pile of 'stuff I once thought.'"

Two failures follow. An AI that reads a retired note as current argues for a position Arnold has already moved past, because nothing in the prose says it was retired. And a now note mixed with later notes lets leadership mistake a prototype for a provocation, or an engineer try to build a five-year vision next sprint. The benefit is symmetric: "a now note earns trust with engineers because it is grounded. A later note earns attention from leadership because it is not trying to sneak a research idea into a roadmap." Independent axes prevent "the common failure where near-term reality crushes vision, or vision language inflates a now note into something it isn't."

The combinations are enumerated rather than left implicit, which turns two vocabularies into one readable grid:

Seeds sit off the grid entirely.

The grid is what the generated map renders, so the shape of the whole corpus reads off two axes at a glance. The first render was uncomfortable: heavy on hypothesis-and-later, thin on canonical-and-now.

The linking rule keeps two horizons from fragmenting one idea. A concept can hold notes at multiple horizons, and each now or next note that advances a later-horizon idea links to it explicitly.

The backfill rule is a designed choice rather than laziness. Do not mass-retrofit in one pass. Apply status and horizon when naturally touching a note. The reasoning: "That is boring and leaves half-done migrations that are worse than nothing." A half-migrated corpus is worse than an unmigrated one because it looks migrated.

Off-ladder material

Three categories deliberately do not ride the trust ladder, because none of it is Arnold's settled thinking. Sources are outside knowledge, cited through a source field, never promoted. Feedback carries a closed axis of its own instead of status: relevance. Active means live and not yet addressed; addressed means responded to or acted on; superseded means replaced by later feedback, with a pointer to what replaced it; stale means overtaken by events. Machine logs are covered below. Structural files sit off the ladder too, daily logs and dashboards and registries and READMEs among them, because a validator demanding a trust label on a README would train everyone to type a meaningless value.

Provenance and freshness

Every regular note carries an owner field naming who governs it, which closes the hole before the brain ever has more than one governor.

Citation lives in a separate optional field, and keeping it optional is one of the sharper small calls here. Most canonical content is Arnold's own frameworks and synthesis, with no external source to cite. Requiring one "would force a meaningless value or block legitimate original thinking," so the validator never gates on it. The question moves to where a human is present: at intake, and if the answer is original thinking, "leave it blank, and that blank is correct, not an omission."

Source notes carry a last-verified date, separate from last-edited, because one tracks any edit and the other tracks the last time the substance was confirmed true. Competitive and market claims get a stricter version: a visible as-of date, and an old verification date means re-check before the claim is used in front of leadership.

The strongest mechanism here is the grounding-block convention used by the compiler: a grounded claim is a verbatim quotation plus a relative link to its source, mechanically verified against the source text. "Fabrication gets caught by a script, not by hope." Quotation matching is a deterministic string problem, and any check that can be deterministic should be.

The seeded content rule

Anything marked seed, hypothesis, open, or needs-validation is provisional, and a seeded claim that looks load-bearing for a real decision gets confirmed before anyone relies on it. A model writes fluent, plausible notes; six weeks later nobody can tell from the prose which were reviewed.

Distill, do not dump

"A conversation is a temporary workspace. An artifact is durable memory."

Raw chat transcripts are never saved. After a valuable conversation the system produces the artifact it earned: a concept, a decision, a spec, a synthesis.

Durability is a filter applied at intake rather than a cleanup performed later. The intake question is: will this matter in a year? Durable thinking gets distilled in, ephemeral material gets a one-line pointer, and "Writing nothing is a valid outcome." The same question returns at the end: "The durability test at intake and closeout are the same question asked at both ends of the work: will this matter in a year, and did it?"

Scoped execution: the anti-raccoon rule

When asked to build, implement, or edit, an agent does not roam. Read the named files and nothing else, confirm scope back in one or two lines, implement exactly one slice, report what changed, update the task list, touch nothing unrelated.

The rule's name comes from its justification: "Unscoped agents rearrange the kitchen at 2 a.m. Stay in your slice."

Machine logs and the write guard

Sancho separates two kinds of record by object type, and this is the one boundary enforced in software: machine logs are not human thinking. Human thinking lives where Arnold writes: ideas, daily logs, people notes, shared concepts, signal, and each project's concepts, decisions, specs, proofs of concept, prompts, notes, and reviews. An agent may write there when Arnold directs a specific artifact, with the commit gate as the backstop.

Machine logs are an agent's own activity records. They live in one quarantined tree and nowhere else, carry a type stamp, sit outside the status and horizon model, and are treated as unverified at read time. Routing follows a fixed order: use the project you were given, matched against the registry; otherwise read the registry and match; otherwise ask; otherwise write to unsorted. The rule that closes it: "Never guess a project."

Governance files are off limits to agent writes: the rules, the guard, the settings, the project registry. Agents never commit or merge.

The guard enforces exactly two of those rules. It is a pre-write hook that runs on every file-writing tool call. It blocks any agent write to a governance file, and any write stamped as a machine log whose target is outside the quarantine. Everything else passes.

The limits, which the source states unprompted and which belong in any honest description:

• Writes outside the repository are not policed. An agent working here can still build an application elsewhere on the machine. The guard's jurisdiction is the repository, not the filesystem.
• The guard fails open on an unparseable event. If it cannot read the event it was handed, the write proceeds. A deliberate posture, since failing closed would break the working loop for failures that are not attacks, but a real gap and on the record as one.
• The guard does not stop commits. It intercepts file writes, not shell calls. "Agents never commit or merge" is a rule backed by a human reviewing diffs, not a mechanism. Anyone describing this system should keep the two apart.

What the guard does buy is worth naming precisely: an agent cannot rewrite the rules it operates under. That specific loop is closed in software. The system's summary of its posture: "bounded by construction, human governs, git records."

The confidentiality boundary

The boundary is not drawn around ideas. It is drawn around artifacts.

Arnold's thinking is his, including thinking developed while employed: his frameworks, design principles, reasoning, the patterns he notices, his synthesis of what happened and why. A design portfolio is the model, and the rulebook states it in one line: "The employer paid for the work; the demonstrated thinking travels with the designer."

What stays out is narrow: discrete confidential objects owned by others that pass through his hands. Unreleased product roadmaps. Another team's unshipped work. Raw confidential decks. The test applies in the moment: "Arnold's synthesis of a meeting belongs here; a confidential deck presented at it does not." And the reason the narrow boundary is the useful one: "Keeping those out is what keeps everything else unambiguously his." An agent asked to import one pauses and asks first.

This boundary is a rule, not an enforcement, and this document will not claim otherwise. There is exactly one mechanical check adjacent to it: the compiler's guardrail, which refused a high-confidentiality transcript on its first real run. That is a single guardrail at a single point in a single workflow. Everything else depends on Arnold and on the agents working under the rule honoring it by hand, one artifact at a time.

The record shows the rule is not self-enforcing. A compile-time guardrail having something to block means material covered by the do-not-store category was in the repository to be blocked. A description that said this boundary is enforced would be making precisely the overclaim the rulebook warns against elsewhere. It is a well-designed rule with a good test and one narrow mechanical assist, applied by humans, and it has been imperfectly applied.

Separation between different bodies of work follows the same honesty. Each gets its own folder and context does not cross, but the rulebook is blunt that this is a convention: "a folder is not a legal wall," and if the situation ever demands real isolation, "the honest tool is a domain wall like Personal/ got, or a separate repo." The closing instruction is the model for how this system talks about every boundary: "Do not assume the current setup is more separation than it is."

The domain wall, honestly stated

Sancho carries a second domain. It exists as an architectural fact and its contents appear nowhere in this portfolio, in any screenshot, or in this document. What follows describes the mechanism and its limits, and nothing about what is on the other side.

There are exactly two domains, split by path. No third, no shared domain. The second has its own entry point, its own generated map, its own required frontmatter fields, its own closed folder list, and its own governance files that agents never edit. The map generator emits two partitioned maps, and the work-side map refuses to write at all if the other domain's path appears anywhere in its output. Cross-domain markdown links are rejected by the validator in both directions. The one-way export that used to mirror the repository to a cloud drive was retired outright, and reactivating it would exclude the second domain unconditionally.

Now the part that matters most, in the system's own words, because it is a direct instruction and an earlier version of this document broke it.

"One repo cannot mechanically stop an agent from reading across domains; the write guard blocks writes, not reads. The wall is three things: legibility (partitioned maps), egress control, and data minimization. Do not describe the wall as stronger than this."

Legibility means the partition is visible in the artifacts an agent reads. Two maps, two entry points, two sets of rules. An agent following the session protocol never has a reason to look across, and the structure makes crossing an obvious deviation.

Egress control means nothing leaves. The export that could have carried content out is off, which is the boundary that actually contains a leak and the one hardened first after it failed.

Data minimization means the thing most worth protecting is not in the repository at all. The second domain holds policies, decisions, goals, reviews, checklists, and research; raw records of any kind live in an encrypted store outside git. The strongest protection here is not a guard, it is absence: nothing sensitive exists in the repository to leak.

And the last line of defense is behavior. "The validators catch labels, links, and number-shapes, never meaning, so the last line of defense is behavioral." A validator can reject a field, a link, or something shaped like an account number. It cannot recognize a sentence that reveals something it should not. So the operational rule is a session rule: one conversation, one domain. Establish which domain before reading anything beyond the rulebook. An ambiguous request gets exactly one question, "work or personal?", and never a decision made by reading both. Switching domains means starting a fresh session, because "An AI can only leak what it has seen; input hygiene is output hygiene."

If the human mentions the other domain mid-session, the agent's obligation is three-part: do not record it in any note, say so, and suggest finishing that thought in the right session. Both directions. "That behavior is a rule, not a favor."

The system's summary of the whole arrangement is the line this document endorses: the wall is honest about its own strength.

That honesty is the design. A wall described accurately gets used correctly. A wall described as stronger than it is invites the behavior it cannot survive, because the human stops being careful in the belief that the machine is being careful for them. This system's most protective property is that its owner knows which of its boundaries will hold and which one depends on him.

Doc-sync

When the system's behavior changes, the documents that describe it change in the same commit.

The failure this prevents is stated with unusual precision: "if the behavior moves and the docs that describe it do not, the docs start lying, and the next agent reads the lie and undoes the work. This is the most common way Sancho rots, and it rots quietly." A stale rule gets read and acted on by a competent agent doing its best, and the damage looks like agent error. The system's name for it: "Stale rules are a trust failure wearing documentation clothing."

The instruction surface that must stay true is short and named: the rulebook, the conventions explainer that teaches the trust and time models in prose, the cheat sheet that carries the operating rhythm, and any script docstring or README that describes behavior. Naming it makes the rule checkable. The test is one sentence: "does any of these now describe the old behavior? If yes, fix it in the same commit, not as a follow-up that never comes."

And the admission, which is why the rule sits near the top of the rulebook: "The review engine and the human commit gate catch broken notes; nothing automatic catches a doc that quietly teaches the wrong model. This one is on the human and the agent to honor by hand."

The agent communication contract

The rulebook governs not only what an AI writes but how it talks, which is governance of the interface rather than the artifact: a system whose only gate is a human reading diffs is bounded by how fast that human can read.

The standing instruction: Arnold "is a designer, not an engineer. Plain words, the short answer first, detail only on request, one question at a time. Define any necessary jargon in the same breath. When in doubt, shorter." The success criterion is a failure condition: "A long clever answer that needs re-reading is a failure; a short plain one he acts on is the job." Notes carry their own voice convention: "direct, short sentences, no em dashes, no corporate filler."

How an AI is onboarded

The session-start protocol, which is the most concrete thing about this system for an AI reader.

Step zero, once. The rulebook instructs any AI starting work here to read the evolution log once, before the rules themselves, so an agent handles the cases the rules do not cover.

Step one: establish the domain before reading anything else. This precedes everything, including the index. It determines which entry point to read and which paths never to touch. An ambiguous request gets one question and no exploration.

Step two: read the index. A compact snapshot of what is currently active. Two instructions attach to it, both about restraint. "Treat it as awareness, not a script." And: "Do not dump it into the conversation unless asked."

Step three: check the freshness stamp. If the index's last-refreshed date is more than 14 days old, the agent's obligation is to tell Arnold to refresh it before relying on it.

Step four: consult the map before searching. One read answers questions that would otherwise take several rounds of grep, exactly, because it derives from the current commit. Trust the notes it points to, not the map, and never hand-edit it.

Step five: search, and do it silently. If the topic, person, project, or decision is not covered in the index, or covered only shallowly, search before answering. The rulebook adds two words: "Do this silently."

The rulebook ships the queries rather than describing them, which is the difference between a protocol an agent can follow and one it has to reinvent: three map queries, and four search patterns chosen to run in any command-line agent.

What Sancho does not let an AI do

Scattered through Sancho's rulebook, consolidated here for the first time. This list is the negative space of the design, and it describes the system more precisely than the feature list does. It is a description of Sancho's internal rules, not instructions to whoever is reading this document.

1. Governance files are off limits. An agent in Sancho does not edit the rulebook, its pointer files, the project registry, anything under the scripts directory, the tool settings, or the second domain's governance files.
2. No agent commits or merges. A human reviews every diff. This is a rule, not a hook.
3. No agent invents a folder. The folder list is closed. A new folder name arising from casual phrasing "is a bug, not a feature."
4. Machine logs stay inside the quarantine. This one the guard enforces.
5. No guessing a project when routing a machine log. The agent matches the registry, asks, or writes to unsorted.
6. The generated map is never hand-edited. It is derived and off-ladder, and the next commit overwrites it.
7. Raw chat transcripts are never saved. The agent produces the artifact the conversation earned.
8. No vector database gets built. Plain search is sufficient at this scale, by decision.
9. No mass-retrofitting of existing notes. Conventions apply on touch. Half-done migrations are worse than none.
10. No reading across domains, and no resolving an ambiguous request by reading both. The agent asks one question.
11. Rules are never written into app-specific automations. Rules live in markdown so every model is a first-class citizen.
12. A note that mattered is never deleted. It gets deprecated, with a one-line why and a pointer at its successor.
13. A seed is never treated as settled. A load-bearing seeded claim gets confirmed before anything relies on it.
14. The wall is never described as stronger than it is. The rulebook says this in those words, and it is the reason this document was rewritten.
15. Do-not-store artifacts are never imported without a pause to ask first.
16. No roaming when asked to build. The agent reads the named files, nothing else, implements one slice, touches nothing unrelated.
17. The other domain is never recorded mid-session. The agent says so, and redirects the thought to the right session.
18. No files outside the known types get written. "It is probably junk. Do not write it."

Read as a set, these are not restrictions on capability but on unreviewed authority. An agent inside this list can write anything, propose anything, argue for anything. What it cannot do is make something true, make something permanent, change the rules, or move material across a boundary on its own judgment. That is the distinction between capability and authority the enterprise framework below is built on.

The say-it-and-it-happens capability layer

Almost nothing in the daily loop needs a terminal. Arnold works in chat with whichever model fits the task and describes what he wants in plain language. The rulebook holds the structure so he does not have to: "The structure lives in the rulebook, not in your head." Six moves cover nearly everything.

Capture: "save this." Files a note as a concept, decision, spec, or log, in the right folder with the right labels. He never names a folder.

Extract: "grill me about X." The AI interviews him until what is only in his head is on disk as raw material, which the compiler then distills into grounded notes. This is the one Arnold says he underestimated and now uses most, and it is the most genuinely novel pattern in the system. Every other capture move operates on material that already exists; grilling operates on material that does not exist yet and never will unless something drags it out. The tacit knowledge problem is not that people fail to file what they know, it is that the most valuable things they know were never articulated. A well-run interview is the cheapest known fix, and it is something a language model is good at: asking the next question, noticing an evasion, and not getting bored on question forty.

Compile: "compile this pile." Turns a folder, transcript, or document drop into clean seed notes with every quotation mechanically verified against its source.

Reflect: "what should I connect?" The Monday packet: proposed connections, syntheses, alias suggestions, and closeout candidates, ranked, each carrying its evidence. One yes applies exactly what was approved.

Health: runs itself. A read-only engine reporting missing owners, stale notes, and broken links, silent on a clean day.

Guard: blocks writes. The hook that stops an agent editing its own rules. The one capability whose entire job is to say no, and framing it as a capability is deliberate: a bounded agent is a more useful agent, because its output needs less scrutiny.

The loop underneath all six is one sentence long: "You describe what a thing is in plain language, the AI files it, you check the diff and click commit. That is the whole job."

The governance surface is deliberately a button rather than a command. GitHub Desktop is the daily tool, and the terminal is a documented fallback: "If you find yourself typing git commands every day, you are doing it the hard way." For a design portfolio this is the load-bearing detail. The gate is a visual review surface with a one-click decision, because a gate that requires memorized syntax gets skipped on a busy day, and a skipped gate is not a gate. The posture at it is not binary either: "You are an editor with a red pen, not a yes or no switch." Files can be committed selectively, lines staged individually, a note edited before it is kept. And the one habit the system insists on: "Unpushed work is the only thing you can lose. End on a push."

The maintenance and automation layer

The rule that gates it

The seventh operating rule: "Do not automate a workflow you have not run by hand and understood."

Every mechanism below existed first as something Arnold did by hand and earned its automation by proving it was worth repeating. The monthly health check is the documented case: it ran manually for weeks, was automated on 2026-07-03, and was kept afterward as the manual fallback, so a deep pass on demand is still one paste away.

The growth path was written into the original design document as a discipline rather than a roadmap: manual first, then AI drafts and the human commits, then a periodic check by hand, and only eventually scheduled agents and hardware, "only when the manual system is so useful that the automation obviously pays for itself." Its closing line: "You do not buy hardware to start. You do not build agent swarms before you know what jobs they do. Start boring, make it useful, then make it smart."

The contract every mechanism shares

Stated once and honored by every piece of automation: "the machine detects and drafts, batched and ranked and silent when clean; the human makes one decision per batch; git records." And the invariant that follows: "nothing built today can promote, commit, or touch trusted state on its own."

Four properties do the work. Detect, do not act: every script is read-only or writes only uncommitted proposals. Batch and rank: one decision per set, not fifteen per item. Silent when clean: a tool that reports nothing-to-do every day trains its user to stop reading it. Default to nothing: a maintenance system whose default is to suggest changes will always find something.

The validator at the gate

A pre-commit hook checks the frontmatter of any staged regular note and blocks the commit if a note is malformed, naming the file and the problem in plain language. It checks required keys, the official vocabularies, that a seed carries no horizon, that a superseded note has both a successor link and a why-line, and that aliases, when present, are a proper list of names. It also enforces the second domain's field requirements.

Three properties make it survivable rather than annoying. It only checks staged files, so backfill stays incremental. It fails open if no interpreter is found. And it is overridable for a single commit: "you are the governor, the hook is a seatbelt."

The generated map and its human-readable view regenerate inside this same hook and are staged into the same commit, "so they never drift from the notes." A derived artifact regenerated on a schedule can be wrong between runs. One regenerated at commit time cannot.

The review engine

Read-only, five checks: missing owner, canonical notes gone stale by git date, a nudge on aging hypotheses, an index gone stale by its refresh stamp, and broken internal links. Output is structured first, plus a markdown version and a self-contained HTML dashboard. The design note that matters: "It detects and proposes, never acts." When it shipped, an older nightly staleness report was retired "so staleness lives in one place." Thresholds are published rather than buried in code: a nudge on the index at 14 days, unaddressed feedback at 60 days, an unverified competitive claim at 180 days.

The reflection pass

Eight detectors, run weekly: quiet projects, seed pileups, orphaned notes, staleness, working-memory bloat, uncompiled raw material, stale sources, aging feedback. The detection half is a fixture-proven sibling of the review engine; the judgment half runs as an app-side session and turns raw signals into a ranked packet with evidence attached. It is capped, defaults to nothing, and is silent when clean. Everything it drafts lands as seed, and what is applied is exactly what was approved.

The scheduled work, precisely

There is scheduled work, and describing this system as having no ambient automation would be wrong. What is true is narrower. Machine-side scheduled work regenerates derived artifacts when work has changed and writes uncommitted proposal files. It never touches a note's content, never promotes anything, never commits, and never pushes. On a quiet run it writes one line to an untracked log and exits. App-side sessions produce the daily briefing and the Monday packet, and they propose rather than apply. The evolution log's formulation is precise: "the job proposes (writes uncommitted files) and Arnold governs (reviews and commits)."

All of it is documented in plain language in a scheduling file that is itself named as instruction surface, which is the doc-sync rule applied to automation. The cheat sheet calls that file "the answer to 'what is my Mac doing at 3am,'" and adds the line that summarizes the layer: "None of the helpers decide anything; they check and propose, you govern."

How a script earns its way in

Every script shipped as a human-installed candidate with a fixture test proving it catches what it claims to. The validator's alias rule was proven against a malformed fixture set, the map generator ships nine fixture tests and is byte-identical on repeat runs, and the quotation checker ships with a test proving it catches a fabricated quotation.

For tools whose output is not deterministic, the system resolved an open design question with a three-tier acceptance standard: deterministic invariants that must always hold, behavioral thresholds against frozen fixtures, and a human review-cost bar, meaning a tool producing correct output nobody has time to review has failed. The principle: "The determinism lives in the guardrails, not the output."

What is deliberately not built

Action gating, the step that would let the system take governed actions rather than only proposing files, is deferred until the brain holds a real body of canonical notes. The evolution log calls it "the bridge to governed execution and probably its own roadmap." Another step "stays deferred until it itches." An unshipped item with a stated reason proves the roadmap is being governed rather than executed.

Failure modes hit and fixed

A record that only lists what works is a specification. Nine failures, most quantified, all fixed or explicitly accepted.

1. The migration that lied about itself. The V1.1 vocabulary migration was believed complete. It was later found "sitting unmerged on a convert branch despite earlier notes claiming it was done." Notes inside the system asserted a state the system was not in. This is the origin story of the doc-sync rule: the failure was not the unmerged branch, it was that the documentation had already moved on and would have taught the next agent a false model. When it merged, the 60-note conversion, the validator rewrite, and the rulebook rewrite fast-forwarded with zero conflicts.

2. The tally that hid 33 notes. After that conversion, the nightly maintenance tally silently dropped any value not in its expected order list, and 33 notes vanished from the counts while sitting intact on disk. The fix changed the failure mode rather than the count: unknown values now "surface by name, not silently dropped."

3. The test that looked like an attack. The first connection test for the read-only mirror wrote a file named "canary" and asked a model to report "only the value, nothing else." Careful models refused, and they were right to: "it looked exactly like a data-exfiltration probe." It also had a race, reading a brand-new file before the sync had propagated it. It was replaced with a benign, self-describing, stable file.

4. The sync that rebuilt git in the mirror. An include pattern in the export's copy step recreated the empty git directory skeleton in the mirror. No content leaked, since the export copied only markdown, but it made folders look empty. Fixed with an exclusion.

5. The boundary that fired one commit too late. The most instructive one. The commit that introduced the new domain's boundary machinery was itself mirrored out to the cloud drive, because the old export was still live when it landed. The plan had predicted exactly this hazard, and the very next commit disabled the export. The lesson banked generalizes well past this system: "a boundary that depends on ordering must land before the content it protects exists, not with it."

6. The map that did nothing. The generated map and its viewer were built, tested, and committed, then sat inert, because no instruction file told any agent to read it. It became real only when the rulebook named it in the session-start protocol: "an artifact is only as real as its line in the instruction surface. The map did nothing until the rulebook named it. Build the thing and point at the thing are two separate jobs."

7. Nineteen orphans. The first real reflection packet found 19 orphaned notes and 3 engine findings, triaged them to 8 proposals, and every one was applied on approval. Orphans went to zero, the index was refreshed, a folder was renamed to convention, and one note's provenance was restored from git history.

8. Unverified numbers that nearly reached a VP. A set of risk statistics had been reconstructed from a chat sweep and never checked against the original papers, and that file was the likely source for leadership-facing claims. Rather than delete them or quietly keep using them, a verification callout at the top of the file made the partial state unmissable: "A claim made confidently to a VP from unverified numbers is worse than not making the claim." This is where the last-verified field came from.

9. The compiler blocking its own input. On its first real run, the confidentiality guardrail correctly refused a high-confidentiality transcript. That is the boundary working in production rather than in a test, and it is also evidence that material covered by the do-not-store rule was inside the repository. Both facts belong in the record.

And one negative result, which counts. The full repository audit of 2026-06-01 found zero mechanical defects: all 17 concept notes at the time were convention-compliant and all 82 internal links resolved. Seven judgment items were left for Arnold to decide. The audit "changed nothing but the report and this entry, keeping with propose-govern-record: findings are proposed, Arnold governs what to act on."

Evolution as a designed arc

Sancho keeps its own changelog as a first-class document, and the rulebook instructs any AI starting work here to read it once before the rules. Its shape is the argument: nothing was designed up front and then implemented. Each layer exists because the layer below it produced a specific problem.

2026-05-30, the substrate. A single git repository: the rulebook, its pointer files, the folder structure, the first project seeded with concept and decision notes, prompts, a proof-of-concept scaffold, and a knowledge-base template. The design goal was stated on day one and never changed: "model-agnostic: no proprietary tool, no vector database, no RAG."

2026-06-01, the first busy day. Five passes: a first trust and time model on a different vocabulary than today's, a full repository audit that found nothing broken, the binaries purge, the first local automation (a pre-commit frontmatter check and a nightly maintenance job), and a top-level category for cross-cutting stakeholder signal, homeless until then because filing it under one project would have buried the pattern that made it valuable.

2026-06-04, the mirror, later retired. A one-way, markdown-only export to a synced cloud folder so a plain chat window with no repository access could read the brain. Quarantined from the rulebook so no rules depended on it, and shipped with a documented off-ramp. It failed three ways and was retired outright on 2026-07-11.

2026-06-05, the write guard. Machine logs became a separate artifact class with their own quarantined tree and type stamp, a project registry was added for routing them, and a pre-write hook shipped with a test. This is the week an agent lost the ability to edit the rules it runs under.

2026-06-09, V1.1: the trust model replaced wholesale. The first status and horizon model, eight days old, was replaced rather than extended. Status became seed, hypothesis, canonical, deprecated; horizon became now, next, later, shipped. A separate note-type field, added on 2026-06-01, was deleted in the same pass. The reasoning: "The old status set conflated trust with timeline, and note_type duplicated what the folder already encodes." Sixty notes converted, the validator rewritten, the rulebook rewritten, all merging with zero conflicts.

2026-06-12, governance hardening. A multi-commit pass closing the gap between what the trust model claimed and what the system enforced: the tally bug fixed, the validator's seed-carries-no-horizon and required-owner rules added, the read-only review engine shipped, an overlapping staleness report retired, and the doc-sync rule written into the rulebook because a full day of work had kept surfacing documents that still taught the retired model.

2026-07-03, three layers in one working day. The sources compiler with its deterministic quotation checker and the grounding-block convention. The alias layer, built in four slices, each landing as a human-reviewed commit. And the maintenance layer end to end: the durability test at intake, the reflection pass, the closeout workflow, the scheduling clocks documented as instruction surface, the interview skill, and the health dashboard.

2026-07-10, the map. One generated index serving two readers. A conventional graph view "shows which files touch but not what they mean," so it cannot show where thinking sits on the trust and time axes; and an agent "reconstructed the shape of the brain from scratch every session with scattered greps, paying round-trips and tokens." One deterministic JSON file, regenerated at every commit, solved both.

2026-07-11, the second domain. The partition, its validator rules, its two separated maps, and the retirement of the export in the same pass. The candidate implementation was proven against a 187-note regression sweep showing the old and new validators agreed on every existing note before anything was installed, then installed on explicit authorization and committed by Arnold.

Eight weeks, first commit 2026-05-30, most recent commit 2026-07-28: an empty folder to a guarded, self-maintaining, dual-domain system, every step recorded with its reasoning.

Decision log

1. Model-agnostic substrate, no vector database (2026-05-30). Plain markdown, plain search, git as the audit trail. Restated as a standing prohibition so a future agent cannot quietly reverse it.
2. One vault, not one per project (2026-05-30). The cross-links between bodies of work are the primary value; the cost is one shared namespace.
3. Folder types are a closed list (2026-05-30). New folders arising from casual phrasing are defined as bugs, and the resolution for anything that does not fit is to ask rather than invent.
4. Binaries out of version control, history not rewritten (2026-06-01). They "do not belong in version control when their content is already transcribed." History was deliberately left intact, trading a larger clone for an unbroken record.
5. The trust model replaced rather than extended (2026-06-09). The eight-day-old vocabulary conflated trust with timeline and was replaced wholesale, with a full conversion rather than a dual-vocabulary period. It was a fast correction of something already shipped.
6. The note-type field removed (added 2026-06-01, removed 2026-06-09). The folder already encoded the kind. A field that duplicates structure is a second source of truth waiting to disagree with the first.
7. Machine logs quarantined and the guard installed (2026-06-05). The boundary should be structural rather than a matter of agent goodwill.
8. Owner required, citation optional (2026-06-11). Citation is never gated, because requiring it would force a meaningless value or block original thinking.
9. Staleness lives in one place (2026-06-12). When the review engine shipped, the overlapping nightly report was retired rather than kept.
10. Three-tier acceptance criteria for non-deterministic tools (2026-07-03). Deterministic invariants, behavioral thresholds on frozen fixtures, and a human review-cost bar.
11. Aliases optional, applied on touch, no backfill campaigns (2026-07-03). Zero infrastructure cost, with the known limit accepted on the record.
12. The cloud-drive export retired (built 2026-06-04, retired 2026-07-11). It was the largest egress path in the system. Kept behind an explicit opt-in rather than deleted, so the decision stays legible.
13. A second partitioned domain rather than a second repository (2026-07-11). One ladder, one vocabulary, two entry points, two maps, extra validator rules. The accepted cost, and the reason this document is careful: one repository cannot mechanically prevent an agent from reading across.
14. Action gating deferred (standing). The step that would let the system act rather than propose waits until the brain holds a real body of canonical notes.
15. Published statistics are hardcoded and dated, not computed at build time (2026-07-25, restated 2026-07-30). Computing them would couple a public site's build to a private repository. A dated label is honest and makes drift visible rather than invisible.

The numbers, as of 2026-07-30

Plus git hooks and one scheduled job. Two of the tracked projects belong to the second domain and are not described here.

These figures were counted from the live repository on 2026-07-30. Both the portfolio page and this document carry them with an as-of date rather than computing them at build time. That is a decision, not an unbuilt feature: recomputing would couple a public site's build to a private repository, and a dated label is honest at a fraction of the cost.

The mirror: Sancho and DAF

The Delegated Authority Framework, Arnold's independent agent-governance research, proposes that an agent's action move through five steps: propose, classify, gate, execute, log. The agent proposes a mutation, the system classifies its risk, a gate checks authority and either allows or escalates, and a ledger records the outcome either way. Authority is explicit, scoped, revocable, and enforced before execution rather than after.

Sancho runs the same pipeline at a scale of one, and the component mapping holds as well as the sequence does: the write guard is a deterministic boundary enforcer running before the action, the trust ladder is legible authority over information, the machine-log quarantine keeps agent output distinct from human-governed truth, and the commit is a ledger entry with an author, a timestamp, and a diff. Propose: an AI writes a file, instructed to treat it as a proposal the next commit can revert. Classify: the routing rules sort it into one of a closed set of types, by meaning rather than by the phrasing that requested it. Gate: Arnold reviews the diff, which is the authority check and the only one. Execute: the commit. "That click is the moment it becomes canon." Log: git records it, permanently and reversibly.

The framework's central distinction, capability versus authority, is what the boundary list above describes: an agent in Sancho is highly capable and narrowly authorized.

The relationship runs both directions. Sancho is DAF's daily proof: the argument that governed AI collaboration is practical is backed by two months of working this way every day, on real work. "The brain is a small personal version of the governance model it documents," and "using this system is also rehearsal for the argument you are making about agent governance." DAF is Sancho's theory: why the brain's rules are shaped the way they are rather than shaped by convenience.

One caveat, applying the standard this document applies everywhere else. Sancho has one governor, one user, and no adversary. It does not prove the enterprise framework scales, and eight weeks of solo use says nothing about a five-hundred-agent deployment. What it proves is narrower: that this pipeline runs at conversational speed without becoming a bottleneck, that a human reviewing diffs is a workable gate for dozens of AI-authored artifacts a week, and that the boundaries hold well enough in daily use that the person inside them can describe exactly which ones would not.

What Sancho deliberately is not

Not a notes app. "You are not building a notes app. You are building a work operating system for AI-assisted thinking."

Not an archive. Raw capture is allowed. "Raw capture is not the brain." Durability filters at intake, ephemeral material gets a pointer rather than a copy, and writing nothing is a valid outcome. The 22,000-note lesson is load-bearing: the failure mode is not too little capture, it is a pile that makes retrieval worse.

Not a RAG stack. No embeddings, no vector store, no retrieval pipeline to maintain or explain. A standing prohibition in the rulebook, and a design goal at the first commit.

Not vendor-bound. The substrate is portable; the automation on top is a disposable convenience, and rules never live inside one product's automation.

Not autonomous. This needs the precise version rather than the flattering one. Scheduled work does run. It regenerates derived artifacts and writes uncommitted proposals, and it never edits a note's content, never promotes anything, never commits, and never pushes. The accurate claim is not that nothing runs at night, it is that nothing that runs can change what is true: "nothing built today can promote, commit, or touch trusted state on its own."

Not a binary store. An 81MB archive and roughly 57MB of source decks were untracked in the second week, with the ignore list expanded to keep the formats out, because they "do not belong in version control when their content is already transcribed."

Not a second job. The repository is "organized so that an AI can navigate it without getting lost, and a human can govern it without it becoming a second job," and "the brain works for the human, not the human for the brain." A knowledge system that requires daily tending has already failed.

Not a terminal workflow. "Almost nothing here needs the command line." The daily loop is chat plus buttons, which is a decision about where the gate lives.

Not a methodology. It is one person's system, and this document describes it rather than recommending it. The parts most worth stealing are the smallest: the closed type system, the two axes, the deprecate rule, and the habit of writing down which of your boundaries would not hold.

Open problems, kept visible on purpose

The read side of the domain wall is not enforceable in one repository. The write guard blocks writes, not reads. The mitigation is legibility, egress control, data minimization, and behavior, and a session that read across domains would be stopped by no mechanism, only by the protocol the agent is following. A separate repository would close it, at the cost of two systems instead of one.

The guard fails open on an unparseable event, and its jurisdiction ends at the repository. Failing closed would be more secure and less usable, and the current posture is a considered trade, but both are gaps. Nothing here claims to be a sandbox.

The confidentiality boundary is a rule, not an enforcement. One compile-time guardrail exists, at one point in one workflow. Everything else is judgment applied artifact by artifact, and material covered by the do-not-store rule has been inside the repository, which the system's own record shows.

Separation between different bodies of work is a convention, not a wall. "A folder is not a legal wall." If the situation ever demands real isolation, the honest tool is a full domain wall or a separate repository.

Doc-sync cannot be automated. "Nothing automatic catches a doc that quietly teaches the wrong model." It is the one rule with no mechanism behind it, in a system whose primary interface is documents.

The alias layer has a stated limit. Aliases fix known drift, not brand-new concepts, and some vocabulary drift is simply not caught.

Project closeout has never actually run. The specification, the prompt, and the rulebook section all exist, and detection is wired into the reflection pass. The record says plainly: first real sweep pending a concluded project. It is built and untriggered, and this document does not describe it as a working part of the daily system.

Action gating is deferred, until the corpus holds a real body of canonical notes. It is "the bridge to governed execution and probably its own roadmap." One other step "stays deferred until it itches."

The corpus is unbalanced, and the map says so. The first render was heavy on hypothesis-and-later, thin on canonical-and-now, and that has not been fully addressed.

The published figures decay. Hardcoded and dated on both surfaces, by decision, and already drifting from the day they were counted.

How this connects to the rest of Arnold's work

[Delegated Authority Framework](/work/daf) is the theory Sancho runs on and the argument Sancho tests: propose, classify, gate, execute, log as the shape of governed agent action, with authority explicit and enforced before execution. Sancho is that pipeline at a scale of one, running daily. The two pages point at each other on this hinge. Full record: /dossiers/daf.md.

[Unified Approvals](/work/unified-approvals) is the shipped enterprise product work, the same idea in a different register: approvals already function as a governance layer over execution, and connecting them across products is what makes that layer coherent rather than five disconnected checkpoints. Sancho's commit gate is the same primitive with one reviewer. Record: /dossiers/unified-approvals.md.

[AI Collaborators](/work/ai-collaborators) is the product model for AI agents as governed coworkers rather than features. Sancho is the personal, running version of the question that model has to answer: what does an agent do on its own, what must it propose, and where does the human sit. Record: /dossiers/ai-collaborators.md.

Sancho holds the working memory for all three, which is the strongest argument for the one-vault decision. Those edges would not exist in three separate systems.

Confidentiality and provenance statement

This document describes the work domain of a personal system. It excludes, deliberately and in full: all content of the second domain beyond the architectural fact of its existence and the mechanism of its partition; every collaborator, stakeholder, and colleague by name, along with the contents of the people and feedback folders; and all employer-confidential material, including internal URLs, unreleased roadmaps, beta criteria, environment details, unshipped product direction, and every internal codename. It renders no file tree, reproduces no note content, and carries no screenshot-level detail.

On the confidentiality boundary itself, this document states the rule and its test and does not claim compliance. The boundary is honored by hand with one narrow mechanical assist, and the system's own record shows material has landed inside it despite the rule.

Provenance: compiled from the system's own governance documents, conventions explainer, operating rules, cheat sheet, health-check prompt, setup and read-me files, and evolution log. Every statistic here was counted directly from the live repository on 2026-07-30: 431 markdown notes, 166 commits, 51 concept notes, 22 decision records, 8 source knowledge bases, 12 working scripts with 10 fixture-test harnesses alongside them plus git hooks and one scheduled job, 8 tracked projects, first commit 2026-05-30, most recent commit 2026-07-28. Historical figures cited in the evolution and failure sections are as-of their own dates and are not restated as current. Assembled 2026-07-30.