Gating

Purpose

The platform's value is the autonomous stretch between two gates. A write is where that autonomy turns into consequence, so a write is the one action the platform never improvises: it is classified before it is planned, checked by an agent that did not write it, and confirmed by a gate whose kind follows from the classification.

§ 1 defines the gate set and when a gate may confirm itself. Trust and Data § 2 defines the grant that permits an operation at all. §§ 2–9 are the layer between them: which writes exist, which gate each one fires, which gates a person always answers, and how a write becomes approvable so that later instances of it confirm under policy (decision Vladimir, 03.09.2026 — D72).

P Gated write operations are allowed on every system the platform reaches. What decides the gate is not the system and not the module — it is the write's class.

1. The gate set — the human decision points

A gate is a persisted decision requirement. A person answers unless an explicitly approved policy is eligible for it. This table is the canonical, complete gate-kind list: H1–H7, Hd, HW-approve, HW-instance, HW-shared, HW-irreversible, HW-ddl, H5-SIM, H5-send, CG-11 and publish. The set is platform-wide; each module declares where in its stage set each gate fires (Requirements Register G-6). Between gates the agents work alone.

Properties of every gate P:

• Parent-agent confirmation never substitutes for a gate (CR-2); a gate is answered by its authorised person or an eligible recorded policy.
• Each gate decision is an audit record carrying its scope — what was approved, against which plan revision and which artifact. A material change to payload, environment, or preconditions invalidates the approval and re-opens the gate.
• Approval is a permission, not a second person: whoever answers a gate must hold the role for that gate and that target (Trust and Data § 3). An operator who holds it approves their own case; one who does not sees the gate become a task for those who do.

P The gate plan per module, and where auto-confirm is allowed (decision Vladimir, 02.09.2026 — D70). Every gate below is defined; the last column is where a human is always required versus where the platform may confirm by policy:

P Writes have their own gate protocol on top of this table (decision Vladimir, 03.09.2026 — D72): every write is classified by effect class × target class into one of seven write classes; the two scoped-and-working classes are the initial candidates for auto-confirm, and then only as an instance of a write shape a person approved at the new HW-approve gate; the shared-row, irreversible, DDL, customer-facing and customer-visible classes are the always-human gate set at the current stage, and that set shrinks only when the organisation accepts a named risk class in a recorded decision — never by a policy widening itself (D76). A deploy to QA is H4 plus the write auditor because QA is not customer-facing; STAGING/TEST and PROD stay H4 plus H5 (D114). An isolated write auditor checks every packet for exactness, boundedness, reversibility and scope before any gate sees it (D73). One revert suspends the shape for every case type.

P Auto-confirm is configured per case type × gate × target class (gates.auto_confirm, Whitelabel Catalogue) and fires only when the nine conditions of § 9.4 pass in order. An auto-confirmed gate writes the same GATE_DECISIONS record with the policy id as the actor — indistinguishable in kind, attributable in fact. The metric is the correction/rollback rate on auto-confirmed gates; one revert on an auto-confirmed decision suspends the shape pending review.

1b. Diagram states

P Every stage diagram of the wiki draws a step in one of four states, defined here and nowhere else (decision Vladimir, 04.09.2026 — D148):

• A person decides — a gate of the table above. Drawn amber; a diamond where the node is the gate itself.
• A signed result — a step whose result is proven by the stage's own test or verification and recorded as evidence: a plan step matched against the write log with its assertion re-run green and the stage skill passing (Configuration Module § 7.4 items 1–2); green gates per repository with the pipeline result as S4 evidence (Stage Test and Corrections); the runtime verification of which commit serves (Stage Deploy and Reversal, D114); the customer's symptom re-checked on the customer's surface (Stage Application and Verification § 2). Drawn green.
• A person decides on a signed result — the tests are green and a person confirms what they prove: H3 on every sign-out, signed by the operator and, where the phase is the one they accept, by the Customer representative (Configuration Module § 1b); CG-11 on the joint proof. Drawn in the two colours.
• After the workflow, asynchronous — a step the customer-facing working flow does not wait for: precipitation, which runs when the working stages end and does not wait for the customer's closure (Stage Precipitation, D49), with its consolidation pass on schedule (Agents Memory and Skills); the platform's learn step. The requested delivery outcome excludes only this ancillary consolidation, not a requested deployment. Drawn violet and dashed, reached by a dotted edge labelled after the workflow; the gates it carries are named in its label.

The four classDef lines are pasted verbatim into every module diagram, and no other class name is used for a state:

classDef human  fill:#e8a33d,stroke:#7a5210,color:#1a1a1a
classDef signed fill:#d9f2e6,stroke:#b7e2cb,color:#047857
classDef both   fill:#f1ecd6,stroke:#d6cfa8,color:#b45309
classDef after  fill:#f4f1fc,stroke:#5b3fa8,color:#5b3fa8,stroke-dasharray:5 3

2. A write is classified before it is planned

P Every plan step that writes carries two labels. Neither is a judgement made at execution time; both are set when the plan is written and are shown in the gate packet.

Effect class — what undoes it (Failure and Recovery § 2): transactional (rollback undoes it) · compensable (a teardown action undoes it) · irreversible (nothing undoes it) · DDL (auto-committed; undone by re-applying the pre-apply snapshot).

Target class — who else can see it:

P A step whose target class cannot be established is not writable. "I believe this row is only used by this product" is not an establishment; the shared-row check is a query, and the estate prober answers it with counts (Components — Configuration § 3).

3. The write classes and the gate each one fires

P Effect and target traits produce a set of requirements. W1–W7 are stable reporting labels, not mutually exclusive permissions. The stored WRITE_CLASS is the primary label; every applicable gate is enforced.

P The five never rows are the always-human gate set at the current stage. Together with H5-SIM (production simulation), H7 (reversal), Hd (module handover), CG-11 (the customer's acceptance) and publish, they are the list of decisions no policy takes today.

P The set shrinks only by an accepted risk class, never by drift (decision Vladimir, 03.09.2026 — D76). Autonomous production self-service is the target state, and it is reached one write class at a time: the organisation accepts a named risk class, per case type and per target, in a recorded decision; that class then moves from never to auto-confirmable under an approved shape, with every other condition of § 5 still required and the suspension rule of § 7 unchanged. The platform never moves a class itself, and no ordinary configuration value can: a human records the organisational decision in RISK_ACCEPTANCES with its decision reference; no acceptance is seeded. The runtime rechecks it at dispatch.

Why W3 is on the list and W1 is not. The blast radius of a scoped write is one object the case already owns; the blast radius of a shared row is every product that reads it, and the case cannot see them. F The estate makes this concrete: a message key with no product prefix lets a new product silently inherit another product's wording, and one shared rate file feeds every version that consumes it (Product Configurator Requirements § 03, § 04).

3.1 Checkpoints and effect requirements compose

P Checkpoints concern a workflow decision: H1 scope, H2 route/plan, H3 result, H4 script set, H6 dead end, Hd handover, CG-11 acceptance and publish. Effect requirements concern what an operation does: HW-instance, HW-shared, HW-irreversible, HW-ddl, H5, H5-send and H5-SIM. H7 decides compensation; its operation still carries the applicable effect requirements. These are two dimensions, not new gate ids.

P Derive requirements from capability and preflight. Add HW-ddl for DDL, HW-irreversible for an irreversible effect, HW-shared for shared targets, H5 for a customer-facing environment, and H5-send for a customer-visible send. Add HW-instance for scoped transactional/compensable working operations. Multiple flags produce multiple requirements. Shared DDL on PROD requires HW-ddl + HW-shared + H5; H4 substitutes for none of them.

P The legacy primary WRITE_CLASS precedence is W5 (DDL), W4 (irreversible), W7 (send), W3 (shared), W6 (customer-facing), W2 (compensable working), W1 (transactional working). Keep every target trait in the packet. A compensable external operation must additionally declare whether its target is scoped working, shared or customer-facing; external alone is not a bounded target and fails closed.

P One packet may carry several GATES rows. A single click can answer their complete set only when the caller holds all roles; append one decision per requirement. Otherwise show the remaining role's task. All decisions bind the same revision/hash; a change invalidates the dependent set. Splitting a decision the same person can make once need not create another queue.

P Roles and accepted risk are permissions, not staffing assumptions. Development placement, publication, acceptance and production simulation retain their separately declared human authority; write-shape graduation does not lift them.

4. Shape approval — the gate that makes auto-confirm possible

P The new gate kind is HW-approve, and it approves a write shape, never a single statement. It is answered by a holder of the Approver role for the target class, and it executes nothing.

A write shape is a versioned row in SRD_SUPPORT carrying:

P Approving a shape makes future instances of it auto-confirmable in the classes where § 3 permits it. It does not approve any instance. It does not widen a grant. An instance still needs a grant that covers its environment, system and target (Trust and Data § 2).

P A shape is versioned and immutable once approved; a changed template is a new shape needing its own approval — the rule the estate already applies to published prompts (Agent Framework § 6.4).

P A shape expires (decision Vladimir, 04.09.2026 — D133, closing A-9). Approval stamps a default expiry from policy (writes.shape_expiry_default, P90D); an expired shape is treated as suspended: its instances fall back to instance confirmation (§ 5) and the auditor refuses auto-confirm. The approver who holds the role for the target class may extend once, by at most one day (writes.shape_extension_max, P1D — enforced by the WRITE_SHAPES guard, Data Model § 3); a shape that needs longer is re-approved as a new version, which is the moment its template, counts and teardown are read again. The extension is a ledger record (SHAPE_STATE with action: extended) naming who extended and until when, so the one-day grace never becomes a silent renewal.

5. Instance confirmation

P An instance of an approved shape auto-confirms when all of the following hold. Any one failing makes it an ordinary gate in the inbox of the role holders.

1. The shape is approved, not suspended, and its version is the one that was approved.
2. Every applicable effect requirement is covered by an unwithdrawn risk acceptance for this customer, case type, gate and target. No production acceptance is implied.
3. The nine conditions of § 9.4 hold, in order — among them the write auditor's pass (§ 6) and the preflight immediately before execution, which runs at application time and not at approval time wherever stale state could change the effect (Trust and Data § 2).

P An auto-confirmed instance writes the same GATE_DECISIONS record with the policy identifier as the actor, plus the shape id and version — indistinguishable in kind from a person's decision, attributable in fact (Architecture § 3.2).

6. The write auditor — the agent that says a write may proceed

P A dedicated, isolated platform profile whose only job is to confirm that a write packet is exact, bounded and revertable (decision Vladimir, 03.09.2026 — D73). It is the counterpart of the mechanism verifier: that one checks whether the reasoning is right, this one checks whether the operation is safe to execute. Neither may be skipped by the agent that wrote the thing it checks.

Profile: platform.write_auditor — a sub-agent, catalogued in Agents § 1.

Denied context. The author's transcript, reasoning and identity. Evidence source, environment and object provenance remain present. It receives only: the write packet, the approved shape and its version, the case's grants, and read access to the target under those grants. It cannot write anything, cannot spawn, and cannot widen its own scope (Agents § 0.2).

P The four checks. Each returns pass or refuse, and a refusal names the check, the item that failed and the evidence for it.

P The exactness check is the one that exists because of vagueness, and it is deliberately unforgiving. A packet that is almost precise is refused, not repaired: the auditor does not correct the author's work, because a checker that fixes what it checks stops being a check. It returns the failing item to the stage agent, which re-plans.

P Tiering. The auditor is mandatory for every W1–W5 instance and for every packet that reaches an H5 or H5-send gate — that is, for every write the platform makes. Unlike the mechanism verifier it is not sampled: its cost is a bounded set of queries and a template comparison, not a re-derivation, so the argument for sampling does not apply.

P Its verdict is part of the gate packet, and a person answering a gate sees it. A pass does not authorize anything on its own; a refusal blocks the instance whatever the gate would have said.

Why an agent and not a rule in the executor. Checks 1 and 3 are judgements about language and derivation — whether a step is stated exactly, and whether a teardown really inverts a write — and no schema expresses them. Checks 2 and 4 are mechanical and are additionally enforced in the connector, which refuses out-of-scope operations before contact (Trust and Data § 2); the auditor runs them earlier so that the refusal arrives as a planning result rather than a failed call.

7. Suspension

P One revert on an auto-confirmed instance suspends the shape, not merely the policy row that permitted it: every case type loses auto-confirm for that shape until a person re-approves it at HW-approve. The suspension is a ledger event, an entry in the exception queue and one of the platform's minimum alerts (Software Architecture § 10.5).

P A refusal on a malformed draft is a planning failure. A refusal on an instance claiming to match an approved shape suspends that shape and resets its clean-instance count (§ 9.3). An unrelated business refusal does not pretend to disprove the template. The metric that watches this page is the pair: auditor refusals per hundred instances, and reverts per hundred auto-confirmed instances (Metrics).

8. What this settles per module

P The staged write-identity path is unchanged and now has a matching gate protocol: stage 1 executes under the existing privileged identity with a person in the loop; stage 2 under a least-privilege platform identity per environment; stage 3 lets only explicitly risk-accepted shape instances confirm by policy (Trust and Data § 3, D65).

9. The architecture of gating

P The sections above say which writes are gated and who may answer. This one says how gating is built — what the agent must produce, what the service stores and binds, how a write shape earns the right to confirm without a person, and what the runtime evaluates on every instance.

9.1 On the agent side — what must exist before a gate may be asked

P A stage agent cannot ask a human anything. It produces a packet and hands it upward; only the module root reaches a person (Agents). The packet is closed-form, and the auditor (§ 6) rejects it otherwise:

P The agent is denied the means to skip the gate, not merely instructed not to: it holds no write connector. The platform.write_executor holds it, and the executor refuses any packet without a draft or approved shape and an auditor pass — so an agent that "decides" to write simply has nothing to write with (Agents § 0.2).

P An agent may not widen its own ask. Changing anything in the packet changes its hash, and a changed hash re-opens the gate instead of reusing the decision. P What the agent is told back is the decision, its scope and the grant — never who decided it, so no route and no retry depends on a person's identity.

9.2 On the backend side — where a gate lives and what binds it

P A gate is a row, not a message. The service owns it; the interface renders it; the agent waits on it.

P Escalation is a timer on the row, configured per SLA class: notify the holders of the role, then the administrator, and draft the customer-facing status meanwhile — a gate with no available holder is a defined state, not a stall (PG-12).

9.3 How a shape earns auto-confirm — the training path

P A write shape is not born trusted; it is observed, then approved, then accepted, and any one of five events sends it back to the beginning.

P What returns a shape to stage 1, immediately and without discussion: one revert on an instance of it; one auditor refusal on a matching instance; a red eval set on any profile in its path; a change to the template; or the withdrawal of the accepted risk class. P The platform never promotes a shape itself and no configuration value can — promotion is a recorded human decision, which is the whole content of N-12.

P The measure is the correction and rollback rate on auto-confirmed instances, reported per module beside the count of instances that took the auto path (Metrics). A shape whose rate is not zero is suspended, not tuned.

9.4 Auto-confirm at runtime — the ordered check

P For a write, evaluate these in order. Failure returns the named condition to the role holder; it never weakens a requirement.

1. Every applicable requirement has an unwithdrawn RISK_ACCEPTANCES record for customer × module × case type × gate × target, with the organisation's decision reference.
2. The exact shape version is approved, not suspended, and inside its expiry/extension.
3. All target traits, including customer-facing and shared, are covered by those acceptances. There is no unconditional production exclusion and no implicit production approval.
4. Every effect, including irreversible and DDL, is covered; standing human-only checkpoints still need their person.
5. The packet is complete and its semantic hash matches the decisions.
6. Relevant profiles, skills and handlers have passing evaluations for their pinned versions.
7. The task is within its active-execution budget and technical limits.
8. The isolated auditor passed this packet; it cannot override deterministic validation.
9. Fresh preflight, current grant authority, impact-key claims and the task fence permit dispatch.

P An auto-confirmed write records the policy version, shape id/version and matching risk-acceptance references in the decision scope. The connector still needs a bound, expiring grant. Ordinary policy editing cannot manufacture risk acceptance.

P Non-write checkpoints have their own predicate. Support H1 classification is automatic by design and records its classification-policy version; an operator correction creates a revision. It is not a write shape and does not wait for three database writes. Other non-write checkpoints remain human until an approved gate-policy version names the schema, case types, evaluation criteria and no-open-question condition. Their decision names that policy without inventing a SHAPE_ID. Development placement, CG-11, publish and H5-SIM retain their separately declared authority. An H1/H3 assigned to the customer is answered on the existing client confirmation card; the assignment comes from trusted case policy, not the model.

P Agent Runtime § 5 is the execution procedure and proposal-hash definition. The proposed schema makes these decisions representable; it seeds no accepted risk and grants no live authority.

Challenges

• C The first shape catalogue: which write shapes the five largest support families and the five configuration stages need, and how many of them a single template covers. Built on the first ten cases of each module.
• C Whether check 2 can always re-derive the affected set cheaply — for a statement over a large table the re-derivation is a count query, but for a multi-statement block it is a set of them; the budget for the auditor is a per-profile ceiling (Agents § 0.1).
• P Whether an approved shape should expire on a schedule the way a grant does, or only on suspension and re-approval — answered 04.09.2026 (D133, A-9): on a schedule, default P90D from approval, extendable once by the approver by at most one day; the write-shape contract carries the two timestamps (Contracts § 1 row 5). Open in its place: whether P90D is the right default — measured on the first shape catalogue by how many shapes are re-approved unchanged.