Model the constraint first, then pick the machinery.

Call it a reliability band: the range of agent output an organization will accept without a human reading every line. A wide band is cheap to run and expensive to trust. A narrow one costs a gate at every seam, and the gates are the budget. Nobody argues about the band directly, so the merge queue settles it one pull request at a time.

Constraint engineering is my name for the work of holding that band. Making a model correct is not the goal, because nobody is offering that. The goal is to constrain the model at several layers, with a different strategy at each. You stop tightening when the output lands inside the band often enough to be worth the tokens.

Push the business analogy one step further, because it predicts the failure. A risk framework dies two ways. People who cannot see the work own the controls, or people who can see it handle the exceptions quietly. Both have exact analogues in a harness, and section 22 covers the role that prevents them.

Start with the test that separates the two levels. Change your agent SDK tomorrow. If your rules survive the change, you have a model. If you rewrite them, you had machinery and called it a design. That is the whole distinction, and it costs a migration to learn the slow way.

The conceptual level answers four questions, and none of them mentions a process or a queue. What is the thing? What attributes does it carry? What is its consistency boundary? How does it change, and who may change it? Answer those and the runner becomes an implementation detail. Skip them and the runner becomes the design.

One more placement, because it decides who is in the room. This domain sits where DevOps sits. It spans development and platform, and it belongs to neither alone. DevOps merged two roles that could not hold a deployment between them. Constraint engineering merges the same two roles, because neither of them can hold a reliability band alone. Section 17 splits the work into sub-disciplines, and section 22 says what each side sees and what each side misses.

flowchart TD
  M["the model · constraint · layer · rung · policy · verdict · family · context · identity"]
  A["a coding agent CLI · charter files, hooks, skills"]
  B["an SDK loop you wrote · predicates in front of every call"]
  C["a delivery pipeline · stages, gates, records"]
  M --> A
  M --> B
  M --> C
  N["swap any runner and the model is unchanged"]
  C --- N
  class M pass
  class A warn
  class B warn
  class C warn
  class N dim

The model in one picture

Below is the whole model as a graph, and every later section is one region of it. Read the arrows as relationships rather than as flow. Section 23 defines each term once, so treat that section as the dictionary and this diagram as the map.

One loop in the graph carries more weight than the rest. Firings and hatch uses become evidence, evidence argues for a move, and a move changes the rung that produces the firings. Cut that loop and the model still looks complete, and it stops learning anything.

flowchart TB
  CON["constraint · the entity"]
  LAYER["layer · whose rule"]
  RUNG["rung · what carries it"]
  POLICY["policy · what happens"]
  VERDICT["verdict · who decides"]
  PRED["predicate · the decision procedure"]
  ESC["escape hatch · the sanctioned deviation"]
  CAP["capability · what the agent can do"]
  SET["setting · budgets and caps"]
  STATE["state · memory and context"]
  EVID["evidence · counts, records, evals"]
  MOVE["promotion or demotion · a pull request"]
  HUMAN["a human"]
  CONTRACT["contract · what was asked"]
  CTX["charter · harness · factory"]

  CON -- "owned by" --> LAYER
  CON -- "carried at" --> RUNG
  CON -- "acts by" --> POLICY
  CON -- "decided by" --> VERDICT
  CON -- "asks" --> PRED
  CON -- "waived by" --> ESC
  RUNG -- "lives in one of" --> CTX
  VERDICT -- "inferential asks a model, deterministic asks" --> PRED
  POLICY -- "ask routes to" --> HUMAN
  CAP -- "withheld at rung 1, so it becomes" --> CON
  SET -- "bounds the turn and the job" --> CTX
  STATE -- "unowned, it becomes a rule nobody wrote" --> CON
  RUNG -- "firings counted as" --> EVID
  ESC -- "uses counted as" --> EVID
  CONTRACT -- "graded against" --> EVID
  HUMAN -- "amends" --> CONTRACT
  EVID -- "argues for" --> MOVE
  MOVE -- "approved by" --> HUMAN
  MOVE -- "changes" --> RUNG
  class CON block
  class RUNG warn
  class VERDICT warn
  class POLICY pass
  class PRED pass
  class EVID pass
  class MOVE block
  class HUMAN warn
  class LAYER dim
  class ESC dim
  class CAP dim
  class SET dim
  class STATE dim
  class CONTRACT dim
  class CTX dim

The mapping, because the problems are not new

I reach for domain-driven design here because I had the machinery working and still could not say what a rule was. The vocabulary is not the point, and section 5 borrows a second frame for a second reason. Use the mapping to test your model, then throw the words away.

Non-goals
Not an argument that you should adopt domain-driven design.
Not a claim that agent work is a domain the way billing is a domain.
Not a layered architecture, and not a diagram of your services.

---
description: A broad except says what it is swallowing and why
why: A gate that fails silently on its own bug stops the factory invisibly.
paths: ["workers/**"]
layer: team              # whose rule. Ships with the harness, not the repo
rung: [3d, 4d]          # what carries it. Two boundaries, not two strictnesses
policy: refuse          # what happens. refuse | ask | warn
verdict: deterministic   # who decides. A predicate, not a judge
locked: false            # may a project override it, or only deviate visibly
predicate: predicates/name_the_swallow.py
escape: swallow-ok
---

The four attributes answer different questions, and confusing any two causes a specific failure. Layer says who ships the rule and who may change it. Rung says which mechanism refuses. Policy says whether a firing stops the work, parks it for a human, or only leaves a record. Verdict says whether a model judged the case or code settled it.

I shipped the layer field and then read it nowhere for months. For that whole time a company standard and one repository's local opinion were the same kind of object. So the harness was something you copied rather than something you shared, which is a modeling bug rather than a coding one.

Policy deserves one note, because people leave that attribute out. A rule set to ask parks the call and puts a human in the loop. It is honest only at a rung that can hold a call rather than veto it. If your mechanism can only say no, ask becomes a rule that refuses in silence, which is worse than either option.

Verdict is the attribute I added last, and section 5 is where it earns its place. Read it now as a plain fact about the mechanism. Either a model read the work and judged, or code read it and settled. Those two fail in different ways, so the record has to keep them apart.

flowchart TD
  F["factory · delivery · stage · gate · guard · ordering · record"]
  H["harness · development · prompt · tool · policy · budget · context · phase"]
  C["charter · project · rule · hook · skill · command · agent · predicate"]
  F -- "hands in its own delivery rules" --> H
  H -- "reads what the repository declares" --> C
  C -- "cannot reach upward" --> X["a charter that configured the harness would be a repo governing the fleet"]
  class F block
  class H warn
  class C pass
  class X dim

The direction matters more than the contents. The factory knows about the harness, and the harness must not know about the factory. Point that arrow both ways and the harness stops running on its own. A developer can then no longer ask the only question they have: what do my charter and my rules do to a turn?

That question makes a harness a product rather than a subsystem. Someone working in a repository wants to run one turn, see which rules fired, and see what it cost. They do not want a queue, a worktree or a pull request. If your design cannot serve that, developers build their own, and you get two harnesses that disagree.

What each context owns

Those change frequencies are a diagnostic, not a schedule. Proposals should thin out with distance from the project's own code. Most of what goes wrong is something the repository wanted and never said. So a cycle producing three factory changes and no charter ones tells you the distribution is wrong, not that the factory needs work.

Two of those families cause most of the confusion. A capability and a constraint look alike in a config file, because both are entries in a list. They differ in what happens when you remove the entry. Remove a capability and the agent can do less. Remove a constraint and the agent can do more.

State, which is the family people model last

Memory is the primitive teams reach for first and design last. A fact the system remembers becomes a constraint nobody wrote down. It shapes every later turn, and it has no layer, no owner, no review and no expiry. The default worth holding is derive, don't remember: rebuild what you need from the work record and the repository.

When you do need memory, give it what every other primitive has. A layer, so someone owns it. A scope, so it cannot govern work it never saw. An expiry or a re-derivation, so it cannot outlive the thing it described. Memory without those three is drift with a good reputation.

Context is the other half of this family, and the trade is direct. You pay for everything in the window on every turn, and it crowds out the rules that matter. Section 20 counts that cost as one of the five kinds of rot.

Every step on either chain moves work out of the model's reading and into something that runs the same way each time. Prose is a suggestion the model interprets, and a predicate is code it cannot argue with. A skill file is text the model may read, ignore or contradict. At the other end sits a tool server, which is a process in another language that answers a schema.

So name the axis once and use it twice: how much of this can the model reinterpret? On the constraint chain that reads as reach and authority. On the capability chain it reads as encapsulation. The mechanism differs and the direction is identical.

The capability chain

The four rungs below run from open to hidden. A command hides nothing, and the model sees every word of it. A tool server hides everything except a schema, because it is a separate process that may not even share a language.

Knowledge and behavior, which is the split underneath

A capability carries two things: what the agent knows, and what the agent does. The chain moves weight from the first to the second. A command is knowledge with no behavior, and a tool server is behavior whose knowledge you never see. The middle two carry both, in different proportions, which is why they are the hard ones to place.

The table states the boundary, and the order of events is what makes it real. Watch what crosses back to the caller in each of the three cases below. A skill returns its whole text into the same context window. A sub-agent returns a summary of work the parent never saw.

sequenceDiagram
  participant P as the parent turn
  participant S as a skill
  participant A as a sub-agent
  participant T as a tool server
  P->>S: load it, because the description matched
  S-->>P: every word, into this same context window
  Note over P,S: nothing is hidden, and the context grew
  P->>A: a task, and the grant it is allowed
  Note over A: its own context window, which the parent never sees
  A-->>P: a summary
  P->>T: a call that matches the schema
  Note over T: another process, and possibly another language
  T-->>P: a result, and no implementation

flowchart TD
  subgraph CON["constraints · reach and authority"]
    direction TB
    A0["prose"] --> A1["hook"] --> A2["harness"] --> A3["factory"]
  end
  subgraph CAP["capabilities · encapsulation"]
    direction TB
    B0["command"] --> B1["skill"] --> B2["sub-agent"] --> B3["tool server"]
  end
  AX["the axis · how much the model can reinterpret · falling"]
  CON --- AX
  CAP --- AX
  class A0 dim
  class A1 warn
  class A2 pass
  class A3 block
  class B0 dim
  class B1 warn
  class B2 pass
  class B3 block
  class AX dim

The object-orientation mapping, which is exact in one place

Knowledge and behavior bundled together, with the internals hidden, is the oldest idea in object orientation. The mapping is close enough to be useful, and the places it fails are worth more than the places it fits.

Three things break, and each one has a known answer. Read the table below as the design work that the analogy hands you rather than as a reason to drop it. An object you cannot trust to return the same answer twice is still an object. It just needs different tools around it.

Two words carry this section. A verdict is inferential when a model reads the work and judges it. A verdict is deterministic when code reads the work and settles it. An inferential rung can decide what no predicate can express. It costs tokens, and it can be wrong twice, by missing a violation and by inventing one.

Cross the two verdicts with the three contexts and you get the six rungs. The numbering keeps faith with the ladder on my other pages. Rung 3 is now written 3d, and rung 4 is now written 4d. Nothing you already reference has moved.

Two rungs sit off the chain, and both stay off it for a reason. Rung 1 is the tool grant, and it withholds a whole capability rather than deciding a case. So a rule cannot move there and stay the same rule. Rung 5 is CI. It sits outside the process that produced the work, and outside the process that checked it. Move your rules there and you spend the one rung that can tell you the others are lying.

flowchart TD
  R0["0 · rule · prose the model reads"]
  R2["2 · hook · the repository's own file"]
  R3i["3i · harness inferential · a judging phase in the turn"]
  R3d["3d · harness deterministic · a predicate at every call"]
  R4i["4i · factory inferential · a review stage on finished work"]
  R4d["4d · factory deterministic · a gate on the diff and the publish"]
  R0 -- "recurs, and someone can name the case" --> R2
  R2 -- "other repositories need it too" --> R3i
  R3i -- "the judgment became a predicate" --> R3d
  R3d -- "the tree matters more than the call" --> R4i
  R4i -- "the reviewer keeps saying the same thing" --> R4d
  R4d -- "the gate fires on cases nobody meant" --> R4i
  R4i -- "the reviewer adds nothing the harness missed" --> R3d
  R3d -- "the predicate and the rule came apart" --> R3i
  R3i -- "only this repository ever cared" --> R2
  R2 -- "nobody can say why it exists" --> R0
  class R0 dim
  class R2 warn
  class R3i warn
  class R3d pass
  class R4i warn
  class R4d block

Why this order, and not some other

Each step does one of two things. It moves the rule further out of the agent's reach, or it makes the verdict more exact inside the same context. The second move is cheaper than the first, so take it first. Turning a judged rule into a predicate costs one function. Moving a rule from the harness to the factory costs a boundary and a new blind spot.

The reviewing phase was in my model for a long time as a capability, and I never noticed it was also a rung. That is why an older version of this page ended its promotion section with the line that undecidable rules stay prose forever. They do not. They stay undecidable, which is a different claim, and rungs 3i and 4i are where undecidable rules go.

The coverage grid, which is the same table read sideways

Six things exist for a rung to see, and no rung sees all six. Put your rungs in this grid and the empty column is the rule you believe you enforce and do not.

Rung 2 is the interesting cell, because a hook is charter content and mechanical at the same time. That mix makes it the cheapest mechanical rung to own, and the agent it governs can delete it. Every design decision about rung 2 follows from those two facts together.

Rung 3d taught me the reach lesson expensively. It used to sit inside three editing tools, so a turn writing through a shell heredoc walked straight past it. That happened twice in testing. It now sits in front of every call the model makes, including calls to tools nobody on my side wrote. That move is what makes reaching for stock tools safe.

No predicate had a bug, and tightening one would have fixed nothing. A rung watches a path, so ask of any rung whether the thing it governs has a second path. Ask before you tighten anything.

Section 5 gave a sub-agent its own context window, and that isolation is the point. It is also the problem, because a fresh context window starts without your charter. So ask three questions of every child turn. Does it see the rules? Does it inherit the grant? Which rung catches it when it breaks something?

Read the first and fifth rows together, because together they are the argument. Prose does not survive a context boundary, and a predicate mounted in the harness does. So a fleet that leans on rung 0 gets weaker with every level of fan-out. One that leans on rung 3d does not.

flowchart TB
  H["the harness · rung 3d mounted here, in front of every call"]
  P["the parent turn · charter loaded, rung 0 present"]
  C1["child turn · a fresh context window"]
  C2["child turn · a fresh context window"]
  H --> P
  P -- "task and grant, never the charter" --> C1
  P -- "task and grant, never the charter" --> C2
  H -- "every call, from any turn" --> C1
  H -- "every call, from any turn" --> C2
  C1 --> J["the join"]
  C2 --> J
  J --> G["rung 4d · grades the joined result, not each child"]
  class H pass
  class P warn
  class C1 block
  class C2 block
  class J dim
  class G warn

Counting, when there are many children

A rule mounted once still fires many times per job, so a per-job count hides which child broke it. Record the firing against the rung and the child that caused it. Otherwise a fan-out of twenty makes one badly briefed child look like a rule that fires constantly.

The identity of the rule does not change inside a child, and neither does its layer. Only the record needs the extra field. That is a small change, and skipping it is how a healthy fleet reports a rule as noisy.

A team standard restated in every repository is not a standard. It is a copy, and copies drift. So a shipped rule travels with the harness rather than with any repository, and its predicate travels beside it. Nobody shared a rule whose decision procedure has to exist in every repository it governs. They pasted it.

The same predicate then mounts at every rung that needs it. That means the repository's hook, the in-harness check, and the stage gate. Two implementations of one rule will disagree, and the agent finds the seam before you do. One function, several mounts, and a record of each firing against the rung that caught it.

When a repository disagrees

Here sits the only genuinely interesting decision in the model, and it is a domain decision rather than a technical one. A project declares a rule with the same identity as a shipped one. Who wins?

The order of events matters as much as the outcome, because the harness writes the record on the way through. Both branches below end with something written down. That is the property to keep if you take nothing else from this section.

sequenceDiagram
  participant H as the harness
  participant P as the project
  participant R as the record
  H->>H: load the shipped rule
  P->>H: declare a rule with the same identity
  alt the shipped rule is ordinary
    H->>H: the project rule wins
    H->>R: write the shipped layer onto the surviving rule
  else the shipped rule is locked
    H->>H: the shipped rule holds
    H->>R: write the attempt down as an override attempt
  end
  H-->>P: the surviving rule, and its collision record

The project wins by default, because a repository knows things the harness does not. A layering nobody could adapt locally gets routed around within a week. That repeats the risk-appetite argument. Nobody obeys a control with no sanctioned deviation. They evade it quietly, and then you lose the register too.

locked marks the floor of the band, and it stays deliberately rare. It names the rules an organization has closed to a project's judgment. Either way the surviving rule carries a record of the collision, because a standard replaced in silence is worse than both outcomes.

Those five apply one design decision five times. When the model cannot read what someone meant, prefer the visible failure over the quiet one. The same instinct makes a broken gate report itself and let the work through. Fail closed instead and it stops the pipeline for a reason nobody can see.

So count a broken predicate against its rule rather than only printing it. A gate that reports itself in prose nobody aggregates is how a rung rots while the table shows nothing. Counting separates a control from a control you can test.

The refusal is part of the design

What a rule says when it fires is a domain concern. People learn to route around a refusal that names no way out. A good refusal carries the rule's own words, its recorded reason, and its escape hatch. Then it says plainly that someone counts every use of that hatch.

The why field earns its place at one moment, years later. A rung whose reason nobody can reconstruct is enforcing institutional memory it does not have. Section 20 turns a missing why into a deletion signal for that reason.

Who checks the checks

Every gate here fails open on its own bug, which is the right trade and leaves one question unanswered. You cannot ask the gates whether the gates work. So at least one rung has to sit outside the process that produced the work, and outside the process that checked it.

That is the whole argument for keeping a rung in CI, or anywhere else the agent and the pipeline both cannot reach. It will be the quietest rung you own. It is also the only one that can tell you your other rungs have been reporting success into a void.

A model reading its charter and a model reading a poisoned file are doing one thing: turning tokens into behavior. Nothing in the context window is labeled trustworthy. So a sentence in an issue comment, a dependency README, a retrieved document or a tool result arrives with one standing. It is the standing of a rule you wrote and reviewed.

The verdict attribute makes this precise, which is the reason it is worth having. An inferential rung decides by reading, so anything that can be read can argue with it. A deterministic rung decides by running code, and code does not get persuaded.

The pattern is exact: every inferential rung is injectable, and every deterministic one is not. That is no coincidence. The thing that lets an inferential rung judge the undecidable is the same thing that lets an attacker address it.

The recursive version, which is the one to worry about

Section 5 called a skill's boundary a convention rather than a wall. Here is what that convention costs. If an agent can write to its own charter, its own skill files or its own rubric, then it can author rung 0. An attacker who reaches any of those files has not bypassed your rules. They have written new ones.

So treat the rule files, the skill files and the rubrics as code rather than as content. They get a review, they get an owner, and no turn writes them without a human merging it. That is the same containment argument as section 9, pointed at a different target.

Read the reaches column as the rungs a primitive can occupy, not as a rank. A tool server and a predicate are both good designs, and they answer different questions. The watch for column carries the failure I would look for first in a review.

Start with the shape of a turn, because the patterns are all edits to it. The model plans a call, a rung decides whether that call happens, the call runs, and the loop repeats until something stops it. Every harness pattern either changes what the model sees, changes which rung decides, or changes when the loop stops.

flowchart TB
  P["prompt · charter, contract, context"] --> M["the model plans a call"]
  M --> G1{"rung 1 · is the tool granted"}
  G1 -- "absent" --> M
  G1 -- "granted" --> G3{"rung 3d · does a predicate refuse"}
  G3 -- "refuse" --> B["the refusal · its words, its why, its hatch"]
  B --> M
  G3 -- "allow" --> T["the call runs"]
  T --> H["rung 2 · the repository hook"]
  H --> M
  M --> D["the work is done"]
  D --> J{"rung 3i · a judging phase reads it"}
  J -- "refuse" --> M
  J -- "pass" --> O["out of the harness"]
  class P dim
  class M warn
  class G1 pass
  class G3 pass
  class B block
  class T dim
  class H warn
  class D dim
  class J warn
  class O pass

Four of those rows are the same idea at different prices. Least privilege, the deterministic wrapper, the reviewer with no editor and structured output all remove the ability to express a violation. That is the cheapest enforcement in the model, and section 19 gives it a name.

The judging patterns need one warning that the table cannot carry. A model grading its own work shares every assumption that produced the work. So a judging rung earns its keep when it has a different prompt, a different context, or a published rubric. Give it none of those and you have bought agreement.

A factory is a pipeline with a record under it. Work arrives as a contract, gets an isolated place to happen, passes through stages, and stops at gates. What separates a factory from a script is the record: every stage writes what it did, so the counts in section 20 exist.

flowchart TB
  I["intake · a written contract"] --> W["a worktree, one per job"]
  W --> S1["plan"]
  S1 --> S2["build"]
  S2 --> S3["test"]
  S3 --> G3{"rung 4d · the stage gate"}
  G3 -- "refuse" --> R["retry, briefed with the gate's own words"]
  R --> S2
  G3 -- "pass" --> S4["review · rung 4i"]
  S4 -- "rework" --> R
  S4 -- "pass" --> HU["the human merge gate"]
  HU -- "merge" --> CI["rung 5 · CI, outside all of it"]
  HU -- "close" --> X["recorded, and not merged"]
  R -- "revision cap reached" --> PK["parked, and visible"]
  class I dim
  class W dim
  class S1 dim
  class S2 dim
  class S3 dim
  class G3 pass
  class R warn
  class S4 warn
  class HU block
  class CI block
  class X dim
  class PK block

Three of those rows exist only to make the rest measurable. The provenance record, the cost row and the sampling audit produce nothing a customer sees. They are also the difference between a factory you can tune and one you can only restart. So build them before you need them.

The sampling audit deserves the extra sentence, because it is the pattern that decays quietest. Nothing else in the list checks the gates themselves against reality. Set the fraction, name the owner, and put the number on the same dashboard as throughput.

A band means nothing without a statement of what was wanted. So the contract earns first-class status: written down, kept in version control, and never rewritten by the system working from it. Acceptance criteria belong there. A rule can say how to write code, and only the contract says whether this code was the point.

That gives evidence somewhere to attach. A claim of done is worth nothing alone, so demand the criteria and the proof that something exercised each one. A verdict with no command under it is unproven rather than done. Treat those two as the same and you will report a band as held.

Where a human can sit, and what each place costs

Twelve patterns, ordered by when they happen. The first four run inside the turn and are cheap and rare. The middle four run at delivery and cost a pass each. The last four are the ones that keep the whole apparatus honest, and they are the ones that decay when nobody owns them.

The first row is the one worth designing carefully, because it is where a human is cheapest and rarest. An agent that guesses on a contradiction produces confident work against a requirement nobody meant. An agent that asks about naming has turned a hatch into a habit, and you will stop reading the questions.

Keep the hatch narrow by design: contradictory requirements, a missing credential, a choice that destroys data, or a direction the contract did not authorise. The agent decides preferences, naming, and anything the codebase already answers, and it reports what it decided. A resumed turn then loses the hatch, because asking the same question twice is not asking.

The sequence below is the whole pattern, and the last arrow is the one people drop. A check that sees the contract without the amendment grades correct work as wrong. Build that arrow first, because the rest of the pattern is useless without it.

sequenceDiagram
  participant A as the agent
  participant F as the factory
  participant U as a human
  participant C as the contract
  participant V as every later check
  A->>F: blocked, and here is the contradiction
  F->>U: park the turn, and ask
  U-->>F: the answer
  F->>C: attach an amendment, and leave the contract untouched
  F-->>A: resume, and this time without the hatch
  A->>F: the finished work
  F->>V: the contract and the amendment, together
  Note over V: grade against both, or grade a withdrawn requirement

Placement follows blast radius, not annoyance

One axis decides more than any other, and almost nobody writes it down. How bad is it if this is wrong, and can you undo it? A constraint about formatting and a constraint about deleting production data are not the same kind of thing. No rung saves you if you placed them by how often they irritate you.

Irreversible actions deserve the expensive answers: withhold the capability, or ask a human. Reversible ones deserve the cheap answers: refuse and let the agent adapt, or record and look later. Sort by cost of being wrong before you sort by anything else.

Six of those are the same mistake wearing different clothes. The copied harness, two implementations, aggregate counting, the uncounted hatch, cost as an aggregate and the nameless rule share one missing thing. That thing is identity, and giving a constraint one stops five of the six from being possible.

The one that cost me most was the second path. Nothing looked wrong, no predicate had a bug, and the report stayed green while a turn wrote through a shell heredoc. An anti-pattern you can see in a report is not the dangerous kind.

Scope is the honest sort order, because it says what a change can affect. A prompt change reaches one call. A graph change reaches every job in flight. Sorting by team instead tells you who is in the meeting, and it tells you nothing about the blast radius.

flowchart TB
  A["one call · prompt"]
  B["one turn · context · tool · harness · memory"]
  C["between turns · loop"]
  D["many jobs · graph"]
  E["the fleet · governance"]
  A --> B --> C --> D --> E
  X["eval · security · cost"]
  X -- "cut across every scope above" --> A
  X --> C
  X --> E
  class A dim
  class B warn
  class C warn
  class D block
  class E block
  class X pass

Four of those carry most of the design weight, and they are the four I would name if someone asked what the job is. Context is what the model is told and what it costs to tell it. Harness is the mechanism that holds a single turn. Loop is what happens between turns. Graph is many turns and many agents, and where work waits.

The other seven are real and they are narrower. Prompt sits inside context, and tool and memory sit inside the harness. Above all of those sits governance. Eval, security and cost refuse to sit anywhere, because each of them is a question you ask at every scope.

Read the sits with column and the point of section 22 arrives early. Two of eleven sit with platform, one sits with development, and eight sit with both. A split that leaves eight shared disciplines is not a split. It is a standing meeting.

A session log holds the prompts and every tool call, with its arguments and its result. It also holds every refusal, the hook output, the phase boundaries, the tokens and the timings. That is the raw material for the entire evidence family. Nobody has to instrument anything new to start, which makes this the cheapest rung of the whole apparatus.

One warning before the table. The log format belongs to your runner, so this is the least portable part of the model. The signals below are stable and the parser you write is not, and I would keep that parser small for exactly that reason.

flowchart TB
  L["session logs · prompts, calls, refusals, hooks, tokens, spans"]
  X["a small parser · one row per event"]
  C["counts · per rung, per rule, per child, per job"]
  E["evals · a score over a fixed set"]
  J["the join · counts beside scores"]
  D["the decision matrix"]
  P["a proposal, as a pull request"]
  L --> X --> C
  E --> J
  C --> J
  J --> D --> P
  class L dim
  class X warn
  class C pass
  class E pass
  class J block
  class D block
  class P warn

The join, which is where the decision actually lives

Counts on their own are ambiguous. A rule that stopped firing might be a rule nobody needs, or a rung that went blind. Evals on their own are worse, because a score that moved tells you nothing about which rung moved it. Put them side by side and the four cases separate cleanly.

The top-right cell is the expensive one, because it looks exactly like the top-left in a report that shows only counts. A team watching firings alone reads a falling number as progress and demotes the rung that was protecting them. That is the argument for the join in one sentence.

A count belongs to a version of the predicate

A predicate that changed is a different classifier, so firings recorded under the old one are not evidence about the new one. Stamp every count with the predicate version. Then reset the variance measurement whenever that version changes, because a variance number averaged across two predicates describes neither.

The rule's identity survives the rewrite, which is what section 1 asks for. Its evidence does not, and the distinction is easy to miss because both live in the same row.

Test the predicate, not only the judge

A predicate is a classifier with a false positive rate and a false negative rate, and almost nobody measures either. Give it a fixture set: cases that must fire, and cases that must not. Run it in CI beside everything else.

This is the cheaper twin of a golden set, and the page has so far prescribed golden sets only for the inferential rungs. That is backwards. A deterministic rung is the easy one to test, so test it first and spend the expensive measurement on the judge.

Consequential means being wrong costs something, and costs it quietly. Recurrent means it has been broken more than once, by more than one person. Settleable means something can decide it without a person, and that is where the test forks. Code can settle "no float in the money module", because it is a predicate over a syntax tree. Only a reader can settle whether someone genuinely exercised a thing rather than claiming it.

So a rule that a machine cannot decide is not stuck at prose. It goes to an inferential rung, where a model reads the work and judges it. That costs tokens, and it buys a verdict nobody can reproduce. Rules that neither code nor a reader can settle stay prose and get an eval, which measures without refusing.

flowchart TB
  Q1{"is being wrong expensive, and quiet when it happens"}
  Q1 -- "no" --> P0["prose · rung 0"]
  Q1 -- "yes" --> Q2{"has more than one person broken it"}
  Q2 -- "no" --> P0
  Q2 -- "yes" --> Q3{"can the capability be withheld instead"}
  Q3 -- "yes" --> P1["withhold the tool · rung 1"]
  Q3 -- "no" --> Q4{"can code settle it"}
  Q4 -- "yes" --> Q5{"does it govern this repository only"}
  Q5 -- "yes" --> P2["the repository hook · rung 2"]
  Q5 -- "no" --> Q6{"does the check need the finished tree"}
  Q6 -- "no" --> P3d["a predicate at every call · rung 3d"]
  Q6 -- "yes" --> P4d["a stage gate · rung 4d"]
  Q4 -- "no" --> Q7{"can a model settle it during the turn"}
  Q7 -- "yes" --> P3i["a judging phase · rung 3i"]
  Q7 -- "no" --> Q8{"can a model settle it from the finished work"}
  Q8 -- "yes" --> P4i["a review stage · rung 4i"]
  Q8 -- "no" --> PE["prose, plus an eval · rung 0"]
  class P0 dim
  class P1 pass
  class P2 warn
  class P3d pass
  class P3i warn
  class P4i warn
  class P4d block
  class PE dim

What a promotion actually is

A promotion should be one field in one file, and nothing else. If moving a rule up means rewriting it, re-registering it, or touching code, promotion costs too much and nobody does it. Keep the rung next to the prose it enforces, so there is no second place to forget.

Two properties are worth stealing. First, a promotion is a proposal rather than an act: it opens a pull request and a human merges it. Second, promoting to a mechanical rung with no predicate and no rubric should produce a task instead. Writing that predicate is the actual work, and a rung without one looks enforced from the outside.

People reach for that first row last. Before you write a predicate, ask whether that phase could hold no such capability at all. A rule nothing can violate needs no gate, no escape hatch and no counting. That is the crossing where a capability becomes a constraint, and it is the best trade in the model.

Anything written down can rot, including the things written down to stop rot. It goes wrong in five distinguishable ways, and naming which one you have makes a count actionable. "Never fires and is six hundred words" and "nobody knows why this exists" look alike in a table and argue for different actions.

Variance is the kind the earlier version of this page could not name, because it only appears once you have inferential rungs. Measure it directly: run the same case through the judging rung several times and count the disagreements. A rung that cannot agree with itself is not enforcing a rule, and no amount of prompt work will hide that from a count.

Context debt hides for the opposite reason, which is that silence looks free. It is not. The harness loads charter content into every turn that touches what it is about. So you pay for a dead rule on all of them. It also dilutes the attention left for the rules that matter.

So a rule that never fires is a demotion if it still matters. It is a deletion if nobody can say why it is there. Those are different findings, and the difference is whether the recorded reason survives the evidence. Removal is half the work here rather than the failure case, and it is the half nobody does unprompted.

flowchart LR
  A["a rung fires, or a hatch is used"] --> B["the record counts it against that rung"]
  B --> C["the analysis pass reads counts, hatch use and variance"]
  C --> D["a proposal, as a pull request"]
  D --> E["a human merges it, or does not"]
  E --> F["the rule's rung, policy or verdict changes"]
  F --> A
  class A warn
  class B pass
  class C pass
  class D block
  class E warn
  class F block

Give the charter a fixed budget

Growth is the default, because every incident adds a line and nothing removes one. So set a size for the charter and hold it. When a new rule arrives and the budget is full, something else leaves, and the argument about which one is the useful part.

A budget converts an unbounded ratchet into a trade, and it puts deletion on the agenda without anyone needing to feel bad about it. It also stops the slowest failure in this whole design, which is a charter so long that nothing in it gets read.

Counting catches per rung, not per rule

Record every firing against the rung that caught it. Then "the in-harness check never catches this any more" stays a readable fact rather than vanishing into a rule-level total. When a backstop starts doing all the work, that tells you how turns are writing code. Ask why, not which rung to tighten.

Two rungs that fire on the same case earn their keep only as two boundaries. Two rungs that differ in how hard they push are redundancy, and they destroy your ability to tell which one works. Per-rung counting makes that distinction visible.

The strongest objection to all of this is that it is a lot of machinery for what began as a style guide. That objection is right about levels two and three, and wrong about level one. Level one is a schema and a habit, and it costs an afternoon.

I cannot tell you where that last crossover sits, and the reason is worth stating plainly. It depends on the width of your band, and section 0 already admitted that nobody has a number for the band. So the crossover is a judgment. Anyone handing you a threshold for it is guessing with more confidence than I have.

Four situations where you should not build this

One failure deserves naming on its own, because this page could cause it. An apparatus nobody maintains reports success into a void, which section 10 already warned about in a smaller way. A level three you cannot staff is worse than a level one you actually run, because it produces numbers that look like evidence.

The DevOps precedent is the argument, and it is worth stating carefully rather than as a slogan. Development and operations were split because deployment was somebody else's problem. They merged because a deployment that nobody owned end to end failed in the gap between them. That gap was invisible from either side. A reliability band fails in the same one.

So the disciplines cut across the org chart rather than along it. Whoever knows the repository writes the context, and whoever owns the budget pays for it. The loop stays a delivery concern until a revision limit throws away correct work, and then it belongs to everyone.

The two-way traffic is the point, and the layer attribute exists to carry it. Propose a local rule as a team rule once it keeps proving itself in one repository. Bring a shipped rule down when its escape hatch does all the work in three. Both moves are pull requests, and both need someone who sees the repository and the fleet at once.

What I would not let a system do on its own

Nothing in this model should apply itself. A proposal to change a rule becomes a task or a pull request, and it passes the same gate as any other work. A loop that rewrites its own constraints on its own authority is the one thing here that escapes the band it exists to hold.

I run the analysis pass by hand, and nothing schedules it. Call that a real gap rather than a design position, and the piece I would build next. A ratchet that someone inspects only when they remember is still a ratchet.

Take the model and rename all of it if your organization already has words for these things. What must not change is the count. Four attributes, three contexts, five families, two chains. Rename a term and the model survives, and merge two terms and it does not.

24.1 · Scope

This standard covers the conceptual design of agent constraints. It says what a constraint is and what it is made of. It also says which context holds it, which mechanism enforces it, and what evidence moves it. It applies to any system where a model produces work that a person did not read line by line.

Out of scope
Any specific framework, SDK, runner, queue or pipeline. The model is deliberately portable.
A number for the reliability band. Section 0 says why I will not invent one.
Model selection, prompt wording, and anything that changes with the next release.
Organizational structure. Section 22 argues for one role and does not draw your org chart.

24.2 · The rules

Twenty-nine rules, each traceable to the section that argues for it. Read them as the shortest form of this page. If you disagree with one, the section behind it is where the argument lives. That argument is the part I would rather you took.

1. Give every constraint an identity that survives a rewrite of its predicate, its prose and its rung.§ 1 · 9
2. Store layer, rung, policy and verdict as four fields. Never derive one from another.§ 2
3. Keep the dependency one way. The factory may know the harness, and the harness must not know the factory.§ 3
4. Place every component in exactly one family, and manage it with that family's lifecycle.§ 4
5. Move a capability up its own chain when the boundary must be enforced rather than respected.§ 5
6. Declare the tool grant on every sub-agent. Never inherit one, because forgetting widens the blast radius.§ 5
7. Never let an inferential rung be the last thing in front of an irreversible action.§ 5 · 15
8. Write the predicate once and mount it at every rung that needs it.§ 9
9. A predicate resolves against the tree it came from and may not leave it.§ 9
10. Keep the backstop when you promote. Two rungs are two boundaries, not two strictnesses.§ 6
11. Default every unreadable field to the visible failure, never to the quiet one.§ 10
12. Let the project win a collision unless the shipped rule is locked, and record either outcome.§ 9
13. A gate fails open on its own bug, and the breakage is counted against the rule.§ 10
14. Every constraint records a why, and loses its rung when that why no longer survives.§ 10 · 20
15. Keep at least one rung outside the process that produced the work and the process that checked it.§ 10
16. Record every firing against the rung that caught it, never only against the rule.§ 20
17. Count escape-hatch use per rule, and read a rising count as a demotion signal.§ 10 · 20
18. Measure variance at every inferential rung, by running one case several times.§ 20
19. Exclude the tool grant and CI from idle counts, by name, and say so in the report.§ 20
20. Give the charter a fixed size, so a new rule displaces an old one.§ 20
21. The authored contract is immutable, and an amendment travels to every later check.§ 15
22. Every promotion and demotion is a proposal a human merges. Nothing applies itself.§ 19 · 22
23. Put a deterministic rung under every rule whose violation would be a security incident.§ 11
24. Humans own the rule files, the skill files and the rubrics. No turn writes rung 0.§ 11
25. Two or more turns deep, carry what matters at rung 1, 2 or 3d. Prose does not cross a context boundary.§ 8
26. Partition the budget across children, and never copy it to each one.§ 8
27. Stamp every count with the predicate version, and reset variance when that version changes.§ 18
28. Give every predicate a fixture set: cases that must fire, and cases that must not.§ 18
29. Read counts beside eval scores, never alone. Only one of the four cases argues for a demotion.§ 18

24.3 · Conformance levels

Three levels, and each one subsumes the one below it. Most teams reach the first in an afternoon and never reach the third. Calling both of those conformant would make the word useless.

24.5 · How this standard changes

The counts are the stable part. Four attributes, three contexts, five families, two chains, and the rungs on each. Rename any term to match what your organization already says, and keep the counts. Merging two of them is what breaks the model.

This page changed once already in a way worth recording. It had three attributes and one chain, and it claimed that a rule a machine cannot decide stays prose forever. Verdict, the inferential rungs and the capability chain came from that being wrong. Assume the same will happen again, and treat a version of this that admits no error as the version to distrust.