#Why This Method Exists
Agents can write anything anywhere. 76 scripts with no registry. Self-declared roles without approval. Features in the wrong directory. The system grows by accretion because nothing gates changes. This method provides the gate -- scoped to the domain, proportional to the tier.
The method is the same process at every tier. Only the authority and the weight of review change. A constitutional amendment and a script addition go through the same five steps -- the difference is who approves and how carefully.
In the constitutional ledger (architecture/33), this method becomes structural: every change is a ledger entry that requires a governance proof (ontology/13, G4). Until the ledger exists, this method is the convention that agents follow.
#The Process
Five steps, same as every method in HAAK (methods/11-five-step).
1. Propose. The agent writes what they want to change and why. For Tier 1-2: a dispatch message to the authority. For Tier 3-4: the agent proceeds but documents the change in a board post or commit message.
2. Scope. Identify the domain (policies/08-domain-authority.md). Look up the authority and tier. If the change spans multiple domains, the highest tier governs.
3. Review. The authority (and any required reviewers) evaluate the proposal:
- Does it conform to the ontology? (Ontologist reviews, if applicable)
- Does it conform to the architecture? (Architect reviews, if applicable)
- Does it conflict with existing policies? (Authority checks)
- Is it necessary? (Authority judges)
For Tier 1: all checks are mandatory. For Tier 2: architectural check mandatory, ontological check if relevant. For Tier 3-4: review is at authority's discretion.
4. Decide. The authority approves, rejects, or requests amendment. For Tier 1, Zach's approval is required explicitly. For Tier 2+, the role authority decides.
5. Register. The change is made. The commit message or board post records: what changed, who approved it, which domain, which tier. This is the audit trail. In the ledger model, this step produces a ledger entry with a governance proof.
#Ontological Grounding
A change review is a governance situation (ontology/13, G1). The actors are the proposer and the authority. The method is the review process. The materials are the proposed changes. The domain is the scope being changed. The proof (G4) is the authority's approval. This is not bureaucracy -- it is the same governance model that the constitutional ledger enforces mechanically, practiced as a convention until the mechanism exists.
#When to Skip
Not every change needs formal review. The method is proportional:
- Fixing a typo in a project file: Tier 3, no review needed.
- Adding a board post: not a change to the system, just coordination. No review.
- Writing a new architecture doc: Tier 2, architect proposes, Zach approves if significant.
- Modifying the constitution: Tier 1, full review, Zach approves explicitly.
- Adding a new script: Tier 4, steward authority, document in scripts/index.md.
The rule: if the change could affect how other agents work, it needs review at the appropriate tier. If it only affects your own domain, proceed.
haak method -- 47 -- change review -- 2026-03-17 -- designed by Lina (architect, session architect-new). The gate that grows with the system: convention now, constitutional enforcement later.
Methods 47 — Change Review — 2026 — Zachary F. Mainen / HAAK