The charter schema says what a valid charter looks like. The formation process says how a model should create the first charter set responsibly.

Why the process matters

Gator’s value comes not only from the final charter files, but from the inquiry the process imposes on the model while it creates them. The process exists to force architectural inquiry before coding acceleration.

The model is not supposed to

  • skim a few files
  • invent a plausible architecture summary
  • start coding from generic priors

The model is supposed to

  • establish ownership context
  • scan for existing knowledge
  • identify real module boundaries
  • extract ownership and negative space from the code
  • identify cross-cutting invariants and tripwires
  • compress those findings into a small, usable map

The formation process

The nine formation steps in three phases Three boxes from left to right, joined by arrows. Phase one, Context, steps 1 to 3: establish ownership, scan for existing knowledge, understand the project. Phase two, The map, steps 4 to 6: identify module boundaries, form charters from the code, add Owns and Does Not Own. Phase three, Cross-cutting, steps 7 to 9: find tripwires and patterns, build INDEX.md, verify. Under the boxes: the model proposes, the Architect decides. Context STEPS 1–3 Ownership Existing knowledge The project The map STEPS 4–6 Module boundaries Charters from code Owns / Does Not Own Cross-cutting STEPS 7–9 Tripwires and patterns INDEX.md Verify The model proposes the map; the Architect decides whether it is good enough to begin governed coding.
Figure 1 — the formation process, step by step, groups into three phases.
  1. Establish ownership context. Before forming a knowledge layer, determine whether this is a solo repository or a team repository, who the Architect is, and where individual context belongs. Primary reference: reference-notes/identity-and-ownership.md.
  2. Scan for existing knowledge. Before inventing a map from scratch, inspect the repository for architectural knowledge that already exists: top-level architecture or design documents, ADRs, module README files, existing AI instruction files, and legacy knowledge systems. The goal is to find what can seed mission.md, roadmap.md, the module charters, the cross-cutting charter, and threads for prior decisions.
  3. Understand the project. Before writing charters, understand what the project is, what problem it solves, what the current priorities are, and how the code is roughly organized. This step populates mission.md and roadmap.md.
  4. Identify module boundaries. The unit is not “one file, one charter.” The unit is a logical domain: a package or directory with a coherent responsibility, a cluster of files that change together, or a subsystem with its own external dependencies or data model.
  5. Form charter skeletons from the code. For each boundary, read the actual code. Enumerate the important public functions and classes, and document what they do, what they read and write, and their callers and callees. If intent is unclear, ask the Architect or mark the uncertainty explicitly.
  6. Add ownership and negative space. Every charter must include ## Owns and ## Does Not Own. The model is not just describing what exists. It is identifying which responsibilities belong here, which belong elsewhere, and which plausible assumptions must be denied explicitly.
  7. Identify tripwires and cross-cutting patterns. Look for architectural truths that are not local to one function or file: multi-module data flows, invariants that span several code paths, synchronized implementations, “looks wrong but is intentional” patterns, and places where a model would otherwise normalize away a deliberate design choice. These belong in the cross-cutting charter, labelled clearly as TRIPWIRE or Pattern.
  8. Build the dispatch table. Write charters/INDEX.md. It turns the charter set into a navigable governance surface by answering one question: if you are changing X, which charters must you read first?
  9. Verify structurally. Check that every major module is covered, that INDEX.md and a cross-cutting charter exist, and that obvious coverage gaps are addressed. The process is not tool-owned: the model and the Architect still decide whether the charter set is good enough to begin governed coding.
The rule for step 5

Do not invent. Extract from the code.

Step 6

Does Not Own is load-bearing. Good engineering is not only knowing what a module does, but what it must not be responsible for.

Why this process is distinct

This is not just a documentation routine. It is a constrained architectural inquiry process. The model is asked to find boundaries, ownership, negative space, invariants and tripwires—not merely files, classes, functions and signatures.

The schema says what a valid charter artifact looks like. This process says how the initial charter set should be created. The two stay separate on purpose.

Documents involved in bootstrap

The local bootstrap is driven mainly by gator-start-up.md, reference-notes/identity-and-ownership.md, reference-notes/example-project.md (density and tone), charters/README.md (notation, philosophy and anti-patterns), and, once normal governed work begins, the repository constitution. The Charter schema document, in this Docs list, defines the artifact itself.