← Back to directory

stage-3d-owner-decision-request.md

implementation/stage-3d-owner-decision-request.md · 11.9 KB · 2026-11-02 12:48

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).

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 and the implementation architecture.

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.

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

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:

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:

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:

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:

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:

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 must also be completed and reviewed before BUILD.