Gated Permissions Process (GPP)

Status: working draft 0.19 · Date: 2026-10-16 · Epic: EP-B932453F · Backlog: BI-2C3B3AC9 Placement decision: DI-5E0B3CA09D27 (WWMD, high confidence). GPP is the fourth member of the standards family and owns the binding semantic only.

Build review implementation: an incomplete reviewer panel leaves its gate closed without rejecting the document or requesting a new human approval. Saved design and plan artifacts, completed semantic rounds and individual reviewer evidence survive the execution wait. The browser presents that wait as an incomplete review; recovery retains the existing authority boundaries. See the MCP recovery contract.

Abstract

The Gated Permissions Process (GPP) is a modeling standard for governing which tools an AI agent may reach, and under whose decision. It defines one modelled unit, the Gated Permission. A Gated Permission binds a decision gate in a named owning authority scope to a bounded set of tool capabilities, for a specific stage of a specific work shape, with stated evidence, validity and stop conditions.

GPP exists because neither of the two common ways to govern agent tool use holds up:

• Per-call approval asks a person to approve every tool call. People stop reading. One vendor reports that users approve 93–97% of prompts and catch a disguised dangerous command 13.6% of the time (see the market brief).
• Blanket approval (“YOLO” or skip-permission modes) approves nothing because it approves everything. The agent’s standing credentials become its authority, and the 2024–2026 incident record shows what follows (market brief §3).

GPP moves the human or governed decision to the place where it carries information: the decision that admits a class of tool use for a bounded piece of work. One decision, made by the right authority and recorded, authorizes many deterministic tool calls inside a declared envelope. Calls outside the envelope do not reach a human prompt. They are unreachable.

GPP does not enforce anything at runtime. TAK enforces. GAID identifies the actor and binds the receipt. TAK-JSI qualifies the actor. GPP supplies the model that tells each of them what the governed envelope is, and lets an assessor check that the model is complete, consistent and actually enforced.

1. Scope

This standard specifies:

• the Gated Permission binding and its required elements
• how bindings attach to work shapes, shape stages and Workrooms
• how a binding names its owning decision scope and gate
• a shared capability vocabulary that resolves to enforceable tool grants
• capability co-occurrence constraints
• reuse, expiry and revocation of a gate decision across the tool calls it admits
• completeness and consistency checks over a set of bindings
• evidence and efficacy measures for a GPP implementation
• an informative textual notation and a SysML v2 mapping

It applies to:

• AI coworkers inside a platform
• external coding agents and other clients reaching the platform through MCP or another tool protocol
• human-plus-agent Workrooms, finite or standing
• any work shape that can reach a side-effecting tool

It does not:

• define runtime mediation, effective-permission intersection, proposal mode or the default safety rule; TAK §7.2, §8.4 and §7.12.1 own those
• define agent identity, operating profiles or receipts; GAID owns those
• define job qualification; TAK-JSI owns that
• define the doctrine inside a decision scope (WWMD, WWWD, WSID or another implementation’s equivalent); the scope owner owns its doctrine
• prescribe a policy engine, a scoring algorithm or a model vendor
• claim that a complete model makes an agent safe; a model is evidence of intent, and enforcement evidence is separate (§11)

2. Conformance

An implementation conforms only if it satisfies every MUST for its claimed profile.

An implementation:

• MUST declare the supported GPP version and the highest profile claimed
• MUST NOT claim GPP-Enforced for a binding whose gate runs in shadow or advisory mode
• MUST NOT claim GPP-Evidenced from a model, a design or a test fixture alone

2.1 Versioning

A binding MUST carry a version. A change to its scope, gate, capability set, subject scope, validity or stop conditions is a material change and MUST produce a new version. A gate decision recorded against an earlier version MUST NOT authorize calls under a later one (§9.3).

2.1.1 Binding revision versus shape version

Work shapes are often pinned by the work that uses them: a Workroom may claim an exact shape version. If every binding change forced a new shape version, tightening a binding would unbind live work, and implementers would have a reason to avoid tightening. To prevent that:

• A binding’s version MUST be tracked separately from the version of the work shape it attaches to.
• A revision that only narrows a binding — removes a capability, shrinks the subject scope, shortens validity, or adds a stop condition or precondition — MAY apply to work pinned to the existing shape version, and MUST take effect at the next reach (§9.3).
• A revision that makes explicit a capability already reachable under the binding’s current effective envelope MAY apply without a shape version change. It MUST be recorded with its date and author, and C-6 reach reconciliation (§10) MUST confirm that the declaration did not widen reach.
• A revision that widens the effective envelope MUST produce a new binding version, and MUST NOT authorize calls for work admitted under an earlier version until that work’s gate is resolved again for the new version.

3. References

3.1 Normative references

• Trusted AI Kernel (TAK): §7.2 effective permission, §7.12.1 autonomy bounded by gate coverage, §7.13 principle-directed decision contract, §8.1 tool definitions, §8.4 default safety rule, §8.11 governed activity shapes
• Global AI Agent Identification and Governance (GAID): §10 receipts, §10.2.1 principle-directed execution binding
• Job-Specific Intelligence (TAK-JSI): §8.4 qualification of principle-directed work, §14 qualification and earned autonomy

3.2 Informative references

• Market and thought-leadership landscape (2026)
• External standards alignment
• Work shapes and the decision gate
• Principle-directed composition design
• OMG SysML v2 / KerML, DMN 1.5, BPMN 2.0.2, CMMN 1.1; W3C PROV-O
• OWASP LLM06:2025 Excessive Agency; OWASP Top 10 for Agentic Applications 2026
• Meta, Agents Rule of Two; Simon Willison, The lethal trifecta
• EU AI Act Article 14 (human oversight)

3.3 Reuse rule

When a requirement already lives in TAK, GAID or TAK-JSI, GPP references it and does not restate it. A GPP clause that appears to duplicate one of them is a defect in GPP.

4. Terms and definitions

5. Core principle

Authority is decided once per class of work, by the scope that owns it, and enforced on every call.

Three consequences follow:

1. Approve the decision, not the keystroke. A person or governed resolver decides whether a class of tool use is admissible for this work, and the runtime enforces that decision deterministically on each call. People supervise where they are effective. The market brief records users rejecting 39% of plans while approving 97% of prompts.
2. Unreachable beats prompted. A tool that no satisfied binding admits is not offered. It is never presented for approval, so it can never be approved by fatigue.
3. Every consequential reach traces to a named authority. For any consequential tool call the platform can answer which gate admitted this class of action, in which scope, decided by whom, on what evidence, valid until when. That answer is GPP’s audit object.

6. Relationship to the family

Composition order for one governed action:

1. GAID identifies the actor and profile.
2. GPP resolves the envelope for the actor’s Workroom and stage, which is the set of satisfied Gated Permissions.
3. TAK-JSI confirms any qualification a binding requires.
4. TAK intersects principal authority, agent grants, the GPP envelope and data constraints, then mediates the call.
5. GAID records the receipt, including the binding reference and gate-decision reference.

No member widens another. An envelope never adds a grant the agent or principal lacks. It can only narrow TAK’s intersection.

7. The Gated Permission binding

A Gated Permission MUST declare the following elements.

A binding MUST NOT admit a capability for a stage whose accountable principal lacks the authority to own that capability’s consequence. Unresolved ownership is a hold, never an admit.

7.1 Capability vocabulary

The capability vocabulary is the contract between modeled bindings and enforceable grants.

• Every capability token MUST resolve to a non-empty set of enforceable tool grants in the implementation’s grant catalog.
• A token that resolves to nothing is a dangling capability. It MUST fail the §10 consistency check. A dangling token fails safe at runtime (it admits nothing), but in the model it reads as authority that is in force when it is not.
• Capabilities SHOULD be classed by consequence, reusing the TAK §8.1 consequence classes, so that a binding’s risk is legible without reading every tool.

Minimum capability classes (informative names; implementations may refine them):

7.2 Gate resolution semantics

• A gate MUST resolve to exactly one of admit, refuse, hold or escalate.
• Hard constraints in the owning scope MUST be applied before any preference ranking (TAK §7.13). A preference score cannot turn a refuse into an admit.
• Missing evidence MUST yield hold. Where the owning scope is known but the required decision authority is missing, the gate MUST yield escalate through the binding’s escalation path. If ownership itself is unresolved, §7’s hold applies until ownership is established; routing an ownership question does not admit the action. Neither outcome overrides a TAK grant denial or defaults to admit.
• An admit MUST be recorded with the binding version, the scope, the resolver (doctrine reference and/or human principal), the evidence references and the validity.

7.3 The pairing at a glance

Every consequential tool call has two independent questions behind it. One is on the decision side: has the authority that owns this class of action decided it may happen? The other is on the permission side: is this tool inside the envelope this actor may reach, for this stage of this work? GPP binds the two, and TAK enforces both on every call. Neither side can stand in for the other. A high decision score does not make a tool reachable, and holding a grant does not answer who decided.

flowchart TB
    req["An agent reaches for a tool<br/>coworker or external agent, identified by GAID"]

    subgraph decision["Decision side: who may decide"]
        scope{"Owning scope of<br/>this stage's gate"}
        wwmd["WWMD<br/>platform doctrine<br/>principle_decide"]
        wwwd["WWWD<br/>organization stance<br/>evaluate_org_business_decision"]
        wsid["WSID<br/>profession craft<br/>evaluate_profession_decision"]
        score["Hard constraints filter options,<br/>then preferences score what remains"]
        verdict{"Gate resolution"}
    end

    subgraph permission["Permission side: what may run"]
        stage["Work-shape stage<br/>declares its capability set"]
        intersect["Agent grants<br/>∩ acting user's capability<br/>∩ room and stage capability set<br/>∩ token scope"]
        envelope["Envelope:<br/>tools reachable now"]
    end

    req --> scope
    scope --> wwmd
    scope --> wwwd
    scope --> wsid
    wwmd --> score
    wwwd --> score
    wsid --> score
    score --> verdict
    req --> stage --> intersect --> envelope

    verdict -->|admit| bound["Gated Permission satisfied<br/>versioned decision, validity window"]
    verdict -->|hold: evidence missing| hold["Collect the missing evidence"]
    verdict -->|escalate: authority missing| esc["Accountable human rules"]
    verdict -->|refuse| refused["Recorded refusal"]
    esc -->|rules admit| bound

    bound --> tak{"TAK mediates the call"}
    envelope --> tak
    tak -->|admitted and in envelope| run["Execute"]
    tak -->|outside the envelope| unreachable["Unreachable:<br/>never offered, never prompted"]
    run --> receipt["GAID receipt cites the<br/>binding version and gate decision"]

How to read it:

• The left side runs once per class of work, not once per call. An admit stays valid for the binding’s validity window (§9.1). Later calls inside the envelope reuse it, so nobody is asked again for each keystroke.
• The right side runs on every call, and it can only narrow. Each term of the intersection is owned by TAK §7.2; the room and stage term is what GPP models.
• The two sides meet only at TAK. A tool runs only when a current decision admits its class and the tool is in the envelope. Anything outside the envelope never reaches a human prompt.
• The scoring stays inside its scope. WWMD, WWWD and WSID are consulted according to which scope owns the gate, and their scores are never averaged into one number across scopes (§7.2, TAK §7.13). In DPF, a consequential call inside a Workroom also passes the WWWD × WSID alignment gate, where the most restrictive verdict wins (Annex A).

The diagram is the GPP model. Annex A says which parts of it DPF enforces today, and Annex C walks through it for Build Studio.

8. Capability co-occurrence

A single envelope can combine capabilities that are each safe alone and dangerous together. GPP adopts the Agents Rule of Two as a model-level constraint.

• An implementation MUST tag each capability with whether it introduces untrusted input, sensitive access or state change / outward communication.
• An envelope that combines all three for one actor in one session MUST require an actual accountable-human decision admitting that combination as a distinct, reviewable class. The decision MUST name the accountable principal and cover the binding version, subject scope and validity. Doctrine may inform it; a doctrine-then-human mode label without an actual human decision does not satisfy this requirement.
• An implementation SHOULD report every envelope that reaches the full combination, per actor.

This is a decision for a bounded class of work, not a fresh prompt for every call within the approved envelope. Other capability combinations retain their declared resolution modes. Validator-only admission is not specified by this revision: a future profile would need to define validator identity, independence, authority and evidence before claiming that alternative. A validator result alone MUST NOT be treated as the human decision required here. No runtime binding is promoted by this draft clarification.

This constraint governs the model. Data-flow techniques such as capability-tagged values (CaMeL-style) remain runtime controls under TAK and are complementary.

9. Bindings over time

9.1 Decide once, act within

A satisfied binding authorizes every call inside its capability set, subject scope and validity without a further human prompt. This is the mechanism that removes approval fatigue without removing authority. The decision is made at the granularity a person can judge, and enforcement is per call.

9.2 Phase boundaries

A human checkpoint belongs at a stage boundary where a decision can change the outcome, not on calls the decision has already admitted. An implementation SHOULD NOT re-prompt for calls a current binding admits. A prompt that cannot change the decision is a rubber stamp and trains inattention.

9.3 Expiry, revocation and material change

• A gate decision MUST stop authorizing when its validity ends, when a stop condition fires, or when the binding version changes.
• A change in the actor’s operating profile that the applicable TAK-JSI rules treat as material MUST re-evaluate any binding that requires qualification.
• Revocation MUST take effect at the next tool reach. It MUST NOT wait for the envelope to be recomputed on some later schedule.

9.4 Narrowing only

A Workroom’s posture, a proactivity setting or an autonomy level can narrow an envelope. None can widen it (TAK §8.11.2). Raising autonomy changes how often a gated class proceeds without a person. It does not admit a new class.

10. Completeness and consistency

A conforming GPP-Modeled implementation MUST be able to run the following checks over its bindings and report every violation:

C-6 is the most important check. A model that the runtime does not match is documentation, not governance. C-8 is its counterpart for transitions: a gate that one code path enforces and another path skips is not a gate.

11. Evidence and efficacy measures

A GPP-Evidenced implementation MUST publish, for a stated period and environment, with numerator and denominator:

Measures MUST be computed from execution and decision records, not from configuration. A published measure MUST state what it omits.

12. Notation

GPP does not require a particular notation. Two informative forms follow.

12.1 Textual form

gatedPermission:
  id: gp.delivery-small.repair.write-source
  version: 1.0.0
  attach: { shape: delivery-small@1.0.0, stage: repair }
  scope: WWMD
  gate: { key: delivery-implementation, mode: doctrine-then-human }
  capabilities: [read, write-source]
  subject: { repository: platform, branch: "doc/*|fix/*|feat/*", worktree: governed }
  validity: { until: stage-exit, maxDuration: P7D }
  preconditions:
    evidence: [backlog-item-claimed, research-receipt]
    qualification: null
  escalation: { role: delivery-coordinator, whileWaiting: hold }
  stop: [grant-revoked, stage-regressed, pr-closed]
  enforcement: enforced

12.2 SysML v2 mapping

The mapping is a modeling profile, not a claim of full SysML execution semantics. It composes the existing MBSE composition design.

12.3 The binding as a model

The same binding expressed as model elements. This is the view an MBSE tool, or a reviewer, navigates, and it is the structure the §10 checks walk.

classDiagram
    class WorkShape {
        +key and version
        +triggers
        +stop conditions
        +review point
    }
    class Stage {
        +key
        +accountable principal
        +advance condition
    }
    class GatedPermission {
        +id and version
        +subject scope
        +validity
        +preconditions
        +stop conditions
        +enforcement mode
    }
    class Gate {
        +key
        +resolution mode
    }
    class AuthorityScope {
        +WWMD platform
        +WWWD organization
        +WSID profession
    }
    class CapabilitySet {
        +capability classes
    }
    class Tool {
        +name
        +consequence class
        +honouring grants
    }
    class Agent {
        +GAID identity
        +operating profile
    }
    class Qualification {
        +TAK-JSI status
    }
    class Receipt {
        +binding version
        +gate decision
        +effect
    }
    WorkShape "1" *-- "1..*" Stage : stages
    Stage "1" o-- "0..*" GatedPermission : attaches
    GatedPermission --> "1" Gate : resolved by
    Gate --> "1" AuthorityScope : owned by
    GatedPermission --> "1" CapabilitySet : admits
    CapabilitySet --> "1..*" Tool : resolves to, C-2
    Agent --> Stage : performs
    GatedPermission ..> Qualification : may require
    Tool ..> Receipt : each call leaves
    Receipt --> GatedPermission : cites

Each relationship maps to one completeness check:

12.4 From model to running system

A diagram that explains governance is not MBSE. In MBSE the model is precise enough to be interpreted and implemented as the running workroom shape, and it stays visible both to the people designing the work and to the people supervising it while it runs. This section makes that requirement normative for GPP-Modeled and GPP-Enforced.

12.4.1 The model is executable or verified

A conforming implementation:

• MUST hold its Gated Permission model in a machine-readable form. It uses typed elements for every §7 binding element and every §12.3 class, and identifiers that stay stable across versions.
• MUST either execute that model directly, so the declared shape is what the runtime runs, or verify the running configuration against it whenever either one changes. A model that exists only as prose or a picture does not satisfy GPP-Modeled.
• MUST declare, for each stage transition, the complete gate set that guards it: owning scope, resolver, whether it blocks or advises, and its mode. Every runtime path that performs that transition MUST enforce the same set (C-8).
• MUST map each model element to exactly one runtime artifact and publish that mapping, so an assessor can go from a clause to the code or configuration that realizes it.
• SHOULD derive participants, capability sets and gate bindings from the model, rather than configuring them separately and reconciling afterwards.

12.4.2 The model is visible at design time and at runtime

A view MUST be a projection of model and execution records. It MUST NOT infer a verdict the records do not contain. A picture that disagrees with the ledger is worse than no picture, because people act on the picture.

12.4.3 DPF status

13. Hazards

14. Security and privacy considerations

A binding names authorities, subjects and evidence. Binding records and gate decisions can reveal organizational structure and sensitive subjects. They MUST be readable only by principals entitled to the underlying work. A GPP model does not reduce the need for sandboxing, egress control, credential isolation or data-flow controls. It determines what those controls must permit.

Annex A (informative): DPF realization status

Assessed against repository source on 2026-09-30. Source presence is not runtime enforcement; the mode column says which.

Promoting a permit binding to enforced (informative). Each promotion is its own small, revertable PR that adds one entry to GPP_BINDING_ENFORCEMENT in apps/web/lib/gpp/binding-enforcement.ts and removes the binding from KNOWN_SHADOW_BINDINGS. Nothing in the database and no environment variable can promote a binding; DPF_GPP_ENFORCEMENT=shadow-all is the only runtime override, and it can only return every binding to shadow. binding-enforcement.test.ts refuses the entry unless:

1. it cites a WWMD decision id (DI- and 12 hex digits) from principle_decide, recorded with dpf-record-decision-outcome, a ratification date, and the evidence it rests on: at least 14 days of GppPermitObservation for the binding with no unexplained mac_invalid, param_mismatch, lineage_missing, absent, ungoverned or unmediated verdict for its tools;
2. the binding names an explicit tools list, and every tool is outward, authority or irreversible by classifyConsequentialTool. A predicate-wide binding, such as the two seeds, cannot be promoted;
3. no tool on the list has a direct executeTool site, and no direct site with a dynamic tool name exists. After Phase 2 PR-H two dynamic sites remain, the proposal-approval paths, so no binding is promotable yet;
4. for an alignment-admit binding, the alignment gate runs for every listed tool outside a Workroom;
5. the entry states how it treats unsealed lineage (R1): sealed-required, where an unsealed decision downgrades that call to shadow, or unsealed-accepted, which the decision must accept explicitly;
6. for a human-checkpoint binding, no listed tool can be called directly, that is, without a coworker agent (a person over REST, or an agent-unbound MCP token). The checkpoint gate runs only for coworker calls, so a direct call could never carry its permit. A direct call is not treated as its own checkpoint, because the platform cannot tell a person from an agent using that person’s session or token. Every registered tool is directly callable today, so human-checkpoint-admit is not promotable over any tool (PR-G).

Every install path now generates DPF_GPP_PERMIT_SECRET (BI-8541D491); before a promotion the operator confirms the install has it, since an install that predates it gets it at its next self-upgrade. Without it the binding records enforcement_downgraded (permit-key-unconfigured) on every call rather than enforcing. To demote a binding, revert its promotion PR. In an emergency the operator sets DPF_GPP_ENFORCEMENT=shadow-all.

Overall DPF status:

• GPP-Modeled: partial. Standing, coworker and orchestration stages declare stage-level tools under a parity test that is a CI gate, with a shrink-only gap list. Delivery shapes bind at shape level in the §7.1 vocabulary under the C-2 guard; 26 standing-shape tokens remain dangling on a shrink-only list.
• GPP-Enforced: partial. Room narrowing, the alignment and escalation gates are enforced; the shape gate is in shadow mode, and the Phase 2 permit is enforced per binding with no binding promoted yet; exact-action projection covers 11 tools.
• GPP-Evidenced: not yet.

Annex B (informative): proposed assertions

These are assessment designs. None has been executed by writing this draft. Executable form belongs with the family’s conformance work (BI-2AB781FA).

Annex C (informative): Build Studio as a GPP model

Build Studio is DPF’s own delivery flow: the path by which an idea becomes reviewed, merged and shipped platform change. Its phases, transitions and per-phase tool permissions are the most fully defined workroom flow DPF ships, so it is the first worked example. Everything below was read from repository source at 02aca6a234 on 2026-10-01. Each element states its mode. The annex models what exists and does not claim that the model is complete.

C.1 The model

flowchart TB
    intake(["Backlog item<br/>approved to start"]) -->|"WWMD ideate-start gate<br/>autonomous mode only"| ideate
    ideate["IDEATE<br/>~52 tools: research, brief,<br/>design review, decomposition<br/>no sandbox write"] -->|"evidence: design doc,<br/>design review passed<br/>+ readiness 'plan'"| plan
    plan["PLAN<br/>~42 tools: plan review,<br/>project reads<br/>no sandbox write"] -->|"WWMD plan-advancement gate<br/>BLOCKING<br/>+ WSID consults, advisory<br/>+ evidence + readiness"| build
    build["BUILD<br/>~50 tools: sandbox read, write,<br/>edit, tests, schema checks"] -->|"evidence: typecheck passed<br/>+ releasable diff"| review
    review["REVIEW<br/>~51 tools: sandbox still writable,<br/>page evaluation, semantic review"] -->|"rework"| build
    review -->|"WWMD ship gate<br/>blocks in enforce mode only<br/>+ WSID consults, advisory<br/>+ acceptance evidence"| ship
    ship["SHIP<br/>~45 tools: PR, deploy,<br/>promotion, release bundle"] -->|"merge queue +<br/>delivery-acceptance decision"| done(["Complete"])

Where each part of the model lives today:

C.2 One binding, written out

The plan → build transition, expressed in the §12.1 notation. This is a model of what exists, not a new configuration.

gatedPermission:
  id: gp.build-studio.build.sandbox-write
  version: 0.1.0-model
  attach: { flow: build-studio, stage: build }
  scope: WWMD
  gate:
    key: build-studio            # evaluator gate key, projected to WWMD
    question: Start implementation from the reviewed plan?
    options: [start, revise-plan, escalate-to-owner]
    mode: doctrine-then-human    # escalate goes to the Build Studio owner
    blocking: true
  advisory:
    - scope: WSID                # acumen consults, chosen by the paths touched
      blocking: false
  capabilities: [read, write-source-sandbox, run-tests, schema-validate]
  subject: { sandbox: build-scoped }
  preconditions:
    evidence: [buildPlan, planReview-passed, happyPathIntake-ready]
    readiness: implementation    # initiative-readiness lane
    humanApproval: approve-start
  validity: { until: stage-exit }
  stop: [build-failed, build-abandoned, rework-from-review-reenters]
  enforcement: enforced          # on the canonical path only; see C.3 item 2

C.3 What modeling it revealed

Writing the flow down as a model exposed six things that the code, read file by file, did not make obvious. This is the practical argument for MBSE.

1. The model is implicit. Build Studio’s stages, gates and capability sets are spread across at least six modules. A second, parallel model, the delivery shape’s stages (design-note → implement → merge → accept for a medium item), governs the same work through initiative readiness. There is no single declared artifact a reviewer can inspect. That fails §12.4.1, and it is the first thing to fix.
2. One transition, two gate sets (C-8). save_phase_handoff is available in the plan phase and auto-advances plan → build after only the evidence check. The canonical path also enforces the blocking WWMD gate, initiative readiness and Approve Start. Recorded as BI-45F9CB7A; found by source reading, not yet reproduced at runtime. Approve Start now holds this path too, and the tool refuses any phase outside its own buildPhases tag, so it can no longer complete a ship build over external MCP (BI-BDB63485). WWMD and readiness stay open under BI-5D59A982.
3. Accountable identity is not one thing (C-4). The phase-handoff record and the IT4IT prompt map name different agents for the same phase, and neither ties back to the agent rows that hold tool grants. Until that is resolved, “can the stage’s accountable principal own this consequence?” cannot be evaluated.
4. WSID advises but never blocks, and the QA craft has no route. Profession consults are chosen by file path, and no path rule selects the QA profession. Whether any WSID verdict should become blocking is an open decision for the platform scope, not something this annex can settle.
5. The build engine’s boundary is the environment, not the tool list. The primary build path runs a coding CLI inside the build sandbox with its permission prompts disabled. The MCP phase filter does not apply there. The sandbox is the containment. That is a legitimate design, and it is the containment-first approach the market brief describes. GPP requires it to be declared as a binding whose capability set is “unrestricted inside the sandbox, nothing outside it”, with its enforcement at the environment layer, rather than left implicit.
6. The ship gate is shadow unless enforce mode is on (C-7). Promotion is then approved automatically after deploy_feature. The model has to show that mode, and the public ledger (white paper §8) has to report it as shadow.

C.4 Path to conformance

Revision history