Set and enforce boundaries

A boundary is not what the work must do, and not what counts as correct. It is what a change may reach. The three are separate, and a boundary states the worst a change reaches. A boundary blocks, and what bends instead of blocking is the concern of Guidance is no guarantee.

The boundary is drawn against what the change was traced to reach, not against the specification and not from memory. The specification names what the work must do; the trace names what the work touches, and the two lists differ. The boundary is declared before the work is claimed, so it is checkable against everything else in flight.

Enforcement belongs at the weakest tier that holds. The tiers, in order:

• Structural. A permission never granted, a directory the agent cannot leave, a tool it does not hold.
• Write-point refusal. A check that runs before the action and refuses it.
• Preflight. The local gate before anything leaves the machine, where type checks and linters run.
• CI gates. Required checks that block the merge.
• Human review. The change a person reads before it ships.

The ladder is an ordered preference. Passing every tier is not the aim.

A change that reaches outside its declared boundary, and a boundary declared after the work is claimed, are violations. A boundary held only by a written rule, where a tier that refuses the action is available, is a violation.

Inspection

Trace what our last few changes were allowed to touch against what they actually touched, and show me what would have stopped one that went further.

Held this, or broke it? Say which principle and what happened — tell me at /contact, subject Principles. What moves a band is somebody else's experience, and I'll publish what moved and who moved it.