net-kingdom/docs/security-case-execution-owner-review.md

NetKingdom owner review: closed SecurityCase execution seam — 2026-10-10

Disposition: support design direction with the requirements below. This is NetKingdom's architectural owner review; it is not founder approval, another repository's review, executable type acceptance, materialization or native case completion. Reviewed proposal SHA256: 78ab1439e4c5beb205aeccf15b1b2e706511be55ab195c5a3aa682f326c7c77c.

Architectural fit

NetKingdom declares Taxonomy and owns case canon/schema/type composition. ops-warden owns follow-through routing and caller-proxy orchestration. The existing type's entry_point/auth/check/action fields are descriptive strings, not fixed argv contracts. Inferring a shell command from those descriptions would invent a new execution interface and authority. The proposal correctly keeps them descriptive and adds a separately validated closed owner adapter reference, exact source/interface pins, parameter schemas and bounded receipts. Owner-native execution/undo remains with each provider; consumer OIDC/group configuration remains railiance-apps, and mint remains railiance-platform.

Caller proxy must continue to use the caller's declared lane and grant. It must not become a standing Warden broker, borrow user-engine's provisioner credential, or merge the KeyCape and OpenBao issuer sessions. The proposal's receipt-only pending-owner path is useful and does not count as success. Its uncertain-on-interruption, no replay of success, reconcile-before-retry and created-object-only rollback are appropriate. Confirmed grant/session revocation is part of native completion, not an inferred exit-code success.

Source-evidenced deadlock and version mismatch

1. ops-mason/workplans/MASON-WP-0010-security-case-materialization.md T03's blocking_reason waits for CCR application plus mint-secret, and then says the case is live. Its task acceptance is materialization, not full live follow-through. The same file says its build writes a bundle and never contacts OpenBao; bundle preparation is not observed materialization.
2. ops-warden/src/warden/case_plan.py requires case status materialized before planning (PLANNABLE_CASE_STATUS, plan_case); an accepted case is refused.
3. railiance-platform/scripts/keycape_client_secret_generate.py check_case also requires status materialized before mint (line117 at this revision). mint is a follow_through step in type1.1, not a structural materialization template. Thus requiring mint before materialized prevents the mint route from being entered. The accepted case still has status accepted.
4. The original broker source separately pins CASE_TYPE = oidc-browser-relying-party@1.0 and compares exact case.type. Forgejo has already been accepted/re-pinned to @1.1 on the founder's recorded go. No run can silently pass the @1.1 case as @1.0 or ignore the check. Platform must review the broker's actual version binding and owner test it against the exact accepted type/case. Platform now has a reviewed staged correction at /tmp/security-stage/railiance-platform/scripts/keycape_client_secret_generate.py SHA256 9576cd211cfc06526ec4cc9bd0a5b06f0f59287a68931bb2d6e3592a951ddc7d: exact @1.1 is admitted, @1.0/later types and unmaterialized cases remain refused. Its owner reports ten fake-backend subprocess tests passed. This removes the identified source mismatch when applied; it does not establish installed broker provenance, applied structural receipts or native mint.

Required implementation contract

• Define materialized as accepted and verified structure: exact type/case/render pins plus the owner's native structural receipt identifying created and pre-existing objects and current target identity. All applicable structure must have admission evidence; CCR-0042's unfinished consumer binding is not waived by separating mint. Empty generated-value custody can exist at this state; mint/delivery/env/registry/consumer/verification occur afterwards. A file status label or source bundle cannot stand in for that receipt.
• Lifecycle change from accepted to materialized changes exact case bytes and therefore case-ref. Authoritative materialization receipt must preserve the accepted content/record and bind the new exact bytes, rather than carry an old case-ref into broker generation. Do not mark the type implemented until a reference case is actually live and verified; keep the established first acknowledged-type exception explicit.
• Introduce a separately versioned schema for adapter references and run/step receipts, with closed fields, immutable owner/interface/source references, machine target/parameter mapping, actor/lane equality and fixed argv (no shell interpolation). Unknown adapters/params fail closed. Existing descriptive types remain valid for plan-only output until migrated; absence of execution descriptors permits no dispatch. Receipt provenance must be authenticated or explicitly attended manual evidence, with bounded input and secret withholding.
• Classify each actual type migration under canon section6. Preserving existing auth/trust and adding closed execution references is not itself authority to change those boundaries. A changed auth path/materialization/trust transition or loosened validation needs new informed-decision acknowledgment. Retain existing type1.0 acknowledgment and founder-approved1.1 provenance.
• Reconcile broker CAS0 outcomes via an owner adapter. Already-present metadata is not proof this case generated the value or its consumer can use it, and must not be retried into generation or automatically promoted to success. Map grant creation, write and post-write verification uncertainty explicitly; no exception may claim failed-before-change without owner evidence. Grant revocation and attended parent-session revocation are distinct receipts.
• Rollback may remove only changes actually attributed to the exact case, not every target rendered from templates. Existing group memberships, policies, shared registrations and custody data survive. Secret rollback is owner-native and may not extract prior values through Warden.

The proposal's stated negative tests should accompany the schema and injected runner implementation: changed pins, unsupported argv/adapter, unaccepted or unmaterialized case, agent mint refusal, pending-owner, crash after running, lost result, CAS reconciliation, explicit safe retry, uncertain undo, malicious output suppression and absent revocation. Add current type1.1 broker compatibility and materialized-before-mint ordering tests using non-secret fixtures.

Precise final-revision re-review

The final proposal reviewed here is the staged SHA256 named above, which supersedes the earlier 1035f049... review. The added Local reducer prototype appendix explicitly says the reducer is pure preparation, not an accepted wire format, and implements no provenance, durable storage, dispatch or live action. This boundary is appropriate. Inspected staged case_receipt_state.py: begin returns running intent; recover marks interrupted dispatch uncertain; success cannot replay; explicit retry-safe failed-before is the only retry path; created-object rollback is reversed and interrupted undo becomes uncertain. Those functions do not enforce materialization, caller authorization, receipt provenance or persistence themselves. The design decision must therefore not accept their local outcome enum or dataclass shape as a completed runtime protocol. pending-owner remains a run-sheet/native gate even though the reducer has no pending-owner dispatch state. The previously stated schema, owner adapter and persistence requirements remain implementation prerequisites. No new auth/session or live authority is introduced by this appendix.

Concrete informed-decision act

Recommended design question: adopt a closed owner-adapter and immutable receipt contract for SecurityCase follow-through, keeping current case/type acceptance and caller/session authority intact; require structural materialized receipt before follow-through and leave missing adapters as pending-owner. Alternative: continue manual owner execution with honest source/run-sheet receipts, and do not expose Warden run/rollback dispatch. Reject inferred shell execution from prose. Acceptance authorizes schema/interface implementation and local tests only; it grants no live rollout, mint, credential, case status transition, new issuer identity, type risk-class change or consumer configuration.

NK-WP-0048-T06 remains wait for this execution seam and actual structural/native owner receipts. Its historical approvals remain valid within scope. T07 waits for first live proof; this design review does not satisfy it.