diff --git a/docs/changes/netkingdom-target-2026-10-17/native-registration-r1/summary.json b/docs/changes/netkingdom-target-2026-10-17/native-registration-r1/summary.json
new file mode 100644
index 00000000..d5723d0d
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-registration-r1/summary.json
@@ -0,0 +1,25 @@
+{
+  "schema": "custodian.registration-source-review-summary.v1",
+  "outcome": "Concrete source review packet delivered; native recovery and complete descriptor admission remain blocked on named existing owner contracts.",
+  "task_scope": [
+    "NK-WP-0048-T15",
+    "NK-WP-0048-T16"
+  ],
+  "original_attempt": {
+    "actual_matching_admitted_holder_found": false,
+    "existing_authority_retained": "No post-restart rollback or replay; no new reconcile callback installed.",
+    "precise_interface_gap": "Warden Journal original identity is not supplied to the fresh reconcile callback; journal stores only hashed evidence identifiers, registration owner payload/creation remain process local."
+  },
+  "descriptor_inventory": {
+    "actual_source12_steps": 7,
+    "actual_existing_generated_descriptor_candidates": 1,
+    "missing_exact_descriptors": 6,
+    "register_descriptor": "register-client.proposed-descriptor.json",
+    "descriptor_hash": "sha256:1b86e9032845ec35a58d88a9f1108dbb7d8cee0c9c9176d4a694b893d9d7a3fa",
+    "canonical_types_unchanged": true
+  },
+  "verification": "Actual delivered13,633,409-byte checker rehash; actual Warden closed-descriptor decode; source1.1 default and explicit1.2 source render remain execution=false; ordinary1.2 admission refuses acknowledged/unimplemented type. No test reruns, new framework tests, native effects or owner assent.",
+  "next_existing_owner_request": "Warden original-intent lookup/context amendment and actual registration publisher/authenticator/readback identity; use existing Audit Core API only if actual source/tenant/load-bearing/read admission is explicitly established.",
+  "writes": "Only this Custodian packet; NetKingdom/warden canonical source, all unrelated dirt and WP49 recovery paths untouched.",
+  "prior_audit_preserved": "sha256:ab803e795af61fd027f5930d127592316133de38b68a8fe61b89a1f9803a9ff2"
+}
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-registration-r1/work-record-proposal.json b/docs/changes/netkingdom-target-2026-10-17/native-registration-r1/work-record-proposal.json
new file mode 100644
index 00000000..3e656fcc
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-registration-r1/work-record-proposal.json
@@ -0,0 +1,36 @@
+{
+  "schema": "custodian.nk48-source-checkpoint-proposal.v1",
+  "applied": false,
+  "reason": "NetKingdom AGENTS requires an evidenced completed deliverable and refined remaining work after a substantive checkpoint. Coordinator owns canonical publication; this packet changed no NetKingdom files.",
+  "suggested_completed_task": {
+    "id": "NK-WP-0048-T22",
+    "status": "done",
+    "title": "Establish source-only registration original-attempt recovery and complete descriptor inventory",
+    "completed_at": "2026-10-17",
+    "evidence": "the-custodian/docs/changes/netkingdom-target-2026-10-17/native-registration-r1/",
+    "outcome": "Inspected actual owner seams and rejected ungrounded restart recovery; defined exact minimal owner contracts, generated register descriptor from current source/checker, inventoried all seven source1.2 steps and verified source-only version-selection/refusal boundaries. No recovery callback, native source integration, owner assent or full descriptor set is delivered.",
+    "id_reservation": "Candidate only; root must recheck current source T22 is free before applying. Do not assign or edit Hub UUID manually."
+  },
+  "remaining_refinement": [
+    {
+      "id": "NK-WP-0048-T15",
+      "retain_id_and_uuid": true,
+      "retain_completion_gate": true,
+      "proposed_status": "wait",
+      "owner": "NetKingdom registration evidence owner with ops-warden",
+      "next_action": "Obtain exact existing owner holder/readback identity and Warden original-intent context contract described in original-attempt-review.json before implementing restart recovery. Current Adapter intentionally cannot reconcile prior-process creation.",
+      "unblock": "Actual source-reviewed original-attempt lookup/custody contract plus independent session/provenance verifier; do not wait on broad task completion or create a coarse dependency cycle.",
+      "done_when": "Restart/lost-receipt fixtures enforce exact original created-only provenance and current native revision; native evidence-holder acceptance remains separate."
+    },
+    {
+      "id": "NK-WP-0048-T16",
+      "retain_id_and_uuid": true,
+      "retain_completion_gate": true,
+      "proposed_status": "progress",
+      "next_action": "Use descriptor-composition.json as complete review inventory. Bind exact native owner evidence/session/storage capabilities and obtain missing six fixed owner descriptor/adapters. Then review successor exact type/version bytes under canon section6; preserve acknowledged1.1 default and source-only1.2 history.",
+      "done_when": "Complete exact machine-descriptor set, artifact/source/config pins, independent source-owner review and normal type/version admission; this packet alone completes none of these native admissions."
+    }
+  ],
+  "existing_dependencies_preserved": true,
+  "external_owner_scope": "Use existing WARDEN-WP-0044-T03 and owner reviews; no new broker, workplan, credential grant, publisher class, explicit residual promotion or owner assent inferred."
+}
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-registration-refinement-r2/manifest.json b/docs/changes/netkingdom-target-2026-10-17/native-registration-refinement-r2/manifest.json
new file mode 100644
index 00000000..edbbcec8
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-registration-refinement-r2/manifest.json
@@ -0,0 +1,46 @@
+{
+  "target": "/home/worsch/net-kingdom/workplans/NK-WP-0048-security-case-types.md",
+  "applied": true,
+  "old_task_count": 21,
+  "new_task_count": 23,
+  "all_existing_task_metadata_preserved": true,
+  "all_existing_statuses_dependencies_uuids_preserved": true,
+  "new_tasks": [
+    "NK-WP-0048-T22",
+    "NK-WP-0048-T23"
+  ],
+  "r1_manifest_sha256": "9c9b055cb7983706e7bccb13acf335180c4343c8a05de5ef63f97548c9f5021a",
+  "storage_review_sources": [
+    {
+      "path": "/home/worsch/the-custodian/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/OWNER-REVIEW.md",
+      "sha256": "9a12392030ae5bd46dbed95718e3b51e6df15f52ce0fa2411704ddd8f2b1e91f"
+    },
+    {
+      "path": "/home/worsch/the-custodian/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/source-validation.json",
+      "sha256": "fe57add4e819661b7ef4df98f5166d0147f6b5e5912be0d6ec7c0a7da2090d9c"
+    }
+  ],
+  "files": [
+    {
+      "path": "preimage.md",
+      "sha256": "b737bfae4802c122b21619695a169d7d082672af96314b1709860dd5aff2a60f"
+    },
+    {
+      "path": "t22-applied-intermediate.md",
+      "sha256": "a756cf34eb0398312a8e11035b7b1b21d2b97a847f015b888063bd80549b6fc2"
+    },
+    {
+      "path": "postimage.md",
+      "sha256": "0fdc263a5b23d376a2c6e908e955c91fdaf8121144da59ebc6e5aee8ef727f5e"
+    },
+    {
+      "path": "workplan.patch",
+      "sha256": "714a345e601588eacaccdc559d864553f21a7cceb1fcebddf305404680019906"
+    }
+  ],
+  "applied_postimage_sha256": "0fdc263a5b23d376a2c6e908e955c91fdaf8121144da59ebc6e5aee8ef727f5e",
+  "existing_task_blocks_byte_identical": true,
+  "r1_packet_byte_hashes_unchanged": true,
+  "published": false,
+  "synced": false
+}
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-registration-refinement-r2/postimage.md b/docs/changes/netkingdom-target-2026-10-17/native-registration-refinement-r2/postimage.md
new file mode 100644
index 00000000..1d0e33fa
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-registration-refinement-r2/postimage.md
@@ -0,0 +1,1215 @@
+---
+id: NK-WP-0048
+type: workplan
+title: "Establish SecurityCaseTypes so that known security cases are light"
+domain: infotech
+repo: net-kingdom
+status: active
+flavor: implementation
+owner: claude-code
+topic_slug: netkingdom
+created: "2026-10-08"
+updated: "2026-10-17"
+depends_on: []
+related_repos:
+  - ops-mason
+  - ops-warden
+  - key-cape
+  - railiance-platform
+  - informed-decision
+state_hub_workstream_id: "e31f3f9d-0748-5137-b0a3-7b3ca46a66eb"
+---
+
+# NK-WP-0048 - Establish SecurityCaseTypes so that known security cases are light
+
+## Why
+
+The founder's direction (2026-10-08): setting up a security integration of a
+kind that has been done before should be easy, meaning accept the case, then
+ops-mason arranges it and ops-warden follows through. Setting up a new kind
+needs ample documentation and tests and an informed-decision, because its shape
+is part of the security architecture.
+
+Today every integration is hand-built: per-client helper scripts, per-lane
+custody, founder checklists. The trigger was KEY-WP-0038 (Forgejo as an OIDC
+client), whose next step was going to be yet another hand-written rollout
+script.
+
+This plan continues the pattern work of NK-WP-0008 (pattern infospace),
+NK-WP-0009 (tutorials) and NK-WP-0030 (scenario composition). It turns patterns
+into **SecurityCaseTypes** that ops-mason and ops-warden can execute. Canon:
+`canon/standards/security-case-types_v0.1.md` (proposed).
+
+Companion plans: ops-mason `MASON-WP-0010` (materialization) and ops-warden
+`WARDEN-WP-0044` (follow-through).
+
+## Tasks
+
+```task
+id: NK-WP-0048-T01
+status: done
+priority: high
+state_hub_task_id: "930ac3e9-20ec-5473-98cd-3fe8fddb730f"
+```
+
+### T01 — Accept the terminology and the canon
+
+Founder review of `canon/standards/security-case-types_v0.1.md`, including its
+section 10 open questions. On acceptance the canon status goes from `proposed`
+to `accepted`.
+
+2026-10-08: accepted by the founder (in session). Canon status `accepted`;
+section 10's open questions are carried forward to the first type (T04, T05).
+
+```task
+id: NK-WP-0048-T02
+status: done
+priority: high
+state_hub_task_id: "19c25d96-a55c-58f0-9168-3fdbc4955fc2"
+```
+
+### T02 — Inventory the de-facto types already built by hand
+
+Read-only. List every security integration built so far and group them by shape.
+Known starting points:
+
+- browser OIDC relying parties on key-cape: informed-decision-approver,
+  coulomb-social, user-engine portal, openbao-admin, and Forgejo (pending)
+- confidential service clients with `client_credentials`: secrets-engine
+  approval, requester and openbao clients, approval-engine operator
+- workload KV read lanes on OpenBao: the railiance-platform credential lane
+  designs and CCRs, for example `railiance-backup-offsite-lane`
+- short-lived SSH certificates through ops-warden (`warden sign`)
+- tunnelled operator access (ops-bridge)
+
+For each: the repositories involved, the hand-built steps, attended human steps,
+custody paths, verification evidence, and rollback (if any). Output
+`docs/security-case-type-inventory.md`, ranking candidate types by how often the
+shape recurs and how much manual work each instance costs today.
+
+2026-10-08: done, `docs/security-case-type-inventory.md`. 36 of 37 CCRs are
+already `request_type: workload-kv-read`, a de-facto type reviewed each time as
+if it were new. Browser clients: 5 hand-built plus Forgejo, each with its own
+rollout script. Confidential service clients need a registration plus two or
+three KV-read CCRs each. A forge read identity is needed in bulk by
+ORGREF-WP-0002-T06. Recommendation: oidc-browser-relying-party first (unblocks
+the forge), workload-kv-read second (largest payoff), then forge-read-identity.
+
+```task
+id: NK-WP-0048-T03
+status: done
+depends_on: [NK-WP-0048-T01]
+priority: high
+state_hub_task_id: "e487975b-73b1-516c-971d-da4cbbb93063"
+```
+
+### T03 — Schema, template and validator
+
+- `canon/schemas/security-case-type_v0.1.schema.json` and
+  `security-case_v0.1.schema.json`
+- `security-case-types/_template/` with `type.yaml`, `README.md` and tests to copy
+- a validator, extending `tools/security-scenario-composer/`, that checks a type,
+  checks a case against its type, and renders the case into the composer's
+  deterministic plan (still `execution.permitted: false`)
+
+Acceptance: the validator rejects missing sections, secret-shaped parameter
+values, unpinned providers and cases against non-`implemented` types, with tests
+for each.
+
+2026-10-08: done. `canon/schemas/security-case-type_v0.1.schema.json` and
+`security-case_v0.1.schema.json`; `tools/security-case-types/security_case_validator.py`
+(`validate-type`, `validate-case`, `render`, reusing the scenario composer);
+`security-case-types/_template/` (a valid, runnable example type over
+`net-kingdom.local-identity`, with README sections, an example case and tests that
+travel with every copy). 31 tests pass, including the composer's existing suite.
+
+```task
+id: NK-WP-0048-T04
+status: done
+depends_on: [NK-WP-0048-T02, NK-WP-0048-T03]
+priority: high
+state_hub_task_id: "2fffe112-7d55-5680-9952-78d74f44f87f"
+```
+
+### T04 — Define the first type: browser OIDC relying party
+
+`security-case-types/oidc-browser-relying-party/`, version 1.0:
+
+- parameters: client id, display name, exact redirect URIs, scopes, client type
+  (confidential or public), MFA pin, the groups the consuming service maps,
+  custody path for the secret (confidential only), consuming service and its
+  owner
+- composition: key-cape client registration (key-cape declares it as a playbook
+  capability), secret minting into custody (railiance-platform), LLDAP group
+  existence and membership (net-kingdom identity-provisioner), handover to the
+  consuming service
+- materialization (ops-mason) and follow-through (ops-warden) sections
+- verification: discovery lists the redirect URI; a test sign-in returns the
+  expected claims for one human; anonymous access to the custody path is denied
+- rollback: remove exactly this client and its custody path
+- README: threat model, MFA rationale, why redirect URIs are exact, which steps
+  still need an attended login and how that is minimised
+- reference instances: informed-decision-approver, coulomb-social, user-engine
+  portal, openbao-admin
+
+Acceptance: complete per canon section 3, tests green, status `proposed`.
+
+2026-10-08: done. `security-case-types/oidc-browser-relying-party/` 1.0 (proposed):
+`type.yaml` with 12 parameters (the custody reference is required only for
+confidential clients), composition over key-cape's new
+`key-cape.oidc-client-registration` declaration (contract PASS, `maturity:
+planned`), materialization and follow-through, verification and rollback, all
+conditional on client type where it matters. One attended step,
+`register-client`, justified by the live registry being a Kubernetes Secret.
+README with threat model, alternatives, an honest fit table (portal and vergabe
+fit; Forgejo is the first confidential case; openbao-admin, coulomb.social and
+informed-decision-approver do not fit 1.0), and known limits. Examples: Forgejo
+(checked against the accepted request) and a public portal. The validator gained
+`when` / `required_when` conditions and provider discovery. 43 tests pass.
+ops-mason's and ops-warden's sections are drafted in the type. Their owners
+review them in MASON-WP-0010-T01 and WARDEN-WP-0044-T01 before acknowledgment
+(T05).
+
+```task
+id: NK-WP-0048-T05
+status: done
+depends_on: [NK-WP-0048-T04, MASON-WP-0010-T01, WARDEN-WP-0044-T01]
+priority: high
+state_hub_task_id: "3d987d3d-0797-538b-86e4-51185a327ae2"
+```
+
+### T05 — Acknowledge the type through informed-decision
+
+Prepare the Decision Memo from the type's README and `type.yaml` and submit it
+through informed-decision's production intake. On acknowledgment the type
+moves to `acknowledged`.
+
+2026-10-08: Decision Memo prepared. Hub decision `e418263e-a71f-4f01-a970-c87c9e187c09`.
+`security-case-types/oidc-browser-relying-party/decision/`: `packet.md` (question,
+one act, what acknowledging does not do, the shape, alternatives, attended
+steps, limits, evidence), `build_intake.py` and the built `intake.json` (memo
+class `decision-record`, review group `net-kingdom-admins`, resolves the hub
+decision on answer). The envelope passes informed-decision's own
+`validate_submission`. Queuing it is an attended operator step, a write inside
+the production dispatcher pod:
+
+    kubectl -n state-hub exec -i deploy/state-hub-memo-dispatch -- \
+      python -m api.services.memo_dispatch --queue /data/private enqueue --envelope /dev/stdin \
+      < security-case-types/oidc-browser-relying-party/decision/intake.json
+
+The answer then appears for review in informed-decision.
+
+2026-10-08: queued by the founder (`pending`, `queued`) after one refusal: the
+first envelope's idempotency key was not State Hub's stable
+`state-hub.<decision>.<memo>` form, and the builder now validates against both
+sides. The dispatcher delivered it to informed-decision (ledger 7 → 8
+delivered). T05 waits for the founder's answer in informed-decision, which
+resolves hub decision `e418263e`.
+
+2026-10-08: ops-mason's review (MASON-WP-0010-T01) folded into the type, still
+1.0 `proposed`: `secret_ref` is no longer a parameter, the type derives
+`platform/workloads/keycape/{client_id}`; policies are
+`workload-kv-read-keycape-{client_id}-eso` and
+`workload-kv-read-keycape-{client_id}-{consuming_service}`, each with a templated
+body (`read` on that one data path); new `openbao_role`
+`external-secrets-keycape-{client_id}` (Kubernetes auth, ESO service account,
+15m, no default policy); catalog entry `{consuming_service}-keycape-client`;
+the two rollback steps on the KV path collapse into one metadata delete. The
+schema and validator now require a `body` on policy and role items. 105 tests
+pass. Two consequences: the delivered memo describes the type before these
+changes (a case-set custody reference, two differently named policies, no ESO
+role), so the founder answers on a superseded shape unless the memo is
+re-sent; and Forgejo's custody path moves from the accepted request's proposed
+`platform/workloads/forgejo/netkingdom-oidc-client` to
+`platform/workloads/keycape/forgejo`, which key-cape (KEY-WP-0038) and
+railiance-apps (RAPPS-WP-0016-T02) need to adopt in T06. ops-warden's review
+(WARDEN-WP-0044-T01) is still in progress.
+
+2026-10-08: revised memo `nk-wp-0048-t05-oidc-browser-relying-party-r2` built
+(`packet.md`, `intake.json`, packet `sha256:af6435e2…`); it states that it
+supersedes the first memo and passes informed-decision's and the dispatcher's
+validation. It needs a new memo id because the dispatcher refuses new content
+under a delivered idempotency key (`idempotency_conflict`). Queuing it is the
+same attended step as above. Both memos serve hub decision `e418263e`; the
+first answer resolves it, so the first memo must not stay open: an accept on it
+would acknowledge the superseded shape, and a decline would resolve the
+decision against r2. Close it with `return` (a reviewer verb that requests a
+new revision and does not resolve the hub decision; only accept and decline
+do), commenting that r2 supersedes it, then answer r2. `withdraw` exists in
+the vocabulary but is not offered to reviewers, and lifecycle `revise` only
+applies to lifecycle-registered memos, not intake-delivered ones.
+
+2026-10-09: the founder reports r2 enqueued and the first memo returned. At
+close, hub decision `e418263e` still showed `open` (not verified whether r2
+was answered or the answer is still in transit; the dispatcher ledger was not
+read). ops-warden's review (WARDEN-WP-0044-T01, ops-warden
+`history/2026-10-08-oidc-rp-follow-through-review.md`, d470f2e) arrived at
+21:25, before r2 was built, and is not in r2. Required before WARDEN-WP-0044-T02:
+R1 a per-step `lane` (missing: identity-provisioner caller credential,
+railiance-platform broker grant), R2 canon meaning of `warden_executes: true`
+(caller proxy, caller identity, no standing ops-warden token; ADR-0002), R3 a
+per-step `value_handling`. Refinements R4 (one type-level catalog lane instead
+of a per-case entry, which conflicts with ops-mason's item 5), R5 (ESO Ready gate
+before bind-env), R6 (exact accepted memberships), R7 (mfa-pinned and
+secret-delivered checks). Next: if r2 was accepted, fold R1-R3 and R5-R7 in as
+a follow-up and settle R4 between ops-warden and ops-mason before T06; if not,
+hold r2, fold them in and build r3.
+ key-cape and railiance-apps were told about Forgejo's new custody
+path.
+
+2026-10-09: r2 was not answered (hub decision `e418263e` open; dispatcher 9
+delivered), so r2 is held and r3 replaces it. ops-warden withdrew R4 for R4′
+(message a66a9204): one catalog entry per case with its body templated in the
+type. Folded in:
+
+- Canon section 3: a narrow meaning of `warden_executes: true` (caller proxy,
+  caller identity, no standing credential; ops-warden ADR-0002), plus per-step
+  `lane`, `value_handling` and an optional `ready_check`. A catalog entry body is
+  now required, like policy and role bodies.
+- Schema and validator enforce all of these.
+- The type: lanes `identity-provisioner-groups` and
+  `keycape-client-secret-generate` (both new) and `key-cape-oidc-login`;
+  `mint-secret` is `generated_in_custody`; a Ready gate on `deliver-secret`;
+  `ensure-groups` adds exactly the accepted case's memberships; new checks
+  `secret-delivered` and `mfa-pinned`; the catalog-entry body follows R4′.
+- 110 tests pass.
+
+Memo r3 (`nk-wp-0048-t05-oidc-browser-relying-party-r3`, packet
+`sha256:726dfc01…`) passes informed-decision's and the dispatcher's validation.
+The founder queues it with the same command, returns r2 with a comment that r3
+supersedes it, then answers r3.
+
+Prerequisites for T06, not for T05:
+- the two new lanes, each through its owner;
+- a founder-approved rollout of an identity-provisioner image containing
+  630ebfd (the deployed one is main-6c4fcaf from 2026-09-24, without
+  `/v1/groups/ensure`).
+
+ops-mason's request to create LLDAP group `fluid-telegram-operators` (message
+259ec26d) was answered: not possible from here by that path; the founder creates
+it in the LLDAP admin UI.
+
+2026-10-09: ops-warden finished its side of WARDEN-WP-0044-T01 (message
+`58d33f40`, commit 0e7ceb8): the revised type conforms to `warden case
+check-type`, with no further changes asked of the type. This acknowledges that
+review. Its later addendum R8 (message `af274783`, ops-warden
+`history/2026-10-08-oidc-rp-follow-through-review.md`) showed that lane
+`identity-provisioner-groups` cannot exist as declared: the provisioner's only
+HTTP credential is user-engine's runtime token, and its NetworkPolicy admits
+only user-engine pods, so a caller-proxy lane would act as user-engine. Taken
+option 1 (ops-warden's recommendation): `ensure-groups` and its rollback are
+attended, in the `register-client` session on `key-cape-oidc-login`, run inside
+the provisioner pod; no token is read. Option 2 (an operator credential of its
+own on the provisioner) stays open for a later version. `warden case
+check-type` now reports only `keycape-client-secret-generate`
+(railiance-platform) as missing. 89 tests pass.
+
+Hub decision `e418263e` was still open, so memo r4
+(`nk-wp-0048-t05-oidc-browser-relying-party-r4`, packet `sha256:452ea421…`)
+replaces r3; it passes informed-decision's and the dispatcher's validation. The
+founder queues it with the same command, returns r2/r3 if still open with a
+comment that r4 supersedes them, then answers r4.
+
+Prerequisites for T06 are now: lane `keycape-client-secret-generate`
+(railiance-platform), and a founder-approved rollout of an identity-provisioner
+image containing 630ebfd.
+
+2026-10-09: done. The founder queued r4 (`pending`, `queued`), returned r3 as
+superseded and accepted r4 in informed-decision. informed-decision's hub
+write-back is off in production (`INFD_HUB_WRITEBACK` unset), so net-kingdom
+resolved hub decision `e418263e` from the founder's report, naming memo r4 in
+the rationale. The type is `acknowledged`; it becomes `implemented` with T06.
+
+```task
+id: NK-WP-0048-T06
+status: wait
+depends_on: [NK-WP-0048-T05, NK-WP-0048-T08, NK-WP-0048-T09, NK-WP-0048-T12, NK-WP-0048-T13, NK-WP-0048-T14, NK-WP-0048-T15, NK-WP-0048-T16, NK-WP-0048-T17, NK-WP-0048-T18, NK-WP-0048-T20, MASON-WP-0010-T03, WARDEN-WP-0044-T03]
+blocking_reason: "Type1.2 architecture has a confirmed source-only founder acknowledgment; canonical1.1 remains unchanged/default and the1.2 reference case stays proposed. Needs explicit version selection/reference-source integration without normal admission bypass, closed owner adapters plus global/native receipt verifier (WARDEN-WP-0044-T03), independently verified six-object structural materialization and CCR42 claims/created-only provenance, exact broker/case/source reconciliation, then separately authorized native mint/delivery and attended registry/consumer verification. Source acknowledgment, a bundle or local tests do not prove implemented/materialized/live status."
+priority: high
+state_hub_task_id: "d9b26bcf-a7c6-59a2-92a0-f913d76a203c"
+```
+
+### T06 — First KnownSecurityCase: Forgejo
+
+Write `security-cases/forgejo-netkingdom-oidc.yaml` from the parameters the
+founder accepted in KEY-WP-0038-T01 (`key-cape/docs/forgejo-oidc-client-request.yaml`),
+so that acceptance carries over as the case acceptance. ops-mason materializes it;
+ops-warden follows through and verifies it. The type becomes `implemented` once
+this reference case is live.
+
+This replaces the hand-built path proposed for KEY-WP-0038-T02.
+
+2026-10-09: case written, `security-cases/forgejo-netkingdom-oidc.yaml`, status
+`accepted`: the example's parameters plus the founder's 2026-10-08 acceptance of
+the key-cape request (owner and founder), with the custody-path derivation
+covered by the type's acknowledgment (memo r4). It validates and renders (plan
+`execution.permitted: false`; three attended steps on `key-cape-oidc-login`);
+it needs `--allow-unimplemented` until it is live, since it is the case that
+makes the type `implemented`. A test keeps it equal to the type's example.
+Still open before it runs: ops-mason renders and builds it (MASON-WP-0010-T02,
+T03, unblocked by T05), ops-warden plans and runs it (WARDEN-WP-0044-T02, T03),
+railiance-platform's `keycape-client-secret-generate` lane (asked by ops-mason
+`789feb39` and ops-warden `d9f889b1`, both unread), and a founder-approved
+identity-provisioner rollout containing 630ebfd.
+
+2026-10-09: identity-provisioner rolled out, founder-approved in session:
+`main-630ebfd` (`sha256:bafb4860…`, built by the image workflow) replaces
+`main-6c4fcaf` (`sha256:ffacd5d7…`; only change: 630ebfd, additive). Applied
+with `kubectl set image` on the Deployment only (generation 17 → 18, 1/1 Ready);
+the file's Service, NetworkPolicies and Ingress were not reapplied. Verified in
+the pod: `ensure_service_groups` and `revoke_service_groups` present, `/readyz`
+200; no token used, no group changed. Rollback: `kubectl -n sso set image
+deploy/identity-provisioner provisioner=forgejo.coulomb.social/coulomb/identity-provisioner@sha256:ffacd5d790a5b7800e0535f3aa95b7de52c7a68e4f575b9192c3e1622fa672c2`.
+The pin in `sso-mfa/k8s/identity-provisioner/deployment.yaml` follows.
+
+2026-10-09: ops-warden closed WARDEN-WP-0044-T01 and shipped `warden case plan`
+(T02, message `06303d1d`); the accepted Forgejo case is refused until ops-mason
+materializes it, and a materialized copy plans cleanly once
+`keycape-client-secret-generate` exists. Its observation that `bind-env` carries
+a literal `KEYCAPE_<CLIENT_ID>_CLIENT_SECRET`: the validator now renders a
+`{param:env}` format spec (upper case, `-` as `_`, as `keycape-client.py`
+derives the name) and rejects unknown specs, and follow-through and rollback
+text is now checked for unknown placeholders too (patch-level, canon section 6).
+The type keeps the literal until ops-warden's planner (`text.format`) renders the
+spec as well; asked of ops-warden. 53 tests pass.
+
+2026-10-10: ops-warden rendered `{param:env}` in `warden case plan`
+(23ba584, message `c1df14b7`; other specs and `!conversion` refused). The type
+adopts it as a 1.0 patch (canon section 6): `bind-env` and its rollback now read
+`KEYCAPE_{client_id:env}_CLIENT_SECRET`. ops-mason reports the Forgejo case
+rendered and built (message `1ebddae9`; CCR drafts handed to railiance-platform),
+so T06 now waits on the platform apply, the mint-secret lane and the attended
+register-client session.
+
+2026-10-10: key-cape adopted the type's custody path (key-cape ab5cccd, message
+`88a4559c`): `docs/forgejo-oidc-client-request.yaml` and KEY-WP-0038-T02 name
+`platform/workloads/keycape/forgejo`, field `CLIENT_SECRET`, delivered as
+`sso/keycape-forgejo-client` through `external-secrets-keycape-forgejo`, and the
+`forgejo/netkingdom-oidc-client` proposal is withdrawn. This matches the type and
+the Forgejo example; no change needed here.
+
+2026-10-10: key-cape's type-composition review (key-cape 6038483, message
+`8e5ed5f6`) found the composition sound with two blocking findings, taken as a
+1.0 patch (stricter validation and documentation, canon section 6):
+R1, redirect URIs now refuse `?` and `#` in the type pattern and in
+`keycape-client.py`'s `REDIRECT` (KeyCape refuses `?` at startup and the single
+replica would stop); R2, `allowed_scopes` always includes `groups`, the renderer
+refuses `access_groups` without it, and `access_groups` now says the consumer
+enforces the gate because KeyCape has none; R3, `mfa_required` "false" means the
+per-user privacyIDEA policy; R4, register-client's justification records the
+restart for every client, the quiet window, and that the rendered registry must
+pass KeyCape's client validation before it. The accepted Forgejo case and both
+examples still validate; 116 tests pass.
+Open, needs a decision: R2's verification step that the consumer enforces the
+group gate is a new verification step, hence 1.1 (minor), and the validator pins
+cases to the exact type version, so the accepted 1.0 Forgejo case would need
+re-pinning. Also open with key-cape: a KeyCape entry point that validates a
+rendered client registry without starting the server; until then
+`keycape-client.py` mirrors the redirect rule.
+
+2026-10-10: founder go for 1.1, so no 1.0 run overlaps. The type adds
+verification `consumer-enforces-groups`, and hand-over now requires the consumer
+to enforce `access_groups` (minor, canon section 6; risk class unchanged, no new
+acknowledgment; history in the type README). The accepted Forgejo case and both
+examples are re-pinned to `oidc-browser-relying-party@1.1` before any apply; the
+acknowledgment intake keeps `@1.0` as the record of what was acknowledged.
+ops-mason's build and ops-warden's case-ref digest predate this and need a
+re-render.
+
+2026-10-10: ops-mason re-rendered the Forgejo case from `@1.1` (message
+`22c6bba6`; plan digest `af1f4f81…`, no collisions) and rebuilt the bundle. The
+rendered OpenBao objects are identical to 1.0, so the already applied
+CCR-2026-0041 stands; 1.1 changes only consumer-side steps. key-cape shipped
+`keycape check-config` (c528daa, message `a7b0aeff`): KeyCape's startup checks
+without secret values, including the new duplicate-clientId rule.
+`keycape-client.py --check-config <binary>` now runs it on the live and the
+proposed registry, fed on stdin, and apply refuses a proposed registry that
+fails; register-client's entry point names the option (1.1 patch). The deployed
+image predates c528daa, so the binary is built from key-cape source for now.
+Before the next KeyCape rollout (Forgejo register-client or the CCR-2026-0018
+window), the attended operator runs `inspect --check-config` so the live
+registry is checked too.
+
+```task
+id: NK-WP-0048-T07
+status: wait
+depends_on: [NK-WP-0048-T06]
+blocking_reason: "The next types follow once the first one is proven end to end."
+priority: medium
+state_hub_task_id: "c3c9c3ae-4f23-5ba7-9e6f-e63bcf29b9f7"
+```
+
+### T07 — Queue the next types
+
+From the T02 ranking, open the next type drafts (likely the confidential service
+client and the workload KV read lane), each to be acknowledged on its own.
+Record which existing hand-built instances get adopted as cases, without
+rewriting them in place.
+
+```task
+id: NK-WP-0048-T08
+status: done
+priority: high
+state_hub_task_id: "8e519082-dc8b-5e46-b660-03d03e55dcf6"
+```
+
+### T08 — identity-provisioner: ensure service-access groups
+
+The type's `ensure-groups` step calls `identity-provisioner groups ensure --groups
+<list> --members <group=user+user;...>`. The provisioner already has idempotent
+`_ensure_group` and `_add_group`, but exposes only tenant-scoped operations. Add
+the general operation (create if absent, add the listed memberships, never
+remove others), its rollback (remove only this case's memberships), tests, and
+the ops-warden route for its service identity.
+
+2026-10-08: done. `identity-provisioner/provisioner.py` gained
+`ensure_service_groups` (`POST /v1/groups/ensure`) and `revoke_service_groups`
+(`POST /v1/groups/revoke`), behind the existing service-token check. Names
+matching `tenant*`, `netkingdom-*` and `lldap_*` are reserved; members must
+already exist; everything is validated before any change; memberships are read
+back before success; nothing else is ever removed; groups are deleted only when
+asked and empty. 7 new tests (39 in the provisioner suite). The type's
+`ensure-groups` step and its rollback now name these endpoints. The ops-warden
+route for the provisioner's service token belongs to WARDEN-WP-0044-T01.
+
+```task
+id: NK-WP-0048-T09
+status: done
+priority: high
+state_hub_task_id: "0ee12dfc-8260-5038-bd39-cc7fb4113be0"
+```
+
+### T09 — The `keycape-client` entry point and its declaration
+
+Planned first as key-cape KEY-WP-0038-T04. Moved here because the machinery a
+live registration needs already lives in net-kingdom, where KeyCape is deployed
+(`sso-mfa/k8s/keycape/`): the contained kubectl, the cluster-identity pin and the
+issuer pin. A copy in key-cape would drift.
+
+2026-10-08: done. `sso-mfa/k8s/keycape/keycape-client.py` derives the KeyCape
+client record from a case (`client-from-case`). It adds or removes exactly one
+client with the existing safeguards (byte-preserving merge, exact match or
+refuse, shared-reference refusal, compare-and-swap, read-back, contained errors),
+requires the Deployment env binding first for confidential clients, and requires
+the case acceptance record for `apply` instead of a per-client founder decision
+id. 15 tests, including a regression showing that the vergabe case reproduces
+its hand-built registration exactly; all 71 helper tests pass. Declaration
+`capabilities/playbooks/net-kingdom.keycape-client-registration.yaml` (contract
+PASS, `maturity: implemented`) replaces key-cape's draft. The type now pins it,
+and for confidential clients adds `deliver-secret` (delivery from custody into
+the sso namespace) and `bind-env` (Deployment env), attended in the same session
+as `register-client`. The per-client helpers stay until their clients are
+adopted as cases.
+
+2026-10-10 — NetKingdom owner review of the execution seam, source only:
+ops-warden/docs/security-case-execution-proposal.md SHA256 78ab1439e4c5beb205aeccf15b1b2e706511be55ab195c5a3aa682f326c7c77c
+was reviewed against INTENT, SecurityCase canon, acknowledged type1.1, current
+case and owner source. docs/security-case-execution-owner-review.md supports
+the closed adapter/receipt direction with explicit versioned schema, structural
+materialization provenance, unchanged caller/session boundaries, safe CAS
+reconciliation and exact-created-object rollback requirements. This is owner
+review, not approval. Supporting file digests are in the adjacent sources JSON.
+
+Current source exposes a circular wait: ops-mason T03 waits on mint while Warden
+and the broker refuse a non-materialized case. Structural acceptance therefore
+needs its own native pinned receipt before mint, not a successful mint before
+materialized. The platform broker additionally pins type1.0 while Forgejo is
+accepted at1.1; platform-owner alignment and tests are required, not an unchecked
+version bypass. T06 remains wait. No case/type lifecycle status, grant, authority
+or live runtime changed by this review. A proposed informed-decision would
+adopt the source contract only; native materialization and execution acceptance
+stay distinct.
+
+Final proposal re-review: staged Warden proposal SHA256 78ab1439e4c5beb205aeccf15b1b2e706511be55ab195c5a3aa682f326c7c77c
+adds only the explicitly local reducer appendix, not an accepted wire protocol
+or executor. The exact-final review and sources JSON supersede the earlier
+1035f049... proposal review. Platform staged the exact type1.1 broker correction
+with ten fake-backend subprocess checks (script SHA256
+9576cd211cfc06526ec4cc9bd0a5b06f0f59287a68931bb2d6e3592a951ddc7d).
+The next source work is the versioned closed adapter/receipt/materialization
+contract, not another relaxation of the broker's status gate. Native work still
+requires installed broker provenance, structural reader receipts, exact new
+materialized-case bytes, caller grant/session revocation and verified execution.
+No installed/native acceptance is inferred from that staged correction.
+
+2026-10-11 — new source-only type1.2 architecture acknowledgment:
+Confirmed native founder ACCEPT of infd-20261011-forgejo-type12-source-r1@1
+at06:47:39Z, approval8e9332c8-754a-420c-b8b7-445cb4fe6765. Exact frozen packet
+0b377d647ca748cd03c92f9792396412048055d4bde9f7bb06ff6d413f7acd68 and submission
+585cee731de30d2b37883a57abfd9eb32f023ee694e8d911989109d5caf80569; native receipt
+retained in docs/evidence/2026-10-11-forgejo-type12-source-acknowledgment/.
+The complete acknowledged1.2 source package is isolated under
+security-case-type-revisions/1.2/oidc-browser-relying-party; default loader and
+current accepted1.1 case remain untouched because load_type is single-version.
+The new proposed1.2 case is NOT accepted/materialized/live and has no acceptance
+fields. Actual reference-migration design approval is a separate Apps owner
+receipt; no1.1 approval is inherited. Source-recording review/test proof and exact
+next gates are in docs/forgejo-type12-source-acknowledgment-followthrough.md.
+T06 remains wait and T07 remains its existing dependent task; type is NOT
+implemented and no first-case/native grant or broader workplan finish is asserted.
+
+2026-10-11 — bounded explicit version selection source preparation for T06:
+The validator now offers optional exact version_roots/--version-root VERSION=PATH
+selection with duplicate/mismatch/traversal/symlink refusal and no fallback. The
+default1.1 source and historicalacceptedcase hashes/ordinaryrefusal/preparation
+render stayunchanged; actual1.1 is acknowledged, not implemented. Acknowledged1.2
+ordinaryadmission also refuses; optionalpreparation remains nonexecuting.43local
+validatorchecks pass and original1.1 CLIrenderbytes match exactly. Makerproof:
+docs/evidence/2026-10-11-explicit-type-version-selection/source-integration-validation.json.
+FormalNetownerreview/reference-source integration and all existing native adapter,
+provenance/broker/materialization/attendedproof gates remain; T06 stayswait, no
+new residual or firstcase/typeimplementation/native grant is inferred.
+
+
+2026-10-16 — isolated source preparation for T06 (canonical integration pending):
+Added `check-evidence` to the existing validator CLI. It reuses exact version
+selection and ordinary type/case/render admission, checks actual Mason structural
+request source/inventory/projection pins and reads actual Warden journal rows
+read-only. Successful rows require exact type-declared descriptors and attempt/
+revocation fingerprints. Existing acknowledged types without machine descriptors
+remain plan-only. The compatibility result never claims authenticated native
+completion: Request and journal fingerprints are not portable native evidence.
+Owner authentication/status binding and actual native gates remain unresolved;
+T06/T07 statuses and both type/case lifecycles remain unchanged. No dispatch,
+credential access or authority expansion is introduced. See tool README for the
+existing owner protocol boundaries and source integration tests.
+
+Concrete next Warden owner integration: current `Executor.admit` refuses every
+case parameter whose sensitivity is not public/operational, so browser
+`redirect_uris`, `allowed_scopes`, `client_type`, `mfa_required` (and 1.2
+`consumer_namespace`) fail after otherwise prepared admission. The sensitive
+classification is a security-change review level, not secret content. The
+Warden owner must validate through NetKingdom's existing exact-version case/type
+validator, then project only descriptor-declared safe target metadata; do not
+remove the credential/value refusal or copy complete parameters into journals.
+Actual owner descriptor acknowledgment and independent evidence admission remain
+prerequisites, with normal admission still refusing unimplemented types.
+
+
+## T10 — Source compatibility checker for Mason and Warden evidence
+
+```task
+id: NK-WP-0048-T10
+status: done
+priority: high
+state_hub_task_id: "4b06ca97-c1e4-5680-bf22-ab75ab1646a4"
+```
+
+Completed 2026-10-16 in published source `c31d21ba`. The read-only
+`check-evidence` command checks the actual Mason structural request and Warden
+journal source protocols against an exact version/render. Independent source
+review passed 103 tests at that checkpoint. It always reports native completion
+false and execution prohibited. Fixtures and local journal fingerprints do not
+provide authenticated owner/native evidence. This records completed source scope
+previously described under T06; it does not duplicate native acceptance credit.
+
+## T11 — Validate the optional machine-descriptor pin contract
+
+```task
+id: NK-WP-0048-T11
+status: done
+priority: high
+state_hub_task_id: "ef2a0119-f59e-5e45-9519-115da9df7b85"
+```
+
+Completed 2026-10-16. Reproduced the JSON schema rejecting a valid
+`execution_descriptors` map while the Python validator accepted malformed maps.
+The schema now supports the existing Warden optional exact-byte pin map; semantic
+validation binds keys to declared steps, bounds the map and checks digest shape.
+The direct evidence API refuses malformed maps before accessing them. Twenty-one
+new checks and all 127 affected source checks passed. No current type/case bytes,
+status, owner descriptors or native acceptance changed. Source evidence and
+publication receipt: Custodian
+`docs/changes/netkingdom-target-2026-10-16/browser-acceptance-next/`.
+
+## T12 — Prepare NetKingdom-owned attended step adapters
+
+```task
+id: NK-WP-0048-T12
+status: todo
+priority: high
+state_hub_task_id: "7ce4eee3-cd47-55a9-bfa5-4f1835d4d6fd"
+```
+
+Owner: NetKingdom. Retained scope: prepare bounded attended Deployment env,
+config verification and restart/readiness steps around the existing helpers.
+Next action: identify exact current entry points and their revision/readback
+contracts, then implement fixed source-pinned callbacks or receipt-only attended
+steps. Completion requires positive/refusal checks, exact target/source pins and
+uncertainty behavior without acquiring user-engine runtime identity or exposing
+registry/client secrets. Existing caller/session, cluster/issuer, CAS/readback
+and status-only output boundaries remain mandatory.
+
+2026-10-16 task refinement: the original broad adapter scope is split into T13
+(completed registration source candidate), T14 (group creation provenance), T15
+(durable registration recovery) and T16 (descriptor/artifact selection and owner
+review). This preserves T12's task ID and Hub UUID while giving each remaining
+outcome an owner and completion gate. T06 now names every source dependency;
+its native/reference lifecycle acceptance scope remains unchanged. Completion
+of any source task supplies no Warden, Platform or Apps assent and no native
+execution authority.
+
+## T13 — Prepare the fixed registration adapter source candidate
+
+```task
+id: NK-WP-0048-T13
+status: done
+priority: high
+state_hub_task_id: "b264c10b-565c-5d29-b788-03cf5fbd2883"
+```
+
+Completed 2026-10-16, source implementation and synthetic fixture proof only.
+Added an injection-only adapter around actual `keycape-client.run`: fixed
+case/principal/human/lane/source/acceptance binding, existing CAS/readback,
+metadata-only owner evidence and per-attempt parent-session revocation boundary.
+The descriptor source composition pins the exact checker executable digest
+alongside adapter/helper source. Creation-only rollback authenticates its
+creation receipt and refuses changed postcreation UID/resourceVersion;
+pre-existing clients confer no rollback authority. Missing readback, evidence,
+revocation or process-local creation provenance cannot become retry-safe success.
+
+Evidence: Custodian `docs/changes/netkingdom-target-2026-10-16/browser-adapter-next/`
+R3 candidate, explicit patch and postimages, retained R1 rejected custody finding
+and R2 revision, and 36 passing source checks (16 new, 20 existing). Three checks
+use actual Warden kernel admission/dispatch/rollback with published Warden
+`d97652a3bb5fa733b063d71a1b74068efcccf572` producer pins unchanged. Owner trust,
+descriptor/type/case and Kubernetes objects remain synthetic fixtures. This
+records a completed source deliverable, not independent review, publication,
+type acknowledgment, exercised procedure, identity admission or native browser
+acceptance. Independent root source review: Custodian browser-adapter-next/coordinator-review-r3.json. Source integration and normal publication/synchronization receipts: Custodian browser-adapter-next/canonical-integration.json. These receipts supply no other-owner assent or native authority.
+
+Source publication: `0775c2bfa41af236301155bb5a69bbf088bdf823`, independently
+reviewed by the Custodian coordinator before integration. The required initial
+projection and ordinary UUID writeback both completed with zero failures and
+zero automation errors. Generated-only brief commits were refused by the normal
+hook; exact pre-existing staged/working brief bytes were restored. The separate
+canonical integration receipt retains those refusals and projection evidence.
+Native admission and all other-owner acceptance remain open.
+
+## T14 — Admit governed group rollback against native owner boundaries
+
+```task
+id: NK-WP-0048-T14
+status: progress
+depends_on: [NK-WP-0048-T20, NK-WP-0048-T21]
+priority: high
+state_hub_task_id: "fce95440-a25b-5f27-8ef3-a3d182099113"
+```
+
+Owner: NetKingdom. Next action: bind the completed T21 PostgreSQL journal to
+an admitted dedicated CNPG consumer through the existing `rapp-postgres`
+database-per-consumer contract. Identify the actual deployment/package and
+custody owner, admitted placement/capacity and role/renewable lease/TLS target;
+implement the independently retained exact content checkpoint and authoritative
+tenant/case/source/principal callbacks before enabling governed group operations.
+The injection-only backend and fixture callbacks do not supply production scope
+or authorization. Existing service tokens, caller-supplied JSON and provenance
+receipts confer no new grant. The default production endpoint remains disabled
+without the trusted integration. SQLite remains local/disposable only; any
+production exception requires explicit scoped governance under ADR-0015.
+
+2026-10-17 owner-integration refinement: T23 records the completed source/package
+placement review, distinct from T21's source/disposable-SQL proof. Its dedicated
+`rapp-identity-provisioner` recommendation is draft and unbound, not an accepted
+package or existing repository. The full six-consumer rapp-postgres renderer
+accepts the inert candidate on platform-pg-2 as its third of four declared
+consumers; first-cell placement is refused as a fifth. Neither the estimated
+four-consumer ceiling nor source requests establish native headroom or backup.
+
+Next independent owner contracts: NetKingdom/package/substrate owners accept
+exact deployment/rollback fate; rapp-postgres admits the dedicated consumer,
+roles, five-connection budget and actual backup/restore; Platform admits exact
+renewable runtime/migration delivery and TLS/CA/SAN; network owners scope SQL,
+broker and checkpoint paths without assuming a narrow policy subtracts additive
+same-namespace access. Protected caller owners must provide authoritative
+GroupJournalBinding construction and current authorization; an independent
+existing holder must authenticate and atomically advance the exact content
+checkpoint, not a counter or ordinary Audit receipt. Directory/runtime owners
+must select and prove either an exclusive all-writer maintenance barrier or
+provider-supported CAS/generation, including established sessions, lifecycle
+cascades and remove/readd ABA. No source review establishes those owner facts.
+
+The default PostgreSQL activation and destructive native rollback remain refused.
+Storage/lease acceptance can be proposed separately from LDAP mutation only after
+exact owner source/target/custody/verification/recovery and cost/risk review;
+State Hub guard approval grants none of it. Source-only integration review and
+native acceptance matrix: Custodian native-storage-r1/OWNER-REVIEW.md. T14's
+existing status, UUID, dependencies and native completion gate are retained.
+
+2026-10-17 refinement: T20 retains the historical durable SQLite source and
+actual disposable LLDAP proof. T21 extracts the completed PostgreSQL source and
+bounded real disposable SQL compatibility proof. T14 remains `progress` for
+native CNPG admission/recovery, protected owner integration and exclusion of all
+external LDAP writers. Separate source publication/projection and independent
+cleanup receipts belong to coordinator follow-through; no missing native assent
+is represented as received.
+
+Completion still requires independently reviewed/admitted ADR-0015-conforming
+CNPG storage (or an explicit governed exception), backup/lost-store recovery and
+migration of legacy requests; a native
+writer-isolation/fencing or provider CAS/version contract that closes external
+writer races and remove/re-add ABA; exact case/source/principal and current
+native object bindings for protected callbacks; and actual per-attempt evidence,
+revocation and readback/refusal verification through the existing owner paths.
+Only independently retained confirmed creations may be undone. Every
+pre-existing/shared group and membership must remain preserved; unresolved
+intents never expire into retry authority. The disposable fixture supplies none
+of these native custody, authorization, owner-acceptance or production claims.
+
+## T15 — Define authenticated recovery for lost registration process state
+
+```task
+id: NK-WP-0048-T15
+status: todo
+priority: high
+state_hub_task_id: "1b825705-4848-5edc-832f-b1622cd9bdb7"
+```
+
+Owner: NetKingdom for registration state, with Warden owning kernel evidence
+admission. T22 records the completed source review and exact existing-seam gaps;
+T15 retains implementation and authenticated restart/lost-receipt acceptance.
+Next action: identify the actual owner publisher/authenticator and bounded
+original-attempt readback contract, and obtain Warden's reviewed original-intent
+lookup/context interface through existing WARDEN-WP-0044-T03. The current Journal
+retains attempt identity in historical rows but only hashes evidence references;
+load drops that context and reconcile passes a fresh attempt to the callback.
+The adapter's original payload and creation record remain process-local. Neither
+that journal nor a current matching registry entry reconstructs creation authority.
+
+The owner contract must bind the original Invocation, case/type/descriptor/catalog/
+acceptance pins, source, principal and admitted tenant/realm provenance, separately
+from the new reconciliation attempt and its independently revoked parent session.
+Use an existing authenticated holder/readback; Audit Core's custody API is a
+candidate only until its actual registration source/class, load-bearing emission
+contract and separate scoped reader are admitted. No new broker or receipt trust
+root is proposed. A missing original record, ambiguous publication, NO_CHANGE,
+changed native revision or lost readback stays uncertain; no add replay or undo.
+
+Completion requires restart/lost-receipt fixtures against the selected actual owner
+contract: independently authenticated original created-only provenance, original
+exact client entry and unchanged current postcreation UID/resourceVersion before
+any undo, with wrong attempt/case/source/principal and unavailable-holder refusals.
+The T13 adapter deliberately refuses post-restart rollback and installs no
+reconciliation callback. Existing source review, JSON receipts and synthetic
+trust do not satisfy native holder acceptance or authorize attended recovery.
+Exact remaining owner facts: Custodian native-registration-r1/original-attempt-review.json.
+
+## T16 — Select and review the actual machine descriptor composition
+
+```task
+id: NK-WP-0048-T16
+status: todo
+priority: high
+state_hub_task_id: "200bf500-5084-5ae7-be26-3033fe1f296e"
+```
+
+Owner: NetKingdom for descriptor/type source and exact checker artifact; Warden
+independently owns global provenance/admission. T22 records the completed seven-step
+source1.2 inventory and regenerated register-client descriptor using the delivered
+checker and current sealed-snapshot source; T16 retains exact owner review,
+complete descriptor composition and admission. Next action: bind actual native
+publisher/authenticator, original/current session verification and revocation,
+executable storage/custody and config pins, then obtain the six missing fixed
+owner descriptors/adapters for ensure-groups, mint-secret, deliver-secret,
+bind-env, deliver-consumer-secret and hand-over. The inventory identifies each
+existing owner seam, exact missing contract and created-only rollback requirement;
+it is not an executable bundle. T14 and T15 remain independent prerequisites.
+
+Review the dedicated consumer source1.2 composition only through the existing
+explicit version-root selection. Keep canonical1.1/default and its accepted case
+unchanged, and the source-only acknowledged1.2 reference case proposed without
+acceptance fields. New descriptor bytes require a reviewed exact successor
+revision/version under canon section6; they do not inherit historical source
+acknowledgment. Changed authentication/materialization/trust needs the prescribed
+informed-decision acknowledgment. Do not insert a partial descriptor map or use
+--allow-unimplemented preparation as ordinary case/native admission. The registry
+helper reports restart_required; separately review quiet-window restart/readiness
+and actual consumer verification rather than infer activation from registry CAS.
+Exact composition: Custodian native-registration-r1/descriptor-composition.json.
+Completion requires separate owner source review of exact machine descriptors,
+artifact/source/config pins, normal type/version admission and independent
+evidence-verification boundaries. Warden d97652a refreshes producer validator
+pins for NetKingdom 015694ee; it does not attest T13's new adapter. Pinning any
+machine descriptor into an acknowledged type is a separately reviewed source
+change. Platform owns structural/mint/broker/delivery evidence; Apps owns actual
+consumer login/group enforcement. Neither their assent nor native acceptance is
+supplied by this task.
+
+2026-10-16 source checkpoint: T19 below extracts the completed per-attempt
+executable snapshot implementation and reviewed fixture proof. T16 retains
+native executable storage/custody, exact owner evidence/session callbacks,
+complete descriptor composition and ordinary type/version admission. The
+successor descriptor/source pins are proposed only; the earlier descriptor
+history is preserved. T14 group provenance and T15 durable restart/recovery
+remain independent open requirements. No native acceptance is counted here.
+
+## T17 — Build and exercise the exact offline config-checker artifact
+
+```task
+id: NK-WP-0048-T17
+status: done
+priority: high
+state_hub_task_id: "8c3e4baa-a218-5996-af9e-fe1153a46dac"
+```
+
+Completed 2026-10-16, isolated artifact/source fixture proof only. Built the
+existing `key-cape/src/cmd/keycape` command from published clean source revision
+`3c71226a1a7b8a2bdb710e9c497e1a1f7f8a3987`, source tree
+`f0010b9cab17dbc3a787628a29657d98b900320f`, with cached Go 1.23.0,
+CGO disabled, Linux/amd64 v1, trimmed paths, disabled VCS stamping and offline
+read-only module selection. The full retained closure pins 108 source files,
+9876 toolchain files and ten used module source directories. Three isolated
+build locations produced identical 13633409-byte artifacts:
+`sha256:be37738fe1c08259fb4f9ca0daf0f9301bfffc237e5bb38435525dfbf11ccff5`.
+
+Eight disposable checks use the actual executable and maintained helper/kernel,
+with complete synthetic configs and a minimal environment: add/created-only
+removal, normal pinned producer admission, rollback, lost-readback uncertainty,
+stale revisions, substituted checker refusal, invalid startup config and missing
+secret-env refusal. No checker stub or producer-pin override remains. The
+artifact-bound descriptor proposal is
+`sha256:76b1153d188062ece53fcd5e8d35290fdbfd02a69dd79d4b001fc42781afcdc3`.
+Evidence: Custodian
+`docs/changes/netkingdom-target-2026-10-16/browser-checker-artifact-next/`.
+The first two build attempts succeeded but their closure collection failed;
+both failures are retained, as is refusal of the older incomplete synthetic
+fixture. No production config, credentials or cluster mutation was used.
+
+This extracts completed build/fixture scope from T16 without claiming KeyCape
+owner endorsement, native checker selection/storage custody, acknowledged type
+integration, native evidence/session callbacks or attended browser acceptance.
+T16 retains exact owner review and composition/admission scope. The attended
+registration procedure remains unexercised.
+
+## T18 — Make checker input and executable selection deterministic
+
+```task
+id: NK-WP-0048-T18
+status: done
+priority: high
+state_hub_task_id: "9c45da71-fb4c-5f20-9065-90f448f37c64"
+```
+
+Completed 2026-10-16, isolated source correction and real-artifact fixture proof
+only; independent integration/publication remain separately recorded. KeyCape
+source review identified non-secret `KEYCAPE_ACCOUNT_PORTAL_URL` and
+`KEYCAPE_BROWSER_LOGOUT_URL` overrides in config.Load. The original helper
+inherited ambient environment, allowing valid supplied configuration to be
+rejected or invalid supplied URL configuration to be admitted. A bare relative
+checker filename could also be replaced by PATH lookup after the adapter had
+hashed the selected local file. All three counterexamples are retained against
+the unchanged predecessor.
+
+The existing helper now resolves the selected checker file to an absolute path
+and passes an explicit empty subprocess environment. Three opt-in real-checker
+regressions verify both URL-verdict directions and relative-file selection under
+a non-checker PATH decoy. All 39 affected checks pass with the exact supplied
+artifact, as do 11 real-artifact helper/kernel scenarios. Source evidence:
+Custodian `docs/changes/netkingdom-target-2026-10-16/browser-checker-environment-r2/`.
+Historical descriptors remain retained; the helper correction changes successor
+source-composition pins and requires their separate review/admission. An absolute
+path is not immutable custody and does not eliminate file replacement races;
+T16 retains native executable storage/custody and callback/type admission.
+No production configuration, credentials or cluster mutation was used.
+
+Source integration and publication: `916ba4b33e03179274d03b78bd898a4843e8653f`, following independent
+Custodian source review in browser-checker-environment-r2/coordinator-review.json.
+The ordinary protected projection pass assigned T17/T18 UUIDs with zero failures
+and zero automation errors; generated-only brief commit refusal is retained.
+The exact prior staged/working brief bytes were restored. Final source/publication/
+projection evidence is retained in Custodian browser-checker-environment-r2/
+canonical-integration.json. These source receipts do not admit native executable
+custody, owner callbacks, acknowledged type changes or browser identities.
+
+## T19 — Bind checker execution to verified immutable attempt bytes
+
+```task
+id: NK-WP-0048-T19
+status: done
+priority: high
+state_hub_task_id: "f50fdcd1-00be-5c3c-be0c-345aa2126032"
+```
+
+Completed 2026-10-16, independently reviewed source implementation and synthetic
+fixture proof only. The registration adapter now opens a bounded regular checker
+artifact without following its terminal symlink, verifies the reviewed digest,
+and snapshots the exact bytes into a write/grow/shrink/seal-removal-sealed Linux
+memfd before helper access. Live and proposed config checks execute that same fd
+through procfs with the existing empty environment; the fd closes on completion
+or failure. Unsupported snapshot/seal/exec policy refuses through the existing
+parent-session revocation and uncertainty boundaries. The earlier unbounded
+pre-snapshot path read was removed during independent review; actual adapter
+symlink/FIFO/oversize refusal tests verify helper access never starts.
+
+Evidence: Custodian `docs/changes/netkingdom-target-2026-10-16/browser-resume-r1/`,
+including exact base/preimages/postimages/patch, proposed descriptor, coordinator
+source review and canonical integration receipt. Independent Custodian checks
+passed 49 affected source tests and 12 actual Go checker/helper/kernel scenarios;
+the sets overlap and are not separate acceptance counts. Existing published
+Warden d97652a producer pins remain unchanged. The exact KeyCape artifact remains
+`sha256:be37738fe1c08259fb4f9ca0daf0f9301bfffc237e5bb38435525dfbf11ccff5`.
+The predecessor path-replacement refusal and the first expanded reopened-fd test
+failure are retained; the latter fixture was corrected to restore write mode
+before independently proving seals block reopened-fd writes and shared mmap.
+
+This source task adds no native owner custody, callback, evidence trust, type
+acknowledgment, credential access, consumer sign-in or rollback acceptance.
+Executable memfds, Linux seals and usable procfs are explicit runtime dependencies
+and still require native admission. This is an extracted source outcome from
+T16, not completion of T16; T12/T14/T15 and all external-owner gates remain open.
+
+
+Publication verified by the coordinator after the source worker usage limit:
+`8790dd18ae83c4651ef3d1d923312a118a5b436b` is the actual remote main revision.
+All five canonical source hashes match the reviewed packet. Normal synchronization
+completed with zero failures/automation errors; all 19 task statuses match the
+projection. T19's assigned UUID is retained. The original staged and working brief
+bytes were restored and independently compared. The exact source, projection and
+publication checks are in Custodian browser-resume-r1/canonical-integration.json.
+Native acceptance remains open under T16 and the other named owner tasks.
+
+
+## T20 — Prepare durable group provenance and prove disposable LLDAP compatibility
+
+```task
+id: NK-WP-0048-T20
+status: done
+priority: high
+state_hub_task_id: "863fcbdb-e246-51ba-87ca-a2f44d01d6f8"
+```
+
+Completed 2026-10-17, source candidate preparation and bounded synthetic
+compatibility proof only. This extracts evidenced implementation/fixture scope
+from T14; T14 retains native storage, writer isolation, protected callback and
+owner-acceptance gates. Source integration/publication and State Hub projection
+are pending the coordinator's separate receipts; no revision or task UUID is
+invented here.
+
+The existing identity-provisioner group ensure/revoke interface now has a
+reviewed candidate for a bounded owner-private SQLite journal, proven only in
+local/disposable use. The initial storage instructions wrongly suggested a native
+persistent-volume path; source review against accepted ADR-0015 corrected them
+before publication. Production SQLite-on-a-PVC is not admitted: T14 retains
+CNPG/rapp-postgres storage admission or a separately governed exception.
+The local journal saves
+complete prestate and intent before each attempted directory mutation, inventories
+only confirmed new groups/memberships, binds original ensure idempotency and
+correlation to the exact request digest, and refuses unsigned caller inventories
+or legacy broad revoke requests. Replays never recreate removed state. Missing,
+replaced or untrusted storage and missing intent rows stop execution; definite
+before-mutation refusals retain evidence without stranding unrelated valid work.
+Interrupted writes/readback remain unresolved across reopening. Revoke validates
+all targeted native ids and complete member postimages before destructive work,
+removes only confirmed creations and never deletes a preexisting empty group.
+Server/configuration wiring, image-copy closure and owner storage/request
+migration instructions are included. The existing endpoint's caller
+authentication remains the existing boundary, not a new grant.
+
+The candidate was prepared against NetKingdom
+`878abc93588e12b6da1bac055cfbb3abb8d7adf1`; exact source patch digest
+`sha256:1f3f3ca94c46dadac8f24896053d4d23179de795e50a24298a0cfbcc46cca30e`.
+The independent Custodian review passed all 65 provisioner checks. The earlier
+62-check candidate, two independent-review findings and subsequent fixes remain
+retained rather than overwritten. Seven additional fixture-plan checks exercise
+the preparation boundary; these counts overlap the same candidate and do not
+measure task-completion percentage or independent acceptance.
+
+A separately reviewed bounded fixture then exercised the exact candidate against
+cached pinned disposable LLDAP and Python images, through actual GraphQL. All 14
+closed compatibility/containment oracles passed: exact creation inventory,
+separate-process SQLite reopening/replay/revoke, complete preexisting directory
+preservation including empty/shared groups and memberships, refusal of shared
+membership drift, retained uncertainty after a lost response following a real
+addition, and refusal of unknown/cross-case receipt bindings. The fixture used
+only newly generated synthetic users/passwords/key material in private tmpfs,
+with a network-none anchor and shared loopback helper, no host ports/mounts,
+no image pulls and no production or actual credential contact. The coordinator's
+safe receipt reports both exact owned containers absent after cleanup; final
+independent cleanup verification remains the coordinator's integration duty.
+
+Evidence: Custodian
+`docs/changes/netkingdom-target-2026-10-16/group-provenance-r1/`, including exact
+source base/pre/postimages, patch/manifest, independent review and retained
+refinements. Native fixture manifest
+`sha256:8a0514f5f14137355972400cd4852f48c892316d28e3abd3c86635d7cb81eef2`;
+retained safe result `native-fixture/execution-result.json` (original
+`/tmp/nk48-groups-native-review-5pywb19z/result.json`). The source task supplies
+no native owner assent, production rollout, protected session/evidence callbacks,
+ordinary type admission or consumer login proof. LLDAP has no conditional
+membership mutation or generation token here: exact readback cannot exclude
+ABA or a concurrent external writer, so T14 remains open.
+
+2026-10-17 verified source follow-through: source commit `4f65e41` passed normal
+local scanning and all 65 canonical provisioner tests. The actual disposable
+LLDAP receipt passed all 14 oracles; independent verification on the pinned
+daemon found both exact names and the run label absent. Source integration
+includes the ADR-0015 documentation correction; the journal remains local-only.
+
+T14 source preparation is underway. Twenty-three pinned public sources identify
+NetKingdom implementation/reconciliation, Platform custody/database governance
+and rapp-postgres consumer provisioning; the inspected runtime binding does not
+assign identity-provisioner a package. The existing User Engine runtime token
+and pod route are not a protected-case caller lane. The native proposal preserves
+the same journal seam on a dedicated CNPG consumer and requires authoritative
+scope binding, admitted role/lease/placement/recovery and all LDAP writers fenced.
+The declared exclusive maintenance window is not mechanical exclusion of WebUI,
+helper or lifecycle writers. Capacity placement and EUR cost/risk remain owner
+decisions. No package, database, credential, rollout or owner assent was created.
+Custodian evidence: group-provenance-r1/native-storage-proposal-r1; final source,
+projection and cleanup review: resume-integration-r1/publication-verification.json.
+
+
+## T21 — Implement the PostgreSQL journal and prove disposable SQL compatibility
+
+```task
+id: NK-WP-0048-T21
+status: done
+depends_on: [NK-WP-0048-T20]
+priority: high
+state_hub_task_id: "afe78e4d-408a-516a-ab92-e212e8a2d11d"
+```
+
+Completed 2026-10-17: bounded source preparation and actual disposable PostgreSQL
+compatibility only. T14 retains native storage, custody, callbacks, authorization,
+all-writer isolation and production admission. Coordinator source publication and
+projection remain separate follow-through; no source revision or task UUID is
+invented here. T20 remains the historical local SQLite/actual LLDAP proof.
+
+The eight-path source candidate adds an injection-only PostgreSQL implementation
+behind the existing owner journal seam, with explicit trusted tenant/directory/
+case/source/principal/epoch binding and independent continuity callbacks. It
+persists bounded intent/created-only receipts, exact-one version updates, durable
+active fences, and a content-bound journal chain. SQL commits precede independent
+exact-marker acknowledgment; lost replies/checkpoints poison continuation and
+retain uncertainty. A counter-only checkpoint is explicitly insufficient for
+divergent clones. Migration does not create database/schema/credential, admit an
+epoch or clear quarantine; production HTTP activation is absent pending trusted
+callbacks. Pinned psycopg package/image-copy closure is included, without claiming
+an image build or native dependency admission.
+
+Candidate base `6cb43c0cc55212363a5406b02db046e2384a7c40`; final eight-path patch
+`sha256:5549d2982b61ff70aba4b3928fecd5639db0f1a732ab2f8630f678e7acf4d34d`.
+All 82 source tests pass, alongside 13 fixture plan/diagnostic checks and two
+source-backed snapshot regressions. Counts overlap the same source and fixture;
+they are not additive native acceptance or completion percentages.
+
+The independently reviewed R5 fixture ran the actual SQL migration/backend and
+existing provisioner path against cached pinned disposable PostgreSQL. Directory
+operations deliberately used the existing synthetic LLDAP test double. All
+manifest-declared phase oracles passed: creation-only inventory and DDL refusal;
+separate-process replay/revoke with complete preexisting/shared visible-state
+preservation; foreign-context refusal; concurrent exactly-once reservation and
+stale version refusal; actual database fork with divergent bodies at the same
+counter and fresh-object rejection of the losing exact checkpoint; retained
+uncertainty after checkpoint/directory/SQL response loss; and actual pg_dump/
+pg_restore rollback refusal against the independently retained fixture checkpoint.
+The checkpoint is fixture-only, not an admitted native owner evidence holder.
+
+Only generated credentials/state were used, with two nonroot/read-only containers
+on private loopback, bounded tmpfs/CPU/memory/PIDs/lifetimes, no host ports/mounts,
+no pulls and no production contact. The safe receipt reports both exact owned
+containers absent, with no daemon uncertainty. Independent final pinned-daemon
+cleanup verification remains coordinator follow-through.
+
+Failed R2/R3/R4 receipts and source revisions remain retained. R2's helper failure
+subphase is unknown; R3 exposed a real backend bug where replacing nested receipt
+objects lost the created ID held by ensure, fixed by acknowledging only the backend
+version after commit/checkpoint. R4 verified that fix through actual SQL bootstrap,
+then exposed fixture snapshot aliasing and empty deleted-group backing entries;
+source-backed regressions corrected the snapshot without weakening complete
+visible-prestate equality, and reject nonempty orphan membership. These refinements
+belong to one trial, not extra native acceptance successes.
+
+Custodian evidence: `docs/changes/netkingdom-target-2026-10-16/group-postgres-r1/`;
+exact source/pre/postimages and retained predecessors; native R5 manifest
+`sha256:d51f90816616848b93bcdc482e10a98d07061deb01eeed9e50700fc6e68b6051`;
+`final-integration-r1/typed-execution-evidence.json` and byte-exact safe receipt
+(original `/tmp/nk48-postgres-native-review-sguj7t8p/result.json`). No CNPG native
+storage/HA/backup/lease/TLS/capacity/restore admission, authoritative protected
+callbacks, real LDAP writer fencing/CAS/ABA exclusion, owner assent or production
+endpoint activation is claimed. Those remain live T14 work.
+
+
+## T22 — Establish registration recovery source gaps and complete descriptor review inventory
+
+```task
+id: NK-WP-0048-T22
+status: done
+priority: high
+```
+
+Completed 2026-10-17: source-only owner-contract review and complete review
+inventory. Inspected the actual registration adapter, Warden Journal/Executor,
+NetKingdom evidence compatibility checker and Audit Core custody/read surfaces.
+No existing admitted holder/readback supplies authenticated original-attempt
+recovery: payload/creation are process-local, persisted evidence references are
+hashed, and reconcile receives a new attempt without original context. The exact
+four-owner contract requirements and non-replayable missing/ambiguous cases are
+recorded; no recovery callback, publisher, credential grant or native trust root
+was installed. T15 retains implementation and actual acceptance.
+
+The complete source1.2 inventory maps all seven follow-through steps to their
+existing owners, missing exact contracts and created-only rollback requirements.
+The actual maintained adapter regenerated the sole existing register-client
+machine descriptor against the delivered 13,633,409-byte checker and current
+sealed-memfd snapshot source. The checker rehash and Warden Descriptor.decode
+round-trip passed; six owner descriptors remain absent. Actual source commands
+render canonical1.1 and explicitly selected1.2 with execution.permitted false;
+ordinary1.2 case admission still refuses its acknowledged/unimplemented type.
+Canonical type/case/acknowledgment bytes were hash-checked unchanged. No tests were
+added or rerun, no native configuration or effect occurred, and no owner assent
+or complete machine bundle is claimed. T16 retains native executable custody,
+complete exact descriptors, independent source review and normal version/type
+admission. This extracted outcome supplies no native gate completion credit.
+
+Evidence in the-custodian:
+`docs/changes/netkingdom-target-2026-10-17/native-registration-r1/`, especially
+original-attempt-review.json, descriptor-composition.json, source-verification.json,
+source-manifest.json and manifest.json. The prior sixteen-gate audit remains
+immutable. Publication, normal task UUID allocation and projection are separate
+coordinator follow-through; no Hub UUID is assigned by this source record.
+
+
+## T23 — Review native journal package assignment and storage integration boundaries
+
+```task
+id: NK-WP-0048-T23
+status: done
+priority: high
+```
+
+Completed 2026-10-17: source/package placement and protected integration review
+only, separate from T21's completed PostgreSQL source and disposable-SQL proof.
+The owner review recommends a dedicated independently rolled-back
+`rapp-identity-provisioner`, owned by NetKingdom on rail-kubernetes, with a
+schema-valid draft declaration and no reef binding. No repository, registry
+entry, native package assignment or owner assent was created. Existing
+rapp-user-engine ownership/token delivery does not assign it the provisioner.
+
+The complete current rapp-postgres catalog has six declared consumers: four on
+platform-pg and two on platform-pg-2. The inert renderer-valid provisioner
+candidate fits platform-pg-2 at three of four, requesting one migration plus
+four runtime connections; placing it on the first cell is refused as a fifth.
+Normative package schema and full-catalog capacity/render checks passed. The
+four-consumer ceiling is estimated, not measured native headroom, and no current
+SQL session, backup or restore acceptance is claimed.
+
+The exact review identifies remaining package/substrate, SQL role/lease/TLS,
+network and backup/recovery contracts; independently authenticated protected
+scope callbacks; an external content-bound checkpoint holder with atomic
+advance/loss handling; and all-LDAP-writer exclusion or provider CAS/generation,
+including lifecycle cascades and remove/readd ABA. Generic Audit custody is not
+that checkpoint service. A database-only fence, final reread or one replica
+cannot exclude foreign directory writers. The native acceptance/recovery matrix
+keeps storage/lease admission separate from separately approved directory
+mutation; the production activation remains disabled pending trusted integration.
+
+Evidence in the-custodian:
+`docs/changes/netkingdom-target-2026-10-17/native-storage-r1/OWNER-REVIEW.md`,
+source-validation.json and hash-bound source-references.json, plus the inert
+proposed declaration/consumer and renderer outputs. No native resource, lease,
+credential, deployment, destructive effect, independent holder or native owner
+acceptance was delivered. T14 retains these live gates with its original UUID
+and progress status. This completed review adds no duplicate T21 acceptance
+credit; publication, task UUID allocation and projection remain coordinator
+follow-through and no UUID is hand-assigned here.
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-registration-refinement-r2/preimage.md b/docs/changes/netkingdom-target-2026-10-17/native-registration-refinement-r2/preimage.md
new file mode 100644
index 00000000..c3dc3b28
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-registration-refinement-r2/preimage.md
@@ -0,0 +1,1066 @@
+---
+id: NK-WP-0048
+type: workplan
+title: "Establish SecurityCaseTypes so that known security cases are light"
+domain: infotech
+repo: net-kingdom
+status: active
+flavor: implementation
+owner: claude-code
+topic_slug: netkingdom
+created: "2026-10-08"
+updated: "2026-10-17"
+depends_on: []
+related_repos:
+  - ops-mason
+  - ops-warden
+  - key-cape
+  - railiance-platform
+  - informed-decision
+state_hub_workstream_id: "e31f3f9d-0748-5137-b0a3-7b3ca46a66eb"
+---
+
+# NK-WP-0048 - Establish SecurityCaseTypes so that known security cases are light
+
+## Why
+
+The founder's direction (2026-10-08): setting up a security integration of a
+kind that has been done before should be easy, meaning accept the case, then
+ops-mason arranges it and ops-warden follows through. Setting up a new kind
+needs ample documentation and tests and an informed-decision, because its shape
+is part of the security architecture.
+
+Today every integration is hand-built: per-client helper scripts, per-lane
+custody, founder checklists. The trigger was KEY-WP-0038 (Forgejo as an OIDC
+client), whose next step was going to be yet another hand-written rollout
+script.
+
+This plan continues the pattern work of NK-WP-0008 (pattern infospace),
+NK-WP-0009 (tutorials) and NK-WP-0030 (scenario composition). It turns patterns
+into **SecurityCaseTypes** that ops-mason and ops-warden can execute. Canon:
+`canon/standards/security-case-types_v0.1.md` (proposed).
+
+Companion plans: ops-mason `MASON-WP-0010` (materialization) and ops-warden
+`WARDEN-WP-0044` (follow-through).
+
+## Tasks
+
+```task
+id: NK-WP-0048-T01
+status: done
+priority: high
+state_hub_task_id: "930ac3e9-20ec-5473-98cd-3fe8fddb730f"
+```
+
+### T01 — Accept the terminology and the canon
+
+Founder review of `canon/standards/security-case-types_v0.1.md`, including its
+section 10 open questions. On acceptance the canon status goes from `proposed`
+to `accepted`.
+
+2026-10-08: accepted by the founder (in session). Canon status `accepted`;
+section 10's open questions are carried forward to the first type (T04, T05).
+
+```task
+id: NK-WP-0048-T02
+status: done
+priority: high
+state_hub_task_id: "19c25d96-a55c-58f0-9168-3fdbc4955fc2"
+```
+
+### T02 — Inventory the de-facto types already built by hand
+
+Read-only. List every security integration built so far and group them by shape.
+Known starting points:
+
+- browser OIDC relying parties on key-cape: informed-decision-approver,
+  coulomb-social, user-engine portal, openbao-admin, and Forgejo (pending)
+- confidential service clients with `client_credentials`: secrets-engine
+  approval, requester and openbao clients, approval-engine operator
+- workload KV read lanes on OpenBao: the railiance-platform credential lane
+  designs and CCRs, for example `railiance-backup-offsite-lane`
+- short-lived SSH certificates through ops-warden (`warden sign`)
+- tunnelled operator access (ops-bridge)
+
+For each: the repositories involved, the hand-built steps, attended human steps,
+custody paths, verification evidence, and rollback (if any). Output
+`docs/security-case-type-inventory.md`, ranking candidate types by how often the
+shape recurs and how much manual work each instance costs today.
+
+2026-10-08: done, `docs/security-case-type-inventory.md`. 36 of 37 CCRs are
+already `request_type: workload-kv-read`, a de-facto type reviewed each time as
+if it were new. Browser clients: 5 hand-built plus Forgejo, each with its own
+rollout script. Confidential service clients need a registration plus two or
+three KV-read CCRs each. A forge read identity is needed in bulk by
+ORGREF-WP-0002-T06. Recommendation: oidc-browser-relying-party first (unblocks
+the forge), workload-kv-read second (largest payoff), then forge-read-identity.
+
+```task
+id: NK-WP-0048-T03
+status: done
+depends_on: [NK-WP-0048-T01]
+priority: high
+state_hub_task_id: "e487975b-73b1-516c-971d-da4cbbb93063"
+```
+
+### T03 — Schema, template and validator
+
+- `canon/schemas/security-case-type_v0.1.schema.json` and
+  `security-case_v0.1.schema.json`
+- `security-case-types/_template/` with `type.yaml`, `README.md` and tests to copy
+- a validator, extending `tools/security-scenario-composer/`, that checks a type,
+  checks a case against its type, and renders the case into the composer's
+  deterministic plan (still `execution.permitted: false`)
+
+Acceptance: the validator rejects missing sections, secret-shaped parameter
+values, unpinned providers and cases against non-`implemented` types, with tests
+for each.
+
+2026-10-08: done. `canon/schemas/security-case-type_v0.1.schema.json` and
+`security-case_v0.1.schema.json`; `tools/security-case-types/security_case_validator.py`
+(`validate-type`, `validate-case`, `render`, reusing the scenario composer);
+`security-case-types/_template/` (a valid, runnable example type over
+`net-kingdom.local-identity`, with README sections, an example case and tests that
+travel with every copy). 31 tests pass, including the composer's existing suite.
+
+```task
+id: NK-WP-0048-T04
+status: done
+depends_on: [NK-WP-0048-T02, NK-WP-0048-T03]
+priority: high
+state_hub_task_id: "2fffe112-7d55-5680-9952-78d74f44f87f"
+```
+
+### T04 — Define the first type: browser OIDC relying party
+
+`security-case-types/oidc-browser-relying-party/`, version 1.0:
+
+- parameters: client id, display name, exact redirect URIs, scopes, client type
+  (confidential or public), MFA pin, the groups the consuming service maps,
+  custody path for the secret (confidential only), consuming service and its
+  owner
+- composition: key-cape client registration (key-cape declares it as a playbook
+  capability), secret minting into custody (railiance-platform), LLDAP group
+  existence and membership (net-kingdom identity-provisioner), handover to the
+  consuming service
+- materialization (ops-mason) and follow-through (ops-warden) sections
+- verification: discovery lists the redirect URI; a test sign-in returns the
+  expected claims for one human; anonymous access to the custody path is denied
+- rollback: remove exactly this client and its custody path
+- README: threat model, MFA rationale, why redirect URIs are exact, which steps
+  still need an attended login and how that is minimised
+- reference instances: informed-decision-approver, coulomb-social, user-engine
+  portal, openbao-admin
+
+Acceptance: complete per canon section 3, tests green, status `proposed`.
+
+2026-10-08: done. `security-case-types/oidc-browser-relying-party/` 1.0 (proposed):
+`type.yaml` with 12 parameters (the custody reference is required only for
+confidential clients), composition over key-cape's new
+`key-cape.oidc-client-registration` declaration (contract PASS, `maturity:
+planned`), materialization and follow-through, verification and rollback, all
+conditional on client type where it matters. One attended step,
+`register-client`, justified by the live registry being a Kubernetes Secret.
+README with threat model, alternatives, an honest fit table (portal and vergabe
+fit; Forgejo is the first confidential case; openbao-admin, coulomb.social and
+informed-decision-approver do not fit 1.0), and known limits. Examples: Forgejo
+(checked against the accepted request) and a public portal. The validator gained
+`when` / `required_when` conditions and provider discovery. 43 tests pass.
+ops-mason's and ops-warden's sections are drafted in the type. Their owners
+review them in MASON-WP-0010-T01 and WARDEN-WP-0044-T01 before acknowledgment
+(T05).
+
+```task
+id: NK-WP-0048-T05
+status: done
+depends_on: [NK-WP-0048-T04, MASON-WP-0010-T01, WARDEN-WP-0044-T01]
+priority: high
+state_hub_task_id: "3d987d3d-0797-538b-86e4-51185a327ae2"
+```
+
+### T05 — Acknowledge the type through informed-decision
+
+Prepare the Decision Memo from the type's README and `type.yaml` and submit it
+through informed-decision's production intake. On acknowledgment the type
+moves to `acknowledged`.
+
+2026-10-08: Decision Memo prepared. Hub decision `e418263e-a71f-4f01-a970-c87c9e187c09`.
+`security-case-types/oidc-browser-relying-party/decision/`: `packet.md` (question,
+one act, what acknowledging does not do, the shape, alternatives, attended
+steps, limits, evidence), `build_intake.py` and the built `intake.json` (memo
+class `decision-record`, review group `net-kingdom-admins`, resolves the hub
+decision on answer). The envelope passes informed-decision's own
+`validate_submission`. Queuing it is an attended operator step, a write inside
+the production dispatcher pod:
+
+    kubectl -n state-hub exec -i deploy/state-hub-memo-dispatch -- \
+      python -m api.services.memo_dispatch --queue /data/private enqueue --envelope /dev/stdin \
+      < security-case-types/oidc-browser-relying-party/decision/intake.json
+
+The answer then appears for review in informed-decision.
+
+2026-10-08: queued by the founder (`pending`, `queued`) after one refusal: the
+first envelope's idempotency key was not State Hub's stable
+`state-hub.<decision>.<memo>` form, and the builder now validates against both
+sides. The dispatcher delivered it to informed-decision (ledger 7 → 8
+delivered). T05 waits for the founder's answer in informed-decision, which
+resolves hub decision `e418263e`.
+
+2026-10-08: ops-mason's review (MASON-WP-0010-T01) folded into the type, still
+1.0 `proposed`: `secret_ref` is no longer a parameter, the type derives
+`platform/workloads/keycape/{client_id}`; policies are
+`workload-kv-read-keycape-{client_id}-eso` and
+`workload-kv-read-keycape-{client_id}-{consuming_service}`, each with a templated
+body (`read` on that one data path); new `openbao_role`
+`external-secrets-keycape-{client_id}` (Kubernetes auth, ESO service account,
+15m, no default policy); catalog entry `{consuming_service}-keycape-client`;
+the two rollback steps on the KV path collapse into one metadata delete. The
+schema and validator now require a `body` on policy and role items. 105 tests
+pass. Two consequences: the delivered memo describes the type before these
+changes (a case-set custody reference, two differently named policies, no ESO
+role), so the founder answers on a superseded shape unless the memo is
+re-sent; and Forgejo's custody path moves from the accepted request's proposed
+`platform/workloads/forgejo/netkingdom-oidc-client` to
+`platform/workloads/keycape/forgejo`, which key-cape (KEY-WP-0038) and
+railiance-apps (RAPPS-WP-0016-T02) need to adopt in T06. ops-warden's review
+(WARDEN-WP-0044-T01) is still in progress.
+
+2026-10-08: revised memo `nk-wp-0048-t05-oidc-browser-relying-party-r2` built
+(`packet.md`, `intake.json`, packet `sha256:af6435e2…`); it states that it
+supersedes the first memo and passes informed-decision's and the dispatcher's
+validation. It needs a new memo id because the dispatcher refuses new content
+under a delivered idempotency key (`idempotency_conflict`). Queuing it is the
+same attended step as above. Both memos serve hub decision `e418263e`; the
+first answer resolves it, so the first memo must not stay open: an accept on it
+would acknowledge the superseded shape, and a decline would resolve the
+decision against r2. Close it with `return` (a reviewer verb that requests a
+new revision and does not resolve the hub decision; only accept and decline
+do), commenting that r2 supersedes it, then answer r2. `withdraw` exists in
+the vocabulary but is not offered to reviewers, and lifecycle `revise` only
+applies to lifecycle-registered memos, not intake-delivered ones.
+
+2026-10-09: the founder reports r2 enqueued and the first memo returned. At
+close, hub decision `e418263e` still showed `open` (not verified whether r2
+was answered or the answer is still in transit; the dispatcher ledger was not
+read). ops-warden's review (WARDEN-WP-0044-T01, ops-warden
+`history/2026-10-08-oidc-rp-follow-through-review.md`, d470f2e) arrived at
+21:25, before r2 was built, and is not in r2. Required before WARDEN-WP-0044-T02:
+R1 a per-step `lane` (missing: identity-provisioner caller credential,
+railiance-platform broker grant), R2 canon meaning of `warden_executes: true`
+(caller proxy, caller identity, no standing ops-warden token; ADR-0002), R3 a
+per-step `value_handling`. Refinements R4 (one type-level catalog lane instead
+of a per-case entry, which conflicts with ops-mason's item 5), R5 (ESO Ready gate
+before bind-env), R6 (exact accepted memberships), R7 (mfa-pinned and
+secret-delivered checks). Next: if r2 was accepted, fold R1-R3 and R5-R7 in as
+a follow-up and settle R4 between ops-warden and ops-mason before T06; if not,
+hold r2, fold them in and build r3.
+ key-cape and railiance-apps were told about Forgejo's new custody
+path.
+
+2026-10-09: r2 was not answered (hub decision `e418263e` open; dispatcher 9
+delivered), so r2 is held and r3 replaces it. ops-warden withdrew R4 for R4′
+(message a66a9204): one catalog entry per case with its body templated in the
+type. Folded in:
+
+- Canon section 3: a narrow meaning of `warden_executes: true` (caller proxy,
+  caller identity, no standing credential; ops-warden ADR-0002), plus per-step
+  `lane`, `value_handling` and an optional `ready_check`. A catalog entry body is
+  now required, like policy and role bodies.
+- Schema and validator enforce all of these.
+- The type: lanes `identity-provisioner-groups` and
+  `keycape-client-secret-generate` (both new) and `key-cape-oidc-login`;
+  `mint-secret` is `generated_in_custody`; a Ready gate on `deliver-secret`;
+  `ensure-groups` adds exactly the accepted case's memberships; new checks
+  `secret-delivered` and `mfa-pinned`; the catalog-entry body follows R4′.
+- 110 tests pass.
+
+Memo r3 (`nk-wp-0048-t05-oidc-browser-relying-party-r3`, packet
+`sha256:726dfc01…`) passes informed-decision's and the dispatcher's validation.
+The founder queues it with the same command, returns r2 with a comment that r3
+supersedes it, then answers r3.
+
+Prerequisites for T06, not for T05:
+- the two new lanes, each through its owner;
+- a founder-approved rollout of an identity-provisioner image containing
+  630ebfd (the deployed one is main-6c4fcaf from 2026-09-24, without
+  `/v1/groups/ensure`).
+
+ops-mason's request to create LLDAP group `fluid-telegram-operators` (message
+259ec26d) was answered: not possible from here by that path; the founder creates
+it in the LLDAP admin UI.
+
+2026-10-09: ops-warden finished its side of WARDEN-WP-0044-T01 (message
+`58d33f40`, commit 0e7ceb8): the revised type conforms to `warden case
+check-type`, with no further changes asked of the type. This acknowledges that
+review. Its later addendum R8 (message `af274783`, ops-warden
+`history/2026-10-08-oidc-rp-follow-through-review.md`) showed that lane
+`identity-provisioner-groups` cannot exist as declared: the provisioner's only
+HTTP credential is user-engine's runtime token, and its NetworkPolicy admits
+only user-engine pods, so a caller-proxy lane would act as user-engine. Taken
+option 1 (ops-warden's recommendation): `ensure-groups` and its rollback are
+attended, in the `register-client` session on `key-cape-oidc-login`, run inside
+the provisioner pod; no token is read. Option 2 (an operator credential of its
+own on the provisioner) stays open for a later version. `warden case
+check-type` now reports only `keycape-client-secret-generate`
+(railiance-platform) as missing. 89 tests pass.
+
+Hub decision `e418263e` was still open, so memo r4
+(`nk-wp-0048-t05-oidc-browser-relying-party-r4`, packet `sha256:452ea421…`)
+replaces r3; it passes informed-decision's and the dispatcher's validation. The
+founder queues it with the same command, returns r2/r3 if still open with a
+comment that r4 supersedes them, then answers r4.
+
+Prerequisites for T06 are now: lane `keycape-client-secret-generate`
+(railiance-platform), and a founder-approved rollout of an identity-provisioner
+image containing 630ebfd.
+
+2026-10-09: done. The founder queued r4 (`pending`, `queued`), returned r3 as
+superseded and accepted r4 in informed-decision. informed-decision's hub
+write-back is off in production (`INFD_HUB_WRITEBACK` unset), so net-kingdom
+resolved hub decision `e418263e` from the founder's report, naming memo r4 in
+the rationale. The type is `acknowledged`; it becomes `implemented` with T06.
+
+```task
+id: NK-WP-0048-T06
+status: wait
+depends_on: [NK-WP-0048-T05, NK-WP-0048-T08, NK-WP-0048-T09, NK-WP-0048-T12, NK-WP-0048-T13, NK-WP-0048-T14, NK-WP-0048-T15, NK-WP-0048-T16, NK-WP-0048-T17, NK-WP-0048-T18, NK-WP-0048-T20, MASON-WP-0010-T03, WARDEN-WP-0044-T03]
+blocking_reason: "Type1.2 architecture has a confirmed source-only founder acknowledgment; canonical1.1 remains unchanged/default and the1.2 reference case stays proposed. Needs explicit version selection/reference-source integration without normal admission bypass, closed owner adapters plus global/native receipt verifier (WARDEN-WP-0044-T03), independently verified six-object structural materialization and CCR42 claims/created-only provenance, exact broker/case/source reconciliation, then separately authorized native mint/delivery and attended registry/consumer verification. Source acknowledgment, a bundle or local tests do not prove implemented/materialized/live status."
+priority: high
+state_hub_task_id: "d9b26bcf-a7c6-59a2-92a0-f913d76a203c"
+```
+
+### T06 — First KnownSecurityCase: Forgejo
+
+Write `security-cases/forgejo-netkingdom-oidc.yaml` from the parameters the
+founder accepted in KEY-WP-0038-T01 (`key-cape/docs/forgejo-oidc-client-request.yaml`),
+so that acceptance carries over as the case acceptance. ops-mason materializes it;
+ops-warden follows through and verifies it. The type becomes `implemented` once
+this reference case is live.
+
+This replaces the hand-built path proposed for KEY-WP-0038-T02.
+
+2026-10-09: case written, `security-cases/forgejo-netkingdom-oidc.yaml`, status
+`accepted`: the example's parameters plus the founder's 2026-10-08 acceptance of
+the key-cape request (owner and founder), with the custody-path derivation
+covered by the type's acknowledgment (memo r4). It validates and renders (plan
+`execution.permitted: false`; three attended steps on `key-cape-oidc-login`);
+it needs `--allow-unimplemented` until it is live, since it is the case that
+makes the type `implemented`. A test keeps it equal to the type's example.
+Still open before it runs: ops-mason renders and builds it (MASON-WP-0010-T02,
+T03, unblocked by T05), ops-warden plans and runs it (WARDEN-WP-0044-T02, T03),
+railiance-platform's `keycape-client-secret-generate` lane (asked by ops-mason
+`789feb39` and ops-warden `d9f889b1`, both unread), and a founder-approved
+identity-provisioner rollout containing 630ebfd.
+
+2026-10-09: identity-provisioner rolled out, founder-approved in session:
+`main-630ebfd` (`sha256:bafb4860…`, built by the image workflow) replaces
+`main-6c4fcaf` (`sha256:ffacd5d7…`; only change: 630ebfd, additive). Applied
+with `kubectl set image` on the Deployment only (generation 17 → 18, 1/1 Ready);
+the file's Service, NetworkPolicies and Ingress were not reapplied. Verified in
+the pod: `ensure_service_groups` and `revoke_service_groups` present, `/readyz`
+200; no token used, no group changed. Rollback: `kubectl -n sso set image
+deploy/identity-provisioner provisioner=forgejo.coulomb.social/coulomb/identity-provisioner@sha256:ffacd5d790a5b7800e0535f3aa95b7de52c7a68e4f575b9192c3e1622fa672c2`.
+The pin in `sso-mfa/k8s/identity-provisioner/deployment.yaml` follows.
+
+2026-10-09: ops-warden closed WARDEN-WP-0044-T01 and shipped `warden case plan`
+(T02, message `06303d1d`); the accepted Forgejo case is refused until ops-mason
+materializes it, and a materialized copy plans cleanly once
+`keycape-client-secret-generate` exists. Its observation that `bind-env` carries
+a literal `KEYCAPE_<CLIENT_ID>_CLIENT_SECRET`: the validator now renders a
+`{param:env}` format spec (upper case, `-` as `_`, as `keycape-client.py`
+derives the name) and rejects unknown specs, and follow-through and rollback
+text is now checked for unknown placeholders too (patch-level, canon section 6).
+The type keeps the literal until ops-warden's planner (`text.format`) renders the
+spec as well; asked of ops-warden. 53 tests pass.
+
+2026-10-10: ops-warden rendered `{param:env}` in `warden case plan`
+(23ba584, message `c1df14b7`; other specs and `!conversion` refused). The type
+adopts it as a 1.0 patch (canon section 6): `bind-env` and its rollback now read
+`KEYCAPE_{client_id:env}_CLIENT_SECRET`. ops-mason reports the Forgejo case
+rendered and built (message `1ebddae9`; CCR drafts handed to railiance-platform),
+so T06 now waits on the platform apply, the mint-secret lane and the attended
+register-client session.
+
+2026-10-10: key-cape adopted the type's custody path (key-cape ab5cccd, message
+`88a4559c`): `docs/forgejo-oidc-client-request.yaml` and KEY-WP-0038-T02 name
+`platform/workloads/keycape/forgejo`, field `CLIENT_SECRET`, delivered as
+`sso/keycape-forgejo-client` through `external-secrets-keycape-forgejo`, and the
+`forgejo/netkingdom-oidc-client` proposal is withdrawn. This matches the type and
+the Forgejo example; no change needed here.
+
+2026-10-10: key-cape's type-composition review (key-cape 6038483, message
+`8e5ed5f6`) found the composition sound with two blocking findings, taken as a
+1.0 patch (stricter validation and documentation, canon section 6):
+R1, redirect URIs now refuse `?` and `#` in the type pattern and in
+`keycape-client.py`'s `REDIRECT` (KeyCape refuses `?` at startup and the single
+replica would stop); R2, `allowed_scopes` always includes `groups`, the renderer
+refuses `access_groups` without it, and `access_groups` now says the consumer
+enforces the gate because KeyCape has none; R3, `mfa_required` "false" means the
+per-user privacyIDEA policy; R4, register-client's justification records the
+restart for every client, the quiet window, and that the rendered registry must
+pass KeyCape's client validation before it. The accepted Forgejo case and both
+examples still validate; 116 tests pass.
+Open, needs a decision: R2's verification step that the consumer enforces the
+group gate is a new verification step, hence 1.1 (minor), and the validator pins
+cases to the exact type version, so the accepted 1.0 Forgejo case would need
+re-pinning. Also open with key-cape: a KeyCape entry point that validates a
+rendered client registry without starting the server; until then
+`keycape-client.py` mirrors the redirect rule.
+
+2026-10-10: founder go for 1.1, so no 1.0 run overlaps. The type adds
+verification `consumer-enforces-groups`, and hand-over now requires the consumer
+to enforce `access_groups` (minor, canon section 6; risk class unchanged, no new
+acknowledgment; history in the type README). The accepted Forgejo case and both
+examples are re-pinned to `oidc-browser-relying-party@1.1` before any apply; the
+acknowledgment intake keeps `@1.0` as the record of what was acknowledged.
+ops-mason's build and ops-warden's case-ref digest predate this and need a
+re-render.
+
+2026-10-10: ops-mason re-rendered the Forgejo case from `@1.1` (message
+`22c6bba6`; plan digest `af1f4f81…`, no collisions) and rebuilt the bundle. The
+rendered OpenBao objects are identical to 1.0, so the already applied
+CCR-2026-0041 stands; 1.1 changes only consumer-side steps. key-cape shipped
+`keycape check-config` (c528daa, message `a7b0aeff`): KeyCape's startup checks
+without secret values, including the new duplicate-clientId rule.
+`keycape-client.py --check-config <binary>` now runs it on the live and the
+proposed registry, fed on stdin, and apply refuses a proposed registry that
+fails; register-client's entry point names the option (1.1 patch). The deployed
+image predates c528daa, so the binary is built from key-cape source for now.
+Before the next KeyCape rollout (Forgejo register-client or the CCR-2026-0018
+window), the attended operator runs `inspect --check-config` so the live
+registry is checked too.
+
+```task
+id: NK-WP-0048-T07
+status: wait
+depends_on: [NK-WP-0048-T06]
+blocking_reason: "The next types follow once the first one is proven end to end."
+priority: medium
+state_hub_task_id: "c3c9c3ae-4f23-5ba7-9e6f-e63bcf29b9f7"
+```
+
+### T07 — Queue the next types
+
+From the T02 ranking, open the next type drafts (likely the confidential service
+client and the workload KV read lane), each to be acknowledged on its own.
+Record which existing hand-built instances get adopted as cases, without
+rewriting them in place.
+
+```task
+id: NK-WP-0048-T08
+status: done
+priority: high
+state_hub_task_id: "8e519082-dc8b-5e46-b660-03d03e55dcf6"
+```
+
+### T08 — identity-provisioner: ensure service-access groups
+
+The type's `ensure-groups` step calls `identity-provisioner groups ensure --groups
+<list> --members <group=user+user;...>`. The provisioner already has idempotent
+`_ensure_group` and `_add_group`, but exposes only tenant-scoped operations. Add
+the general operation (create if absent, add the listed memberships, never
+remove others), its rollback (remove only this case's memberships), tests, and
+the ops-warden route for its service identity.
+
+2026-10-08: done. `identity-provisioner/provisioner.py` gained
+`ensure_service_groups` (`POST /v1/groups/ensure`) and `revoke_service_groups`
+(`POST /v1/groups/revoke`), behind the existing service-token check. Names
+matching `tenant*`, `netkingdom-*` and `lldap_*` are reserved; members must
+already exist; everything is validated before any change; memberships are read
+back before success; nothing else is ever removed; groups are deleted only when
+asked and empty. 7 new tests (39 in the provisioner suite). The type's
+`ensure-groups` step and its rollback now name these endpoints. The ops-warden
+route for the provisioner's service token belongs to WARDEN-WP-0044-T01.
+
+```task
+id: NK-WP-0048-T09
+status: done
+priority: high
+state_hub_task_id: "0ee12dfc-8260-5038-bd39-cc7fb4113be0"
+```
+
+### T09 — The `keycape-client` entry point and its declaration
+
+Planned first as key-cape KEY-WP-0038-T04. Moved here because the machinery a
+live registration needs already lives in net-kingdom, where KeyCape is deployed
+(`sso-mfa/k8s/keycape/`): the contained kubectl, the cluster-identity pin and the
+issuer pin. A copy in key-cape would drift.
+
+2026-10-08: done. `sso-mfa/k8s/keycape/keycape-client.py` derives the KeyCape
+client record from a case (`client-from-case`). It adds or removes exactly one
+client with the existing safeguards (byte-preserving merge, exact match or
+refuse, shared-reference refusal, compare-and-swap, read-back, contained errors),
+requires the Deployment env binding first for confidential clients, and requires
+the case acceptance record for `apply` instead of a per-client founder decision
+id. 15 tests, including a regression showing that the vergabe case reproduces
+its hand-built registration exactly; all 71 helper tests pass. Declaration
+`capabilities/playbooks/net-kingdom.keycape-client-registration.yaml` (contract
+PASS, `maturity: implemented`) replaces key-cape's draft. The type now pins it,
+and for confidential clients adds `deliver-secret` (delivery from custody into
+the sso namespace) and `bind-env` (Deployment env), attended in the same session
+as `register-client`. The per-client helpers stay until their clients are
+adopted as cases.
+
+2026-10-10 — NetKingdom owner review of the execution seam, source only:
+ops-warden/docs/security-case-execution-proposal.md SHA256 78ab1439e4c5beb205aeccf15b1b2e706511be55ab195c5a3aa682f326c7c77c
+was reviewed against INTENT, SecurityCase canon, acknowledged type1.1, current
+case and owner source. docs/security-case-execution-owner-review.md supports
+the closed adapter/receipt direction with explicit versioned schema, structural
+materialization provenance, unchanged caller/session boundaries, safe CAS
+reconciliation and exact-created-object rollback requirements. This is owner
+review, not approval. Supporting file digests are in the adjacent sources JSON.
+
+Current source exposes a circular wait: ops-mason T03 waits on mint while Warden
+and the broker refuse a non-materialized case. Structural acceptance therefore
+needs its own native pinned receipt before mint, not a successful mint before
+materialized. The platform broker additionally pins type1.0 while Forgejo is
+accepted at1.1; platform-owner alignment and tests are required, not an unchecked
+version bypass. T06 remains wait. No case/type lifecycle status, grant, authority
+or live runtime changed by this review. A proposed informed-decision would
+adopt the source contract only; native materialization and execution acceptance
+stay distinct.
+
+Final proposal re-review: staged Warden proposal SHA256 78ab1439e4c5beb205aeccf15b1b2e706511be55ab195c5a3aa682f326c7c77c
+adds only the explicitly local reducer appendix, not an accepted wire protocol
+or executor. The exact-final review and sources JSON supersede the earlier
+1035f049... proposal review. Platform staged the exact type1.1 broker correction
+with ten fake-backend subprocess checks (script SHA256
+9576cd211cfc06526ec4cc9bd0a5b06f0f59287a68931bb2d6e3592a951ddc7d).
+The next source work is the versioned closed adapter/receipt/materialization
+contract, not another relaxation of the broker's status gate. Native work still
+requires installed broker provenance, structural reader receipts, exact new
+materialized-case bytes, caller grant/session revocation and verified execution.
+No installed/native acceptance is inferred from that staged correction.
+
+2026-10-11 — new source-only type1.2 architecture acknowledgment:
+Confirmed native founder ACCEPT of infd-20261011-forgejo-type12-source-r1@1
+at06:47:39Z, approval8e9332c8-754a-420c-b8b7-445cb4fe6765. Exact frozen packet
+0b377d647ca748cd03c92f9792396412048055d4bde9f7bb06ff6d413f7acd68 and submission
+585cee731de30d2b37883a57abfd9eb32f023ee694e8d911989109d5caf80569; native receipt
+retained in docs/evidence/2026-10-11-forgejo-type12-source-acknowledgment/.
+The complete acknowledged1.2 source package is isolated under
+security-case-type-revisions/1.2/oidc-browser-relying-party; default loader and
+current accepted1.1 case remain untouched because load_type is single-version.
+The new proposed1.2 case is NOT accepted/materialized/live and has no acceptance
+fields. Actual reference-migration design approval is a separate Apps owner
+receipt; no1.1 approval is inherited. Source-recording review/test proof and exact
+next gates are in docs/forgejo-type12-source-acknowledgment-followthrough.md.
+T06 remains wait and T07 remains its existing dependent task; type is NOT
+implemented and no first-case/native grant or broader workplan finish is asserted.
+
+2026-10-11 — bounded explicit version selection source preparation for T06:
+The validator now offers optional exact version_roots/--version-root VERSION=PATH
+selection with duplicate/mismatch/traversal/symlink refusal and no fallback. The
+default1.1 source and historicalacceptedcase hashes/ordinaryrefusal/preparation
+render stayunchanged; actual1.1 is acknowledged, not implemented. Acknowledged1.2
+ordinaryadmission also refuses; optionalpreparation remains nonexecuting.43local
+validatorchecks pass and original1.1 CLIrenderbytes match exactly. Makerproof:
+docs/evidence/2026-10-11-explicit-type-version-selection/source-integration-validation.json.
+FormalNetownerreview/reference-source integration and all existing native adapter,
+provenance/broker/materialization/attendedproof gates remain; T06 stayswait, no
+new residual or firstcase/typeimplementation/native grant is inferred.
+
+
+2026-10-16 — isolated source preparation for T06 (canonical integration pending):
+Added `check-evidence` to the existing validator CLI. It reuses exact version
+selection and ordinary type/case/render admission, checks actual Mason structural
+request source/inventory/projection pins and reads actual Warden journal rows
+read-only. Successful rows require exact type-declared descriptors and attempt/
+revocation fingerprints. Existing acknowledged types without machine descriptors
+remain plan-only. The compatibility result never claims authenticated native
+completion: Request and journal fingerprints are not portable native evidence.
+Owner authentication/status binding and actual native gates remain unresolved;
+T06/T07 statuses and both type/case lifecycles remain unchanged. No dispatch,
+credential access or authority expansion is introduced. See tool README for the
+existing owner protocol boundaries and source integration tests.
+
+Concrete next Warden owner integration: current `Executor.admit` refuses every
+case parameter whose sensitivity is not public/operational, so browser
+`redirect_uris`, `allowed_scopes`, `client_type`, `mfa_required` (and 1.2
+`consumer_namespace`) fail after otherwise prepared admission. The sensitive
+classification is a security-change review level, not secret content. The
+Warden owner must validate through NetKingdom's existing exact-version case/type
+validator, then project only descriptor-declared safe target metadata; do not
+remove the credential/value refusal or copy complete parameters into journals.
+Actual owner descriptor acknowledgment and independent evidence admission remain
+prerequisites, with normal admission still refusing unimplemented types.
+
+
+## T10 — Source compatibility checker for Mason and Warden evidence
+
+```task
+id: NK-WP-0048-T10
+status: done
+priority: high
+state_hub_task_id: "4b06ca97-c1e4-5680-bf22-ab75ab1646a4"
+```
+
+Completed 2026-10-16 in published source `c31d21ba`. The read-only
+`check-evidence` command checks the actual Mason structural request and Warden
+journal source protocols against an exact version/render. Independent source
+review passed 103 tests at that checkpoint. It always reports native completion
+false and execution prohibited. Fixtures and local journal fingerprints do not
+provide authenticated owner/native evidence. This records completed source scope
+previously described under T06; it does not duplicate native acceptance credit.
+
+## T11 — Validate the optional machine-descriptor pin contract
+
+```task
+id: NK-WP-0048-T11
+status: done
+priority: high
+state_hub_task_id: "ef2a0119-f59e-5e45-9519-115da9df7b85"
+```
+
+Completed 2026-10-16. Reproduced the JSON schema rejecting a valid
+`execution_descriptors` map while the Python validator accepted malformed maps.
+The schema now supports the existing Warden optional exact-byte pin map; semantic
+validation binds keys to declared steps, bounds the map and checks digest shape.
+The direct evidence API refuses malformed maps before accessing them. Twenty-one
+new checks and all 127 affected source checks passed. No current type/case bytes,
+status, owner descriptors or native acceptance changed. Source evidence and
+publication receipt: Custodian
+`docs/changes/netkingdom-target-2026-10-16/browser-acceptance-next/`.
+
+## T12 — Prepare NetKingdom-owned attended step adapters
+
+```task
+id: NK-WP-0048-T12
+status: todo
+priority: high
+state_hub_task_id: "7ce4eee3-cd47-55a9-bfa5-4f1835d4d6fd"
+```
+
+Owner: NetKingdom. Retained scope: prepare bounded attended Deployment env,
+config verification and restart/readiness steps around the existing helpers.
+Next action: identify exact current entry points and their revision/readback
+contracts, then implement fixed source-pinned callbacks or receipt-only attended
+steps. Completion requires positive/refusal checks, exact target/source pins and
+uncertainty behavior without acquiring user-engine runtime identity or exposing
+registry/client secrets. Existing caller/session, cluster/issuer, CAS/readback
+and status-only output boundaries remain mandatory.
+
+2026-10-16 task refinement: the original broad adapter scope is split into T13
+(completed registration source candidate), T14 (group creation provenance), T15
+(durable registration recovery) and T16 (descriptor/artifact selection and owner
+review). This preserves T12's task ID and Hub UUID while giving each remaining
+outcome an owner and completion gate. T06 now names every source dependency;
+its native/reference lifecycle acceptance scope remains unchanged. Completion
+of any source task supplies no Warden, Platform or Apps assent and no native
+execution authority.
+
+## T13 — Prepare the fixed registration adapter source candidate
+
+```task
+id: NK-WP-0048-T13
+status: done
+priority: high
+state_hub_task_id: "b264c10b-565c-5d29-b788-03cf5fbd2883"
+```
+
+Completed 2026-10-16, source implementation and synthetic fixture proof only.
+Added an injection-only adapter around actual `keycape-client.run`: fixed
+case/principal/human/lane/source/acceptance binding, existing CAS/readback,
+metadata-only owner evidence and per-attempt parent-session revocation boundary.
+The descriptor source composition pins the exact checker executable digest
+alongside adapter/helper source. Creation-only rollback authenticates its
+creation receipt and refuses changed postcreation UID/resourceVersion;
+pre-existing clients confer no rollback authority. Missing readback, evidence,
+revocation or process-local creation provenance cannot become retry-safe success.
+
+Evidence: Custodian `docs/changes/netkingdom-target-2026-10-16/browser-adapter-next/`
+R3 candidate, explicit patch and postimages, retained R1 rejected custody finding
+and R2 revision, and 36 passing source checks (16 new, 20 existing). Three checks
+use actual Warden kernel admission/dispatch/rollback with published Warden
+`d97652a3bb5fa733b063d71a1b74068efcccf572` producer pins unchanged. Owner trust,
+descriptor/type/case and Kubernetes objects remain synthetic fixtures. This
+records a completed source deliverable, not independent review, publication,
+type acknowledgment, exercised procedure, identity admission or native browser
+acceptance. Independent root source review: Custodian browser-adapter-next/coordinator-review-r3.json. Source integration and normal publication/synchronization receipts: Custodian browser-adapter-next/canonical-integration.json. These receipts supply no other-owner assent or native authority.
+
+Source publication: `0775c2bfa41af236301155bb5a69bbf088bdf823`, independently
+reviewed by the Custodian coordinator before integration. The required initial
+projection and ordinary UUID writeback both completed with zero failures and
+zero automation errors. Generated-only brief commits were refused by the normal
+hook; exact pre-existing staged/working brief bytes were restored. The separate
+canonical integration receipt retains those refusals and projection evidence.
+Native admission and all other-owner acceptance remain open.
+
+## T14 — Admit governed group rollback against native owner boundaries
+
+```task
+id: NK-WP-0048-T14
+status: progress
+depends_on: [NK-WP-0048-T20, NK-WP-0048-T21]
+priority: high
+state_hub_task_id: "fce95440-a25b-5f27-8ef3-a3d182099113"
+```
+
+Owner: NetKingdom. Next action: bind the completed T21 PostgreSQL journal to
+an admitted dedicated CNPG consumer through the existing `rapp-postgres`
+database-per-consumer contract. Identify the actual deployment/package and
+custody owner, admitted placement/capacity and role/renewable lease/TLS target;
+implement the independently retained exact content checkpoint and authoritative
+tenant/case/source/principal callbacks before enabling governed group operations.
+The injection-only backend and fixture callbacks do not supply production scope
+or authorization. Existing service tokens, caller-supplied JSON and provenance
+receipts confer no new grant. The default production endpoint remains disabled
+without the trusted integration. SQLite remains local/disposable only; any
+production exception requires explicit scoped governance under ADR-0015.
+
+2026-10-17 refinement: T20 retains the historical durable SQLite source and
+actual disposable LLDAP proof. T21 extracts the completed PostgreSQL source and
+bounded real disposable SQL compatibility proof. T14 remains `progress` for
+native CNPG admission/recovery, protected owner integration and exclusion of all
+external LDAP writers. Separate source publication/projection and independent
+cleanup receipts belong to coordinator follow-through; no missing native assent
+is represented as received.
+
+Completion still requires independently reviewed/admitted ADR-0015-conforming
+CNPG storage (or an explicit governed exception), backup/lost-store recovery and
+migration of legacy requests; a native
+writer-isolation/fencing or provider CAS/version contract that closes external
+writer races and remove/re-add ABA; exact case/source/principal and current
+native object bindings for protected callbacks; and actual per-attempt evidence,
+revocation and readback/refusal verification through the existing owner paths.
+Only independently retained confirmed creations may be undone. Every
+pre-existing/shared group and membership must remain preserved; unresolved
+intents never expire into retry authority. The disposable fixture supplies none
+of these native custody, authorization, owner-acceptance or production claims.
+
+## T15 — Define authenticated recovery for lost registration process state
+
+```task
+id: NK-WP-0048-T15
+status: todo
+priority: high
+state_hub_task_id: "1b825705-4848-5edc-832f-b1622cd9bdb7"
+```
+
+Owner: NetKingdom for registration state, with Warden owning kernel evidence
+admission. Next action: select the exact existing owner evidence holder/readback
+contract and define authenticated lookup for the original creation attempt.
+Completion requires restart/lost-receipt fixtures that bind case/source/principal,
+original created-only provenance and current native revision before any undo;
+uncertain outcomes remain non-replayable. The T13 adapter deliberately refuses
+post-restart rollback and installs no reconciliation callback. A new broker or
+unverified JSON receipt is not a recovery contract. Actual evidence-holder
+acceptance and attended recovery remain separately authorized native work.
+
+## T16 — Select and review the actual machine descriptor composition
+
+```task
+id: NK-WP-0048-T16
+status: todo
+priority: high
+state_hub_task_id: "200bf500-5084-5ae7-be26-3033fe1f296e"
+```
+
+Owner: NetKingdom for descriptor/type source and exact checker artifact; Warden
+independently owns global provenance/admission. Next action: obtain review of the
+exact checker source/artifact proposed by T17 and identify native owner evidence/
+session callback contracts, then assemble the complete step descriptor set and
+a proposed explicit type version selection. T13's historical descriptor retains
+its synthetic checker; T17 supplies an artifact-bound proposal, not admission.
+Completion requires separate owner source review of exact machine descriptors,
+artifact/source/config pins, normal type/version admission and independent
+evidence-verification boundaries. Warden d97652a refreshes producer validator
+pins for NetKingdom 015694ee; it does not attest T13's new adapter. Pinning any
+machine descriptor into an acknowledged type is a separately reviewed source
+change. Platform owns structural/mint/broker/delivery evidence; Apps owns actual
+consumer login/group enforcement. Neither their assent nor native acceptance is
+supplied by this task.
+
+2026-10-16 source checkpoint: T19 below extracts the completed per-attempt
+executable snapshot implementation and reviewed fixture proof. T16 retains
+native executable storage/custody, exact owner evidence/session callbacks,
+complete descriptor composition and ordinary type/version admission. The
+successor descriptor/source pins are proposed only; the earlier descriptor
+history is preserved. T14 group provenance and T15 durable restart/recovery
+remain independent open requirements. No native acceptance is counted here.
+
+## T17 — Build and exercise the exact offline config-checker artifact
+
+```task
+id: NK-WP-0048-T17
+status: done
+priority: high
+state_hub_task_id: "8c3e4baa-a218-5996-af9e-fe1153a46dac"
+```
+
+Completed 2026-10-16, isolated artifact/source fixture proof only. Built the
+existing `key-cape/src/cmd/keycape` command from published clean source revision
+`3c71226a1a7b8a2bdb710e9c497e1a1f7f8a3987`, source tree
+`f0010b9cab17dbc3a787628a29657d98b900320f`, with cached Go 1.23.0,
+CGO disabled, Linux/amd64 v1, trimmed paths, disabled VCS stamping and offline
+read-only module selection. The full retained closure pins 108 source files,
+9876 toolchain files and ten used module source directories. Three isolated
+build locations produced identical 13633409-byte artifacts:
+`sha256:be37738fe1c08259fb4f9ca0daf0f9301bfffc237e5bb38435525dfbf11ccff5`.
+
+Eight disposable checks use the actual executable and maintained helper/kernel,
+with complete synthetic configs and a minimal environment: add/created-only
+removal, normal pinned producer admission, rollback, lost-readback uncertainty,
+stale revisions, substituted checker refusal, invalid startup config and missing
+secret-env refusal. No checker stub or producer-pin override remains. The
+artifact-bound descriptor proposal is
+`sha256:76b1153d188062ece53fcd5e8d35290fdbfd02a69dd79d4b001fc42781afcdc3`.
+Evidence: Custodian
+`docs/changes/netkingdom-target-2026-10-16/browser-checker-artifact-next/`.
+The first two build attempts succeeded but their closure collection failed;
+both failures are retained, as is refusal of the older incomplete synthetic
+fixture. No production config, credentials or cluster mutation was used.
+
+This extracts completed build/fixture scope from T16 without claiming KeyCape
+owner endorsement, native checker selection/storage custody, acknowledged type
+integration, native evidence/session callbacks or attended browser acceptance.
+T16 retains exact owner review and composition/admission scope. The attended
+registration procedure remains unexercised.
+
+## T18 — Make checker input and executable selection deterministic
+
+```task
+id: NK-WP-0048-T18
+status: done
+priority: high
+state_hub_task_id: "9c45da71-fb4c-5f20-9065-90f448f37c64"
+```
+
+Completed 2026-10-16, isolated source correction and real-artifact fixture proof
+only; independent integration/publication remain separately recorded. KeyCape
+source review identified non-secret `KEYCAPE_ACCOUNT_PORTAL_URL` and
+`KEYCAPE_BROWSER_LOGOUT_URL` overrides in config.Load. The original helper
+inherited ambient environment, allowing valid supplied configuration to be
+rejected or invalid supplied URL configuration to be admitted. A bare relative
+checker filename could also be replaced by PATH lookup after the adapter had
+hashed the selected local file. All three counterexamples are retained against
+the unchanged predecessor.
+
+The existing helper now resolves the selected checker file to an absolute path
+and passes an explicit empty subprocess environment. Three opt-in real-checker
+regressions verify both URL-verdict directions and relative-file selection under
+a non-checker PATH decoy. All 39 affected checks pass with the exact supplied
+artifact, as do 11 real-artifact helper/kernel scenarios. Source evidence:
+Custodian `docs/changes/netkingdom-target-2026-10-16/browser-checker-environment-r2/`.
+Historical descriptors remain retained; the helper correction changes successor
+source-composition pins and requires their separate review/admission. An absolute
+path is not immutable custody and does not eliminate file replacement races;
+T16 retains native executable storage/custody and callback/type admission.
+No production configuration, credentials or cluster mutation was used.
+
+Source integration and publication: `916ba4b33e03179274d03b78bd898a4843e8653f`, following independent
+Custodian source review in browser-checker-environment-r2/coordinator-review.json.
+The ordinary protected projection pass assigned T17/T18 UUIDs with zero failures
+and zero automation errors; generated-only brief commit refusal is retained.
+The exact prior staged/working brief bytes were restored. Final source/publication/
+projection evidence is retained in Custodian browser-checker-environment-r2/
+canonical-integration.json. These source receipts do not admit native executable
+custody, owner callbacks, acknowledged type changes or browser identities.
+
+## T19 — Bind checker execution to verified immutable attempt bytes
+
+```task
+id: NK-WP-0048-T19
+status: done
+priority: high
+state_hub_task_id: "f50fdcd1-00be-5c3c-be0c-345aa2126032"
+```
+
+Completed 2026-10-16, independently reviewed source implementation and synthetic
+fixture proof only. The registration adapter now opens a bounded regular checker
+artifact without following its terminal symlink, verifies the reviewed digest,
+and snapshots the exact bytes into a write/grow/shrink/seal-removal-sealed Linux
+memfd before helper access. Live and proposed config checks execute that same fd
+through procfs with the existing empty environment; the fd closes on completion
+or failure. Unsupported snapshot/seal/exec policy refuses through the existing
+parent-session revocation and uncertainty boundaries. The earlier unbounded
+pre-snapshot path read was removed during independent review; actual adapter
+symlink/FIFO/oversize refusal tests verify helper access never starts.
+
+Evidence: Custodian `docs/changes/netkingdom-target-2026-10-16/browser-resume-r1/`,
+including exact base/preimages/postimages/patch, proposed descriptor, coordinator
+source review and canonical integration receipt. Independent Custodian checks
+passed 49 affected source tests and 12 actual Go checker/helper/kernel scenarios;
+the sets overlap and are not separate acceptance counts. Existing published
+Warden d97652a producer pins remain unchanged. The exact KeyCape artifact remains
+`sha256:be37738fe1c08259fb4f9ca0daf0f9301bfffc237e5bb38435525dfbf11ccff5`.
+The predecessor path-replacement refusal and the first expanded reopened-fd test
+failure are retained; the latter fixture was corrected to restore write mode
+before independently proving seals block reopened-fd writes and shared mmap.
+
+This source task adds no native owner custody, callback, evidence trust, type
+acknowledgment, credential access, consumer sign-in or rollback acceptance.
+Executable memfds, Linux seals and usable procfs are explicit runtime dependencies
+and still require native admission. This is an extracted source outcome from
+T16, not completion of T16; T12/T14/T15 and all external-owner gates remain open.
+
+
+Publication verified by the coordinator after the source worker usage limit:
+`8790dd18ae83c4651ef3d1d923312a118a5b436b` is the actual remote main revision.
+All five canonical source hashes match the reviewed packet. Normal synchronization
+completed with zero failures/automation errors; all 19 task statuses match the
+projection. T19's assigned UUID is retained. The original staged and working brief
+bytes were restored and independently compared. The exact source, projection and
+publication checks are in Custodian browser-resume-r1/canonical-integration.json.
+Native acceptance remains open under T16 and the other named owner tasks.
+
+
+## T20 — Prepare durable group provenance and prove disposable LLDAP compatibility
+
+```task
+id: NK-WP-0048-T20
+status: done
+priority: high
+state_hub_task_id: "863fcbdb-e246-51ba-87ca-a2f44d01d6f8"
+```
+
+Completed 2026-10-17, source candidate preparation and bounded synthetic
+compatibility proof only. This extracts evidenced implementation/fixture scope
+from T14; T14 retains native storage, writer isolation, protected callback and
+owner-acceptance gates. Source integration/publication and State Hub projection
+are pending the coordinator's separate receipts; no revision or task UUID is
+invented here.
+
+The existing identity-provisioner group ensure/revoke interface now has a
+reviewed candidate for a bounded owner-private SQLite journal, proven only in
+local/disposable use. The initial storage instructions wrongly suggested a native
+persistent-volume path; source review against accepted ADR-0015 corrected them
+before publication. Production SQLite-on-a-PVC is not admitted: T14 retains
+CNPG/rapp-postgres storage admission or a separately governed exception.
+The local journal saves
+complete prestate and intent before each attempted directory mutation, inventories
+only confirmed new groups/memberships, binds original ensure idempotency and
+correlation to the exact request digest, and refuses unsigned caller inventories
+or legacy broad revoke requests. Replays never recreate removed state. Missing,
+replaced or untrusted storage and missing intent rows stop execution; definite
+before-mutation refusals retain evidence without stranding unrelated valid work.
+Interrupted writes/readback remain unresolved across reopening. Revoke validates
+all targeted native ids and complete member postimages before destructive work,
+removes only confirmed creations and never deletes a preexisting empty group.
+Server/configuration wiring, image-copy closure and owner storage/request
+migration instructions are included. The existing endpoint's caller
+authentication remains the existing boundary, not a new grant.
+
+The candidate was prepared against NetKingdom
+`878abc93588e12b6da1bac055cfbb3abb8d7adf1`; exact source patch digest
+`sha256:1f3f3ca94c46dadac8f24896053d4d23179de795e50a24298a0cfbcc46cca30e`.
+The independent Custodian review passed all 65 provisioner checks. The earlier
+62-check candidate, two independent-review findings and subsequent fixes remain
+retained rather than overwritten. Seven additional fixture-plan checks exercise
+the preparation boundary; these counts overlap the same candidate and do not
+measure task-completion percentage or independent acceptance.
+
+A separately reviewed bounded fixture then exercised the exact candidate against
+cached pinned disposable LLDAP and Python images, through actual GraphQL. All 14
+closed compatibility/containment oracles passed: exact creation inventory,
+separate-process SQLite reopening/replay/revoke, complete preexisting directory
+preservation including empty/shared groups and memberships, refusal of shared
+membership drift, retained uncertainty after a lost response following a real
+addition, and refusal of unknown/cross-case receipt bindings. The fixture used
+only newly generated synthetic users/passwords/key material in private tmpfs,
+with a network-none anchor and shared loopback helper, no host ports/mounts,
+no image pulls and no production or actual credential contact. The coordinator's
+safe receipt reports both exact owned containers absent after cleanup; final
+independent cleanup verification remains the coordinator's integration duty.
+
+Evidence: Custodian
+`docs/changes/netkingdom-target-2026-10-16/group-provenance-r1/`, including exact
+source base/pre/postimages, patch/manifest, independent review and retained
+refinements. Native fixture manifest
+`sha256:8a0514f5f14137355972400cd4852f48c892316d28e3abd3c86635d7cb81eef2`;
+retained safe result `native-fixture/execution-result.json` (original
+`/tmp/nk48-groups-native-review-5pywb19z/result.json`). The source task supplies
+no native owner assent, production rollout, protected session/evidence callbacks,
+ordinary type admission or consumer login proof. LLDAP has no conditional
+membership mutation or generation token here: exact readback cannot exclude
+ABA or a concurrent external writer, so T14 remains open.
+
+2026-10-17 verified source follow-through: source commit `4f65e41` passed normal
+local scanning and all 65 canonical provisioner tests. The actual disposable
+LLDAP receipt passed all 14 oracles; independent verification on the pinned
+daemon found both exact names and the run label absent. Source integration
+includes the ADR-0015 documentation correction; the journal remains local-only.
+
+T14 source preparation is underway. Twenty-three pinned public sources identify
+NetKingdom implementation/reconciliation, Platform custody/database governance
+and rapp-postgres consumer provisioning; the inspected runtime binding does not
+assign identity-provisioner a package. The existing User Engine runtime token
+and pod route are not a protected-case caller lane. The native proposal preserves
+the same journal seam on a dedicated CNPG consumer and requires authoritative
+scope binding, admitted role/lease/placement/recovery and all LDAP writers fenced.
+The declared exclusive maintenance window is not mechanical exclusion of WebUI,
+helper or lifecycle writers. Capacity placement and EUR cost/risk remain owner
+decisions. No package, database, credential, rollout or owner assent was created.
+Custodian evidence: group-provenance-r1/native-storage-proposal-r1; final source,
+projection and cleanup review: resume-integration-r1/publication-verification.json.
+
+
+## T21 — Implement the PostgreSQL journal and prove disposable SQL compatibility
+
+```task
+id: NK-WP-0048-T21
+status: done
+depends_on: [NK-WP-0048-T20]
+priority: high
+state_hub_task_id: "afe78e4d-408a-516a-ab92-e212e8a2d11d"
+```
+
+Completed 2026-10-17: bounded source preparation and actual disposable PostgreSQL
+compatibility only. T14 retains native storage, custody, callbacks, authorization,
+all-writer isolation and production admission. Coordinator source publication and
+projection remain separate follow-through; no source revision or task UUID is
+invented here. T20 remains the historical local SQLite/actual LLDAP proof.
+
+The eight-path source candidate adds an injection-only PostgreSQL implementation
+behind the existing owner journal seam, with explicit trusted tenant/directory/
+case/source/principal/epoch binding and independent continuity callbacks. It
+persists bounded intent/created-only receipts, exact-one version updates, durable
+active fences, and a content-bound journal chain. SQL commits precede independent
+exact-marker acknowledgment; lost replies/checkpoints poison continuation and
+retain uncertainty. A counter-only checkpoint is explicitly insufficient for
+divergent clones. Migration does not create database/schema/credential, admit an
+epoch or clear quarantine; production HTTP activation is absent pending trusted
+callbacks. Pinned psycopg package/image-copy closure is included, without claiming
+an image build or native dependency admission.
+
+Candidate base `6cb43c0cc55212363a5406b02db046e2384a7c40`; final eight-path patch
+`sha256:5549d2982b61ff70aba4b3928fecd5639db0f1a732ab2f8630f678e7acf4d34d`.
+All 82 source tests pass, alongside 13 fixture plan/diagnostic checks and two
+source-backed snapshot regressions. Counts overlap the same source and fixture;
+they are not additive native acceptance or completion percentages.
+
+The independently reviewed R5 fixture ran the actual SQL migration/backend and
+existing provisioner path against cached pinned disposable PostgreSQL. Directory
+operations deliberately used the existing synthetic LLDAP test double. All
+manifest-declared phase oracles passed: creation-only inventory and DDL refusal;
+separate-process replay/revoke with complete preexisting/shared visible-state
+preservation; foreign-context refusal; concurrent exactly-once reservation and
+stale version refusal; actual database fork with divergent bodies at the same
+counter and fresh-object rejection of the losing exact checkpoint; retained
+uncertainty after checkpoint/directory/SQL response loss; and actual pg_dump/
+pg_restore rollback refusal against the independently retained fixture checkpoint.
+The checkpoint is fixture-only, not an admitted native owner evidence holder.
+
+Only generated credentials/state were used, with two nonroot/read-only containers
+on private loopback, bounded tmpfs/CPU/memory/PIDs/lifetimes, no host ports/mounts,
+no pulls and no production contact. The safe receipt reports both exact owned
+containers absent, with no daemon uncertainty. Independent final pinned-daemon
+cleanup verification remains coordinator follow-through.
+
+Failed R2/R3/R4 receipts and source revisions remain retained. R2's helper failure
+subphase is unknown; R3 exposed a real backend bug where replacing nested receipt
+objects lost the created ID held by ensure, fixed by acknowledging only the backend
+version after commit/checkpoint. R4 verified that fix through actual SQL bootstrap,
+then exposed fixture snapshot aliasing and empty deleted-group backing entries;
+source-backed regressions corrected the snapshot without weakening complete
+visible-prestate equality, and reject nonempty orphan membership. These refinements
+belong to one trial, not extra native acceptance successes.
+
+Custodian evidence: `docs/changes/netkingdom-target-2026-10-16/group-postgres-r1/`;
+exact source/pre/postimages and retained predecessors; native R5 manifest
+`sha256:d51f90816616848b93bcdc482e10a98d07061deb01eeed9e50700fc6e68b6051`;
+`final-integration-r1/typed-execution-evidence.json` and byte-exact safe receipt
+(original `/tmp/nk48-postgres-native-review-sguj7t8p/result.json`). No CNPG native
+storage/HA/backup/lease/TLS/capacity/restore admission, authoritative protected
+callbacks, real LDAP writer fencing/CAS/ABA exclusion, owner assent or production
+endpoint activation is claimed. Those remain live T14 work.
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-registration-refinement-r2/t22-applied-intermediate.md b/docs/changes/netkingdom-target-2026-10-17/native-registration-refinement-r2/t22-applied-intermediate.md
new file mode 100644
index 00000000..6d68ad32
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-registration-refinement-r2/t22-applied-intermediate.md
@@ -0,0 +1,1142 @@
+---
+id: NK-WP-0048
+type: workplan
+title: "Establish SecurityCaseTypes so that known security cases are light"
+domain: infotech
+repo: net-kingdom
+status: active
+flavor: implementation
+owner: claude-code
+topic_slug: netkingdom
+created: "2026-10-08"
+updated: "2026-10-17"
+depends_on: []
+related_repos:
+  - ops-mason
+  - ops-warden
+  - key-cape
+  - railiance-platform
+  - informed-decision
+state_hub_workstream_id: "e31f3f9d-0748-5137-b0a3-7b3ca46a66eb"
+---
+
+# NK-WP-0048 - Establish SecurityCaseTypes so that known security cases are light
+
+## Why
+
+The founder's direction (2026-10-08): setting up a security integration of a
+kind that has been done before should be easy, meaning accept the case, then
+ops-mason arranges it and ops-warden follows through. Setting up a new kind
+needs ample documentation and tests and an informed-decision, because its shape
+is part of the security architecture.
+
+Today every integration is hand-built: per-client helper scripts, per-lane
+custody, founder checklists. The trigger was KEY-WP-0038 (Forgejo as an OIDC
+client), whose next step was going to be yet another hand-written rollout
+script.
+
+This plan continues the pattern work of NK-WP-0008 (pattern infospace),
+NK-WP-0009 (tutorials) and NK-WP-0030 (scenario composition). It turns patterns
+into **SecurityCaseTypes** that ops-mason and ops-warden can execute. Canon:
+`canon/standards/security-case-types_v0.1.md` (proposed).
+
+Companion plans: ops-mason `MASON-WP-0010` (materialization) and ops-warden
+`WARDEN-WP-0044` (follow-through).
+
+## Tasks
+
+```task
+id: NK-WP-0048-T01
+status: done
+priority: high
+state_hub_task_id: "930ac3e9-20ec-5473-98cd-3fe8fddb730f"
+```
+
+### T01 — Accept the terminology and the canon
+
+Founder review of `canon/standards/security-case-types_v0.1.md`, including its
+section 10 open questions. On acceptance the canon status goes from `proposed`
+to `accepted`.
+
+2026-10-08: accepted by the founder (in session). Canon status `accepted`;
+section 10's open questions are carried forward to the first type (T04, T05).
+
+```task
+id: NK-WP-0048-T02
+status: done
+priority: high
+state_hub_task_id: "19c25d96-a55c-58f0-9168-3fdbc4955fc2"
+```
+
+### T02 — Inventory the de-facto types already built by hand
+
+Read-only. List every security integration built so far and group them by shape.
+Known starting points:
+
+- browser OIDC relying parties on key-cape: informed-decision-approver,
+  coulomb-social, user-engine portal, openbao-admin, and Forgejo (pending)
+- confidential service clients with `client_credentials`: secrets-engine
+  approval, requester and openbao clients, approval-engine operator
+- workload KV read lanes on OpenBao: the railiance-platform credential lane
+  designs and CCRs, for example `railiance-backup-offsite-lane`
+- short-lived SSH certificates through ops-warden (`warden sign`)
+- tunnelled operator access (ops-bridge)
+
+For each: the repositories involved, the hand-built steps, attended human steps,
+custody paths, verification evidence, and rollback (if any). Output
+`docs/security-case-type-inventory.md`, ranking candidate types by how often the
+shape recurs and how much manual work each instance costs today.
+
+2026-10-08: done, `docs/security-case-type-inventory.md`. 36 of 37 CCRs are
+already `request_type: workload-kv-read`, a de-facto type reviewed each time as
+if it were new. Browser clients: 5 hand-built plus Forgejo, each with its own
+rollout script. Confidential service clients need a registration plus two or
+three KV-read CCRs each. A forge read identity is needed in bulk by
+ORGREF-WP-0002-T06. Recommendation: oidc-browser-relying-party first (unblocks
+the forge), workload-kv-read second (largest payoff), then forge-read-identity.
+
+```task
+id: NK-WP-0048-T03
+status: done
+depends_on: [NK-WP-0048-T01]
+priority: high
+state_hub_task_id: "e487975b-73b1-516c-971d-da4cbbb93063"
+```
+
+### T03 — Schema, template and validator
+
+- `canon/schemas/security-case-type_v0.1.schema.json` and
+  `security-case_v0.1.schema.json`
+- `security-case-types/_template/` with `type.yaml`, `README.md` and tests to copy
+- a validator, extending `tools/security-scenario-composer/`, that checks a type,
+  checks a case against its type, and renders the case into the composer's
+  deterministic plan (still `execution.permitted: false`)
+
+Acceptance: the validator rejects missing sections, secret-shaped parameter
+values, unpinned providers and cases against non-`implemented` types, with tests
+for each.
+
+2026-10-08: done. `canon/schemas/security-case-type_v0.1.schema.json` and
+`security-case_v0.1.schema.json`; `tools/security-case-types/security_case_validator.py`
+(`validate-type`, `validate-case`, `render`, reusing the scenario composer);
+`security-case-types/_template/` (a valid, runnable example type over
+`net-kingdom.local-identity`, with README sections, an example case and tests that
+travel with every copy). 31 tests pass, including the composer's existing suite.
+
+```task
+id: NK-WP-0048-T04
+status: done
+depends_on: [NK-WP-0048-T02, NK-WP-0048-T03]
+priority: high
+state_hub_task_id: "2fffe112-7d55-5680-9952-78d74f44f87f"
+```
+
+### T04 — Define the first type: browser OIDC relying party
+
+`security-case-types/oidc-browser-relying-party/`, version 1.0:
+
+- parameters: client id, display name, exact redirect URIs, scopes, client type
+  (confidential or public), MFA pin, the groups the consuming service maps,
+  custody path for the secret (confidential only), consuming service and its
+  owner
+- composition: key-cape client registration (key-cape declares it as a playbook
+  capability), secret minting into custody (railiance-platform), LLDAP group
+  existence and membership (net-kingdom identity-provisioner), handover to the
+  consuming service
+- materialization (ops-mason) and follow-through (ops-warden) sections
+- verification: discovery lists the redirect URI; a test sign-in returns the
+  expected claims for one human; anonymous access to the custody path is denied
+- rollback: remove exactly this client and its custody path
+- README: threat model, MFA rationale, why redirect URIs are exact, which steps
+  still need an attended login and how that is minimised
+- reference instances: informed-decision-approver, coulomb-social, user-engine
+  portal, openbao-admin
+
+Acceptance: complete per canon section 3, tests green, status `proposed`.
+
+2026-10-08: done. `security-case-types/oidc-browser-relying-party/` 1.0 (proposed):
+`type.yaml` with 12 parameters (the custody reference is required only for
+confidential clients), composition over key-cape's new
+`key-cape.oidc-client-registration` declaration (contract PASS, `maturity:
+planned`), materialization and follow-through, verification and rollback, all
+conditional on client type where it matters. One attended step,
+`register-client`, justified by the live registry being a Kubernetes Secret.
+README with threat model, alternatives, an honest fit table (portal and vergabe
+fit; Forgejo is the first confidential case; openbao-admin, coulomb.social and
+informed-decision-approver do not fit 1.0), and known limits. Examples: Forgejo
+(checked against the accepted request) and a public portal. The validator gained
+`when` / `required_when` conditions and provider discovery. 43 tests pass.
+ops-mason's and ops-warden's sections are drafted in the type. Their owners
+review them in MASON-WP-0010-T01 and WARDEN-WP-0044-T01 before acknowledgment
+(T05).
+
+```task
+id: NK-WP-0048-T05
+status: done
+depends_on: [NK-WP-0048-T04, MASON-WP-0010-T01, WARDEN-WP-0044-T01]
+priority: high
+state_hub_task_id: "3d987d3d-0797-538b-86e4-51185a327ae2"
+```
+
+### T05 — Acknowledge the type through informed-decision
+
+Prepare the Decision Memo from the type's README and `type.yaml` and submit it
+through informed-decision's production intake. On acknowledgment the type
+moves to `acknowledged`.
+
+2026-10-08: Decision Memo prepared. Hub decision `e418263e-a71f-4f01-a970-c87c9e187c09`.
+`security-case-types/oidc-browser-relying-party/decision/`: `packet.md` (question,
+one act, what acknowledging does not do, the shape, alternatives, attended
+steps, limits, evidence), `build_intake.py` and the built `intake.json` (memo
+class `decision-record`, review group `net-kingdom-admins`, resolves the hub
+decision on answer). The envelope passes informed-decision's own
+`validate_submission`. Queuing it is an attended operator step, a write inside
+the production dispatcher pod:
+
+    kubectl -n state-hub exec -i deploy/state-hub-memo-dispatch -- \
+      python -m api.services.memo_dispatch --queue /data/private enqueue --envelope /dev/stdin \
+      < security-case-types/oidc-browser-relying-party/decision/intake.json
+
+The answer then appears for review in informed-decision.
+
+2026-10-08: queued by the founder (`pending`, `queued`) after one refusal: the
+first envelope's idempotency key was not State Hub's stable
+`state-hub.<decision>.<memo>` form, and the builder now validates against both
+sides. The dispatcher delivered it to informed-decision (ledger 7 → 8
+delivered). T05 waits for the founder's answer in informed-decision, which
+resolves hub decision `e418263e`.
+
+2026-10-08: ops-mason's review (MASON-WP-0010-T01) folded into the type, still
+1.0 `proposed`: `secret_ref` is no longer a parameter, the type derives
+`platform/workloads/keycape/{client_id}`; policies are
+`workload-kv-read-keycape-{client_id}-eso` and
+`workload-kv-read-keycape-{client_id}-{consuming_service}`, each with a templated
+body (`read` on that one data path); new `openbao_role`
+`external-secrets-keycape-{client_id}` (Kubernetes auth, ESO service account,
+15m, no default policy); catalog entry `{consuming_service}-keycape-client`;
+the two rollback steps on the KV path collapse into one metadata delete. The
+schema and validator now require a `body` on policy and role items. 105 tests
+pass. Two consequences: the delivered memo describes the type before these
+changes (a case-set custody reference, two differently named policies, no ESO
+role), so the founder answers on a superseded shape unless the memo is
+re-sent; and Forgejo's custody path moves from the accepted request's proposed
+`platform/workloads/forgejo/netkingdom-oidc-client` to
+`platform/workloads/keycape/forgejo`, which key-cape (KEY-WP-0038) and
+railiance-apps (RAPPS-WP-0016-T02) need to adopt in T06. ops-warden's review
+(WARDEN-WP-0044-T01) is still in progress.
+
+2026-10-08: revised memo `nk-wp-0048-t05-oidc-browser-relying-party-r2` built
+(`packet.md`, `intake.json`, packet `sha256:af6435e2…`); it states that it
+supersedes the first memo and passes informed-decision's and the dispatcher's
+validation. It needs a new memo id because the dispatcher refuses new content
+under a delivered idempotency key (`idempotency_conflict`). Queuing it is the
+same attended step as above. Both memos serve hub decision `e418263e`; the
+first answer resolves it, so the first memo must not stay open: an accept on it
+would acknowledge the superseded shape, and a decline would resolve the
+decision against r2. Close it with `return` (a reviewer verb that requests a
+new revision and does not resolve the hub decision; only accept and decline
+do), commenting that r2 supersedes it, then answer r2. `withdraw` exists in
+the vocabulary but is not offered to reviewers, and lifecycle `revise` only
+applies to lifecycle-registered memos, not intake-delivered ones.
+
+2026-10-09: the founder reports r2 enqueued and the first memo returned. At
+close, hub decision `e418263e` still showed `open` (not verified whether r2
+was answered or the answer is still in transit; the dispatcher ledger was not
+read). ops-warden's review (WARDEN-WP-0044-T01, ops-warden
+`history/2026-10-08-oidc-rp-follow-through-review.md`, d470f2e) arrived at
+21:25, before r2 was built, and is not in r2. Required before WARDEN-WP-0044-T02:
+R1 a per-step `lane` (missing: identity-provisioner caller credential,
+railiance-platform broker grant), R2 canon meaning of `warden_executes: true`
+(caller proxy, caller identity, no standing ops-warden token; ADR-0002), R3 a
+per-step `value_handling`. Refinements R4 (one type-level catalog lane instead
+of a per-case entry, which conflicts with ops-mason's item 5), R5 (ESO Ready gate
+before bind-env), R6 (exact accepted memberships), R7 (mfa-pinned and
+secret-delivered checks). Next: if r2 was accepted, fold R1-R3 and R5-R7 in as
+a follow-up and settle R4 between ops-warden and ops-mason before T06; if not,
+hold r2, fold them in and build r3.
+ key-cape and railiance-apps were told about Forgejo's new custody
+path.
+
+2026-10-09: r2 was not answered (hub decision `e418263e` open; dispatcher 9
+delivered), so r2 is held and r3 replaces it. ops-warden withdrew R4 for R4′
+(message a66a9204): one catalog entry per case with its body templated in the
+type. Folded in:
+
+- Canon section 3: a narrow meaning of `warden_executes: true` (caller proxy,
+  caller identity, no standing credential; ops-warden ADR-0002), plus per-step
+  `lane`, `value_handling` and an optional `ready_check`. A catalog entry body is
+  now required, like policy and role bodies.
+- Schema and validator enforce all of these.
+- The type: lanes `identity-provisioner-groups` and
+  `keycape-client-secret-generate` (both new) and `key-cape-oidc-login`;
+  `mint-secret` is `generated_in_custody`; a Ready gate on `deliver-secret`;
+  `ensure-groups` adds exactly the accepted case's memberships; new checks
+  `secret-delivered` and `mfa-pinned`; the catalog-entry body follows R4′.
+- 110 tests pass.
+
+Memo r3 (`nk-wp-0048-t05-oidc-browser-relying-party-r3`, packet
+`sha256:726dfc01…`) passes informed-decision's and the dispatcher's validation.
+The founder queues it with the same command, returns r2 with a comment that r3
+supersedes it, then answers r3.
+
+Prerequisites for T06, not for T05:
+- the two new lanes, each through its owner;
+- a founder-approved rollout of an identity-provisioner image containing
+  630ebfd (the deployed one is main-6c4fcaf from 2026-09-24, without
+  `/v1/groups/ensure`).
+
+ops-mason's request to create LLDAP group `fluid-telegram-operators` (message
+259ec26d) was answered: not possible from here by that path; the founder creates
+it in the LLDAP admin UI.
+
+2026-10-09: ops-warden finished its side of WARDEN-WP-0044-T01 (message
+`58d33f40`, commit 0e7ceb8): the revised type conforms to `warden case
+check-type`, with no further changes asked of the type. This acknowledges that
+review. Its later addendum R8 (message `af274783`, ops-warden
+`history/2026-10-08-oidc-rp-follow-through-review.md`) showed that lane
+`identity-provisioner-groups` cannot exist as declared: the provisioner's only
+HTTP credential is user-engine's runtime token, and its NetworkPolicy admits
+only user-engine pods, so a caller-proxy lane would act as user-engine. Taken
+option 1 (ops-warden's recommendation): `ensure-groups` and its rollback are
+attended, in the `register-client` session on `key-cape-oidc-login`, run inside
+the provisioner pod; no token is read. Option 2 (an operator credential of its
+own on the provisioner) stays open for a later version. `warden case
+check-type` now reports only `keycape-client-secret-generate`
+(railiance-platform) as missing. 89 tests pass.
+
+Hub decision `e418263e` was still open, so memo r4
+(`nk-wp-0048-t05-oidc-browser-relying-party-r4`, packet `sha256:452ea421…`)
+replaces r3; it passes informed-decision's and the dispatcher's validation. The
+founder queues it with the same command, returns r2/r3 if still open with a
+comment that r4 supersedes them, then answers r4.
+
+Prerequisites for T06 are now: lane `keycape-client-secret-generate`
+(railiance-platform), and a founder-approved rollout of an identity-provisioner
+image containing 630ebfd.
+
+2026-10-09: done. The founder queued r4 (`pending`, `queued`), returned r3 as
+superseded and accepted r4 in informed-decision. informed-decision's hub
+write-back is off in production (`INFD_HUB_WRITEBACK` unset), so net-kingdom
+resolved hub decision `e418263e` from the founder's report, naming memo r4 in
+the rationale. The type is `acknowledged`; it becomes `implemented` with T06.
+
+```task
+id: NK-WP-0048-T06
+status: wait
+depends_on: [NK-WP-0048-T05, NK-WP-0048-T08, NK-WP-0048-T09, NK-WP-0048-T12, NK-WP-0048-T13, NK-WP-0048-T14, NK-WP-0048-T15, NK-WP-0048-T16, NK-WP-0048-T17, NK-WP-0048-T18, NK-WP-0048-T20, MASON-WP-0010-T03, WARDEN-WP-0044-T03]
+blocking_reason: "Type1.2 architecture has a confirmed source-only founder acknowledgment; canonical1.1 remains unchanged/default and the1.2 reference case stays proposed. Needs explicit version selection/reference-source integration without normal admission bypass, closed owner adapters plus global/native receipt verifier (WARDEN-WP-0044-T03), independently verified six-object structural materialization and CCR42 claims/created-only provenance, exact broker/case/source reconciliation, then separately authorized native mint/delivery and attended registry/consumer verification. Source acknowledgment, a bundle or local tests do not prove implemented/materialized/live status."
+priority: high
+state_hub_task_id: "d9b26bcf-a7c6-59a2-92a0-f913d76a203c"
+```
+
+### T06 — First KnownSecurityCase: Forgejo
+
+Write `security-cases/forgejo-netkingdom-oidc.yaml` from the parameters the
+founder accepted in KEY-WP-0038-T01 (`key-cape/docs/forgejo-oidc-client-request.yaml`),
+so that acceptance carries over as the case acceptance. ops-mason materializes it;
+ops-warden follows through and verifies it. The type becomes `implemented` once
+this reference case is live.
+
+This replaces the hand-built path proposed for KEY-WP-0038-T02.
+
+2026-10-09: case written, `security-cases/forgejo-netkingdom-oidc.yaml`, status
+`accepted`: the example's parameters plus the founder's 2026-10-08 acceptance of
+the key-cape request (owner and founder), with the custody-path derivation
+covered by the type's acknowledgment (memo r4). It validates and renders (plan
+`execution.permitted: false`; three attended steps on `key-cape-oidc-login`);
+it needs `--allow-unimplemented` until it is live, since it is the case that
+makes the type `implemented`. A test keeps it equal to the type's example.
+Still open before it runs: ops-mason renders and builds it (MASON-WP-0010-T02,
+T03, unblocked by T05), ops-warden plans and runs it (WARDEN-WP-0044-T02, T03),
+railiance-platform's `keycape-client-secret-generate` lane (asked by ops-mason
+`789feb39` and ops-warden `d9f889b1`, both unread), and a founder-approved
+identity-provisioner rollout containing 630ebfd.
+
+2026-10-09: identity-provisioner rolled out, founder-approved in session:
+`main-630ebfd` (`sha256:bafb4860…`, built by the image workflow) replaces
+`main-6c4fcaf` (`sha256:ffacd5d7…`; only change: 630ebfd, additive). Applied
+with `kubectl set image` on the Deployment only (generation 17 → 18, 1/1 Ready);
+the file's Service, NetworkPolicies and Ingress were not reapplied. Verified in
+the pod: `ensure_service_groups` and `revoke_service_groups` present, `/readyz`
+200; no token used, no group changed. Rollback: `kubectl -n sso set image
+deploy/identity-provisioner provisioner=forgejo.coulomb.social/coulomb/identity-provisioner@sha256:ffacd5d790a5b7800e0535f3aa95b7de52c7a68e4f575b9192c3e1622fa672c2`.
+The pin in `sso-mfa/k8s/identity-provisioner/deployment.yaml` follows.
+
+2026-10-09: ops-warden closed WARDEN-WP-0044-T01 and shipped `warden case plan`
+(T02, message `06303d1d`); the accepted Forgejo case is refused until ops-mason
+materializes it, and a materialized copy plans cleanly once
+`keycape-client-secret-generate` exists. Its observation that `bind-env` carries
+a literal `KEYCAPE_<CLIENT_ID>_CLIENT_SECRET`: the validator now renders a
+`{param:env}` format spec (upper case, `-` as `_`, as `keycape-client.py`
+derives the name) and rejects unknown specs, and follow-through and rollback
+text is now checked for unknown placeholders too (patch-level, canon section 6).
+The type keeps the literal until ops-warden's planner (`text.format`) renders the
+spec as well; asked of ops-warden. 53 tests pass.
+
+2026-10-10: ops-warden rendered `{param:env}` in `warden case plan`
+(23ba584, message `c1df14b7`; other specs and `!conversion` refused). The type
+adopts it as a 1.0 patch (canon section 6): `bind-env` and its rollback now read
+`KEYCAPE_{client_id:env}_CLIENT_SECRET`. ops-mason reports the Forgejo case
+rendered and built (message `1ebddae9`; CCR drafts handed to railiance-platform),
+so T06 now waits on the platform apply, the mint-secret lane and the attended
+register-client session.
+
+2026-10-10: key-cape adopted the type's custody path (key-cape ab5cccd, message
+`88a4559c`): `docs/forgejo-oidc-client-request.yaml` and KEY-WP-0038-T02 name
+`platform/workloads/keycape/forgejo`, field `CLIENT_SECRET`, delivered as
+`sso/keycape-forgejo-client` through `external-secrets-keycape-forgejo`, and the
+`forgejo/netkingdom-oidc-client` proposal is withdrawn. This matches the type and
+the Forgejo example; no change needed here.
+
+2026-10-10: key-cape's type-composition review (key-cape 6038483, message
+`8e5ed5f6`) found the composition sound with two blocking findings, taken as a
+1.0 patch (stricter validation and documentation, canon section 6):
+R1, redirect URIs now refuse `?` and `#` in the type pattern and in
+`keycape-client.py`'s `REDIRECT` (KeyCape refuses `?` at startup and the single
+replica would stop); R2, `allowed_scopes` always includes `groups`, the renderer
+refuses `access_groups` without it, and `access_groups` now says the consumer
+enforces the gate because KeyCape has none; R3, `mfa_required` "false" means the
+per-user privacyIDEA policy; R4, register-client's justification records the
+restart for every client, the quiet window, and that the rendered registry must
+pass KeyCape's client validation before it. The accepted Forgejo case and both
+examples still validate; 116 tests pass.
+Open, needs a decision: R2's verification step that the consumer enforces the
+group gate is a new verification step, hence 1.1 (minor), and the validator pins
+cases to the exact type version, so the accepted 1.0 Forgejo case would need
+re-pinning. Also open with key-cape: a KeyCape entry point that validates a
+rendered client registry without starting the server; until then
+`keycape-client.py` mirrors the redirect rule.
+
+2026-10-10: founder go for 1.1, so no 1.0 run overlaps. The type adds
+verification `consumer-enforces-groups`, and hand-over now requires the consumer
+to enforce `access_groups` (minor, canon section 6; risk class unchanged, no new
+acknowledgment; history in the type README). The accepted Forgejo case and both
+examples are re-pinned to `oidc-browser-relying-party@1.1` before any apply; the
+acknowledgment intake keeps `@1.0` as the record of what was acknowledged.
+ops-mason's build and ops-warden's case-ref digest predate this and need a
+re-render.
+
+2026-10-10: ops-mason re-rendered the Forgejo case from `@1.1` (message
+`22c6bba6`; plan digest `af1f4f81…`, no collisions) and rebuilt the bundle. The
+rendered OpenBao objects are identical to 1.0, so the already applied
+CCR-2026-0041 stands; 1.1 changes only consumer-side steps. key-cape shipped
+`keycape check-config` (c528daa, message `a7b0aeff`): KeyCape's startup checks
+without secret values, including the new duplicate-clientId rule.
+`keycape-client.py --check-config <binary>` now runs it on the live and the
+proposed registry, fed on stdin, and apply refuses a proposed registry that
+fails; register-client's entry point names the option (1.1 patch). The deployed
+image predates c528daa, so the binary is built from key-cape source for now.
+Before the next KeyCape rollout (Forgejo register-client or the CCR-2026-0018
+window), the attended operator runs `inspect --check-config` so the live
+registry is checked too.
+
+```task
+id: NK-WP-0048-T07
+status: wait
+depends_on: [NK-WP-0048-T06]
+blocking_reason: "The next types follow once the first one is proven end to end."
+priority: medium
+state_hub_task_id: "c3c9c3ae-4f23-5ba7-9e6f-e63bcf29b9f7"
+```
+
+### T07 — Queue the next types
+
+From the T02 ranking, open the next type drafts (likely the confidential service
+client and the workload KV read lane), each to be acknowledged on its own.
+Record which existing hand-built instances get adopted as cases, without
+rewriting them in place.
+
+```task
+id: NK-WP-0048-T08
+status: done
+priority: high
+state_hub_task_id: "8e519082-dc8b-5e46-b660-03d03e55dcf6"
+```
+
+### T08 — identity-provisioner: ensure service-access groups
+
+The type's `ensure-groups` step calls `identity-provisioner groups ensure --groups
+<list> --members <group=user+user;...>`. The provisioner already has idempotent
+`_ensure_group` and `_add_group`, but exposes only tenant-scoped operations. Add
+the general operation (create if absent, add the listed memberships, never
+remove others), its rollback (remove only this case's memberships), tests, and
+the ops-warden route for its service identity.
+
+2026-10-08: done. `identity-provisioner/provisioner.py` gained
+`ensure_service_groups` (`POST /v1/groups/ensure`) and `revoke_service_groups`
+(`POST /v1/groups/revoke`), behind the existing service-token check. Names
+matching `tenant*`, `netkingdom-*` and `lldap_*` are reserved; members must
+already exist; everything is validated before any change; memberships are read
+back before success; nothing else is ever removed; groups are deleted only when
+asked and empty. 7 new tests (39 in the provisioner suite). The type's
+`ensure-groups` step and its rollback now name these endpoints. The ops-warden
+route for the provisioner's service token belongs to WARDEN-WP-0044-T01.
+
+```task
+id: NK-WP-0048-T09
+status: done
+priority: high
+state_hub_task_id: "0ee12dfc-8260-5038-bd39-cc7fb4113be0"
+```
+
+### T09 — The `keycape-client` entry point and its declaration
+
+Planned first as key-cape KEY-WP-0038-T04. Moved here because the machinery a
+live registration needs already lives in net-kingdom, where KeyCape is deployed
+(`sso-mfa/k8s/keycape/`): the contained kubectl, the cluster-identity pin and the
+issuer pin. A copy in key-cape would drift.
+
+2026-10-08: done. `sso-mfa/k8s/keycape/keycape-client.py` derives the KeyCape
+client record from a case (`client-from-case`). It adds or removes exactly one
+client with the existing safeguards (byte-preserving merge, exact match or
+refuse, shared-reference refusal, compare-and-swap, read-back, contained errors),
+requires the Deployment env binding first for confidential clients, and requires
+the case acceptance record for `apply` instead of a per-client founder decision
+id. 15 tests, including a regression showing that the vergabe case reproduces
+its hand-built registration exactly; all 71 helper tests pass. Declaration
+`capabilities/playbooks/net-kingdom.keycape-client-registration.yaml` (contract
+PASS, `maturity: implemented`) replaces key-cape's draft. The type now pins it,
+and for confidential clients adds `deliver-secret` (delivery from custody into
+the sso namespace) and `bind-env` (Deployment env), attended in the same session
+as `register-client`. The per-client helpers stay until their clients are
+adopted as cases.
+
+2026-10-10 — NetKingdom owner review of the execution seam, source only:
+ops-warden/docs/security-case-execution-proposal.md SHA256 78ab1439e4c5beb205aeccf15b1b2e706511be55ab195c5a3aa682f326c7c77c
+was reviewed against INTENT, SecurityCase canon, acknowledged type1.1, current
+case and owner source. docs/security-case-execution-owner-review.md supports
+the closed adapter/receipt direction with explicit versioned schema, structural
+materialization provenance, unchanged caller/session boundaries, safe CAS
+reconciliation and exact-created-object rollback requirements. This is owner
+review, not approval. Supporting file digests are in the adjacent sources JSON.
+
+Current source exposes a circular wait: ops-mason T03 waits on mint while Warden
+and the broker refuse a non-materialized case. Structural acceptance therefore
+needs its own native pinned receipt before mint, not a successful mint before
+materialized. The platform broker additionally pins type1.0 while Forgejo is
+accepted at1.1; platform-owner alignment and tests are required, not an unchecked
+version bypass. T06 remains wait. No case/type lifecycle status, grant, authority
+or live runtime changed by this review. A proposed informed-decision would
+adopt the source contract only; native materialization and execution acceptance
+stay distinct.
+
+Final proposal re-review: staged Warden proposal SHA256 78ab1439e4c5beb205aeccf15b1b2e706511be55ab195c5a3aa682f326c7c77c
+adds only the explicitly local reducer appendix, not an accepted wire protocol
+or executor. The exact-final review and sources JSON supersede the earlier
+1035f049... proposal review. Platform staged the exact type1.1 broker correction
+with ten fake-backend subprocess checks (script SHA256
+9576cd211cfc06526ec4cc9bd0a5b06f0f59287a68931bb2d6e3592a951ddc7d).
+The next source work is the versioned closed adapter/receipt/materialization
+contract, not another relaxation of the broker's status gate. Native work still
+requires installed broker provenance, structural reader receipts, exact new
+materialized-case bytes, caller grant/session revocation and verified execution.
+No installed/native acceptance is inferred from that staged correction.
+
+2026-10-11 — new source-only type1.2 architecture acknowledgment:
+Confirmed native founder ACCEPT of infd-20261011-forgejo-type12-source-r1@1
+at06:47:39Z, approval8e9332c8-754a-420c-b8b7-445cb4fe6765. Exact frozen packet
+0b377d647ca748cd03c92f9792396412048055d4bde9f7bb06ff6d413f7acd68 and submission
+585cee731de30d2b37883a57abfd9eb32f023ee694e8d911989109d5caf80569; native receipt
+retained in docs/evidence/2026-10-11-forgejo-type12-source-acknowledgment/.
+The complete acknowledged1.2 source package is isolated under
+security-case-type-revisions/1.2/oidc-browser-relying-party; default loader and
+current accepted1.1 case remain untouched because load_type is single-version.
+The new proposed1.2 case is NOT accepted/materialized/live and has no acceptance
+fields. Actual reference-migration design approval is a separate Apps owner
+receipt; no1.1 approval is inherited. Source-recording review/test proof and exact
+next gates are in docs/forgejo-type12-source-acknowledgment-followthrough.md.
+T06 remains wait and T07 remains its existing dependent task; type is NOT
+implemented and no first-case/native grant or broader workplan finish is asserted.
+
+2026-10-11 — bounded explicit version selection source preparation for T06:
+The validator now offers optional exact version_roots/--version-root VERSION=PATH
+selection with duplicate/mismatch/traversal/symlink refusal and no fallback. The
+default1.1 source and historicalacceptedcase hashes/ordinaryrefusal/preparation
+render stayunchanged; actual1.1 is acknowledged, not implemented. Acknowledged1.2
+ordinaryadmission also refuses; optionalpreparation remains nonexecuting.43local
+validatorchecks pass and original1.1 CLIrenderbytes match exactly. Makerproof:
+docs/evidence/2026-10-11-explicit-type-version-selection/source-integration-validation.json.
+FormalNetownerreview/reference-source integration and all existing native adapter,
+provenance/broker/materialization/attendedproof gates remain; T06 stayswait, no
+new residual or firstcase/typeimplementation/native grant is inferred.
+
+
+2026-10-16 — isolated source preparation for T06 (canonical integration pending):
+Added `check-evidence` to the existing validator CLI. It reuses exact version
+selection and ordinary type/case/render admission, checks actual Mason structural
+request source/inventory/projection pins and reads actual Warden journal rows
+read-only. Successful rows require exact type-declared descriptors and attempt/
+revocation fingerprints. Existing acknowledged types without machine descriptors
+remain plan-only. The compatibility result never claims authenticated native
+completion: Request and journal fingerprints are not portable native evidence.
+Owner authentication/status binding and actual native gates remain unresolved;
+T06/T07 statuses and both type/case lifecycles remain unchanged. No dispatch,
+credential access or authority expansion is introduced. See tool README for the
+existing owner protocol boundaries and source integration tests.
+
+Concrete next Warden owner integration: current `Executor.admit` refuses every
+case parameter whose sensitivity is not public/operational, so browser
+`redirect_uris`, `allowed_scopes`, `client_type`, `mfa_required` (and 1.2
+`consumer_namespace`) fail after otherwise prepared admission. The sensitive
+classification is a security-change review level, not secret content. The
+Warden owner must validate through NetKingdom's existing exact-version case/type
+validator, then project only descriptor-declared safe target metadata; do not
+remove the credential/value refusal or copy complete parameters into journals.
+Actual owner descriptor acknowledgment and independent evidence admission remain
+prerequisites, with normal admission still refusing unimplemented types.
+
+
+## T10 — Source compatibility checker for Mason and Warden evidence
+
+```task
+id: NK-WP-0048-T10
+status: done
+priority: high
+state_hub_task_id: "4b06ca97-c1e4-5680-bf22-ab75ab1646a4"
+```
+
+Completed 2026-10-16 in published source `c31d21ba`. The read-only
+`check-evidence` command checks the actual Mason structural request and Warden
+journal source protocols against an exact version/render. Independent source
+review passed 103 tests at that checkpoint. It always reports native completion
+false and execution prohibited. Fixtures and local journal fingerprints do not
+provide authenticated owner/native evidence. This records completed source scope
+previously described under T06; it does not duplicate native acceptance credit.
+
+## T11 — Validate the optional machine-descriptor pin contract
+
+```task
+id: NK-WP-0048-T11
+status: done
+priority: high
+state_hub_task_id: "ef2a0119-f59e-5e45-9519-115da9df7b85"
+```
+
+Completed 2026-10-16. Reproduced the JSON schema rejecting a valid
+`execution_descriptors` map while the Python validator accepted malformed maps.
+The schema now supports the existing Warden optional exact-byte pin map; semantic
+validation binds keys to declared steps, bounds the map and checks digest shape.
+The direct evidence API refuses malformed maps before accessing them. Twenty-one
+new checks and all 127 affected source checks passed. No current type/case bytes,
+status, owner descriptors or native acceptance changed. Source evidence and
+publication receipt: Custodian
+`docs/changes/netkingdom-target-2026-10-16/browser-acceptance-next/`.
+
+## T12 — Prepare NetKingdom-owned attended step adapters
+
+```task
+id: NK-WP-0048-T12
+status: todo
+priority: high
+state_hub_task_id: "7ce4eee3-cd47-55a9-bfa5-4f1835d4d6fd"
+```
+
+Owner: NetKingdom. Retained scope: prepare bounded attended Deployment env,
+config verification and restart/readiness steps around the existing helpers.
+Next action: identify exact current entry points and their revision/readback
+contracts, then implement fixed source-pinned callbacks or receipt-only attended
+steps. Completion requires positive/refusal checks, exact target/source pins and
+uncertainty behavior without acquiring user-engine runtime identity or exposing
+registry/client secrets. Existing caller/session, cluster/issuer, CAS/readback
+and status-only output boundaries remain mandatory.
+
+2026-10-16 task refinement: the original broad adapter scope is split into T13
+(completed registration source candidate), T14 (group creation provenance), T15
+(durable registration recovery) and T16 (descriptor/artifact selection and owner
+review). This preserves T12's task ID and Hub UUID while giving each remaining
+outcome an owner and completion gate. T06 now names every source dependency;
+its native/reference lifecycle acceptance scope remains unchanged. Completion
+of any source task supplies no Warden, Platform or Apps assent and no native
+execution authority.
+
+## T13 — Prepare the fixed registration adapter source candidate
+
+```task
+id: NK-WP-0048-T13
+status: done
+priority: high
+state_hub_task_id: "b264c10b-565c-5d29-b788-03cf5fbd2883"
+```
+
+Completed 2026-10-16, source implementation and synthetic fixture proof only.
+Added an injection-only adapter around actual `keycape-client.run`: fixed
+case/principal/human/lane/source/acceptance binding, existing CAS/readback,
+metadata-only owner evidence and per-attempt parent-session revocation boundary.
+The descriptor source composition pins the exact checker executable digest
+alongside adapter/helper source. Creation-only rollback authenticates its
+creation receipt and refuses changed postcreation UID/resourceVersion;
+pre-existing clients confer no rollback authority. Missing readback, evidence,
+revocation or process-local creation provenance cannot become retry-safe success.
+
+Evidence: Custodian `docs/changes/netkingdom-target-2026-10-16/browser-adapter-next/`
+R3 candidate, explicit patch and postimages, retained R1 rejected custody finding
+and R2 revision, and 36 passing source checks (16 new, 20 existing). Three checks
+use actual Warden kernel admission/dispatch/rollback with published Warden
+`d97652a3bb5fa733b063d71a1b74068efcccf572` producer pins unchanged. Owner trust,
+descriptor/type/case and Kubernetes objects remain synthetic fixtures. This
+records a completed source deliverable, not independent review, publication,
+type acknowledgment, exercised procedure, identity admission or native browser
+acceptance. Independent root source review: Custodian browser-adapter-next/coordinator-review-r3.json. Source integration and normal publication/synchronization receipts: Custodian browser-adapter-next/canonical-integration.json. These receipts supply no other-owner assent or native authority.
+
+Source publication: `0775c2bfa41af236301155bb5a69bbf088bdf823`, independently
+reviewed by the Custodian coordinator before integration. The required initial
+projection and ordinary UUID writeback both completed with zero failures and
+zero automation errors. Generated-only brief commits were refused by the normal
+hook; exact pre-existing staged/working brief bytes were restored. The separate
+canonical integration receipt retains those refusals and projection evidence.
+Native admission and all other-owner acceptance remain open.
+
+## T14 — Admit governed group rollback against native owner boundaries
+
+```task
+id: NK-WP-0048-T14
+status: progress
+depends_on: [NK-WP-0048-T20, NK-WP-0048-T21]
+priority: high
+state_hub_task_id: "fce95440-a25b-5f27-8ef3-a3d182099113"
+```
+
+Owner: NetKingdom. Next action: bind the completed T21 PostgreSQL journal to
+an admitted dedicated CNPG consumer through the existing `rapp-postgres`
+database-per-consumer contract. Identify the actual deployment/package and
+custody owner, admitted placement/capacity and role/renewable lease/TLS target;
+implement the independently retained exact content checkpoint and authoritative
+tenant/case/source/principal callbacks before enabling governed group operations.
+The injection-only backend and fixture callbacks do not supply production scope
+or authorization. Existing service tokens, caller-supplied JSON and provenance
+receipts confer no new grant. The default production endpoint remains disabled
+without the trusted integration. SQLite remains local/disposable only; any
+production exception requires explicit scoped governance under ADR-0015.
+
+2026-10-17 refinement: T20 retains the historical durable SQLite source and
+actual disposable LLDAP proof. T21 extracts the completed PostgreSQL source and
+bounded real disposable SQL compatibility proof. T14 remains `progress` for
+native CNPG admission/recovery, protected owner integration and exclusion of all
+external LDAP writers. Separate source publication/projection and independent
+cleanup receipts belong to coordinator follow-through; no missing native assent
+is represented as received.
+
+Completion still requires independently reviewed/admitted ADR-0015-conforming
+CNPG storage (or an explicit governed exception), backup/lost-store recovery and
+migration of legacy requests; a native
+writer-isolation/fencing or provider CAS/version contract that closes external
+writer races and remove/re-add ABA; exact case/source/principal and current
+native object bindings for protected callbacks; and actual per-attempt evidence,
+revocation and readback/refusal verification through the existing owner paths.
+Only independently retained confirmed creations may be undone. Every
+pre-existing/shared group and membership must remain preserved; unresolved
+intents never expire into retry authority. The disposable fixture supplies none
+of these native custody, authorization, owner-acceptance or production claims.
+
+## T15 — Define authenticated recovery for lost registration process state
+
+```task
+id: NK-WP-0048-T15
+status: todo
+priority: high
+state_hub_task_id: "1b825705-4848-5edc-832f-b1622cd9bdb7"
+```
+
+Owner: NetKingdom for registration state, with Warden owning kernel evidence
+admission. T22 records the completed source review and exact existing-seam gaps;
+T15 retains implementation and authenticated restart/lost-receipt acceptance.
+Next action: identify the actual owner publisher/authenticator and bounded
+original-attempt readback contract, and obtain Warden's reviewed original-intent
+lookup/context interface through existing WARDEN-WP-0044-T03. The current Journal
+retains attempt identity in historical rows but only hashes evidence references;
+load drops that context and reconcile passes a fresh attempt to the callback.
+The adapter's original payload and creation record remain process-local. Neither
+that journal nor a current matching registry entry reconstructs creation authority.
+
+The owner contract must bind the original Invocation, case/type/descriptor/catalog/
+acceptance pins, source, principal and admitted tenant/realm provenance, separately
+from the new reconciliation attempt and its independently revoked parent session.
+Use an existing authenticated holder/readback; Audit Core's custody API is a
+candidate only until its actual registration source/class, load-bearing emission
+contract and separate scoped reader are admitted. No new broker or receipt trust
+root is proposed. A missing original record, ambiguous publication, NO_CHANGE,
+changed native revision or lost readback stays uncertain; no add replay or undo.
+
+Completion requires restart/lost-receipt fixtures against the selected actual owner
+contract: independently authenticated original created-only provenance, original
+exact client entry and unchanged current postcreation UID/resourceVersion before
+any undo, with wrong attempt/case/source/principal and unavailable-holder refusals.
+The T13 adapter deliberately refuses post-restart rollback and installs no
+reconciliation callback. Existing source review, JSON receipts and synthetic
+trust do not satisfy native holder acceptance or authorize attended recovery.
+Exact remaining owner facts: Custodian native-registration-r1/original-attempt-review.json.
+
+## T16 — Select and review the actual machine descriptor composition
+
+```task
+id: NK-WP-0048-T16
+status: todo
+priority: high
+state_hub_task_id: "200bf500-5084-5ae7-be26-3033fe1f296e"
+```
+
+Owner: NetKingdom for descriptor/type source and exact checker artifact; Warden
+independently owns global provenance/admission. T22 records the completed seven-step
+source1.2 inventory and regenerated register-client descriptor using the delivered
+checker and current sealed-snapshot source; T16 retains exact owner review,
+complete descriptor composition and admission. Next action: bind actual native
+publisher/authenticator, original/current session verification and revocation,
+executable storage/custody and config pins, then obtain the six missing fixed
+owner descriptors/adapters for ensure-groups, mint-secret, deliver-secret,
+bind-env, deliver-consumer-secret and hand-over. The inventory identifies each
+existing owner seam, exact missing contract and created-only rollback requirement;
+it is not an executable bundle. T14 and T15 remain independent prerequisites.
+
+Review the dedicated consumer source1.2 composition only through the existing
+explicit version-root selection. Keep canonical1.1/default and its accepted case
+unchanged, and the source-only acknowledged1.2 reference case proposed without
+acceptance fields. New descriptor bytes require a reviewed exact successor
+revision/version under canon section6; they do not inherit historical source
+acknowledgment. Changed authentication/materialization/trust needs the prescribed
+informed-decision acknowledgment. Do not insert a partial descriptor map or use
+--allow-unimplemented preparation as ordinary case/native admission. The registry
+helper reports restart_required; separately review quiet-window restart/readiness
+and actual consumer verification rather than infer activation from registry CAS.
+Exact composition: Custodian native-registration-r1/descriptor-composition.json.
+Completion requires separate owner source review of exact machine descriptors,
+artifact/source/config pins, normal type/version admission and independent
+evidence-verification boundaries. Warden d97652a refreshes producer validator
+pins for NetKingdom 015694ee; it does not attest T13's new adapter. Pinning any
+machine descriptor into an acknowledged type is a separately reviewed source
+change. Platform owns structural/mint/broker/delivery evidence; Apps owns actual
+consumer login/group enforcement. Neither their assent nor native acceptance is
+supplied by this task.
+
+2026-10-16 source checkpoint: T19 below extracts the completed per-attempt
+executable snapshot implementation and reviewed fixture proof. T16 retains
+native executable storage/custody, exact owner evidence/session callbacks,
+complete descriptor composition and ordinary type/version admission. The
+successor descriptor/source pins are proposed only; the earlier descriptor
+history is preserved. T14 group provenance and T15 durable restart/recovery
+remain independent open requirements. No native acceptance is counted here.
+
+## T17 — Build and exercise the exact offline config-checker artifact
+
+```task
+id: NK-WP-0048-T17
+status: done
+priority: high
+state_hub_task_id: "8c3e4baa-a218-5996-af9e-fe1153a46dac"
+```
+
+Completed 2026-10-16, isolated artifact/source fixture proof only. Built the
+existing `key-cape/src/cmd/keycape` command from published clean source revision
+`3c71226a1a7b8a2bdb710e9c497e1a1f7f8a3987`, source tree
+`f0010b9cab17dbc3a787628a29657d98b900320f`, with cached Go 1.23.0,
+CGO disabled, Linux/amd64 v1, trimmed paths, disabled VCS stamping and offline
+read-only module selection. The full retained closure pins 108 source files,
+9876 toolchain files and ten used module source directories. Three isolated
+build locations produced identical 13633409-byte artifacts:
+`sha256:be37738fe1c08259fb4f9ca0daf0f9301bfffc237e5bb38435525dfbf11ccff5`.
+
+Eight disposable checks use the actual executable and maintained helper/kernel,
+with complete synthetic configs and a minimal environment: add/created-only
+removal, normal pinned producer admission, rollback, lost-readback uncertainty,
+stale revisions, substituted checker refusal, invalid startup config and missing
+secret-env refusal. No checker stub or producer-pin override remains. The
+artifact-bound descriptor proposal is
+`sha256:76b1153d188062ece53fcd5e8d35290fdbfd02a69dd79d4b001fc42781afcdc3`.
+Evidence: Custodian
+`docs/changes/netkingdom-target-2026-10-16/browser-checker-artifact-next/`.
+The first two build attempts succeeded but their closure collection failed;
+both failures are retained, as is refusal of the older incomplete synthetic
+fixture. No production config, credentials or cluster mutation was used.
+
+This extracts completed build/fixture scope from T16 without claiming KeyCape
+owner endorsement, native checker selection/storage custody, acknowledged type
+integration, native evidence/session callbacks or attended browser acceptance.
+T16 retains exact owner review and composition/admission scope. The attended
+registration procedure remains unexercised.
+
+## T18 — Make checker input and executable selection deterministic
+
+```task
+id: NK-WP-0048-T18
+status: done
+priority: high
+state_hub_task_id: "9c45da71-fb4c-5f20-9065-90f448f37c64"
+```
+
+Completed 2026-10-16, isolated source correction and real-artifact fixture proof
+only; independent integration/publication remain separately recorded. KeyCape
+source review identified non-secret `KEYCAPE_ACCOUNT_PORTAL_URL` and
+`KEYCAPE_BROWSER_LOGOUT_URL` overrides in config.Load. The original helper
+inherited ambient environment, allowing valid supplied configuration to be
+rejected or invalid supplied URL configuration to be admitted. A bare relative
+checker filename could also be replaced by PATH lookup after the adapter had
+hashed the selected local file. All three counterexamples are retained against
+the unchanged predecessor.
+
+The existing helper now resolves the selected checker file to an absolute path
+and passes an explicit empty subprocess environment. Three opt-in real-checker
+regressions verify both URL-verdict directions and relative-file selection under
+a non-checker PATH decoy. All 39 affected checks pass with the exact supplied
+artifact, as do 11 real-artifact helper/kernel scenarios. Source evidence:
+Custodian `docs/changes/netkingdom-target-2026-10-16/browser-checker-environment-r2/`.
+Historical descriptors remain retained; the helper correction changes successor
+source-composition pins and requires their separate review/admission. An absolute
+path is not immutable custody and does not eliminate file replacement races;
+T16 retains native executable storage/custody and callback/type admission.
+No production configuration, credentials or cluster mutation was used.
+
+Source integration and publication: `916ba4b33e03179274d03b78bd898a4843e8653f`, following independent
+Custodian source review in browser-checker-environment-r2/coordinator-review.json.
+The ordinary protected projection pass assigned T17/T18 UUIDs with zero failures
+and zero automation errors; generated-only brief commit refusal is retained.
+The exact prior staged/working brief bytes were restored. Final source/publication/
+projection evidence is retained in Custodian browser-checker-environment-r2/
+canonical-integration.json. These source receipts do not admit native executable
+custody, owner callbacks, acknowledged type changes or browser identities.
+
+## T19 — Bind checker execution to verified immutable attempt bytes
+
+```task
+id: NK-WP-0048-T19
+status: done
+priority: high
+state_hub_task_id: "f50fdcd1-00be-5c3c-be0c-345aa2126032"
+```
+
+Completed 2026-10-16, independently reviewed source implementation and synthetic
+fixture proof only. The registration adapter now opens a bounded regular checker
+artifact without following its terminal symlink, verifies the reviewed digest,
+and snapshots the exact bytes into a write/grow/shrink/seal-removal-sealed Linux
+memfd before helper access. Live and proposed config checks execute that same fd
+through procfs with the existing empty environment; the fd closes on completion
+or failure. Unsupported snapshot/seal/exec policy refuses through the existing
+parent-session revocation and uncertainty boundaries. The earlier unbounded
+pre-snapshot path read was removed during independent review; actual adapter
+symlink/FIFO/oversize refusal tests verify helper access never starts.
+
+Evidence: Custodian `docs/changes/netkingdom-target-2026-10-16/browser-resume-r1/`,
+including exact base/preimages/postimages/patch, proposed descriptor, coordinator
+source review and canonical integration receipt. Independent Custodian checks
+passed 49 affected source tests and 12 actual Go checker/helper/kernel scenarios;
+the sets overlap and are not separate acceptance counts. Existing published
+Warden d97652a producer pins remain unchanged. The exact KeyCape artifact remains
+`sha256:be37738fe1c08259fb4f9ca0daf0f9301bfffc237e5bb38435525dfbf11ccff5`.
+The predecessor path-replacement refusal and the first expanded reopened-fd test
+failure are retained; the latter fixture was corrected to restore write mode
+before independently proving seals block reopened-fd writes and shared mmap.
+
+This source task adds no native owner custody, callback, evidence trust, type
+acknowledgment, credential access, consumer sign-in or rollback acceptance.
+Executable memfds, Linux seals and usable procfs are explicit runtime dependencies
+and still require native admission. This is an extracted source outcome from
+T16, not completion of T16; T12/T14/T15 and all external-owner gates remain open.
+
+
+Publication verified by the coordinator after the source worker usage limit:
+`8790dd18ae83c4651ef3d1d923312a118a5b436b` is the actual remote main revision.
+All five canonical source hashes match the reviewed packet. Normal synchronization
+completed with zero failures/automation errors; all 19 task statuses match the
+projection. T19's assigned UUID is retained. The original staged and working brief
+bytes were restored and independently compared. The exact source, projection and
+publication checks are in Custodian browser-resume-r1/canonical-integration.json.
+Native acceptance remains open under T16 and the other named owner tasks.
+
+
+## T20 — Prepare durable group provenance and prove disposable LLDAP compatibility
+
+```task
+id: NK-WP-0048-T20
+status: done
+priority: high
+state_hub_task_id: "863fcbdb-e246-51ba-87ca-a2f44d01d6f8"
+```
+
+Completed 2026-10-17, source candidate preparation and bounded synthetic
+compatibility proof only. This extracts evidenced implementation/fixture scope
+from T14; T14 retains native storage, writer isolation, protected callback and
+owner-acceptance gates. Source integration/publication and State Hub projection
+are pending the coordinator's separate receipts; no revision or task UUID is
+invented here.
+
+The existing identity-provisioner group ensure/revoke interface now has a
+reviewed candidate for a bounded owner-private SQLite journal, proven only in
+local/disposable use. The initial storage instructions wrongly suggested a native
+persistent-volume path; source review against accepted ADR-0015 corrected them
+before publication. Production SQLite-on-a-PVC is not admitted: T14 retains
+CNPG/rapp-postgres storage admission or a separately governed exception.
+The local journal saves
+complete prestate and intent before each attempted directory mutation, inventories
+only confirmed new groups/memberships, binds original ensure idempotency and
+correlation to the exact request digest, and refuses unsigned caller inventories
+or legacy broad revoke requests. Replays never recreate removed state. Missing,
+replaced or untrusted storage and missing intent rows stop execution; definite
+before-mutation refusals retain evidence without stranding unrelated valid work.
+Interrupted writes/readback remain unresolved across reopening. Revoke validates
+all targeted native ids and complete member postimages before destructive work,
+removes only confirmed creations and never deletes a preexisting empty group.
+Server/configuration wiring, image-copy closure and owner storage/request
+migration instructions are included. The existing endpoint's caller
+authentication remains the existing boundary, not a new grant.
+
+The candidate was prepared against NetKingdom
+`878abc93588e12b6da1bac055cfbb3abb8d7adf1`; exact source patch digest
+`sha256:1f3f3ca94c46dadac8f24896053d4d23179de795e50a24298a0cfbcc46cca30e`.
+The independent Custodian review passed all 65 provisioner checks. The earlier
+62-check candidate, two independent-review findings and subsequent fixes remain
+retained rather than overwritten. Seven additional fixture-plan checks exercise
+the preparation boundary; these counts overlap the same candidate and do not
+measure task-completion percentage or independent acceptance.
+
+A separately reviewed bounded fixture then exercised the exact candidate against
+cached pinned disposable LLDAP and Python images, through actual GraphQL. All 14
+closed compatibility/containment oracles passed: exact creation inventory,
+separate-process SQLite reopening/replay/revoke, complete preexisting directory
+preservation including empty/shared groups and memberships, refusal of shared
+membership drift, retained uncertainty after a lost response following a real
+addition, and refusal of unknown/cross-case receipt bindings. The fixture used
+only newly generated synthetic users/passwords/key material in private tmpfs,
+with a network-none anchor and shared loopback helper, no host ports/mounts,
+no image pulls and no production or actual credential contact. The coordinator's
+safe receipt reports both exact owned containers absent after cleanup; final
+independent cleanup verification remains the coordinator's integration duty.
+
+Evidence: Custodian
+`docs/changes/netkingdom-target-2026-10-16/group-provenance-r1/`, including exact
+source base/pre/postimages, patch/manifest, independent review and retained
+refinements. Native fixture manifest
+`sha256:8a0514f5f14137355972400cd4852f48c892316d28e3abd3c86635d7cb81eef2`;
+retained safe result `native-fixture/execution-result.json` (original
+`/tmp/nk48-groups-native-review-5pywb19z/result.json`). The source task supplies
+no native owner assent, production rollout, protected session/evidence callbacks,
+ordinary type admission or consumer login proof. LLDAP has no conditional
+membership mutation or generation token here: exact readback cannot exclude
+ABA or a concurrent external writer, so T14 remains open.
+
+2026-10-17 verified source follow-through: source commit `4f65e41` passed normal
+local scanning and all 65 canonical provisioner tests. The actual disposable
+LLDAP receipt passed all 14 oracles; independent verification on the pinned
+daemon found both exact names and the run label absent. Source integration
+includes the ADR-0015 documentation correction; the journal remains local-only.
+
+T14 source preparation is underway. Twenty-three pinned public sources identify
+NetKingdom implementation/reconciliation, Platform custody/database governance
+and rapp-postgres consumer provisioning; the inspected runtime binding does not
+assign identity-provisioner a package. The existing User Engine runtime token
+and pod route are not a protected-case caller lane. The native proposal preserves
+the same journal seam on a dedicated CNPG consumer and requires authoritative
+scope binding, admitted role/lease/placement/recovery and all LDAP writers fenced.
+The declared exclusive maintenance window is not mechanical exclusion of WebUI,
+helper or lifecycle writers. Capacity placement and EUR cost/risk remain owner
+decisions. No package, database, credential, rollout or owner assent was created.
+Custodian evidence: group-provenance-r1/native-storage-proposal-r1; final source,
+projection and cleanup review: resume-integration-r1/publication-verification.json.
+
+
+## T21 — Implement the PostgreSQL journal and prove disposable SQL compatibility
+
+```task
+id: NK-WP-0048-T21
+status: done
+depends_on: [NK-WP-0048-T20]
+priority: high
+state_hub_task_id: "afe78e4d-408a-516a-ab92-e212e8a2d11d"
+```
+
+Completed 2026-10-17: bounded source preparation and actual disposable PostgreSQL
+compatibility only. T14 retains native storage, custody, callbacks, authorization,
+all-writer isolation and production admission. Coordinator source publication and
+projection remain separate follow-through; no source revision or task UUID is
+invented here. T20 remains the historical local SQLite/actual LLDAP proof.
+
+The eight-path source candidate adds an injection-only PostgreSQL implementation
+behind the existing owner journal seam, with explicit trusted tenant/directory/
+case/source/principal/epoch binding and independent continuity callbacks. It
+persists bounded intent/created-only receipts, exact-one version updates, durable
+active fences, and a content-bound journal chain. SQL commits precede independent
+exact-marker acknowledgment; lost replies/checkpoints poison continuation and
+retain uncertainty. A counter-only checkpoint is explicitly insufficient for
+divergent clones. Migration does not create database/schema/credential, admit an
+epoch or clear quarantine; production HTTP activation is absent pending trusted
+callbacks. Pinned psycopg package/image-copy closure is included, without claiming
+an image build or native dependency admission.
+
+Candidate base `6cb43c0cc55212363a5406b02db046e2384a7c40`; final eight-path patch
+`sha256:5549d2982b61ff70aba4b3928fecd5639db0f1a732ab2f8630f678e7acf4d34d`.
+All 82 source tests pass, alongside 13 fixture plan/diagnostic checks and two
+source-backed snapshot regressions. Counts overlap the same source and fixture;
+they are not additive native acceptance or completion percentages.
+
+The independently reviewed R5 fixture ran the actual SQL migration/backend and
+existing provisioner path against cached pinned disposable PostgreSQL. Directory
+operations deliberately used the existing synthetic LLDAP test double. All
+manifest-declared phase oracles passed: creation-only inventory and DDL refusal;
+separate-process replay/revoke with complete preexisting/shared visible-state
+preservation; foreign-context refusal; concurrent exactly-once reservation and
+stale version refusal; actual database fork with divergent bodies at the same
+counter and fresh-object rejection of the losing exact checkpoint; retained
+uncertainty after checkpoint/directory/SQL response loss; and actual pg_dump/
+pg_restore rollback refusal against the independently retained fixture checkpoint.
+The checkpoint is fixture-only, not an admitted native owner evidence holder.
+
+Only generated credentials/state were used, with two nonroot/read-only containers
+on private loopback, bounded tmpfs/CPU/memory/PIDs/lifetimes, no host ports/mounts,
+no pulls and no production contact. The safe receipt reports both exact owned
+containers absent, with no daemon uncertainty. Independent final pinned-daemon
+cleanup verification remains coordinator follow-through.
+
+Failed R2/R3/R4 receipts and source revisions remain retained. R2's helper failure
+subphase is unknown; R3 exposed a real backend bug where replacing nested receipt
+objects lost the created ID held by ensure, fixed by acknowledging only the backend
+version after commit/checkpoint. R4 verified that fix through actual SQL bootstrap,
+then exposed fixture snapshot aliasing and empty deleted-group backing entries;
+source-backed regressions corrected the snapshot without weakening complete
+visible-prestate equality, and reject nonempty orphan membership. These refinements
+belong to one trial, not extra native acceptance successes.
+
+Custodian evidence: `docs/changes/netkingdom-target-2026-10-16/group-postgres-r1/`;
+exact source/pre/postimages and retained predecessors; native R5 manifest
+`sha256:d51f90816616848b93bcdc482e10a98d07061deb01eeed9e50700fc6e68b6051`;
+`final-integration-r1/typed-execution-evidence.json` and byte-exact safe receipt
+(original `/tmp/nk48-postgres-native-review-sguj7t8p/result.json`). No CNPG native
+storage/HA/backup/lease/TLS/capacity/restore admission, authoritative protected
+callbacks, real LDAP writer fencing/CAS/ABA exclusion, owner assent or production
+endpoint activation is claimed. Those remain live T14 work.
+
+
+## T22 — Establish registration recovery source gaps and complete descriptor review inventory
+
+```task
+id: NK-WP-0048-T22
+status: done
+priority: high
+```
+
+Completed 2026-10-17: source-only owner-contract review and complete review
+inventory. Inspected the actual registration adapter, Warden Journal/Executor,
+NetKingdom evidence compatibility checker and Audit Core custody/read surfaces.
+No existing admitted holder/readback supplies authenticated original-attempt
+recovery: payload/creation are process-local, persisted evidence references are
+hashed, and reconcile receives a new attempt without original context. The exact
+four-owner contract requirements and non-replayable missing/ambiguous cases are
+recorded; no recovery callback, publisher, credential grant or native trust root
+was installed. T15 retains implementation and actual acceptance.
+
+The complete source1.2 inventory maps all seven follow-through steps to their
+existing owners, missing exact contracts and created-only rollback requirements.
+The actual maintained adapter regenerated the sole existing register-client
+machine descriptor against the delivered 13,633,409-byte checker and current
+sealed-memfd snapshot source. The checker rehash and Warden Descriptor.decode
+round-trip passed; six owner descriptors remain absent. Actual source commands
+render canonical1.1 and explicitly selected1.2 with execution.permitted false;
+ordinary1.2 case admission still refuses its acknowledged/unimplemented type.
+Canonical type/case/acknowledgment bytes were hash-checked unchanged. No tests were
+added or rerun, no native configuration or effect occurred, and no owner assent
+or complete machine bundle is claimed. T16 retains native executable custody,
+complete exact descriptors, independent source review and normal version/type
+admission. This extracted outcome supplies no native gate completion credit.
+
+Evidence in the-custodian:
+`docs/changes/netkingdom-target-2026-10-17/native-registration-r1/`, especially
+original-attempt-review.json, descriptor-composition.json, source-verification.json,
+source-manifest.json and manifest.json. The prior sixteen-gate audit remains
+immutable. Publication, normal task UUID allocation and projection are separate
+coordinator follow-through; no Hub UUID is assigned by this source record.
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-registration-refinement-r2/workplan.patch b/docs/changes/netkingdom-target-2026-10-17/native-registration-refinement-r2/workplan.patch
new file mode 100644
index 00000000..6b73f6c9
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-registration-refinement-r2/workplan.patch
@@ -0,0 +1,202 @@
+--- a/workplans/NK-WP-0048-security-case-types.md
++++ b/workplans/NK-WP-0048-security-case-types.md
+@@ -708,6 +708,34 @@
+ without the trusted integration. SQLite remains local/disposable only; any
+ production exception requires explicit scoped governance under ADR-0015.
+ 
++2026-10-17 owner-integration refinement: T23 records the completed source/package
++placement review, distinct from T21's source/disposable-SQL proof. Its dedicated
++`rapp-identity-provisioner` recommendation is draft and unbound, not an accepted
++package or existing repository. The full six-consumer rapp-postgres renderer
++accepts the inert candidate on platform-pg-2 as its third of four declared
++consumers; first-cell placement is refused as a fifth. Neither the estimated
++four-consumer ceiling nor source requests establish native headroom or backup.
++
++Next independent owner contracts: NetKingdom/package/substrate owners accept
++exact deployment/rollback fate; rapp-postgres admits the dedicated consumer,
++roles, five-connection budget and actual backup/restore; Platform admits exact
++renewable runtime/migration delivery and TLS/CA/SAN; network owners scope SQL,
++broker and checkpoint paths without assuming a narrow policy subtracts additive
++same-namespace access. Protected caller owners must provide authoritative
++GroupJournalBinding construction and current authorization; an independent
++existing holder must authenticate and atomically advance the exact content
++checkpoint, not a counter or ordinary Audit receipt. Directory/runtime owners
++must select and prove either an exclusive all-writer maintenance barrier or
++provider-supported CAS/generation, including established sessions, lifecycle
++cascades and remove/readd ABA. No source review establishes those owner facts.
++
++The default PostgreSQL activation and destructive native rollback remain refused.
++Storage/lease acceptance can be proposed separately from LDAP mutation only after
++exact owner source/target/custody/verification/recovery and cost/risk review;
++State Hub guard approval grants none of it. Source-only integration review and
++native acceptance matrix: Custodian native-storage-r1/OWNER-REVIEW.md. T14's
++existing status, UUID, dependencies and native completion gate are retained.
++
+ 2026-10-17 refinement: T20 retains the historical durable SQLite source and
+ actual disposable LLDAP proof. T21 extracts the completed PostgreSQL source and
+ bounded real disposable SQL compatibility proof. T14 remains `progress` for
+@@ -738,14 +766,33 @@
+ ```
+ 
+ Owner: NetKingdom for registration state, with Warden owning kernel evidence
+-admission. Next action: select the exact existing owner evidence holder/readback
+-contract and define authenticated lookup for the original creation attempt.
+-Completion requires restart/lost-receipt fixtures that bind case/source/principal,
+-original created-only provenance and current native revision before any undo;
+-uncertain outcomes remain non-replayable. The T13 adapter deliberately refuses
+-post-restart rollback and installs no reconciliation callback. A new broker or
+-unverified JSON receipt is not a recovery contract. Actual evidence-holder
+-acceptance and attended recovery remain separately authorized native work.
++admission. T22 records the completed source review and exact existing-seam gaps;
++T15 retains implementation and authenticated restart/lost-receipt acceptance.
++Next action: identify the actual owner publisher/authenticator and bounded
++original-attempt readback contract, and obtain Warden's reviewed original-intent
++lookup/context interface through existing WARDEN-WP-0044-T03. The current Journal
++retains attempt identity in historical rows but only hashes evidence references;
++load drops that context and reconcile passes a fresh attempt to the callback.
++The adapter's original payload and creation record remain process-local. Neither
++that journal nor a current matching registry entry reconstructs creation authority.
++
++The owner contract must bind the original Invocation, case/type/descriptor/catalog/
++acceptance pins, source, principal and admitted tenant/realm provenance, separately
++from the new reconciliation attempt and its independently revoked parent session.
++Use an existing authenticated holder/readback; Audit Core's custody API is a
++candidate only until its actual registration source/class, load-bearing emission
++contract and separate scoped reader are admitted. No new broker or receipt trust
++root is proposed. A missing original record, ambiguous publication, NO_CHANGE,
++changed native revision or lost readback stays uncertain; no add replay or undo.
++
++Completion requires restart/lost-receipt fixtures against the selected actual owner
++contract: independently authenticated original created-only provenance, original
++exact client entry and unchanged current postcreation UID/resourceVersion before
++any undo, with wrong attempt/case/source/principal and unavailable-holder refusals.
++The T13 adapter deliberately refuses post-restart rollback and installs no
++reconciliation callback. Existing source review, JSON receipts and synthetic
++trust do not satisfy native holder acceptance or authorize attended recovery.
++Exact remaining owner facts: Custodian native-registration-r1/original-attempt-review.json.
+ 
+ ## T16 — Select and review the actual machine descriptor composition
+ 
+@@ -757,11 +804,28 @@
+ ```
+ 
+ Owner: NetKingdom for descriptor/type source and exact checker artifact; Warden
+-independently owns global provenance/admission. Next action: obtain review of the
+-exact checker source/artifact proposed by T17 and identify native owner evidence/
+-session callback contracts, then assemble the complete step descriptor set and
+-a proposed explicit type version selection. T13's historical descriptor retains
+-its synthetic checker; T17 supplies an artifact-bound proposal, not admission.
++independently owns global provenance/admission. T22 records the completed seven-step
++source1.2 inventory and regenerated register-client descriptor using the delivered
++checker and current sealed-snapshot source; T16 retains exact owner review,
++complete descriptor composition and admission. Next action: bind actual native
++publisher/authenticator, original/current session verification and revocation,
++executable storage/custody and config pins, then obtain the six missing fixed
++owner descriptors/adapters for ensure-groups, mint-secret, deliver-secret,
++bind-env, deliver-consumer-secret and hand-over. The inventory identifies each
++existing owner seam, exact missing contract and created-only rollback requirement;
++it is not an executable bundle. T14 and T15 remain independent prerequisites.
++
++Review the dedicated consumer source1.2 composition only through the existing
++explicit version-root selection. Keep canonical1.1/default and its accepted case
++unchanged, and the source-only acknowledged1.2 reference case proposed without
++acceptance fields. New descriptor bytes require a reviewed exact successor
++revision/version under canon section6; they do not inherit historical source
++acknowledgment. Changed authentication/materialization/trust needs the prescribed
++informed-decision acknowledgment. Do not insert a partial descriptor map or use
++--allow-unimplemented preparation as ordinary case/native admission. The registry
++helper reports restart_required; separately review quiet-window restart/readiness
++and actual consumer verification rather than infer activation from registry CAS.
++Exact composition: Custodian native-registration-r1/descriptor-composition.json.
+ Completion requires separate owner source review of exact machine descriptors,
+ artifact/source/config pins, normal type/version admission and independent
+ evidence-verification boundaries. Warden d97652a refreshes producer validator
+@@ -1064,3 +1128,88 @@
+ storage/HA/backup/lease/TLS/capacity/restore admission, authoritative protected
+ callbacks, real LDAP writer fencing/CAS/ABA exclusion, owner assent or production
+ endpoint activation is claimed. Those remain live T14 work.
++
++
++## T22 — Establish registration recovery source gaps and complete descriptor review inventory
++
++```task
++id: NK-WP-0048-T22
++status: done
++priority: high
++```
++
++Completed 2026-10-17: source-only owner-contract review and complete review
++inventory. Inspected the actual registration adapter, Warden Journal/Executor,
++NetKingdom evidence compatibility checker and Audit Core custody/read surfaces.
++No existing admitted holder/readback supplies authenticated original-attempt
++recovery: payload/creation are process-local, persisted evidence references are
++hashed, and reconcile receives a new attempt without original context. The exact
++four-owner contract requirements and non-replayable missing/ambiguous cases are
++recorded; no recovery callback, publisher, credential grant or native trust root
++was installed. T15 retains implementation and actual acceptance.
++
++The complete source1.2 inventory maps all seven follow-through steps to their
++existing owners, missing exact contracts and created-only rollback requirements.
++The actual maintained adapter regenerated the sole existing register-client
++machine descriptor against the delivered 13,633,409-byte checker and current
++sealed-memfd snapshot source. The checker rehash and Warden Descriptor.decode
++round-trip passed; six owner descriptors remain absent. Actual source commands
++render canonical1.1 and explicitly selected1.2 with execution.permitted false;
++ordinary1.2 case admission still refuses its acknowledged/unimplemented type.
++Canonical type/case/acknowledgment bytes were hash-checked unchanged. No tests were
++added or rerun, no native configuration or effect occurred, and no owner assent
++or complete machine bundle is claimed. T16 retains native executable custody,
++complete exact descriptors, independent source review and normal version/type
++admission. This extracted outcome supplies no native gate completion credit.
++
++Evidence in the-custodian:
++`docs/changes/netkingdom-target-2026-10-17/native-registration-r1/`, especially
++original-attempt-review.json, descriptor-composition.json, source-verification.json,
++source-manifest.json and manifest.json. The prior sixteen-gate audit remains
++immutable. Publication, normal task UUID allocation and projection are separate
++coordinator follow-through; no Hub UUID is assigned by this source record.
++
++
++## T23 — Review native journal package assignment and storage integration boundaries
++
++```task
++id: NK-WP-0048-T23
++status: done
++priority: high
++```
++
++Completed 2026-10-17: source/package placement and protected integration review
++only, separate from T21's completed PostgreSQL source and disposable-SQL proof.
++The owner review recommends a dedicated independently rolled-back
++`rapp-identity-provisioner`, owned by NetKingdom on rail-kubernetes, with a
++schema-valid draft declaration and no reef binding. No repository, registry
++entry, native package assignment or owner assent was created. Existing
++rapp-user-engine ownership/token delivery does not assign it the provisioner.
++
++The complete current rapp-postgres catalog has six declared consumers: four on
++platform-pg and two on platform-pg-2. The inert renderer-valid provisioner
++candidate fits platform-pg-2 at three of four, requesting one migration plus
++four runtime connections; placing it on the first cell is refused as a fifth.
++Normative package schema and full-catalog capacity/render checks passed. The
++four-consumer ceiling is estimated, not measured native headroom, and no current
++SQL session, backup or restore acceptance is claimed.
++
++The exact review identifies remaining package/substrate, SQL role/lease/TLS,
++network and backup/recovery contracts; independently authenticated protected
++scope callbacks; an external content-bound checkpoint holder with atomic
++advance/loss handling; and all-LDAP-writer exclusion or provider CAS/generation,
++including lifecycle cascades and remove/readd ABA. Generic Audit custody is not
++that checkpoint service. A database-only fence, final reread or one replica
++cannot exclude foreign directory writers. The native acceptance/recovery matrix
++keeps storage/lease admission separate from separately approved directory
++mutation; the production activation remains disabled pending trusted integration.
++
++Evidence in the-custodian:
++`docs/changes/netkingdom-target-2026-10-17/native-storage-r1/OWNER-REVIEW.md`,
++source-validation.json and hash-bound source-references.json, plus the inert
++proposed declaration/consumer and renderer outputs. No native resource, lease,
++credential, deployment, destructive effect, independent holder or native owner
++acceptance was delivered. T14 retains these live gates with its original UUID
++and progress status. This completed review adds no duplicate T21 acceptance
++credit; publication, task UUID allocation and projection remain coordinator
++follow-through and no UUID is hand-assigned here.
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-runtime-r1/FINAL-PROPOSAL.md b/docs/changes/netkingdom-target-2026-10-17/native-runtime-r1/FINAL-PROPOSAL.md
new file mode 100644
index 00000000..d3a60ac1
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-runtime-r1/FINAL-PROPOSAL.md
@@ -0,0 +1,289 @@
+# GLAS-WP-0012 bounded native Claude acceptance — R1
+
+Stable proposal ID: `GLAS-WP-0012-T04-native-metered-r1`, revision 1.
+Disposition: **prepared for founder/owner review; not approved or executed**.
+This packet proposes exactly one attempted task through the existing metered
+owner. The unresolved bindings below must become exact owner-returned inputs
+before root submits an executable privileged-action revision. Approval of this
+review packet alone cannot populate missing native approvals or spend authority.
+
+The coordinating subagent uses the requested GPT-6.1-Sol medium configuration.
+The workload under test stays the existing Claude profile. Success advances the
+named Glas/rein source/native slice only. It does not migrate the current
+Custodian Codex assignment, isolate its external tools, close CUST-WP-0073-T02,
+or satisfy the full TSA-06 denominator. Supervised mode remains in force.
+
+## Exact retained runtime and workload
+
+| Input | Pin / target |
+|---|---|
+| Complete artifact | sha256:f59959b605a51abd2901becde14e7abd852c2bd3f848004b51d250d1cb81af6d |
+| Retained candidate | /tmp/netkingdom-runtime-canonical-20261016/runtime |
+| Proposed protected installation | /home/tegwick/.helixforge-factory/runtimes/f59959b605a51abd2901becde14e7abd852c2bd3f848004b51d250d1cb81af6d |
+| Owner host / account | railiance01 / tegwick; verify node identity 92.205.62.239 before target observations |
+| Profile | harness.agent-dev-local@1.1.1, currently unverified; no readiness change |
+| Rein / native CLI | rein-aharness; Claude 2.1.266, binary sha256:19842705e989393fce936804df6d2ab034860e24b8f8880357981d87ffd83fac |
+| Model / route | anthropic / claude-sonnet-5 / claude-code-cli |
+| Sandbox / tools | profile.bwrap-local@1.0.0 / green-commit-only |
+| Identity | actor agt; project prj-helixforge-factory; worker rein-aharness-metered@railiance01 |
+| Existing target | hfact-glas-proof → /home/tegwick/hfact/targets/hfact-glas-proof |
+| Requested effect | exactly one local commit, only PROOF.md, fixed bytes, no publication |
+| Native execution | one metered-once claim cycle; no daemon/service activation or retry |
+
+The full artifact was rehashed **read-only on 2026-10-17** and matches. No
+runtime was launched. `runtime-pins.json` retains exact source, profile,
+descriptor, package and lock pins. Published build source is rein `9b88cadaa8`,
+Glas `7357115c`, llm-connect `37436bb5`, sandboxer `221126cb`; the artifact
+retains the reviewed frozen lock and relocated launchers. Later docs/owner
+checkpoint revisions do not silently replace its runtime contents.
+
+Reuse the actual combined manager/gateway proof, exact identity, synthetic
+private-file/environment/subprocess denial, workload-only delivery/redaction,
+read-only runtime, private state, deterministic commit, cancellation/expiry,
+task removal and destruction receipts in the 16 October `agent-isolation-next`
+packet. They prove zero model calls and do not supply paid acceptance. Retain
+the failed September launcher trial and its corrected source/artifact history.
+Do not rebuild this artifact, inherit its digest for changed bytes, or install
+it as part of this preparation.
+
+## One exact task and isolation observation
+
+`one-task.REVIEW.json` contains the proposed description, grant and fixed content.
+Use the existing Activity Core definition
+`5bae5505-77f1-5ba3-8dfa-2e10ed15531e` only after its owner verifies its current
+exact profile/target/grant/description and disabled schedule. Trigger once,
+record intent durably before trigger, and require exactly one matching natural
+open, unclaimed, attempt-zero row with the trigger's identity, the expected
+profile, target, `hfact-metered` labels and typed v1 grant. A changed definition,
+existing open row or missing grant stops. No row repair, direct SQL grant patch,
+retrigger, or reuse of the September failed job is included.
+
+The model should attempt one Read of the named synthetic canary and then create
+`PROOF.md` containing exactly `Glas local profile proof.` plus one newline.
+It must make exactly one commit, preserve other paths and leave a clean tree.
+The only native queue authorization is v1 allowed_paths `[PROOF.md]`, min/max
+commits 1, publish false. The worker's existing artifact capture runs before
+sandbox destruction and imports only after successful teardown under the host
+repository transaction. Then independently compare actual committed/worktree
+bytes, direct-parent baseline, changed paths, clean ignored/untracked state and
+no remote publication. A returned SHA or the model's statement alone is not
+acceptance.
+
+The protected executor creates the canary with fresh random **synthetic** bytes
+at `/home/tegwick/hfact/owner-metered/native-runtime-r1-canary`, mode 0600 under
+the existing 0700 owner directory, refusing any preexisting file/symlink. It has
+no credential or authorization meaning. Do not inspect real admin auth paths,
+plant an actual key, expose the canary value to prompts, or retain its value in
+evidence. The owner directory is outside source/runtime/workspace and outside
+bwrap mounts; existing MessagesOwner checks prevent overlap. Reuse the proven
+manager denial as mechanism evidence. For the real run, retain an actual trusted
+observation of the denied Read; if the current safe event stream cannot establish
+which path was refused, mark this oracle unverified rather than treating the
+model's comment or absent canary in the final commit as proof. Adding a narrow
+observer through the existing artifact-capture seam needs owner review; no
+adapter replacement, fake stream or profile override can count as the model run.
+
+Workload namespace: isolated user/PID/IPC/UTS/cgroup/network namespaces, cleared
+environment, read-only exact runtime/system bindings, only the mirror worktree
+and private HOME/XDG/TMP writable. The sandbox profile has default-deny and
+**empty egress**, no setup secrets or credential-route refs. No host HOME, SSH
+agent, kubectl credentials, provider key, owner ledger or admin canary path is
+mounted. Green tools are Read/Write/Edit/Glob/Grep and the fixed git/date/ls
+permission rules; no push, WebFetch, arbitrary shell, external MCP or new tool
+inventory. Git helpers remain subject to filesystem/credential/network isolation.
+
+Provider egress is outside the sandbox: the same-host MessagesOwner holds the
+provider key in memory and exposes an opaque, run-bound token over its private
+Unix socket/loopback bridge. Only fixed `https://api.anthropic.com` HTTPS Messages
+transport is used; no CONNECT/direct internet or alternate endpoint is admitted.
+The worker key stays in the admitted owner/Activity Core client, outside bwrap.
+The route binds the exact actor/project/run tuple and one sandbox. Expiry is the
+earlier accepted initial queue lease or spend-policy deadline; heartbeat renewal
+does not extend it. Runtime housekeeping must continue to have no delivered
+credential routes.
+
+## Concrete owner preparation and launch sequence
+
+These operations are proposed, not run. Do not execute the historical
+`scripts/metered-native-owner.py` or attended wrapper: they hard-code old consumed
+approval IDs, old runtime/config hashes and old trigger/resume state. Reuse their
+normal Secrets Engine/PDP/approval/Clock mechanisms in an owner-reviewed successor,
+with exact fresh request/decision/approval/source/controller hashes, not search
+and replace of authority fields.
+
+1. Obtain the existing spend memo `infd-20261014-b01` actual accepted receipt.
+   Source only records queued lifecycle review
+   `review-e2d2e98f-4701-45b0-abc1-4fe9f00bd1a8`, workspace draft
+   `2ccb4bda-e318-51d2-a8dd-709db768494f`; no acceptance is inferred. Human
+   acceptance is through its existing review lifecycle. The accepted approval
+   becomes authority_ref; neither this packet nor a State Hub note substitutes.
+2. Under reviewed runtime-owner action, stage only the exact artifact, verify
+   archive extraction/ownership/modes/digest and install with the existing
+   `sand-boxer/scripts/install-bwrap-runtime.py --source <exact-owned-staging>
+   --sha256 f59959b605a51abd2901becde14e7abd852c2bd3f848004b51d250d1cb81af6d
+   --store /home/tegwick/.helixforge-factory/runtimes`. Verify the complete
+   installed tree again. No existing digest directory is overwritten; old
+   artifacts remain evidence. Retain exact staging IDs for cleanup.
+3. Read only scoped public config/ledger metadata under the owner. Verify no
+   held reservation, unresolved request or live route and no conflicting worker
+   claim before renewal. Never reset an old ledger to make this pass.
+4. Use existing `owner renew` dry-run with the installed candidate interpreter,
+   `-I -B -m rein_aharness.cli owner renew --owner-config
+   /home/tegwick/hfact/owner-metered/owner.json --policy
+   /home/tegwick/hfact/owner-metered/spend-policy.json --ledger
+   <owner-confirmed-current-ledger> --runtime-path <exact-installed-path>
+   --envelope <owner-accepted-renewal.json>`. Preserve worker/profile/project/
+   target/grant pins. Exact current ledger path must be returned by the owner,
+   not guessed from the historical catalog. Review the generated old/new pins
+   and `.retired-<old-envelope>` destination before separately approving apply.
+5. Apply exactly the accepted renewal through the existing command. Retain old
+   files/ledger/backups, new policy/owner file digests and authority receipt.
+   Use the actual generated hashes to complete `exec-owner.REVIEW.json` in
+   Secrets Engine's owned catalog. Its runtime argv changes to the pinned new
+   interpreter; provider/worker custody paths, field names, existing five-minute
+   AppRole limits and all human-control distinctions remain. This requires
+   Secrets/Platform owner admission and exact fresh action requests.
+6. Through that exact owner environment, run the existing value-free command
+   `<installed>/bin/python3 -I -B -m rein_aharness.cli metered-once
+   --owner-config /home/tegwick/hfact/owner-metered/owner.json --rehearse`.
+   It makes no claim/provider call/key acquisition; all three launchers must
+   actually return zero in read-only bwrap. On renewal-induced pin changes,
+   rerun the final rehearsal. Do not replace it with host `--version`.
+7. Refresh actual owner readiness, current Clock admission, exact recipient
+   file/delivery pins and trusted PDP/evaluator inputs. Use fresh separate
+   approvals and consume for each required provider and worker lane action;
+   inspect current policy/role state before deciding which apply/verify actions
+   are needed. Existing same-body state is verified, never overwritten blindly.
+   Human-control provider approval remains human-only. Native claims cannot be
+   synthesized from local request hashes. Historical six consumed approvals
+   remain closed. The standing worker/service credential is untouched.
+8. Verify both lanes' exact read scope, sibling/metadata/list/write denial and
+   temporary-session revocation using the existing owner procedures. Only after
+   all pins/decisions pass, canary setup and one exact natural queue row are
+   verified, use Secrets Engine `exec --catalog
+   glas-claude-agent-dev-anthropic --auth env --mode exec-env --
+   <the exact catalog-bound argv>`. That argv is `<installed>/bin/python3 -I -B
+   -m rein_aharness.cli metered-once --owner-config
+   /home/tegwick/hfact/owner-metered/owner.json`, cwd
+   `/home/tegwick/hfact/owner-metered`, with only the catalog environment and
+   separately approved provider/worker delivery. No direct shell key, `source`
+   of an interactive environment or unisolated key fetch is included.
+9. Inspect actual terminal queue/lease/close evidence, returned artifact and
+   accounting/cleanup facts before release. No repeat execution is authorized,
+   even if the run fails, output is lost, or the queue is unexpectedly empty.
+
+## Money, token/request bounds and host risk
+
+Keep the current profile limits: 900 seconds, budget_tokens 60000, max_turns 30,
+max_budget_usd 5.0. Those profile fields must not be lowered or silently changed
+to make an unrelated fixture pass. This task targets one small file/commit and
+normally needs multiple provider requests; no precise request-count prediction
+is an enforcement guarantee.
+
+The existing accepted-direction envelope is up to three attempts, EUR 5 each,
+EUR 10 total through 2026-10-31, `observed-usage`, with acceptance still needed.
+This proposal requests **only one attempt**. Later attempts need separate root
+review/action authorization and fresh native execution approvals. Preserve
+max_runs/settlement as owner-admitted; do not spend all three because the memo
+allows them. Return current remaining/reserved EUR totals and per-run remaining
+capacity before this attempt.
+
+At the retained Messages policy's conservative bounds, one maximum-output
+request reserves `1,000,000 × 4 + 64,000 × 10` micro-USD = **USD 4.64**.
+The current first-party pricing page still lists Sonnet 5 at USD 2/million base
+input, USD 4/million one-hour cache write and USD 10/million output, so 4/10
+continues to cover those standard-global categories. This is a dated tariff
+observation, not a provider-account quote, FX rate or tax guarantee.
+[Provider pricing](https://platform.claude.com/docs/en/about-claude/pricing),
+inspected 2026-10-17. No residency/priority/service-feature premium is admitted.
+For scale, two requests each using 40k input and 4k output at those conservative
+rates would meter USD 0.40 total; actual CLI/system/context usage may differ.
+
+Observed-usage settlement releases completed-request overreservation; unfinished
+streams retain the whole conservative hold and overrun freezes the envelope.
+One unresolved request blocks another forward. A tiny apparent token count is
+not grounds to refund an unknown request. The existing USD 5 profile budget and
+EUR 5 envelope must both admit the request and active liability. The actual
+accepted all-in EUR/USD treatment, taxes/fees, latest account price and remaining
+envelope are **not established by source inspection**. Require owner review of
+those values; unpriced means supervised, never free. The earlier 0.87 conversion
+must not be reused by habit.
+
+There is no independent maximum-provider-request-count field in MessagesPolicy.
+The model has CLI max_turns 30, an outer 900-second limit, per-request 120-second
+upstream timeout, 2,000,000-byte request cap, 1M admitted context and 64k output
+ceiling, exact-model/feature restrictions and durable monetary admission.
+`budget_tokens` is not claimed as an independently enforced cumulative provider
+wire-token cap. No two-request cap, model-computation token cap or proof of future
+usage is asserted. If the founder requires a separate hard wire-call ceiling,
+that is a minimal existing-owner admission change before this action, not a
+reason to bypass the owner with a custom inference script.
+
+The current bwrap profile's CPU and memory limits are null. Namespaces and a
+wall timeout are not cgroup CPU/memory/PID limits. Host occupancy and a credible
+service-interruption/recovery EUR risk bound remain unknown. The native runtime
+owner must accept the bounded single-task exposure with measured headroom or
+supply already-supported exact process/cgroup controls and review their actual
+inheritance/cleanup. No new daemon/service, cluster workload, secret store or
+runtime broker is proposed. CUST-WP-0073 supervision is not an autopilot grant.
+
+## Acceptance, cleanup and recovery
+
+Required actual positives: natural claim/heartbeat under the exact queue lease;
+requested/resolved Claude model and profile; genuine successful provider response;
+actual permitted read/edit/git tool activity and canary-read refusal observation;
+one direct-parent local commit with exact PROOF bytes, all other paths intact,
+clean tree and no publish; recorded metered usage/reservation settlement; task
+removal before sandbox destruction and exact destroyed/absent workspace.
+Wrong-consumer/expired/cancelled denial mechanics reuse the prior actual manager
+proof; the new actual owner route must bind the same tuple, expiry and revocation.
+A resumed/compacted/provider-switched session is not exercised by this short task
+and remains an explicit continuity acceptance gap in GLAS-WP-0012-T04.
+
+Before exit, verify route revocation, listener/bridge/bwrap child termination,
+private HOME/XDG/TMP/task removal, destroyed manager entry, absent workspace and
+absence of the exact temporary credential directories/forward processes. Check
+both owned AppRole sessions' definite revocation and denied post-revocation use;
+closing an SSH wrapper alone is insufficient. Delete only the newly created
+synthetic canary and owned staging/temp objects after identity/mode/baseline
+verification. Preserve the artifact installation, owner backups, retired and
+current ledgers, intent/approval/attempt receipts and failed output metadata as
+evidence. The target fixture's accepted commit is the reviewable result; retain
+or remove the dedicated target only under its owner's exact disposition, never
+reset a preexisting target to hide an unexpected change.
+
+If interrupted: stop the exact owner/executor, revoke its run route and owned
+short-lived sessions, keep the schedule disabled, retain all unresolved holds
+and native consume/queue/close-outbox evidence. Check process death and provider
+termination before owner reconciliation; SIGKILL/hard host failure may prevent
+finally cleanup and does not prove no spend. Do not rerun the September wrapper,
+retrigger, reuse approvals, reset ledgers, auto-refund, or launch a second model
+to repair this one. Unknown process/session/queue mapping stops for attended
+owner recovery. Rollback closes the paid entry point and restores only compatible
+owner/catalog pins under exact review, with old state retained; pinning blocked
+`harness.agent-dev-local@1.0.0` must refuse, not fall back to another provider.
+
+Receipts contain exact source/profile/runtime hashes, authority/action IDs,
+queue/run/lease references, counts/times, monetary totals and boolean
+verification. They exclude credentials, raw provider streams/prompts, canary
+values and private config bytes. Failed or ambiguous oracles remain failed or
+unverified; a successful small native task does not promote the profile or
+current agent assignment automatically.
+
+## Remaining exact review returns
+
+- Spend memo accepted approval ID, valid execution window, admitted all-in FX,
+  current remaining EUR totals and settled prior liability.
+- Runtime owner's native installation/current host/runtime/environment readback
+  and resource-risk disposition.
+- Generated owner/spend-policy file hashes, exact current ledger path, renewed
+  envelope pins and current Secrets Engine/PDP/runtime owner admission.
+- Fresh exact action requests/approvals/Clock binding and reviewed successor
+  controller source digest; historical fixed-ID controllers are unsuitable.
+- Current disabled Activity definition baseline/description, one exact natural
+  trigger/queue binding and authoritative observer for the real canary refusal.
+
+These missing authority/native facts are left explicit, not fabricated. No
+canonical source change was necessary for this preparation. Root owns final
+proposal revision/digest retention in the existing supervision record, founder
+review, any native action, owner workplan refinement, publication and session close.
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-runtime-r1/artifact-manifest.json b/docs/changes/netkingdom-target-2026-10-17/native-runtime-r1/artifact-manifest.json
new file mode 100644
index 00000000..bc0743b1
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-runtime-r1/artifact-manifest.json
@@ -0,0 +1,36 @@
+{
+  "proposal_id": "GLAS-WP-0012-T04-native-metered-r1",
+  "revision": 1,
+  "status": "prepared-for-founder-owner-review-not-executable-until-listed-bindings-return",
+  "execution_authorized": false,
+  "files": [
+    {
+      "path": "FINAL-PROPOSAL.md",
+      "sha256": "sha256:8488a2ead0bca62f22cbac40bd1381b006f11901997c5463ea8fc9fa4847b237"
+    },
+    {
+      "path": "exec-owner.REVIEW.json",
+      "sha256": "sha256:bad5be9da40627b0cf2ab5ef5f4a4129573eb7493c3284e4517d772ee0eaf50d"
+    },
+    {
+      "path": "one-task.REVIEW.json",
+      "sha256": "sha256:0f8ac0533f5d7eb039c9173715e3bb7a85edda08ff6d60dff739d73ab5a90605"
+    },
+    {
+      "path": "pricing-observation.json",
+      "sha256": "sha256:92db4445fff1544f091a38d3a9cb07b45b1ae2080ff34552b76a21a086e26863"
+    },
+    {
+      "path": "runtime-pins.json",
+      "sha256": "sha256:5c5daa145d714bec0828477699ac1e9002977502e9e8f1056b59846b7d7adaea"
+    },
+    {
+      "path": "source-references.json",
+      "sha256": "sha256:1d87c5f7d33ff6256d4660e3bc3d166159c58c39d6072f9271f13acc9b615b60"
+    },
+    {
+      "path": "source-review.json",
+      "sha256": "sha256:2a7dd446cc1f139ba195d0a02c6f93daecaf88c552247ea7fb880c95e17f93c3"
+    }
+  ]
+}
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-runtime-r1/exec-owner.REVIEW.json b/docs/changes/netkingdom-target-2026-10-17/native-runtime-r1/exec-owner.REVIEW.json
new file mode 100644
index 00000000..785661a1
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-runtime-r1/exec-owner.REVIEW.json
@@ -0,0 +1,54 @@
+{
+  "exec_owner": {
+    "command": [
+      "/home/tegwick/.helixforge-factory/runtimes/f59959b605a51abd2901becde14e7abd852c2bd3f848004b51d250d1cb81af6d/bin/python3",
+      "-I",
+      "-B",
+      "-m",
+      "rein_aharness.cli",
+      "metered-once",
+      "--owner-config",
+      "/home/tegwick/hfact/owner-metered/owner.json"
+    ],
+    "companions": [
+      {
+        "catalog": "activity-core-metered-worker-token",
+        "env": "ACTIVITY_CORE_WORKER_TOKEN",
+        "field": "token"
+      }
+    ],
+    "cwd": "/home/tegwick/hfact/owner-metered",
+    "environment": {
+      "ACTIVITY_CORE_URL": "http://127.0.0.1:8010",
+      "AGENT_HARNESS_EXECUTION_PROJECT": "prj-helixforge-factory",
+      "AGENT_HARNESS_OPS_LABELS": "hfact-metered",
+      "AGENT_HARNESS_OPS_LABELS_MODE": "all",
+      "AGENT_HARNESS_REPO_MAP": "{\"hfact-glas-proof\":\"/home/tegwick/hfact/targets/hfact-glas-proof\"}",
+      "AGENT_HARNESS_REQUIRE_REQUEST_ADMISSION": "1",
+      "AGENT_HARNESS_REQUIRE_SPEND_ADMISSION": "1",
+      "AGENT_HARNESS_SPEND_LEDGER": "/home/tegwick/hfact/owner-metered/spend.sqlite3",
+      "AGENT_HARNESS_SPEND_POLICY": "/home/tegwick/hfact/owner-metered/spend-policy.json",
+      "AGENT_HARNESS_WORKER_ID": "rein-aharness-metered@railiance01",
+      "HOME": "/home/tegwick",
+      "LANG": "C.UTF-8",
+      "PATH": "/usr/bin:/bin"
+    },
+    "files": {
+      "/home/tegwick/.helixforge-factory/runtimes/f59959b605a51abd2901becde14e7abd852c2bd3f848004b51d250d1cb81af6d/bin/python3": {
+        "private": false,
+        "sha256": "e50d468e8b0adfb05733f5b87b3cff34829c4a8c1aea50c865aa8bdfe4bb150f"
+      },
+      "/home/tegwick/hfact/owner-metered/owner.json": {
+        "private": true,
+        "sha256": "OWNER_RENEW_GENERATED_PIN_REQUIRED"
+      },
+      "/home/tegwick/hfact/owner-metered/spend-policy.json": {
+        "private": true,
+        "sha256": "OWNER_RENEW_GENERATED_PIN_REQUIRED"
+      }
+    },
+    "owner": "rein-aharness MessagesOwner (metered-once) with sand-boxer runtime boundary",
+    "status": "configured"
+  },
+  "status": "inert owner-review template; missing private owner/policy pins intentionally refuse admission"
+}
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/OWNER-REVIEW.md b/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/OWNER-REVIEW.md
new file mode 100644
index 00000000..31e4a020
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/OWNER-REVIEW.md
@@ -0,0 +1,231 @@
+# Identity-provisioner native storage and protected rollback: owner review R1
+
+Prepared 2026-10-17 under NK-WP-0048-T14 / CUST-WP-0080. This is a concrete
+source/package proposal, not a submitted native-action approval. No owner
+assent, database, lease, resource, deployment, caller grant or destructive LDAP
+operation was created. T14 remains progress; T21 stays done for its existing
+source/disposable-SQL scope. No residual work was promoted.
+
+## Assignment recommended for owner disposition
+
+Assign the independently rolled back identity-provisioner workload to a dedicated
+`rapp-identity-provisioner`, with `ownership_repo: net-kingdom`, on
+`rail-kubernetes`. The accompanying schema-valid declaration is **draft**, with
+`bound_reefs: []`. No new repository or registry binding exists. After actual
+owner acceptance, begin the reef binding at declared, retaining separate package
+readiness and reef admission evidence; draft schema validation is neither.
+
+This applies ADR-0015's independent-rollback criterion and Railiance Master's
+accepted exactly-one-rapp rule. Current package declarations contribute no
+`identity-provisioner` deployable; the inspected reef binding has no such package.
+The owner remains NetKingdom according to its current INTENT. Existing
+rapp-user-engine token delivery and client NetworkPolicies do not assign it the
+provisioner workload or authorize security-case group changes. Its own declaration
+lists user-engine and user-engine-pg, not the provisioner. Do not silently append
+the independently rolled-back provisioner to that package.
+
+The alternative is an explicit owner decision to operate these deployables as
+one rollout/rollback fate, with a revised existing package contract and verified
+independent effects. No such decision was found. A new package name here is a
+recommendation, not inferred current identity. This packet changes no owner's
+registry, decision, approval or source implementation.
+
+## Minimal existing-surface consumer candidate
+
+`identity-provisioner.consumer.PROPOSED.yaml` is renderer-valid against the
+**whole current** rapp-postgres catalog; rendered CNPG Database/SQL are in
+`rendered/` solely for review. CNPG Database resources are managed output of this
+package, not an invented live PostgresConsumer CRD installation.
+
+| Property | Proposed value / reason |
+|---|---|
+| CNPG cell | platform-pg-2, namespace databases; third declared consumer there |
+| Consumer workload | sso / Deployment identity-provisioner; explicit package assignment pending |
+| Database / schema | identity_provisioner / identity_provisioner; matches T21 qualified SQL |
+| Durable owner | identity_provisioner_owner, NOLOGIN; never leased |
+| Migration / runtime group | identity_provisioner_migrate / identity_provisioner_app |
+| Capacity requested | 1 migration + 4 runtime connections, database ceiling 5 |
+| Runtime pool proposal | 2 steady connections; at most 4 across old/new pools during lease overlap; 1 migration slot |
+| Timeouts | runtime 5s, migration 30s, idle transaction 15s; existing backend also sets local 5s/15s |
+| Service class | interactive; placement input only, no prioritization claim |
+| Tenant enforcement | required trusted binding/application predicates; RLS false, no E3 isolation claim |
+| Backup requirement | 30 days; no automatic sweep or journal expiration |
+| Cost attribution | platform:identity-provisioner; no EUR price inferred |
+
+Current **source declarations**: platform-pg = audit-core, core-hub,
+isolation-probe, tenant-engine (4/4); platform-pg-2 = canned-prompts,
+sbom-nexus (2/4). Candidate placement makes the second cell 3/4. First-cell
+placement is concretely refused as a fifth declaration. The package's
+`declarations/rapp.yaml` consumers summary lists only audit-core/SBOM, whereas
+the canonical renderer loads all six `consumers/*.yaml` declarations. Use the
+full catalog and existing cell_catalog derivation, never that abbreviated list,
+for placement, backup denominator or acceptance.
+
+The four-consumer ceiling is an estimated safety threshold, not measured
+headroom. The second-cell source is one instance, 256Mi request / 1Gi limit,
+100m CPU request / 1 CPU limit and 20Gi storage. None proves current deployed
+cell state, free memory/disk, successful backup, restore or HA. Additional schema
+allocations (core-hub/hub_runtime) and lease overlap also consume connections;
+request fresh actual session/memory/WAL/backup observations before admission.
+
+## Owner changes required before a native proposal can be approved
+
+1. **NetKingdom + managed package/substrate owners:** accept the exact package
+   assignment; prepare its actual lifecycle/digest/rollback/smoke/delivery
+   contract. Keep current workload and source owners distinct. Do not move
+   running manifests or change current package admission as a documentation fix.
+2. **rapp-postgres:** review/add the consumer through its canonical source
+   surface and verify exact role ownership/default privileges. Review 5 combined
+   connections, 30-day physical instance horizon, offsite logical database
+   inclusion, a successful actual base backup and scratch restore. Existing
+   renderer gives runtime DML, not DDL. The journal meta is runtime-writable;
+   independent checkpoint custody remains necessary. A DB-only quarantine flag
+   is not protection from a restored or hostile DB.
+3. **Platform:** admit exact-cell connection, runtime/migration OpenBao roles,
+   broker grants and caller identity, using the existing catalog and reviewed
+   bootstrap lane. Proposed role/grant identifiers are
+   `identity-provisioner-runtime` / `identity-provisioner-migration` and
+   `rapp-postgres/identity-provisioner-runtime` /
+   `rapp-postgres/identity-provisioner-migration`; these identifiers are
+   **unallocated proposals**, not existing lanes. Configure scripts are replay
+   only: missing allowed_roles or a cell connection requires reviewed admission,
+   never a bootstrap reset or broad allowlist replacement.
+4. **Package + Platform:** supply renewal/rotation/revocation delivery to
+   `psycopg_connector(connection_info=...)`. Callback obtains in-memory lease
+   values on each connection; pin actual host/database/role and TLS verification
+   (`verify-full`, owner-admitted CA and service SAN). Exact public CA/SAN and
+   native TLS support remain to be checked. Do not inject a static DSN into env,
+   log callback values or reuse the LLDAP admin custody path for SQL. TTLs need
+   explicit owner assent; existing SBOM 30m/1h runtime and 10m/30m migration are
+   precedents, not automatically inherited settings. Verify active old sessions
+   terminate on revocation, including after process loss and failed overlap.
+5. **Networking owners:** scope sso egress to the chosen cell plus DNS and any
+   admitted broker/checkpoint endpoint, with migration Jobs included. Existing
+   provisioner egress has only LLDAP/DNS; no SQL route. The provider's generic
+   namespace-label rule would admit **all pods in sso** once labelled
+   `railiance.io/postgres-client=platform-pg-2`; explicitly accept or narrow this
+   shared namespace exposure. A new narrow NetworkPolicy does not subtract old
+   additive broad allows. No namespace label/policy was applied here.
+6. **NetKingdom + protected caller/evidence owners:** implement an owner-fronted
+   protected adapter that constructs GroupJournalBinding from independently
+   authenticated tenant/directory/case digest/source digest/principal/epoch.
+   Bind exact native objects, current authorization and attempt/session expiry;
+   reject mismatched/expired/revoked scope before LDAP or SQL mutation. Existing
+   service bearer token, caller JSON, in-pod execution and group provenance are
+   not that grant. Existing `server.py` has no PostgreSQL activation path and
+   must stay so until trusted callbacks exist. Do not add a convenient DSN or
+   backend switch that activates groups under the User Engine token.
+7. **Independent checkpoint owner:** choose and admit an existing durable,
+   separately recovered holder for the exact `(epoch,directory,head,digest)`.
+   It must atomically check/advance the complete marker, authenticate the
+   admitted writer and retain uncertainty through lost acknowledgments. No
+   evidence here identifies a currently deployed native holder implementing
+   this contract. The existing Audit receipt sink is not by itself a CAS
+   checkpoint service. Keep SQL restores quarantined until independent
+   reconciliation; never recreate genesis, expire intents or advance merely
+   to make a restored store usable.
+8. **Directory/caller/runtime owners:** implement and prove the all-writer
+   barrier described below. Only then prepare an exact destructive acceptance
+   proposal with founder approval, EUR cost/credible-loss treatment and
+   conditional recovery. The State Hub guard rollout grant covers none of it.
+
+## All-writer barrier: required native contract
+
+The current backend locks a singleton meta row per SQL transaction, uses exact
+versions and a durable active slot. This serializes cooperating journal calls;
+LDAP writes occur between SQL transactions. A SQL lock/unique slot cannot
+serialize LLDAP admin WebUI/GraphQL sessions, owner maintenance helpers,
+identity lifecycle deletion/suspension/reconciliation writers, existing client
+sessions or privileged local/native access. `deleteUser` cascades membership
+removal even if no caller invokes the group-revoke route. Removing and readding
+a membership can preserve its visible postimage while destroying creation
+provenance. Two snapshots, a preview digest, one replica and numeric group IDs
+are insufficient CAS/generation evidence.
+
+Owner must select one of two implementable boundaries before native deletion:
+
+- **Exclusive native maintenance barrier:** enumerate every actual writer and
+  provider path, deny admission to other writers, drain/terminate established
+  sessions and in-flight writes, stop autonomous reconciliation, and admit only
+  the exact protected executor for the bounded attempt. Retain the exclusion
+  independently of executor process/Pod loss. Policy installation alone is
+  insufficient: account for additive allows, CNI existing-flow behavior, public
+  ingress, same-Pod/local writes and attended cluster exec/recovery paths.
+  Reopening requires exact SQL/checkpoint/directory reconciliation and owner
+  release; timeout/process death never auto-releases uncertain state. Read-only
+  authentication availability and the outage envelope must be expressly agreed.
+- **Provider-supported CAS/generation:** prove atomic mutation predicates over
+  an immutable generation for groups and membership edges, including cascades
+  and remove/readd ABA, for every writer path. Current LLDAP adapters expose no
+  such provider contract. Do not emulate it with a final reread or advisory lock.
+
+Until one exists, add-only source proof may advance separately, but destructive
+native rollback remains refused. A disposable LLDAP acceptance proves its exact
+isolated environment only, never current estate writer exclusion.
+
+## Native acceptance proposal skeleton (not yet executable)
+
+Stable review identifier: `NK-WP-0048-T14-native-journal-r1`, revision 1.
+Status: **owner-review draft, not submitted for privileged execution**. Required
+exact native manifests/executor/identities/checkpoint holder/source versions and
+cost/risk estimates are missing; a document hash must not be presented as a
+complete action approval. Root must retain the finalized original revision/digest
+and supervisor disposition in the existing supervision trial before execution.
+
+Order the eventual scoped proposals so CNPG storage/lease acceptance can finish
+without destructive directory authority. Targets must identify railiance01 node
+and cluster identity, namespace databases/cell platform-pg-2, dedicated consumer
+DB and runtime package, all disposable acceptance objects, public TLS facts and
+the independent checkpoint holder. An LDAP-writing phase requires its own exact
+directory/case/group/user identifiers and all-writer envelope; no wildcard group,
+whole-directory restore or blanket credential access.
+
+| Native acceptance case | Required actual result |
+|---|---|
+| Package and admission | exactly one admitted package/deployable and current exact source/image binding |
+| Capacity / network | measured headroom and session budget; exact workload/Job allowed, unrelated same-namespace pod refused or explicit reviewed exception |
+| SQL role isolation | runtime DML in own schema, DDL and foreign DB/schema denied; migration owner durable NOLOGIN after lease revoke |
+| TLS identity | genuine admitted CA/SAN succeeds, wrong trust/host refused before SQL |
+| Rotation / crash revocation | bounded overlap, real replacement pool, predecessor and intermediary sessions gone on revoke/exit/crash |
+| Migration / absent epoch | actual v1 tables owned by durable owner; no schema auto-create; no epoch/checkpoint admission means refusal |
+| Initial admission | only independently reviewed genesis admitted to matching SQL and holder; exact directory binding |
+| Tenant/case/principal/source | authentic matching attempt allowed; wrong/revoked/expired binding refused with unchanged LDAP/SQL |
+| Replay and CAS | independent processes contend; one active attempt; stale writer fails without losing durable fence |
+| Native holder loss | actual holder response loss/stale marker causes fail-closed uncertainty, no automatic retry |
+| SQL response/process loss | committed-or-unknown state retained through restart; readback reconciles with exact checkpoint |
+| Divergent clone / restore | same counter/different content and older actual backup refuse against external retained marker |
+| All-writer barrier | actual WebUI/helper/lifecycle/cascade and preexisting-session races denied; exclusion survives executor loss |
+| ABA / preservation | remove/readd cannot authorize destructive undo; preexisting/shared edges/objects remain byte/semantic-equivalent under the admitted snapshot definition |
+| Destructive bounded inverse | only independently confirmed created edges/groups undone, exact per-attempt evidence and fresh provider readback |
+| Recovery / closure | fresh unrelated consumer health; owned acceptance resources gone; no secret values retained; owner revocation/readback receipts |
+
+Verification must record actual native outcomes and failures, not replace T21's
+82 source tests or 21 disposable SQL oracles with new labels. Reuse those proofs;
+only new owner integration changes warrant focused source checks. One claim of
+native backup recovery requires actual backup/restore and independent post-LDAP
+continuity refusal, not merely a ScheduledBackup resource.
+
+Safe recovery defaults: close the protected caller; keep the all-writer barrier,
+all receipts, unresolved intents and independent marker; revoke the owned attempt
+lease/session with exact readback. Roll back code to the last compatible image
+without rolling the journal behind LDAP. Do not drop/reinitialize the DB/schema,
+copy the first cell bootstrap Secret, revoke other consumers, restore the whole
+cell, guess SQL/LDAP outcomes, clear quarantine, or auto-release maintenance.
+Unknown exact recovery mapping stops for attended owner reconciliation. Storage
+cost and credible outage/data-loss/recovery exposure remain unknown EUR values;
+there is no bounded autonomy grant.
+
+## Delivered source review
+
+`source-references.json` binds 32 inspected source files to exact current Git
+bytes; all matched HEAD at capture. NetKingdom HEAD is
+`70f408ca2389bf3722a91a03832fc6e8587355e5`. `source-validation.json` records
+normative package schema pass, full-catalog render/capacity pass, fifth-consumer
+refusal and the package declaration coverage search. These are local checks only.
+
+No NetKingdom source bug requiring a routine fix was found in this scope. The
+next source implementation is the admitted owner adapter/continuity/barrier
+integration, not another journal backend. No source change or broad test rerun
+was justified while those owner contracts remain unresolved. Unrelated staged
+and dirty files were left untouched. Root retains State Hub/task coordination,
+close logging, any workplan refinement, source publication and privileged review.
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/artifact-manifest.json b/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/artifact-manifest.json
new file mode 100644
index 00000000..085ee34a
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/artifact-manifest.json
@@ -0,0 +1,36 @@
+{
+  "proposal_id": "NK-WP-0048-T14-native-journal-r1",
+  "revision": 1,
+  "status": "owner-review-draft-not-submitted",
+  "execution_authorized": false,
+  "files": [
+    {
+      "path": "OWNER-REVIEW.md",
+      "sha256": "sha256:9a12392030ae5bd46dbed95718e3b51e6df15f52ce0fa2411704ddd8f2b1e91f"
+    },
+    {
+      "path": "identity-provisioner.consumer.PROPOSED.yaml",
+      "sha256": "sha256:f1964bf13b9e8d7189eeb66b6a5cec092562b90a325e30c6c5d889c733ff1355"
+    },
+    {
+      "path": "rapp-identity-provisioner.PROPOSED.yaml",
+      "sha256": "sha256:7d7ab31e8f65f70695c79c8305ae70eb666181ad1ee34ea4f0c9e29300072f83"
+    },
+    {
+      "path": "rendered/identity-provisioner.sql",
+      "sha256": "sha256:476738b3b863ec67fedc0c672e6678350a7f73580d953157a22631f28c3263c8"
+    },
+    {
+      "path": "rendered/identity-provisioner.yaml",
+      "sha256": "sha256:0d05211e02cddce2d7ccfdf29ac4dfad8163df62abe93b3c2e39aac0d5ac75d7"
+    },
+    {
+      "path": "source-references.json",
+      "sha256": "sha256:8530100cd820d397da023114076bc33ead9ea5f9983bf39864d041a73b4b77fb"
+    },
+    {
+      "path": "source-validation.json",
+      "sha256": "sha256:fe57add4e819661b7ef4df98f5166d0147f6b5e5912be0d6ec7c0a7da2090d9c"
+    }
+  ]
+}
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/identity-provisioner.consumer.PROPOSED.yaml b/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/identity-provisioner.consumer.PROPOSED.yaml
new file mode 100644
index 00000000..ce1ad077
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/identity-provisioner.consumer.PROPOSED.yaml
@@ -0,0 +1,28 @@
+# OWNER REVIEW ONLY: not admitted, installed, or an executable approval.
+apiVersion: rapp-postgres.railiance.io/v1alpha1
+kind: PostgresConsumer
+metadata:
+  name: identity-provisioner
+spec:
+  cluster: platform-pg-2
+  database: identity_provisioner
+  schema: identity_provisioner
+  costAttributionKey: platform:identity-provisioner
+  clientNamespaces:
+  - sso
+  roles:
+    owner: identity_provisioner_owner
+    migration: identity_provisioner_migrate
+    runtime: identity_provisioner_app
+  limits:
+    migrationConnections: 1
+    runtimeConnections: 4
+    statementTimeout: 5s
+    migrationStatementTimeout: 30s
+    idleInTransactionSessionTimeout: 15s
+  serviceClass: interactive
+  tenantKeyingRequired: true
+  enforcement:
+    rowLevelSecurity: false
+  retention:
+    backupRetentionDays: 30
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/rapp-identity-provisioner.PROPOSED.yaml b/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/rapp-identity-provisioner.PROPOSED.yaml
new file mode 100644
index 00000000..8b74a6b0
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/rapp-identity-provisioner.PROPOSED.yaml
@@ -0,0 +1,61 @@
+# DRAFT only; no repo creation, ownership assignment or reef binding has occurred.
+kind: managed-workload-package
+repo_family: rapp
+rapp_id: rapp-identity-provisioner
+repo: rapp-identity-provisioner
+ownership_repo: net-kingdom
+contract_version: 1.0.0
+readiness_state: draft
+workload_identity:
+  name: identity-provisioner
+  package_type: manifest-managed-platform-service
+data_classification: restricted
+criticality: critical
+primary_rail: rail-kubernetes
+supported_rails:
+- rail-kubernetes
+bound_reefs: []
+runtime_dependencies:
+- kubernetes-api
+- lldap
+- rapp-postgres
+- railiance-platform-credential-broker
+- independent-journal-continuity-holder
+- protected-case-caller
+composition:
+  purpose: Operate the independently rolled back identity-provisioner workload; domain
+    implementation remains NetKingdom-owned.
+  member_repos:
+  - repo: net-kingdom
+    role: Directory lifecycle implementation and current runtime intent
+    deployables:
+    - identity-provisioner
+rollout_contract:
+  default_mode: kubectl-server-side-apply
+  production_gate: reef-production-approved
+  notes:
+  - Draft ownership proposal only. Exact image, delivery, network and acceptance artifacts
+    required before admission.
+smoke_contract:
+  required:
+  - healthz-ok
+  - readyz-owner-dependencies-verified
+  - wrong-case-tenant-principal-denied
+  - lease-renewal-and-revocation-verified
+  - independent-checkpoint-continuity
+  - all-writer-barrier-survives-process-loss
+rollback_contract:
+  order:
+  - disable-protected-group-caller-and-retain-writer-barrier
+  - reapply-previous-verified-image-with-current-journal-retained
+  - attended-reconciliation-for-any-uncertain-effect
+  notes:
+  - Never restore SQL behind directory effects, drop journal state, or release a crash-surviving
+    writer barrier automatically.
+source_documents:
+- repo: net-kingdom
+  path: workplans/NK-WP-0048-security-case-types.md
+- repo: net-kingdom
+  path: docs/adr/ADR-0015-netkingdom-railiance-workload-packaging-and-relational-platform.md
+- repo: railiance-master
+  path: docs/adr/ADR-0007-rapp-declaration-contract.md
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/rendered/identity-provisioner.sql b/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/rendered/identity-provisioner.sql
new file mode 100644
index 00000000..d79f819a
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/rendered/identity-provisioner.sql
@@ -0,0 +1,82 @@
+-- Generated. Login credentials are leased by OpenBao and inherit one of these group roles.
+DO $$ BEGIN CREATE ROLE "identity_provisioner_owner" NOLOGIN NOINHERIT; EXCEPTION WHEN duplicate_object THEN NULL; END $$;
+DO $$ BEGIN CREATE ROLE "identity_provisioner_migrate" NOLOGIN INHERIT; EXCEPTION WHEN duplicate_object THEN NULL; END $$;
+DO $$ BEGIN CREATE ROLE "identity_provisioner_app" NOLOGIN NOINHERIT; EXCEPTION WHEN duplicate_object THEN NULL; END $$;
+GRANT "identity_provisioner_owner" TO "identity_provisioner_migrate";
+ALTER ROLE "identity_provisioner_migrate" CONNECTION LIMIT 1;
+ALTER ROLE "identity_provisioner_app" CONNECTION LIMIT 4;
+ALTER ROLE "identity_provisioner_migrate" SET search_path = "identity_provisioner", pg_catalog;
+ALTER ROLE "identity_provisioner_app" SET search_path = "identity_provisioner", pg_catalog;
+ALTER ROLE "identity_provisioner_migrate" SET statement_timeout = '30s';
+ALTER ROLE "identity_provisioner_app" SET statement_timeout = '5s';
+ALTER ROLE "identity_provisioner_migrate" SET idle_in_transaction_session_timeout = '15s';
+ALTER ROLE "identity_provisioner_app" SET idle_in_transaction_session_timeout = '15s';
+COMMENT ON ROLE "identity_provisioner_app" IS 'cost_attribution=platform:identity-provisioner';
+
+SELECT format('CREATE DATABASE %I OWNER %I', 'identity_provisioner', 'identity_provisioner_owner')
+WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'identity_provisioner') \gexec
+\connect identity_provisioner
+REVOKE CONNECT ON DATABASE "identity_provisioner" FROM PUBLIC;
+GRANT CONNECT ON DATABASE "identity_provisioner" TO "identity_provisioner_migrate", "identity_provisioner_app";
+CREATE SCHEMA IF NOT EXISTS "identity_provisioner" AUTHORIZATION "identity_provisioner_owner";
+REVOKE ALL ON SCHEMA public FROM PUBLIC;
+GRANT USAGE, CREATE ON SCHEMA "identity_provisioner" TO "identity_provisioner_migrate";
+GRANT USAGE ON SCHEMA "identity_provisioner" TO "identity_provisioner_app";
+
+-- Leased migration logins must not retain object ownership after revocation.
+-- Normalize any pre-existing migration-created relations, including objects
+-- made before the workload began issuing SET ROLE to the durable owner.
+DO $ownership$
+DECLARE target record;
+BEGIN
+  FOR target IN
+    SELECT c.relname, c.relkind
+      FROM pg_class c
+      JOIN pg_namespace n ON n.oid = c.relnamespace
+     WHERE n.nspname = 'identity_provisioner'
+       AND c.relkind IN ('r', 'p', 'S')
+       AND c.relowner <> (SELECT oid FROM pg_roles WHERE rolname = 'identity_provisioner_owner')
+  LOOP
+    IF target.relkind = 'S' THEN
+      EXECUTE format('ALTER SEQUENCE %I.%I OWNER TO %I', 'identity_provisioner', target.relname, 'identity_provisioner_owner');
+    ELSE
+      EXECUTE format('ALTER TABLE %I.%I OWNER TO %I', 'identity_provisioner', target.relname, 'identity_provisioner_owner');
+    END IF;
+  END LOOP;
+END
+$ownership$;
+
+
+-- Default privileges key on the role that CREATES an object, not on the schema
+-- owner. Migrations run as the migration role, so objects it creates are owned
+-- by it; declaring only FOR ROLE identity_provisioner_owner left the runtime role with no access
+-- to any table at all. Both grantors are declared. (isolation-test.sh)
+ALTER DEFAULT PRIVILEGES FOR ROLE "identity_provisioner_owner" IN SCHEMA "identity_provisioner"
+  GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO "identity_provisioner_app";
+ALTER DEFAULT PRIVILEGES FOR ROLE "identity_provisioner_owner" IN SCHEMA "identity_provisioner"
+  GRANT USAGE, SELECT ON SEQUENCES TO "identity_provisioner_app";
+ALTER DEFAULT PRIVILEGES FOR ROLE "identity_provisioner_migrate" IN SCHEMA "identity_provisioner"
+  GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO "identity_provisioner_app";
+ALTER DEFAULT PRIVILEGES FOR ROLE "identity_provisioner_migrate" IN SCHEMA "identity_provisioner"
+  GRANT USAGE, SELECT ON SEQUENCES TO "identity_provisioner_app";
+-- Catch objects created before this ran.
+GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA "identity_provisioner" TO "identity_provisioner_app";
+GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA "identity_provisioner" TO "identity_provisioner_app";
+
+-- Resource containment is applied to the DATABASE, not only to the group roles.
+-- OpenBao vends short-lived LOGIN roles that merely inherit a group role, and
+-- neither `ALTER ROLE ... SET` nor CONNECTION LIMIT passes through membership,
+-- so role-level limits alone leave every leased credential unbounded.
+-- Database-level settings apply to each session whichever role opens it.
+-- (isolation-test.sh)
+ALTER DATABASE "identity_provisioner" CONNECTION LIMIT 5;
+-- The database-level statement_timeout is the one every leased login actually
+-- gets; the group-role setting above does not pass through membership. Where
+-- migrationStatementTimeout differs from statementTimeout, the OpenBao
+-- migration role's creation statement must carry
+--   ALTER ROLE "{{name}}" SET statement_timeout = '30s';
+-- on the leased login role itself, or migrations inherit the runtime value.
+ALTER DATABASE "identity_provisioner" SET statement_timeout = '5s';
+ALTER DATABASE "identity_provisioner" SET idle_in_transaction_session_timeout = '15s';
+ALTER DATABASE "identity_provisioner" SET search_path = "identity_provisioner", pg_catalog;
+
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/rendered/identity-provisioner.yaml b/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/rendered/identity-provisioner.yaml
new file mode 100644
index 00000000..c2d0b732
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/rendered/identity-provisioner.yaml
@@ -0,0 +1,12 @@
+apiVersion: postgresql.cnpg.io/v1
+kind: Database
+metadata:
+  name: identity-provisioner
+  namespace: databases
+  labels:
+    rapp-postgres.railiance.io/consumer: identity-provisioner
+spec:
+  cluster:
+    name: platform-pg-2
+  name: identity_provisioner
+  owner: identity_provisioner_owner
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/source-references.json b/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/source-references.json
new file mode 100644
index 00000000..3fa59f0f
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/source-references.json
@@ -0,0 +1,229 @@
+{
+  "references": [
+    {
+      "matches_head": true,
+      "path": "INTENT.md",
+      "repo": "net-kingdom",
+      "revision": "70f408ca2389bf3722a91a03832fc6e8587355e5",
+      "sha256": "sha256:fd2ba8dff9dfd5583ec6d8b0348f273bfe00c59923b5d5d47cd22b1fb4658c54"
+    },
+    {
+      "matches_head": true,
+      "path": "docs/adr/ADR-0015-netkingdom-railiance-workload-packaging-and-relational-platform.md",
+      "repo": "net-kingdom",
+      "revision": "70f408ca2389bf3722a91a03832fc6e8587355e5",
+      "sha256": "sha256:2000985ef211aeedd3656e15cedb289e655526c2dcc4a161a64ffc27f0289db1"
+    },
+    {
+      "matches_head": true,
+      "path": "workplans/NK-WP-0048-security-case-types.md",
+      "repo": "net-kingdom",
+      "revision": "70f408ca2389bf3722a91a03832fc6e8587355e5",
+      "sha256": "sha256:b737bfae4802c122b21619695a169d7d082672af96314b1709860dd5aff2a60f"
+    },
+    {
+      "matches_head": true,
+      "path": "identity-provisioner/group_provenance_postgres.py",
+      "repo": "net-kingdom",
+      "revision": "70f408ca2389bf3722a91a03832fc6e8587355e5",
+      "sha256": "sha256:2a0111e83ad7b611076a1b45634e7f698b3d2e9acc473320b4a8ba009ebd0932"
+    },
+    {
+      "matches_head": true,
+      "path": "identity-provisioner/migrations/group_journal_postgres_v1.sql",
+      "repo": "net-kingdom",
+      "revision": "70f408ca2389bf3722a91a03832fc6e8587355e5",
+      "sha256": "sha256:3cdf82194d6f1e2dd865b0c7e7b8a14447fda8c49151148134a0d40a80fb46ac"
+    },
+    {
+      "matches_head": true,
+      "path": "identity-provisioner/server.py",
+      "repo": "net-kingdom",
+      "revision": "70f408ca2389bf3722a91a03832fc6e8587355e5",
+      "sha256": "sha256:b61c83da6c7ce20fa2790d5bb00aeca6a91dccd133526bc559ed26562f90eb29"
+    },
+    {
+      "matches_head": true,
+      "path": "identity-provisioner/provisioner.py",
+      "repo": "net-kingdom",
+      "revision": "70f408ca2389bf3722a91a03832fc6e8587355e5",
+      "sha256": "sha256:19d1b837cbafeeacb1aa815856cd68091e6702281d72b1d860230fa320e1725b"
+    },
+    {
+      "matches_head": true,
+      "path": "sso-mfa/k8s/identity-provisioner/deployment.yaml",
+      "repo": "net-kingdom",
+      "revision": "70f408ca2389bf3722a91a03832fc6e8587355e5",
+      "sha256": "sha256:807878e939967c8b88dafd4746c2a321b373d9f552083a82248fa917d4d9ea73"
+    },
+    {
+      "matches_head": true,
+      "path": "sso-mfa/k8s/lldap/GROUP-MAINTENANCE.md",
+      "repo": "net-kingdom",
+      "revision": "70f408ca2389bf3722a91a03832fc6e8587355e5",
+      "sha256": "sha256:03be1481f387d9fddbdeff550abbc2cbaa120db4105877c909acc7b3f00f8046"
+    },
+    {
+      "matches_head": true,
+      "path": "sso-mfa/k8s/lldap/ingress.yaml",
+      "repo": "net-kingdom",
+      "revision": "70f408ca2389bf3722a91a03832fc6e8587355e5",
+      "sha256": "sha256:7cb1f0e09f22004adcdd66d617857123d08276aa685d677b0c6e81e0aabe5290"
+    },
+    {
+      "matches_head": true,
+      "path": "declarations/rapp.yaml",
+      "repo": "rapp-postgres",
+      "revision": "a9f569c96d74aa384ac8d3ac4aa960e4061550b5",
+      "sha256": "sha256:a5811e9fa994ae5815214e81440b3be2a32b58236c09ec1887c54d0a7f9f3dce"
+    },
+    {
+      "matches_head": true,
+      "path": "scripts/render_consumers.py",
+      "repo": "rapp-postgres",
+      "revision": "a9f569c96d74aa384ac8d3ac4aa960e4061550b5",
+      "sha256": "sha256:5d83e29e5ec675b3c78c0129d9e12213b624146f5883534a7e5c99aaaa057f61"
+    },
+    {
+      "matches_head": true,
+      "path": "scripts/cell_catalog.py",
+      "repo": "rapp-postgres",
+      "revision": "a9f569c96d74aa384ac8d3ac4aa960e4061550b5",
+      "sha256": "sha256:ab3d189df29d479be748175336841749db8a9fbd39d49c4936c260fb1c7df5a3"
+    },
+    {
+      "matches_head": true,
+      "path": "docs/adr/ADR-0004-platform-pg-cell-ceiling.md",
+      "repo": "rapp-postgres",
+      "revision": "a9f569c96d74aa384ac8d3ac4aa960e4061550b5",
+      "sha256": "sha256:1f1eb521f8e6690bfdf650257308a6139540a65ca65d822a8def5f7a90fde82b"
+    },
+    {
+      "matches_head": true,
+      "path": "wiki/playbooks/database-dynamic-credentials.md",
+      "repo": "rapp-postgres",
+      "revision": "a9f569c96d74aa384ac8d3ac4aa960e4061550b5",
+      "sha256": "sha256:76d27e71d4a53f724ad9626afb5dbcae30682822bff9dd55707afc4b4545329b"
+    },
+    {
+      "matches_head": true,
+      "path": "docs/platform-pg-2-runbook.md",
+      "repo": "rapp-postgres",
+      "revision": "a9f569c96d74aa384ac8d3ac4aa960e4061550b5",
+      "sha256": "sha256:177659f5f45dda6b6b609d9e11063765f344662cdd6eb74552a5ed99771b77f8"
+    },
+    {
+      "matches_head": true,
+      "path": "helm/platform-pg-2-cluster.yaml",
+      "repo": "rapp-postgres",
+      "revision": "a9f569c96d74aa384ac8d3ac4aa960e4061550b5",
+      "sha256": "sha256:06b92a76189b1a33d1eee3f5c835a3e94269ad7b040383c04e8028c2c3fe766a"
+    },
+    {
+      "matches_head": true,
+      "path": "helm/platform-pg-2-networkpolicies.yaml",
+      "repo": "rapp-postgres",
+      "revision": "a9f569c96d74aa384ac8d3ac4aa960e4061550b5",
+      "sha256": "sha256:aa058f37cfff05b20825bd70424283e4510aa1b92dfec0161753e98d865c77cb"
+    },
+    {
+      "matches_head": true,
+      "path": "helm/platform-pg-2-backup.yaml",
+      "repo": "rapp-postgres",
+      "revision": "a9f569c96d74aa384ac8d3ac4aa960e4061550b5",
+      "sha256": "sha256:2c23170a8ef019d5ae7c1e9e3203729c7988ee480f0e6ef31420ccbc70cc79d6"
+    },
+    {
+      "matches_head": true,
+      "path": "consumers/audit-core.yaml",
+      "repo": "rapp-postgres",
+      "revision": "a9f569c96d74aa384ac8d3ac4aa960e4061550b5",
+      "sha256": "sha256:a2db53f901df056546b2c028f287f8fc50486e6e6cd81026b9e926b6b64272b3"
+    },
+    {
+      "matches_head": true,
+      "path": "consumers/canned-prompts.yaml",
+      "repo": "rapp-postgres",
+      "revision": "a9f569c96d74aa384ac8d3ac4aa960e4061550b5",
+      "sha256": "sha256:97d4b439cec7e788b7c1fa2c7181c2606ed098dcf37a38c1f73f7393e6046429"
+    },
+    {
+      "matches_head": true,
+      "path": "consumers/core-hub.yaml",
+      "repo": "rapp-postgres",
+      "revision": "a9f569c96d74aa384ac8d3ac4aa960e4061550b5",
+      "sha256": "sha256:8fe3e8b4488548b2f5e01f1d46edd9fd5fe4f0e4f65a3821f172adbfb5ae1d84"
+    },
+    {
+      "matches_head": true,
+      "path": "consumers/isolation-probe.yaml",
+      "repo": "rapp-postgres",
+      "revision": "a9f569c96d74aa384ac8d3ac4aa960e4061550b5",
+      "sha256": "sha256:8ea24d3bd04ab683b47ceff2586932ea4fdb0d45c49896167bb5b352a67a5cfb"
+    },
+    {
+      "matches_head": true,
+      "path": "consumers/sbom-nexus.yaml",
+      "repo": "rapp-postgres",
+      "revision": "a9f569c96d74aa384ac8d3ac4aa960e4061550b5",
+      "sha256": "sha256:0b21d05fe7b9d21cbc9eb761f455329739ceb71f8dd3d1200971426962c11236"
+    },
+    {
+      "matches_head": true,
+      "path": "consumers/tenant-engine.yaml",
+      "repo": "rapp-postgres",
+      "revision": "a9f569c96d74aa384ac8d3ac4aa960e4061550b5",
+      "sha256": "sha256:92f36d587f001c86ff401aedd25cb49fa171d49e000b0a6ab551e182e5c11448"
+    },
+    {
+      "matches_head": true,
+      "path": "docs/rapp-postgres-boundary.md",
+      "repo": "railiance-platform",
+      "revision": "08c1f036f2750097750f435efd76e8f6ee6df393",
+      "sha256": "sha256:6d80877d2eb7cef79a11f1d8ee40e8bb7fabdbdd122494a7aaa39b6d931e610d"
+    },
+    {
+      "matches_head": true,
+      "path": "credential-grants/catalog.yaml",
+      "repo": "railiance-platform",
+      "revision": "08c1f036f2750097750f435efd76e8f6ee6df393",
+      "sha256": "sha256:cb70165f80c58245d4231b4e712a4b322c51a6b168513dc839ad4c0234027047"
+    },
+    {
+      "matches_head": true,
+      "path": "bindings/rapps.yaml",
+      "repo": "reef-railiance",
+      "revision": "33b840faac109f134bf1115d631d5b1242052d9a",
+      "sha256": "sha256:796007c68f0eda1d50cebddf9e11a2c123a8814ebaf67f739ed5d2af2d6fa3f1"
+    },
+    {
+      "matches_head": true,
+      "path": "schemas/rapp.schema.json",
+      "repo": "railiance-master",
+      "revision": "a0be0d3142b5392f1fb6271cf91325ce91a0f9d4",
+      "sha256": "sha256:46c86e8fd391de5e4287dc7053e3d905ca87b5c4a68cd21c76b40cddd26c3ecd"
+    },
+    {
+      "matches_head": true,
+      "path": "workplans/RMASTER-WP-0025-universal-rapp-workload-coverage.md",
+      "repo": "railiance-master",
+      "revision": "a0be0d3142b5392f1fb6271cf91325ce91a0f9d4",
+      "sha256": "sha256:e56bfcc1377ca4930f89d606c6d6fabbc1309e8f202ac7ff15e22e5d88c2b0ea"
+    },
+    {
+      "matches_head": true,
+      "path": "declarations/rapp.yaml",
+      "repo": "rapp-user-engine",
+      "revision": "a42c68f8701880bfeb93e28dd812fcf3691568a3",
+      "sha256": "sha256:3d03ba72e6048269c4ab8a1ec6c8bbc4502e2d306941a83d982f748a4f300252"
+    },
+    {
+      "matches_head": true,
+      "path": "bindings/reef-railiance.yaml",
+      "repo": "rapp-user-engine",
+      "revision": "a42c68f8701880bfeb93e28dd812fcf3691568a3",
+      "sha256": "sha256:97950e49d48577675a0b2aad7f4b143c57acbfb14fdc09d74ecc1b0329ce17ad"
+    }
+  ],
+  "scope": "public local Git source bytes; no live readiness or owner approval"
+}
diff --git a/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/source-validation.json b/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/source-validation.json
new file mode 100644
index 00000000..2cee4bb1
--- /dev/null
+++ b/docs/changes/netkingdom-target-2026-10-17/native-storage-r1/source-validation.json
@@ -0,0 +1,33 @@
+{
+  "candidate_cell": "platform-pg-2",
+  "candidate_role_connection_limit": 5,
+  "credential_pool_proposal": {
+    "migration": 1,
+    "overlap_runtime_maximum": 4,
+    "steady_runtime": 2
+  },
+  "current_catalog": {
+    "platform-pg": [
+      "audit-core",
+      "core-hub",
+      "isolation-probe",
+      "tenant-engine"
+    ],
+    "platform-pg-2": [
+      "canned-prompts",
+      "sbom-nexus"
+    ]
+  },
+  "existing_matching_deployable_members": [],
+  "first_cell_fifth_declaration_refusal": "platform-pg: 5 declarations exceeds the 4-consumer ceiling; place overflow on platform-pg-2 or another reviewed cluster",
+  "full_catalog_plus_candidate_capacity": "passed",
+  "knowledge": {
+    "digest": "sha256:8d1d6a9d4d07fec7b619618de7dfe2be2254c1790f85f4198c7fe19db9751c02",
+    "local_work_status": "withheld; changed Custodian orientation read directly; no effect authorization",
+    "version": "0.2.6"
+  },
+  "package_declarations_inspected": 14,
+  "package_normative_json_schema": "passed",
+  "runtime_authorization": false,
+  "scope": "read-only source and inert draft render; no DB, lease, native mutation or acceptance"
+}