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.