# Stage 3D Owner Decision Request Status: owner architecture decision received on 2026-10-16; implementation and production authorization remain pending. This document is an external handoff record; it does not grant runtime authority or authorize production access. > **Terminology supersession, 2026-11-02:** "Principal" in this request is superseded terminology for User. Principal is not a current architectural concept. Identifiers such as `principal_id` are legacy implementation details retained until a separately authorized migration (PRR-061). Request semantics are otherwise unchanged, except that any statement treating automation or an integration as an independent identity or authority subject is superseded: automation operates under authority delegated by a User, with the technical executor recorded as execution provenance (see [identity and governance](../architecture/identity-and-governance.md#delegated-authority-for-automation)). ## Purpose Stage 3D cannot enter BUILD until the project owner, or a delegated authority explicitly designated by the owner, decides whether the proposed governed platform Type-revision boundary is acceptable. The detailed proposal and implementation evidence remain in the [Stage 3D semantic authority audit](data-defined-semantics-audit.md) and the [implementation architecture](architecture.md). The repository does not identify the responsible owner or delegated authority. That person must be designated outside this document before a response can be recorded as an approval. ## Decisions requested Please select one response for every row. The recommended defaults are proposals, not approvals. | Decision | Recommended default | Consequence of approval | Consequence of rejection | |---|---|---|---| | `platform.type_revision` Operation | Approve the existing platform Operation/Command boundary | A governed, explicitly authorized Type revision can be implemented and audited | No governed Type revision can be built; Stage 3D remains blocked | | Distinct Type-revision `AuthorityGrant` and `Policy` targeting `TYPE_OF_TYPE_ID` | Approve | Type-revision authority is explicit, attributable and separate from Definition publication | Existing Definition publisher authority remains insufficient; Stage 3D remains blocked | | Permitted target scope | Permit exact supplied platform Type Object IDs, subject to descriptor, dependency and expected-version validation | One governed Operation can handle approved Type identities without a registry | A narrower explicit allowlist or a different approved boundary is required | | Trusted handler boundary | Approve a reviewed handler behind the existing Operation/Command boundary; designate its release owner | No arbitrary persisted code dispatch is introduced | There is no trusted execution boundary for the Operation | | Reuse of the Definition publisher Principal | Do not grant automatically; require a separate explicit Type-revision grant even if the Principal is the same | Separation of authorities remains explicit and approval is attributable | A separate Type-revision Principal must be designated and configured | | Authorization and expected-version revalidation | Require revalidation at invocation and immediately before commit under coordination | Unauthorized, stale and conflicting requests fail without mutation | The operation is not safe to build | | Existing Command, Action Execution, Attempt, Outcome, Event and Provenance pipeline | Require exclusive use of the existing governed evidence mechanisms | Type revisions retain the platform's normal command and provenance evidence | A compliant mutation boundary has not been approved | The proposed Operation must remain distinct from `definition.publish`. Definition publication authority must not be treated as Type-revision authority by implication. ## Response format Return the following completed record through the project's existing governance channel. Do not treat a completed copy stored by an unapproved person as owner approval. ```text decision owner / delegated authority: ______________________________ designation or governance reference: _______________________________ decision date: ______________________ platform.type_revision Operation: APPROVE / REJECT distinct Type-revision AuthorityGrant and Policy: APPROVE / REJECT target scope: all approved platform Type Object IDs / explicit allowlist / REJECT trusted handler and release owner: APPROVE / REJECT / DESIGNATE Definition publisher Principal reuse: APPROVE / REJECT / DESIGNATE SEPARATE PRINCIPAL commit-time grant, Policy and expected-version revalidation: APPROVE / REJECT existing Command and evidence/provenance pipeline only: APPROVE / REJECT conditions, exclusions or required changes: ____________________________________________________________________ ____________________________________________________________________ ``` The project owner has responded in the current session with `APPROVE` for the proposed architecture and the safeguards listed above. The response does not separately designate the trusted handler/release owner or settle the exact permitted Type Object scope beyond the proposed contract; those details must be recorded before implementation. Approval of this request does not authorize production access, grant installation, provisioning, migration or implementation. ## Partial decision record — 2026-10-21 Status: **PARTIALLY DECIDED — PLAN ONLY / NO-GO FOR BUILD**. The following design direction was supplied for the Stage 3D implementation contract. It is recorded as approved in principle only; it is not formal approval for implementation, authority installation, deployment, migration or STAGING access. ### Immutable Type evolution - Preserve the historical Presentation/View Definition Type revision 1 and append revision 2. - Keep `target_type_revision` optional in Presentation revision 2. - Preserve Capability Definition Type revision 3 and append revision 4. - Never redefine a published Type descriptor in place. - Treat the source-controlled hashes as proposed migration expectations until the persisted STAGING predecessors have been verified. - Keep the separate Presentation Object Type unchanged. The proposed source-controlled matrix is: | Type Object | Historical revision/hash | Target revision/hash | |---|---|---| | Presentation/View Definition `8a4f6b8c-3d2e-4f10-8a11-223344556690` | `1` / `a0f1bbb2a3308a58aca56a721a408ce426f9b65a724157f9f2b61ca846a2f4de` | `2` / `a73d394d3b8fa497da582dc7574ffa97622f8669aaf219ae40761a6611ee9e61` | | Capability Definition `7a4f6b8c-3d2e-4f10-8a11-223344556690` | `3` / `894ef3c523d5394ee1d90840ca751d2a1c37a90d7261498c2874135c1391267d` | `4` / `7ede8432e75229b5d7fddeb1068fb3bd14f8519b943a2753182c6a2930d43726` | ### Dedicated Operation and target scope The intended Type-revision Operation is: ```text name: platform.type_revision id: 9f4f6b8c-3d2e-4f10-8a11-223344556702 revision: 1 scope: platform handler: platform.type-revision ``` The candidate identity is subject to repository collision checks, approved installation and persisted-state verification. It must remain distinct from `definition.publish`. The proposed allowlist contains only: ```text 8a4f6b8c-3d2e-4f10-8a11-223344556690 7a4f6b8c-3d2e-4f10-8a11-223344556690 ``` No other Type Object may be revised through this authority without a separate decision. The Presentation Object Type is explicitly excluded. ### Separate authority and evidence The intended Type-revision AuthorityGrant and Policy are separate from the Definition Publisher authority: ```text AuthorityGrant candidate: b3000000-0000-4000-8000-000000000003 Policy candidate: b3000000-0000-4000-8000-000000000004 ``` The configured Definition Publisher Principal is the intended Principal only if the separate grant and Policy are explicitly installed. This does not broaden the existing Definition Publisher grant and does not establish the Principal's identity or authentication evidence. Type revision must use the existing Operation/Command, authorization, Policy, expected-version, generic Object revision and evidence mechanisms. Required evidence includes Command, Action Execution, Attempt, Provenance, Event and Outcome, with `command_id` and `provenance_ref` retained on the resulting Type Object revision. No direct SQL mutation, parallel ledger, custom Type-revision store or trusted-handler bypass is permitted. ### Independent Commands and invocation The Presentation and Capability appends are two separately authorized, independently atomic and idempotent Commands: 1. Presentation revision 1 to revision 2. 2. Capability revision 3 to revision 4. A later failure does not silently roll back an earlier successful Command. Partial and unknown outcomes must be reported explicitly, and retries must inspect persisted state before deciding whether an append remains necessary. The intended existing-target boundary is a separate bounded authenticated CLI based on the safeguards and authentication pattern of `bin/reconcile-foundation.php`. It must authenticate the explicit Principal, verify STAGING identity, invoke the approved Operation through the existing Command path, enforce the Type allowlist, avoid direct repository writes and never invoke empty-target provisioning. Existing View Definitions bound to Presentation revision 1 remain valid and unchanged. New View Definitions may use revision 2 once installed and validated. Exact Type revision references remain mandatory. Definitions, Views and Presentation Objects are not automatically rebound. ### Required diagnostic and commit-time controls Before any STAGING migration execution is authorized, the existing protected read-only diagnostic must report for both exact Type Object IDs: - current Object version, Type-of-Type identity and platform scope; - current persisted descriptor and canonical hash; - all retained Type Object history versions and hashes; - `command_id` and `provenance_ref` presence and related references; - bounded dependent-object counts/identifiers; - comparison with source-controlled historical and target hashes; and - one of `MATCH_HISTORICAL`, `MATCH_CURRENT`, `MISMATCH` or `UNVERIFIABLE`. The diagnostic must use the existing canonicalization implementation, preserve list ordering, expose no credentials and perform no repair or mutation. Any future handler must, inside the governed transaction, lock coordination and target rows, revalidate Principal, grant, Policy, Operation identity, platform scope, Type-of-Type identity, exact allowlist, expected Object version and predecessor hash, validate the target descriptor/hash, append through the generic Object revision mechanism and commit the required evidence together. Missing, stale, conflicting, unauthorized or unverifiable state must fail closed. ### Unresolved decisions — no implied approval The following remain unresolved: - decision owner/delegated authority and governance reference; - trusted handler owner and release owner; - final collision-checked confirmation or replacement of candidate IDs; - designated Type-revision Principal and any Definition Publisher Principal reuse; - final authenticated CLI and credential-handling contract; - exact event and reason-code names; - diagnostic output detail and protected workflow requirements; and - any additional conditions imposed by the designated authority. ## Gate effect The Stage 3D gate remains **NO-GO** until: 1. all requested decisions are explicitly recorded; 2. the approved scope, grant, Policy and trusted handler boundary are unambiguous; 3. any conditions are resolved and reflected in the canonical documentation; and 4. no existing Definition publisher authority is being used as an implicit Type-revision approval. The separate [production evidence request](stage-3d-production-evidence-request.md) must also be completed and reviewed before BUILD.