Invariants and defaults

The rules split into two kinds and only the first kind binds the orchestrator. [78] Invariants are few and they concern proof. [165] No seat can override an invariant, and the Foreman seat is no exception. [78]

  1. 1. No human approval, wait, or form in any pipeline path. The customer accepts the risk and the machine decides from evidence. [98]

  2. 2. Evidence comes only from check runs in fresh containers. A lane report or reply is never evidence. [78]

  3. 3. The verifier lab differs from every builder lab on the item under judgment. A seat that shares a builder lab is refused. [67]

  4. 4. Frozen tests change only by a reissue from the tests lane. The reissue needs recorded evidence that the test asserted a wrong fact. [s63]

  5. 5. No seat invents a table, an id, or a placeholder record. The design source of truth is amended first. [s06b]

  6. 6. The owner boundaries hold: no git push, no cloud resources, no new spend, and nothing destructive. Credentials stay per seat and the engine never reads them. [79]

  7. 7. Gate decisions are computed from evidence rows by the gate policy. No seat can assert a verdict. [99]

The defaults rule

Each other rule is a default, not a binding rule. [78] The orchestrator may override a default with a recorded decision. [78] The record must state the reason for the override. [102]

A recorded override is a lawful input to the gate policy. [78] A panel can read the override and refute it like any other record. [176] Assignments, lap limits, and rosters are defaults of this kind. [78]

The orchestrator may change how work is done. [165] The orchestrator may never change what counts as proof. [165]