policy-nexus/docs/releases/2026-10-11-security-layer-v08-publication-proposal.md

PolicyNexus security guardrail publication — source preparation

Stable proposal ID: POLICY-PUB-20261011-SECURITY-LAYER-V08. Status: preparation; no publication or runtime approval requested by this document. Baseline observed 2026-10-11T00:16:33Z. Publishing source, building/pushing an OCI candidate, updating the production binding and changing the live Helm release are separate actions. No such action was executed by this review.

Intended result and ownership

Publish accepted NetKingdom security-layer-model v0.8 (Markdown SHA256 3d8298560069ef471fba28d2b1245fb2309328f231dad1a667cdf0ce5a5a7c8b), change v0.7's canonical lifecycle notice to superseded while preserving its served immutable HTML, and publish the two annotated CUST ADR002/004 current revisions while retaining accepted-1 pages. PolicyNexus renders owner decisions; this release does not revise guardrail decisions or activate a policy enforcement service.

PolicyNexus owns source audit and static OCI publication. rapp-policy-nexus owns chart 0.2.0, hardening, verification and rollback. railiance-apps owns the production four-pin binding; railiance-platform owns the cluster/Helm execution lane. Argo adoption remains RPF-WP-0043, a separate blocked change. Current hosting is Helm release policy-nexus, namespace policy-nexus, hostname policy.coulomb.social on railiance01. No PolicyNexus Argo Application exists. The RPF0043 transition permits attended founder-approved Helm releases through 2026-12-21 under the existing production-tier gate.

Verified baseline and rollback anchor

The Deployment has one ready replica, generation/observed generation 8, Helm ownership and no Argo tracking annotation. Helm revision 8 is deployed. All four baseline pins match live Deployment annotations, public manifest/inventory and railiance-apps/bindings/policy-nexus-production.json:

• Image: forgejo.coulomb.social/coulomb/policy-nexus@sha256:23df0ab3dc80d2a92b8058eeb572c222ceb05d17434f173a24142b2450ab3cea.
• Publication manifest: 09f9f7edcc46e31d4b3f73b62d16fdf17808ae1f893f312242b7b9e2037319e0.
• Source inventory: 9658803bc79d19cef1a9c842d1a8c161f1998d59ce6e4bc4df3c88aba2f4c9c4.
• Source set: 03f04902a3559099433795453829d75470aa1490dd243b42e7703b6eab87772f.

After approval, rollback is the existing make policy-nexus-rollback POLICY_NEXUS_REVISION=8 through RailianceApps/rApp, then restore the above binding and verify public and workload pins. Re-observe immediately before execution: a changed live revision, Argo adoption or baseline identities invalidates revision 8 as an unreviewed rollback anchor. Rollback retains all old immutable pages in the old image but temporarily removes the newly introduced v0.8 URL; record this availability effect if rollback occurs. There are no PVCs, database migrations or credentials in this package.

Historical failed preparation and verified source repair

The first prepared clean site was structurally valid but failed publication transition safety. The complete-history source repair below resolves that failure; no OCI candidate or native approval is implied. Public baseline contains 72 documents; the clean candidate contains 73. Exact source-digest/revision/lifecycle comparison found seven other source changes besides the intended v0.8 addition, v0.7 lifecycle and two ADR annotations: tenancy-posture, work-record-types, workplan-terminology-fleet, NetKingdom architecture, RMASTER-ADR0006, Warden ADR0004 and RISK-F0008. The source review now explicitly includes these seven changes in the publication scope: four already carry newer accepted owner revisions; three need the minimal publication revision corrections described below. This mirrors owner source decisions and records no new acceptance.

A read-only capture of every one of the 72 prior current immutable revision URLs succeeded. Only v0.7 and CUST ADR002/004 retain original served bytes in the prepared clean site. Sixty-five other immutable pages regenerate with different bytes and four old revision paths disappear. Source HEAD changes alone change embedded HTML provenance even when Markdown is unchanged. Historical URLs must survive byte-exact. immutable-audit.json, captured HTML and transition-failure.txt preserve this failure; clean-build verification alone does not establish publication safety.

The new comparison helper checks every old immutable path and hash and refuses semantic changes outside an explicit reviewed ID allowlist. Five meaningful regressions passed, including unchanged Markdown/new repository HEAD, missing previous revisions, failed public capture and allowlisted content that still rewrites history. The original prepared clean site failed the gate; its output is retained. The corrected 73-document clean source mirror now passes with every one of the 72 old immutable pages byte-exact. This helper is preparation tooling, not a live deployment authorization or CI integration. Owner archives must retain actual prior HTML plus original source hash/revision; changed source under the same revision must be explicitly versioned rather than silently overriding an immutable URL.

Reviewed complete source repair and additional publication scope

docs/evidence/2026-10-11-served-publication-history/receipt.json pins the exact delivered manifest, 72 observed HTML pages, and separately 72 original owner Markdown sources. Original source verification used actual Git object reads at the commit embedded in each served page; all72 hashes match HTML and delivered manifest. The generic archive restore checks every document's coverage, path, hash, id/revision and provenance and refuses conflicting existing output before publication. It restores history independently of whether a current document selects a new revision. Existing three owner snapshots are untouched. All45 PolicyNexus tests pass, including seven generic-history and five transition regressions. No whole-release historical-completeness claim beyond captured current URLs is made; earlier URLs absent from the delivered manifest remain discoverable history, and explicit owner snapshots continue to be retained.

The seven additional reviewed source deltas are explicit publication scope:

• Custodian work-record-types accepted-1 -> accepted-2 and workplan-terminology accepted-1 -> accepted-2: owner accepted review2026-09-14; text records founder ratification of STATE-WP0092 flavor/default-exclusion and dependency semantics. No new decision is invented.
• RMASTER ADR0006 accepted-2 -> accepted-3: owner accepted review2026-09-21; adds the founder Kubernetes change gate and transition consequences while retaining original decision. Hosting still uses the separately recorded RPF0043 attended transition, not automatic adoption.
• Warden ADR0004 revision1 ->2: owner accepted source recognizes issued coding-agent subject, states both caller-visible identity markers remain advisory, and preserves enforced OpenBao boundary rather than claiming a new authorization mechanism.
• Tenancy-posture draft-14 -> draft-15: preserve proposed status and review dates; only publication revision changes now. The pre-existing source delta records audit-core restart evidence V0 ->V1 with its bounded measurement/date. This does not accept the proposed standard.
• NetKingdom architecture draft-3 -> draft-4: preserve proposed status and review dates; only publication revision changes now. The pre-existing delta adds the proposed emission-cadence profile to the source index, with migration pending.
• RISK-F0008 published-1 -> published-2: preserve existing accepted finding, accepter, acceptance ending conditions, dates and overdue regulatory-review terms; only publication revision changes now. Owner-source additions record Sep1/2/5/22 review/history and cadence, explicitly withholding renewed acceptance or regulatory assurance. Publishing those records does not resolve the substantive retention gap.

The three new revision URLs were read-only checked and all returned404 before preparation (no current public collision). Their prior URLs remain archived byte-exact. content-review.json retains exact before/current semantic diffs. Only the three frontmatter revision strings are staged owner changes; current source content is not frozen or newly ratified.

Exact candidate and CI gates before asking for approval

1. Commit the staged complete publisher archive/helper, source review and three owner publication revision fixes. All72 original owner sources have been verified against exact Git commits, and the clean source mirror preserves all72 prior current immutable URLs byte-exact. Preserve original owner historical snapshots and failure evidence. Run all PolicyNexus tests, inventory check, currency and release checks against a clean source mirror. Run the transition helper with the reviewed exact ID allowlist. Retain both the failed baseline and corrected result.
2. Capture the PolicyNexus exact 40-hex revision and each upstream exact revision in _sources/source-lock.json, derived by the existing pinned-source-fetch workflow. Candidate identity must come from the actual CI image, not the local 73-document build. publish-image.yaml runs on main/schedule/dispatch, uses tier2 container-build, has registry publication authority and no cluster deployment authority. Dedicated source/registry secrets remain inside CI; this review does not retrieve them. Public remote main was bfef142d4cf8084b76084e4b0c7775999d72c2e7, with no reported commit statuses; the queried Actions endpoint returned 404. Neither observation proves a successful pending candidate build.
3. The workflow uses pinned Python source-fetch/build tooling and pinned nginx runtime base, builds release-artifact, audits exact lock/inventory and publishes source-/git-/main tags. Resolve the actual registry digest, retain build/check output and verify registry bytes by extracting publication-manifest/source-inventory. Record their SHA256s and source-set digest together. Tags alone cannot be approved as runtime identity. No candidate image or new paired four-pin set exists in this preparation receipt.
4. Prepare a reviewed RailianceApps production binding containing those four exact candidate pins in one change, along with exact source lock, inventory report, content delta and immutable transition receipt. Inspect the image/security findings under the existing owner release policy. Render chart0.2.0 with that binding; compare against the live baseline and require changes limited to image plus three digest annotations. Run existing server dry-run through the approved operator lane after exact action scope is agreed. Do not adopt into Argo as part of this publication.
5. Recheck cluster headroom and existing ownership. Deployment resources stay 10m CPU/32Mi requested, 100m/64Mi limit, nonroot101, readonly root, no service-account token and deny-egress. RollingUpdate maxSurge1/maxUnavailable0 requires an extra 10m/32Mi requested for a brief second pod. Node allocatable CPU is4; current available requested CPU was not measured by this review, so headroom remains a preflight prerequisite.
6. Founder proposal must name exact source revisions, image and all three evidence digests, chart/render digest, binding digest, target, operation and rollback. Founder authorization applies to that exact runtime revision; newer CI schedules do not authorize a moving candidate. Only then execute the existing guarded Helm upgrade --atomic --wait --timeout5m via rApp.

Verification and estimates

Require one ready serving Deployment on the approved digest with all three evidence annotations, HTTPS certificateReady, exact public manifest/inventory hashes, correct inventory source-set digest and source lock/provenance matching the approved source. Explicitly fetch the v0.8 canonical/immutable pages, v0.7 superseded canonical notice and old v0.7 immutable SHA 7d7a38a8c3b9fff65b46280fcd5723eff77dc9d0784f871bb35f718bc4e8c0e7, plus both current ADR revisions and preserved accepted-1 pages. Fetch and hash all captured baseline immutable paths against the reviewed receipt. Existing rApp verify_live.sh samples only the first document; its green status cannot replace these changed-content/history checks. Keep its TLS, runtime pin and legacy redirect checks as additional evidence.

Incremental infrastructure spending estimate EUR0 (existing runner/registry/cluster; no purchased resources). Preparation/build estimated minutes rather than customer downtime; avoid parallel heavy builds on this workstation. Rollout budget5min with atomic rollback; expected brief static-serving rollout with one existing replica retained until readiness. Main risks: wrong source provenance, lost immutable history, unreviewed additional source changes, registry candidate not available to cluster, and insufficient surge CPU causing a stalled rollout. All are concrete gates above. No new paid API calls, credential changes, policy enforcement writes or customer data changes are included.