feat: publish Risk Nexus findings and methods

Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a058f3-8ba0-7692-a042-9a870fc3d663
2026-09-01 01:56:46 +02:00 · 2026-09-01 01:56:46 +02:00 · c1b60f322e
commit c1b60f322e
parent 4c8a7b9666
70 changed files with 3888 additions and 198 deletions
--- a/build/standards/autonomy-lanes/v0.1/index.html
+++ b/build/standards/autonomy-lanes/v0.1/index.html
@ -1,6 +1,6 @@
 <!doctype html>
 <html lang="en"><meta charset="utf-8">
-<meta name="policy-source-revision" content="4b951be3947f9457cc091a7d359d9232646b4c93">
+<meta name="policy-source-revision" content="f9435cd605cc5b3cb0f2e957ce6287d9f3129aac">
 <meta name="policy-source-digest" content="106cb0c99f73983199c9f1d8491143aa2a2eb41ee450a02ec7968d3763f30399">
 <title>Autonomy Lanes (Fleet) v0.1</title>
 <style>
@ -191,7 +191,7 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
@media (prefers-reduced-motion:reduce){*{animation:none!important;transition:none!important}}

 </style>
-<div class="wrap"><header><div class="eyebrow"><span>canon-autonomy-lanes</span> <span class="stat">accepted · accepted-1</span> <span>the-custodian</span> <span>reviewed 2026-08-31</span><span>generated from canonical source — do not edit</span></div><h1>Autonomy Lanes (Fleet) v0.1</h1><p class="sub">Source: <code>the-custodian · canon/standards/autonomy-lanes_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93</code></p><p class="sub">Review due: 2027-02-28</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#the-rule"><span class="n">·</span>The rule</a></li><li><a href="#lanes"><span class="n">·</span>Lanes</a></li><li><a href="#lane-as-a-spine-field"><span class="n">·</span>Lane as a spine field</a></li><li><a href="#approval-packages-yellow-and-above"><span class="n">·</span>Approval packages (yellow and above)</a></li><li><a href="#human-attention-is-a-wip-limited-workstation"><span class="n">·</span>Human attention is a WIP-limited workstation</a></li><li><a href="#raising-autonomy"><span class="n">·</span>Raising autonomy</a></li><li><a href="#references"><span class="n">·</span>References</a></li></ol></nav><main><div class="rule-quote"><p>Ratified by founder 2026-07-20 (CUST-WP-0060-T01, hub decision f4640f9e). Promotes the binky-control AutonomyPolicy lane model to fleet canon, unchanged in substance. binky-control's <code>AutonomyPolicy.md</code> remains the company-level policy instance; this standard makes the lane vocabulary and enforcement rules fleet-wide.</p></div>
+<div class="wrap"><header><div class="eyebrow"><span>canon-autonomy-lanes</span> <span class="stat">accepted · accepted-1</span> <span>the-custodian</span> <span>reviewed 2026-08-31</span><span>generated from canonical source — do not edit</span></div><h1>Autonomy Lanes (Fleet) v0.1</h1><p class="sub">Source: <code>the-custodian · canon/standards/autonomy-lanes_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac</code></p><p class="sub">Review due: 2027-02-28</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#the-rule"><span class="n">·</span>The rule</a></li><li><a href="#lanes"><span class="n">·</span>Lanes</a></li><li><a href="#lane-as-a-spine-field"><span class="n">·</span>Lane as a spine field</a></li><li><a href="#approval-packages-yellow-and-above"><span class="n">·</span>Approval packages (yellow and above)</a></li><li><a href="#human-attention-is-a-wip-limited-workstation"><span class="n">·</span>Human attention is a WIP-limited workstation</a></li><li><a href="#raising-autonomy"><span class="n">·</span>Raising autonomy</a></li><li><a href="#references"><span class="n">·</span>References</a></li></ol></nav><main><div class="rule-quote"><p>Ratified by founder 2026-07-20 (CUST-WP-0060-T01, hub decision f4640f9e). Promotes the binky-control AutonomyPolicy lane model to fleet canon, unchanged in substance. binky-control's <code>AutonomyPolicy.md</code> remains the company-level policy instance; this standard makes the lane vocabulary and enforcement rules fleet-wide.</p></div>
 <section id="the-rule"><h2>The rule</h2>
 <div class="rule-quote"><p>If the responsible human is unavailable, the system must either continue safely, prepare the next decision, or explicitly defer with evidence. It must not silently idle.</p></div>
 <p>Valid states: <code>proceeding</code> | <code>prepared for review</code> | <code>deferred by policy</code>. Invalid state: <code>waiting because unsure</code>. Uncertainty triggers research, comparison, preparation, or risk classification — not paralysis. "Ask the human" is never the default.</p>
@ -219,4 +219,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
 </section>
 <section id="references"><h2>References</h2>
 <ul><li><code>binky-control/AutonomyPolicy.md</code> (origin instance)</li><li><code>canon/standards/work-record-types_v0.1.md</code></li><li><code>research/2026-07-19-work-orchestration-best-practices.md</code> §2</li></ul>
-</section><footer><span>canon-autonomy-lanes · accepted-1 · accepted</span><span>the-custodian · canon/standards/autonomy-lanes_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93</span></footer></main></div></div></html>
+</section><footer><span>canon-autonomy-lanes · accepted-1 · accepted</span><span>the-custodian · canon/standards/autonomy-lanes_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac</span></footer></main></div></div></html>
--- a/build/standards/contribution-convention/v0.1/index.html
+++ b/build/standards/contribution-convention/v0.1/index.html
@ -1,6 +1,6 @@
 <!doctype html>
 <html lang="en"><meta charset="utf-8">
-<meta name="policy-source-revision" content="4b951be3947f9457cc091a7d359d9232646b4c93">
+<meta name="policy-source-revision" content="f9435cd605cc5b3cb0f2e957ce6287d9f3129aac">
 <meta name="policy-source-digest" content="6dfc1d7b2b82ab18228a84660c1c7dff607aad1d9da37ac12084cdd2ab8ae112">
 <title>Contribution Convention v0.1</title>
 <style>
@ -191,7 +191,7 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
@media (prefers-reduced-motion:reduce){*{animation:none!important;transition:none!important}}

 </style>
-<div class="wrap"><header><div class="eyebrow"><span>canon-contrib-convention</span> <span class="stat">accepted · accepted-1</span> <span>the-custodian</span> <span>reviewed 2026-08-31</span><span>generated from canonical source — do not edit</span></div><h1>Contribution Convention v0.1</h1><p class="sub">Source: <code>the-custodian · canon/standards/contribution-convention_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93</code></p><p class="sub">Review due: 2027-02-28</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#purpose"><span class="n">·</span>Purpose</a></li><li><a href="#artifact-types"><span class="n">·</span>Artifact Types</a></li><li><a href="#directory-layout"><span class="n">·</span>Directory Layout</a></li><li><a href="#frontmatter-schema"><span class="n">·</span>Frontmatter Schema</a></li><li><a href="#id-schemes"><span class="n">·</span>ID Schemes</a></li><li><a href="#status-lifecycle"><span class="n">·</span>Status Lifecycle</a></li><li><a href="#relationship-to-state-hub"><span class="n">·</span>Relationship to State Hub</a></li></ol></nav><main><section id="purpose"><h2>Purpose</h2>
+<div class="wrap"><header><div class="eyebrow"><span>canon-contrib-convention</span> <span class="stat">accepted · accepted-1</span> <span>the-custodian</span> <span>reviewed 2026-08-31</span><span>generated from canonical source — do not edit</span></div><h1>Contribution Convention v0.1</h1><p class="sub">Source: <code>the-custodian · canon/standards/contribution-convention_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac</code></p><p class="sub">Review due: 2027-02-28</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#purpose"><span class="n">·</span>Purpose</a></li><li><a href="#artifact-types"><span class="n">·</span>Artifact Types</a></li><li><a href="#directory-layout"><span class="n">·</span>Directory Layout</a></li><li><a href="#frontmatter-schema"><span class="n">·</span>Frontmatter Schema</a></li><li><a href="#id-schemes"><span class="n">·</span>ID Schemes</a></li><li><a href="#status-lifecycle"><span class="n">·</span>Status Lifecycle</a></li><li><a href="#relationship-to-state-hub"><span class="n">·</span>Relationship to State Hub</a></li></ol></nav><main><section id="purpose"><h2>Purpose</h2>
 <p>This document defines the canonical convention for tracking upstream contributions across all custodian-ecosystem repositories. A <em>contribution</em> is any intentional engagement with an external upstream project: a bug report, feature request, extension-point proposal, or pull request.</p>
 <p>Contributions are tracked as Markdown artifacts with typed YAML frontmatter, committed to the repository that authors them, and indexed in the State Hub DB. This enables the Custodian to maintain a full audit trail of all upstream engagement across all six project domains.</p>
 </section>
@ -270,4 +270,4 @@ draft_pr_body: |
 <section id="relationship-to-state-hub"><h2>Relationship to State Hub</h2>
 <p>Once an artifact is registered via <code>register_contribution()</code> MCP tool or <code>POST /contributions/</code> API, the State Hub assigns a UUID and returns it. That UUID is written back into <code>state_hub_contribution_id</code> in the frontmatter.</p>
 <p>The State Hub is a <strong>read/cache layer</strong> — the Markdown file is always the authoritative source of truth. If the DB is reset, contributions can be re-ingested from the files.</p>
-</section><footer><span>canon-contrib-convention · accepted-1 · accepted</span><span>the-custodian · canon/standards/contribution-convention_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93</span></footer></main></div></div></html>
+</section><footer><span>canon-contrib-convention · accepted-1 · accepted</span><span>the-custodian · canon/standards/contribution-convention_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac</span></footer></main></div></div></html>
--- a/build/standards/iam-profile/v0.3/index.html
+++ b/build/standards/iam-profile/v0.3/index.html
@ -1,6 +1,6 @@
 <!doctype html>
 <html lang="en"><meta charset="utf-8">
-<meta name="policy-source-revision" content="d4e57e63126d2cca1d381c025170e4b1f678c3f3">
+<meta name="policy-source-revision" content="9781102e2971d762ae42fdd5085a6647afd1cd66">
 <meta name="policy-source-digest" content="6c47b596ea145fa197c9665081c84902482d90f5bb94d185c1223af65279be1d">
 <title>NetKingdom IAM Profile v0.3</title>
 <style>
@ -191,7 +191,7 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
@media (prefers-reduced-motion:reduce){*{animation:none!important;transition:none!important}}

 </style>
-<div class="wrap"><header><div class="eyebrow"><span>netkingdom-iam-profile-v0.3</span> <span class="stat">accepted · accepted-1</span> <span>net-kingdom</span> <span>reviewed 2026-08-22</span><span>generated from canonical source — do not edit</span></div><h1>NetKingdom IAM Profile v0.3</h1><p class="sub">Source: <code>net-kingdom · canon/standards/iam-profile_v0.3.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3</code></p><p class="sub">Review due: 2027-02-22</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#purpose"><span class="n">·</span>Purpose</a></li><li><a href="#ownership"><span class="n">·</span>Ownership</a></li><li><a href="#design-principles"><span class="n">·</span>Design Principles</a></li><li><a href="#discovery-contract"><span class="n">·</span>Discovery Contract</a></li><li><a href="#required-flows"><span class="n">·</span>Required Flows</a></li><li><a href="#core-claims"><span class="n">·</span>Core Claims</a></li><li><a href="#tenant-claim"><span class="n">·</span>Tenant Claim</a></li><li><a href="#tenant-roles"><span class="n">·</span>Tenant Roles</a></li><li><a href="#assurance-evidence"><span class="n">·</span>Assurance Evidence</a></li><li><a href="#identity-to-authorization-contract"><span class="n">·</span>Identity To Authorization Contract</a></li><li><a href="#token-lifecycle"><span class="n">·</span>Token Lifecycle</a></li><li><a href="#local-development-profile"><span class="n">·</span>Local Development Profile</a></li><li><a href="#emergency-and-break-glass-access"><span class="n">·</span>Emergency And Break-Glass Access</a></li><li><a href="#conformance"><span class="n">·</span>Conformance</a></li><li><a href="#validation-checklist"><span class="n">·</span>Validation Checklist</a></li></ol></nav><main><div class="rule-quote"><p>Minor version. Per ADR-0011's versioning rule, this adds an optional claim and clarifies non-normative guidance — no required claim, validation rule, or previously-issued token is invalidated. Existing v0.2 implementations remain conformant; <code>tenant_roles</code> and the revised Tenant Claim guidance are additive.</p></div>
+<div class="wrap"><header><div class="eyebrow"><span>netkingdom-iam-profile-v0.3</span> <span class="stat">accepted · accepted-1</span> <span>net-kingdom</span> <span>reviewed 2026-08-22</span><span>generated from canonical source — do not edit</span></div><h1>NetKingdom IAM Profile v0.3</h1><p class="sub">Source: <code>net-kingdom · canon/standards/iam-profile_v0.3.md · 9781102e2971d762ae42fdd5085a6647afd1cd66</code></p><p class="sub">Review due: 2027-02-22</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#purpose"><span class="n">·</span>Purpose</a></li><li><a href="#ownership"><span class="n">·</span>Ownership</a></li><li><a href="#design-principles"><span class="n">·</span>Design Principles</a></li><li><a href="#discovery-contract"><span class="n">·</span>Discovery Contract</a></li><li><a href="#required-flows"><span class="n">·</span>Required Flows</a></li><li><a href="#core-claims"><span class="n">·</span>Core Claims</a></li><li><a href="#tenant-claim"><span class="n">·</span>Tenant Claim</a></li><li><a href="#tenant-roles"><span class="n">·</span>Tenant Roles</a></li><li><a href="#assurance-evidence"><span class="n">·</span>Assurance Evidence</a></li><li><a href="#identity-to-authorization-contract"><span class="n">·</span>Identity To Authorization Contract</a></li><li><a href="#token-lifecycle"><span class="n">·</span>Token Lifecycle</a></li><li><a href="#local-development-profile"><span class="n">·</span>Local Development Profile</a></li><li><a href="#emergency-and-break-glass-access"><span class="n">·</span>Emergency And Break-Glass Access</a></li><li><a href="#conformance"><span class="n">·</span>Conformance</a></li><li><a href="#validation-checklist"><span class="n">·</span>Validation Checklist</a></li></ol></nav><main><div class="rule-quote"><p>Minor version. Per ADR-0011's versioning rule, this adds an optional claim and clarifies non-normative guidance — no required claim, validation rule, or previously-issued token is invalidated. Existing v0.2 implementations remain conformant; <code>tenant_roles</code> and the revised Tenant Claim guidance are additive.</p></div>
 <section id="purpose"><h2>Purpose</h2>
 <p>The NetKingdom IAM Profile is the provider-neutral OIDC contract that identity implementations issue and applications consume.</p>
 <p>It defines:</p>
@ -316,4 +316,4 @@ agentic      - financially enabled AI entities</pre>
 <section id="validation-checklist"><h2>Validation Checklist</h2>
 <p>A service or implementation is profile-ready when:</p>
 <ul><li>it reads OIDC discovery rather than hardcoding endpoints;</li><li>it validates issuer, audience, expiry, <code>nbf</code>, algorithm, and signature;</li><li>it refreshes JWKS on unknown <code>kid</code>;</li><li>it supports Authorization Code + PKCE for human login;</li><li>it supports service-account or workload identity tokens;</li><li>it emits <code>tenant</code>, <code>principal_type</code>, <code>groups</code>, <code>roles</code>, <code>scope</code>/<code>scp</code>, and <code>assurance</code>;</li><li>it uses the ADR-0013 grouping vocabulary for new tenant identifiers;</li><li>if it consumes <code>tenant_roles</code>, it treats the claim as a cache and re-validates live against <code>tenant-engine</code> before any <code>aal2</code>-class decision;</li><li>it maps provider-native claims into the canonical core claims;</li><li>it rejects local-development issuers in production;</li><li>it logs emergency access with a durable audit trail;</li><li>flex-auth receives identity facts from the profile, not from provider-specific sessions.</li></ul>
-</section><footer><span>netkingdom-iam-profile-v0.3 · accepted-1 · accepted</span><span>net-kingdom · canon/standards/iam-profile_v0.3.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3</span></footer></main></div></div></html>
+</section><footer><span>netkingdom-iam-profile-v0.3 · accepted-1 · accepted</span><span>net-kingdom · canon/standards/iam-profile_v0.3.md · 9781102e2971d762ae42fdd5085a6647afd1cd66</span></footer></main></div></div></html>
--- a/build/standards/posture-feedback/v0.1/index.html
+++ b/build/standards/posture-feedback/v0.1/index.html
@ -1,6 +1,6 @@
 <!doctype html>
 <html lang="en"><meta charset="utf-8">
-<meta name="policy-source-revision" content="d4e57e63126d2cca1d381c025170e4b1f678c3f3">
+<meta name="policy-source-revision" content="9781102e2971d762ae42fdd5085a6647afd1cd66">
 <meta name="policy-source-digest" content="dd2628b9f0c2a662ac44af22657d91918da228f307ebc7ceb09fc856162985db">
 <title>NetKingdom Posture Feedback v0.1</title>
 <style>
@ -191,7 +191,7 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
@media (prefers-reduced-motion:reduce){*{animation:none!important;transition:none!important}}

 </style>
-<div class="wrap"><header><div class="eyebrow"><span>netkingdom-posture-feedback-v0.1</span> <span class="stat">proposed</span> <span>net-kingdom</span> <span>reviewed 2026-08-23</span><span>generated from canonical source — do not edit</span></div><h1>NetKingdom Posture Feedback v0.1</h1><p class="sub">Source: <code>net-kingdom · canon/standards/posture-feedback_v0.1.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3</code></p><p class="sub">Review due: 2026-11-23</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#s1"><span class="n">1</span>Purpose</a></li><li><a href="#s2"><span class="n">2</span>Deterministic time</a></li><li><a href="#s3"><span class="n">3</span>Owner resolution</a></li><li><a href="#s4"><span class="n">4</span>Finding classes</a></li><li><a href="#s5"><span class="n">5</span>Proposal and safety boundary</a></li><li><a href="#s6"><span class="n">6</span>Exit behavior</a></li></ol></nav><main><section id="s1"><h2><span class="sn">01</span>Purpose</h2>
+<div class="wrap"><header><div class="eyebrow"><span>netkingdom-posture-feedback-v0.1</span> <span class="stat">proposed</span> <span>net-kingdom</span> <span>reviewed 2026-08-23</span><span>generated from canonical source — do not edit</span></div><h1>NetKingdom Posture Feedback v0.1</h1><p class="sub">Source: <code>net-kingdom · canon/standards/posture-feedback_v0.1.md · 9781102e2971d762ae42fdd5085a6647afd1cd66</code></p><p class="sub">Review due: 2026-11-23</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#s1"><span class="n">1</span>Purpose</a></li><li><a href="#s2"><span class="n">2</span>Deterministic time</a></li><li><a href="#s3"><span class="n">3</span>Owner resolution</a></li><li><a href="#s4"><span class="n">4</span>Finding classes</a></li><li><a href="#s5"><span class="n">5</span>Proposal and safety boundary</a></li><li><a href="#s6"><span class="n">6</span>Exit behavior</a></li></ol></nav><main><section id="s1"><h2><span class="sn">01</span>Purpose</h2>
 <p>This contract is the first bounded C6 feedback mechanism. It turns explicit posture review dates, evidence freshness, implemented-but-unevidenced controls, and declared gaps into deterministic remediation <strong>proposals</strong>.</p>
 <p>It does not modify a posture level, policy, declaration, workplan, State Hub, or runtime. Human or separately governed automation decides whether a proposal becomes work.</p>
 </section>
@ -221,4 +221,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
 </section>
 <section id="s6"><h2><span class="sn">06</span>Exit behavior</h2>
 <p>The CLI emits a report conforming to <code>posture-feedback-report_v0.1.schema.json</code>. <code>--fail-on high</code> exits non-zero when at least one high-severity finding exists; <code>medium</code> includes medium and high; <code>low</code> includes every finding; <code>none</code> reports without a finding-based failure. Invalid declarations always exit non-zero.</p>
-</section><footer><span>netkingdom-posture-feedback-v0.1 ·  · proposed</span><span>net-kingdom · canon/standards/posture-feedback_v0.1.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3</span></footer></main></div></div></html>
+</section><footer><span>netkingdom-posture-feedback-v0.1 ·  · proposed</span><span>net-kingdom · canon/standards/posture-feedback_v0.1.md · 9781102e2971d762ae42fdd5085a6647afd1cd66</span></footer></main></div></div></html>
--- a/build/standards/project-repository-flavor/v0.1/index.html
+++ b/build/standards/project-repository-flavor/v0.1/index.html
@ -1,6 +1,6 @@
 <!doctype html>
 <html lang="en"><meta charset="utf-8">
-<meta name="policy-source-revision" content="4b951be3947f9457cc091a7d359d9232646b4c93">
+<meta name="policy-source-revision" content="f9435cd605cc5b3cb0f2e957ce6287d9f3129aac">
 <meta name="policy-source-digest" content="61889b2f18a82a08b66ef90d758efe5c028a4f52aced1721a23e69c6f24a8224">
 <title>Project Repository Flavor (prj-) v0.1</title>
 <style>
@ -191,7 +191,7 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
@media (prefers-reduced-motion:reduce){*{animation:none!important;transition:none!important}}

 </style>
-<div class="wrap"><header><div class="eyebrow"><span>canon-project-repository-flavor</span> <span class="stat">accepted · accepted-1</span> <span>the-custodian</span> <span>reviewed 2026-08-31</span><span>generated from canonical source — do not edit</span></div><h1>Project Repository Flavor (prj-) v0.1</h1><p class="sub">Source: <code>the-custodian · canon/standards/project-repository-flavor_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93</code></p><p class="sub">Review due: 2027-02-28</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#purpose"><span class="n">·</span>Purpose</a></li><li><a href="#when-to-use-a-project-repository"><span class="n">·</span>When to use a project repository</a></li><li><a href="#naming"><span class="n">·</span>Naming</a></li><li><a href="#authority-boundary"><span class="n">·</span>Authority boundary</a></li><li><a href="#required-files"><span class="n">·</span>Required files</a></li><li><a href="#lifecycle"><span class="n">·</span>Lifecycle</a></li><li><a href="#residuals-before-completion"><span class="n">·</span>Residuals before completion</a></li><li><a href="#completion-record"><span class="n">·</span>Completion record</a></li><li><a href="#archive-procedure"><span class="n">·</span>Archive procedure</a></li><li><a href="#workplan-and-agent-conventions"><span class="n">·</span>Workplan and agent conventions</a></li><li><a href="#minimal-layout-example"><span class="n">·</span>Minimal layout example</a></li><li><a href="#reference-instance"><span class="n">·</span>Reference instance</a></li><li><a href="#conformance-checklist"><span class="n">·</span>Conformance checklist</a></li><li><a href="#related"><span class="n">·</span>Related</a></li></ol></nav><main><section id="purpose"><h2>Purpose</h2>
+<div class="wrap"><header><div class="eyebrow"><span>canon-project-repository-flavor</span> <span class="stat">accepted · accepted-1</span> <span>the-custodian</span> <span>reviewed 2026-08-31</span><span>generated from canonical source — do not edit</span></div><h1>Project Repository Flavor (prj-) v0.1</h1><p class="sub">Source: <code>the-custodian · canon/standards/project-repository-flavor_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac</code></p><p class="sub">Review due: 2027-02-28</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#purpose"><span class="n">·</span>Purpose</a></li><li><a href="#when-to-use-a-project-repository"><span class="n">·</span>When to use a project repository</a></li><li><a href="#naming"><span class="n">·</span>Naming</a></li><li><a href="#authority-boundary"><span class="n">·</span>Authority boundary</a></li><li><a href="#required-files"><span class="n">·</span>Required files</a></li><li><a href="#lifecycle"><span class="n">·</span>Lifecycle</a></li><li><a href="#residuals-before-completion"><span class="n">·</span>Residuals before completion</a></li><li><a href="#completion-record"><span class="n">·</span>Completion record</a></li><li><a href="#archive-procedure"><span class="n">·</span>Archive procedure</a></li><li><a href="#workplan-and-agent-conventions"><span class="n">·</span>Workplan and agent conventions</a></li><li><a href="#minimal-layout-example"><span class="n">·</span>Minimal layout example</a></li><li><a href="#reference-instance"><span class="n">·</span>Reference instance</a></li><li><a href="#conformance-checklist"><span class="n">·</span>Conformance checklist</a></li><li><a href="#related"><span class="n">·</span>Related</a></li></ol></nav><main><section id="purpose"><h2>Purpose</h2>
 <p>Define the durable <strong>project repository</strong> flavor used for complex cross-repository efforts: naming, required files, authority boundary, lifecycle, residual handoff, and archive procedure.</p>
 <p>This standard implements and completes <strong>ADR-005</strong> (<em>Cross-Repo Workplans Live in Dedicated Project Repos</em>). It does <strong>not</strong> replace the Repo Classification Standard: project repositories still use <code>category: project</code> in <code>.repo-classification.yaml</code>.</p>
 </section>
@ -276,4 +276,4 @@ reviewed: &quot;YYYY-MM-DD&quot;
 </section>
 <section id="related"><h2>Related</h2>
 <ul><li>ADR-001 — Workplans and Work Items Are Repository Artefacts</li><li>ADR-005 — Cross-Repo Workplans Live in Dedicated Project Repos</li><li><code>repo-classification-standard_v1.0.md</code> — <code>category: project</code></li><li><code>work-record-types_v0.1.md</code> — residuals and work-record kinds</li><li><code>workplan-terminology-fleet_v0.1.md</code> — workplan vocabulary</li></ul>
-</section><footer><span>canon-project-repository-flavor · accepted-1 · accepted</span><span>the-custodian · canon/standards/project-repository-flavor_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93</span></footer></main></div></div></html>
+</section><footer><span>canon-project-repository-flavor · accepted-1 · accepted</span><span>the-custodian · canon/standards/project-repository-flavor_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac</span></footer></main></div></div></html>
--- a/build/standards/security-layer-model/v0.7/index.html
+++ b/build/standards/security-layer-model/v0.7/index.html
@ -1,6 +1,6 @@
 <!doctype html>
 <html lang="en"><meta charset="utf-8">
-<meta name="policy-source-revision" content="d4e57e63126d2cca1d381c025170e4b1f678c3f3">
+<meta name="policy-source-revision" content="9781102e2971d762ae42fdd5085a6647afd1cd66">
 <meta name="policy-source-digest" content="8155e7b123be1e84377d8278525b1bad8961007b6bb8ff012dd01ba24ff8065b">
 <title>NetKingdom Security Layer Model v0.7</title>
 <style>
@ -191,7 +191,7 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
@media (prefers-reduced-motion:reduce){*{animation:none!important;transition:none!important}}

 </style>
-<div class="wrap"><header><div class="eyebrow"><span>netkingdom-security-layer-model-v0.7</span> <span class="stat">accepted</span> <span>gate-house</span> <span>reviewed 2026-08-28</span><span>generated from canonical source — do not edit</span></div><h1>NetKingdom Security Layer Model v0.7</h1><p class="sub">Source: <code>net-kingdom · canon/standards/security-layer-model_v0.7.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3</code></p><p class="sub">Review due: 2026-11-28</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#s1"><span class="n">1</span>Purpose</a></li><li><a href="#s2"><span class="n">2</span>Authority and conformance</a></li><li><a href="#s3"><span class="n">3</span>The layers</a></li><li><a href="#s4"><span class="n">4</span>Layer catalog</a></li><li><a href="#s5"><span class="n">5</span>The binding rule</a></li><li><a href="#s6"><span class="n">6</span>One decision point</a></li><li><a href="#s7"><span class="n">7</span>Relationship to the Active Secrets Management Canon</a></li><li><a href="#s8"><span class="n">8</span>Vocabulary demarcations</a></li><li><a href="#s9"><span class="n">9</span>Capability assignment</a></li><li><a href="#s10"><span class="n">10</span>Changing layer</a></li><li><a href="#s11"><span class="n">11</span>Conformance</a></li><li><a href="#s12"><span class="n">12</span>The conformance loop</a></li><li><a href="#s13"><span class="n">13</span>Open gaps</a></li><li><a href="#s14"><span class="n">14</span>Adoption</a></li><li><a href="#s15"><span class="n">15</span>Change log</a></li><li><a href="#s16"><span class="n">16</span>Open questions</a></li><li><a href="#s17"><span class="n">17</span>Taxonomy artifacts</a></li><li><a href="#s18"><span class="n">18</span>Composition with the sibling standards</a></li><li><a href="#s20"><span class="n">20</span>The Railiance interaction boundary</a></li></ol></nav><main><section id="s1"><h2><span class="sn">01</span>Purpose</h2>
+<div class="wrap"><header><div class="eyebrow"><span>netkingdom-security-layer-model-v0.7</span> <span class="stat">accepted</span> <span>gate-house</span> <span>reviewed 2026-08-28</span><span>generated from canonical source — do not edit</span></div><h1>NetKingdom Security Layer Model v0.7</h1><p class="sub">Source: <code>net-kingdom · canon/standards/security-layer-model_v0.7.md · 9781102e2971d762ae42fdd5085a6647afd1cd66</code></p><p class="sub">Review due: 2026-11-28</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#s1"><span class="n">1</span>Purpose</a></li><li><a href="#s2"><span class="n">2</span>Authority and conformance</a></li><li><a href="#s3"><span class="n">3</span>The layers</a></li><li><a href="#s4"><span class="n">4</span>Layer catalog</a></li><li><a href="#s5"><span class="n">5</span>The binding rule</a></li><li><a href="#s6"><span class="n">6</span>One decision point</a></li><li><a href="#s7"><span class="n">7</span>Relationship to the Active Secrets Management Canon</a></li><li><a href="#s8"><span class="n">8</span>Vocabulary demarcations</a></li><li><a href="#s9"><span class="n">9</span>Capability assignment</a></li><li><a href="#s10"><span class="n">10</span>Changing layer</a></li><li><a href="#s11"><span class="n">11</span>Conformance</a></li><li><a href="#s12"><span class="n">12</span>The conformance loop</a></li><li><a href="#s13"><span class="n">13</span>Open gaps</a></li><li><a href="#s14"><span class="n">14</span>Adoption</a></li><li><a href="#s15"><span class="n">15</span>Change log</a></li><li><a href="#s16"><span class="n">16</span>Open questions</a></li><li><a href="#s17"><span class="n">17</span>Taxonomy artifacts</a></li><li><a href="#s18"><span class="n">18</span>Composition with the sibling standards</a></li><li><a href="#s20"><span class="n">20</span>The Railiance interaction boundary</a></li></ol></nav><main><section id="s1"><h2><span class="sn">01</span>Purpose</h2>
 <p>This standard states how NetKingdom's IT-security estate is layered, and what each layer may and may not do. It answers one question:</p>
 <div class="rule-quote"><p><strong>Given a repository, which layer is it in, and what does that permit it to own?</strong></p></div>
 <p>The layers are distinguished by <strong>determinism</strong> and by <strong>the kind of artifact the layer produces</strong>, not by technical tier, deployment topology, or team.</p>
@ -458,4 +458,4 @@ Taxonomy    cross-cutting language</pre>
 <ul><li>A <strong><code>rapp-*</code></strong> is the most likely <em>resource</em> a decision is rendered about, but nothing states its identity form in a request claim.</li><li>A <strong><code>rail-*</code></strong> describes how a workload runs and is therefore where PEP shape is most likely to live — but §6.4 obligations attach to repositories, and a rail is a contract, so whether a rail can <em>carry</em> an obligation is unwritten.</li><li>A <strong><code>reef-*</code></strong> answers where a workload is bound, which is adjacent to a security zone (<code>security-zones_v0.1</code>) without being one. <code>zone-engine</code> records that a reef capping availability for everything bound to it is a canon composition problem. That composition is unwritten.</li><li>The <strong><code>railiance-*</code> ownership axis</strong> names who owns a capability, which is adjacent to the principal a decision is rendered for. Adjacent is not equal, and no rule connects them.</li><li><strong><code>glas-harness</code> and reins</strong> hold tool policy and session semantics for agents, while §3.4 rule 2 holds that an agent acts only through a conduit or an engine API. Those two must compose, and neither side may treat its own half as sufficient. That seam is the most consequential of the five, because it is where "tool availability is not permission" is actually enforced or lost.</li></ul>
 <h3>20.4 How this boundary changes</h3>
 <p>An interaction boundary between two frameworks is owned by neither alone. Changes to §20 require assent from <code>railiance-master</code> for the axis definitions and from <code>glas-harness</code> for the session and tool-policy seam, on the same terms as any other boundary in this standard (§10). NetKingdom states what a consumer owes; it does not define what a rail, rapp, reef, or rein <em>is</em>.</p>
-</section><footer><span>netkingdom-security-layer-model-v0.7 ·  · accepted</span><span>net-kingdom · canon/standards/security-layer-model_v0.7.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3</span></footer></main></div></div></html>
+</section><footer><span>netkingdom-security-layer-model-v0.7 ·  · accepted</span><span>net-kingdom · canon/standards/security-layer-model_v0.7.md · 9781102e2971d762ae42fdd5085a6647afd1cd66</span></footer></main></div></div></html>
--- a/build/standards/security-scenario-composition/v0.1/index.html
+++ b/build/standards/security-scenario-composition/v0.1/index.html
@ -1,6 +1,6 @@
 <!doctype html>
 <html lang="en"><meta charset="utf-8">
-<meta name="policy-source-revision" content="d4e57e63126d2cca1d381c025170e4b1f678c3f3">
+<meta name="policy-source-revision" content="9781102e2971d762ae42fdd5085a6647afd1cd66">
 <meta name="policy-source-digest" content="17b715d78e04470a0f83b8bc8c7313ab16e13e9e741d5ec445172d9008fce937">
 <title>NetKingdom Security Scenario Composition v0.1</title>
 <style>
@ -191,7 +191,7 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
@media (prefers-reduced-motion:reduce){*{animation:none!important;transition:none!important}}

 </style>
-<div class="wrap"><header><div class="eyebrow"><span>netkingdom-security-scenario-composition-v0.1</span> <span class="stat">proposed</span> <span>net-kingdom</span> <span>reviewed 2026-08-23</span><span>generated from canonical source — do not edit</span></div><h1>NetKingdom Security Scenario Composition v0.1</h1><p class="sub">Source: <code>net-kingdom · canon/standards/security-scenario-composition_v0.1.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3</code></p><p class="sub">Review due: 2026-11-23</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#s1"><span class="n">1</span>Purpose</a></li><li><a href="#s2"><span class="n">2</span>Authority boundary</a></li><li><a href="#s3"><span class="n">3</span>Scenario input</a></li><li><a href="#s4"><span class="n">4</span>Fail-closed selection rules</a></li><li><a href="#s5"><span class="n">5</span>Trust sequencing</a></li><li><a href="#s6"><span class="n">6</span>Composition output</a></li><li><a href="#s7"><span class="n">7</span>Conformance</a></li></ol></nav><main><section id="s1"><h2><span class="sn">01</span>Purpose</h2>
+<div class="wrap"><header><div class="eyebrow"><span>netkingdom-security-scenario-composition-v0.1</span> <span class="stat">proposed</span> <span>net-kingdom</span> <span>reviewed 2026-08-23</span><span>generated from canonical source — do not edit</span></div><h1>NetKingdom Security Scenario Composition v0.1</h1><p class="sub">Source: <code>net-kingdom · canon/standards/security-scenario-composition_v0.1.md · 9781102e2971d762ae42fdd5085a6647afd1cd66</code></p><p class="sub">Review due: 2026-11-23</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#s1"><span class="n">1</span>Purpose</a></li><li><a href="#s2"><span class="n">2</span>Authority boundary</a></li><li><a href="#s3"><span class="n">3</span>Scenario input</a></li><li><a href="#s4"><span class="n">4</span>Fail-closed selection rules</a></li><li><a href="#s5"><span class="n">5</span>Trust sequencing</a></li><li><a href="#s6"><span class="n">6</span>Composition output</a></li><li><a href="#s7"><span class="n">7</span>Conformance</a></li></ol></nav><main><section id="s1"><h2><span class="sn">01</span>Purpose</h2>
 <p>This contract defines the deterministic, plan-only boundary between a requested NetKingdom capability set and the independently owned playbook entry points that can realize it. It consumes conformant Playbook Capability Contract v0.1 declarations and produces an owner-routed responsibility, trust, parameter, and readiness handoff.</p>
 <p>Composition answers <strong>what is selected, in which trust order, with which safe parameters, and who must execute and evidence it</strong>. It does not run a playbook, mint a credential, infer authority, or declare a runtime ready.</p>
 </section>
@ -236,4 +236,4 @@ parameter_overrides:
 <pre>python3 tools/security-scenario-composer/security_scenario_composer.py \
  --scenario &lt;scenario.yaml&gt; &lt;declaration.yaml&gt; [&lt;declaration.yaml&gt; ...]</pre>
 <p>Exit zero means the declarations and scenario compose deterministically. It does not mean the plan was executed or its readiness evidence was observed.</p>
-</section><footer><span>netkingdom-security-scenario-composition-v0.1 ·  · proposed</span><span>net-kingdom · canon/standards/security-scenario-composition_v0.1.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3</span></footer></main></div></div></html>
+</section><footer><span>netkingdom-security-scenario-composition-v0.1 ·  · proposed</span><span>net-kingdom · canon/standards/security-scenario-composition_v0.1.md · 9781102e2971d762ae42fdd5085a6647afd1cd66</span></footer></main></div></div></html>
--- a/build/standards/security-zones/v0.1/index.html
+++ b/build/standards/security-zones/v0.1/index.html
@ -1,6 +1,6 @@
 <!doctype html>
 <html lang="en"><meta charset="utf-8">
-<meta name="policy-source-revision" content="d4e57e63126d2cca1d381c025170e4b1f678c3f3">
+<meta name="policy-source-revision" content="9781102e2971d762ae42fdd5085a6647afd1cd66">
 <meta name="policy-source-digest" content="32e71e9c0d6946bb14099eb66193822da26f199de0e11d8488464207f3bd9906">
 <title>NetKingdom Security Zones v0.1</title>
 <style>
@ -191,7 +191,7 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
@media (prefers-reduced-motion:reduce){*{animation:none!important;transition:none!important}}

 </style>
-<div class="wrap"><header><div class="eyebrow"><span>netkingdom-security-zones-v0.1</span> <span class="stat">proposed</span> <span>zone-engine</span> <span>reviewed 2026-08-22</span><span>generated from canonical source — do not edit</span></div><h1>NetKingdom Security Zones v0.1</h1><p class="sub">Source: <code>net-kingdom · canon/standards/security-zones_v0.1.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3</code></p><p class="sub">Review due: 2026-11-22</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#s1"><span class="n">1</span>Purpose</a></li><li><a href="#s2"><span class="n">2</span>Authority and conformance</a></li><li><a href="#s3"><span class="n">3</span>Resolution is authoritative</a></li><li><a href="#s4"><span class="n">4</span>Zone catalog</a></li><li><a href="#s5"><span class="n">5</span>Stance and failure-mode model</a></li><li><a href="#s6"><span class="n">6</span>Declaration in `tenancy.yaml`</a></li><li><a href="#s7"><span class="n">7</span>Compilation and resolved view</a></li><li><a href="#s8"><span class="n">8</span>Membership-change observability</a></li><li><a href="#s9"><span class="n">9</span>Time-boxed exceptions</a></li><li><a href="#s10"><span class="n">10</span>Adoption</a></li></ol></nav><main><section id="s1"><h2><span class="sn">01</span>Purpose</h2>
+<div class="wrap"><header><div class="eyebrow"><span>netkingdom-security-zones-v0.1</span> <span class="stat">proposed</span> <span>zone-engine</span> <span>reviewed 2026-08-22</span><span>generated from canonical source — do not edit</span></div><h1>NetKingdom Security Zones v0.1</h1><p class="sub">Source: <code>net-kingdom · canon/standards/security-zones_v0.1.md · 9781102e2971d762ae42fdd5085a6647afd1cd66</code></p><p class="sub">Review due: 2026-11-22</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#s1"><span class="n">1</span>Purpose</a></li><li><a href="#s2"><span class="n">2</span>Authority and conformance</a></li><li><a href="#s3"><span class="n">3</span>Resolution is authoritative</a></li><li><a href="#s4"><span class="n">4</span>Zone catalog</a></li><li><a href="#s5"><span class="n">5</span>Stance and failure-mode model</a></li><li><a href="#s6"><span class="n">6</span>Declaration in `tenancy.yaml`</a></li><li><a href="#s7"><span class="n">7</span>Compilation and resolved view</a></li><li><a href="#s8"><span class="n">8</span>Membership-change observability</a></li><li><a href="#s9"><span class="n">9</span>Time-boxed exceptions</a></li><li><a href="#s10"><span class="n">10</span>Adoption</a></li></ol></nav><main><section id="s1"><h2><span class="sn">01</span>Purpose</h2>
 <p>A security zone is a named workload-admission standard. It answers which scrutiny a workload has qualified for; control-owner policy then answers what a particular control does in that zone. A zone is not a repository label, a credential lane, a network segment, a reef, or a temporary exception.</p>
 <p>This standard is a sibling of <code>tenancy-posture_v0.1</code>. It owns zone identity, membership, admission, resolution, and the time-boxed exception lifecycle. <code>flex-auth</code> remains the only PDP for decisions it renders. Every other control continues to be owned and evaluated at its existing enforcement point.</p>
 </section>
@ -317,4 +317,4 @@ controls:
 <p>Net-kingdom published this standard at revision <code>337484a</code>. Adoption requires:</p>
 <ol><li>flex-auth and ops-warden accept the initial control profile or publish a versioned replacement with total zone and <code>unknown</code> coverage;</li><li>at least two workload owners declare authoritative identities and zones;</li><li>a third consumer compiles or reads the resolved view; and</li><li>ops-warden retires <code>policy.enabled</code> and the dormant <code>trust_zone</code> constant in the same migration.</li></ol>
 <p>All four gates were met on 2026-08-22. The owning zone-engine repository records the exact consumer revisions, tests, resolved membership digests, and live caller decision in <code>docs/evidence/security-zone-adoption-2026-08-22.md</code>.</p>
-</section><footer><span>netkingdom-security-zones-v0.1 ·  · proposed</span><span>net-kingdom · canon/standards/security-zones_v0.1.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3</span></footer></main></div></div></html>
+</section><footer><span>netkingdom-security-zones-v0.1 ·  · proposed</span><span>net-kingdom · canon/standards/security-zones_v0.1.md · 9781102e2971d762ae42fdd5085a6647afd1cd66</span></footer></main></div></div></html>
--- a/build/standards/tenancy-posture/v0.1/index.html
+++ b/build/standards/tenancy-posture/v0.1/index.html
@ -1,6 +1,6 @@
 <!doctype html>
 <html lang="en"><meta charset="utf-8">
-<meta name="policy-source-revision" content="d4e57e63126d2cca1d381c025170e4b1f678c3f3">
+<meta name="policy-source-revision" content="9781102e2971d762ae42fdd5085a6647afd1cd66">
 <meta name="policy-source-digest" content="27d6878c68310619877de516000d9af78d5456a92572a709884ed052d765b876">
 <title>NetKingdom Tenancy Posture v0.1</title>
 <style>
@ -191,7 +191,7 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
@media (prefers-reduced-motion:reduce){*{animation:none!important;transition:none!important}}

 </style>
-<div class="wrap"><header><div class="eyebrow"><span>netkingdom-tenancy-posture</span> <span class="stat">proposed · draft-14</span> <span>net-kingdom</span> <span>reviewed 2026-08-23</span><span>generated from canonical source — do not edit</span></div><h1>NetKingdom Tenancy Posture v0.1</h1><p class="sub">A framework for describing, holding and improving multi-tenancy — including where we are not there yet.</p><p class="sub">Source: <code>net-kingdom · canon/standards/tenancy-posture_v0.1.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3</code></p><p class="sub">Review due: 2027-02-23</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#status"><span class="n">·</span>Status</a></li><li><a href="#s0"><span class="n">0</span>Terminology: axes, not planes</a></li><li><a href="#s1"><span class="n">1</span>Context</a></li><li><a href="#s2"><span class="n">2</span>What this document is</a></li><li><a href="#s3"><span class="n">3</span>Six orthogonal axes</a></li><li><a href="#s4"><span class="n">4</span>Graduated levels</a></li><li><a href="#s5"><span class="n">5</span>The posture vector</a></li><li><a href="#s6"><span class="n">6</span>Conformance is accuracy, not altitude</a></li><li><a href="#s7"><span class="n">7</span>Portability across placement levels</a></li><li><a href="#s8"><span class="n">8</span>Placement triggers</a></li><li><a href="#s9"><span class="n">9</span>Credentials as a tenancy control</a></li><li><a href="#s10"><span class="n">10</span>Blast radius must be published</a></li><li><a href="#s11"><span class="n">11</span>Commercial expression</a></li><li><a href="#s12"><span class="n">12</span>Methodology — analyze, establish, improve, guard</a></li><li><a href="#s13"><span class="n">13</span>Evidence per level</a></li><li><a href="#s14"><span class="n">14</span>Adoption stance — structure, not tooling</a></li><li><a href="#s15"><span class="n">15</span>Alternatives considered</a></li><li><a href="#s16"><span class="n">16</span>Held against outside practice</a></li><li><a href="#s17"><span class="n">17</span>Scaling demands</a></li><li><a href="#s18"><span class="n">18</span>Consequences</a></li><li><a href="#s19"><span class="n">19</span>Review resolutions and residual questions</a></li><li><a href="#s20"><span class="n">20</span>Ratification path</a></li></ol></nav><main><section id="status"><h2>Status</h2>
+<div class="wrap"><header><div class="eyebrow"><span>netkingdom-tenancy-posture</span> <span class="stat">proposed · draft-14</span> <span>net-kingdom</span> <span>reviewed 2026-08-23</span><span>generated from canonical source — do not edit</span></div><h1>NetKingdom Tenancy Posture v0.1</h1><p class="sub">A framework for describing, holding and improving multi-tenancy — including where we are not there yet.</p><p class="sub">Source: <code>net-kingdom · canon/standards/tenancy-posture_v0.1.md · 9781102e2971d762ae42fdd5085a6647afd1cd66</code></p><p class="sub">Review due: 2027-02-23</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#status"><span class="n">·</span>Status</a></li><li><a href="#s0"><span class="n">0</span>Terminology: axes, not planes</a></li><li><a href="#s1"><span class="n">1</span>Context</a></li><li><a href="#s2"><span class="n">2</span>What this document is</a></li><li><a href="#s3"><span class="n">3</span>Six orthogonal axes</a></li><li><a href="#s4"><span class="n">4</span>Graduated levels</a></li><li><a href="#s5"><span class="n">5</span>The posture vector</a></li><li><a href="#s6"><span class="n">6</span>Conformance is accuracy, not altitude</a></li><li><a href="#s7"><span class="n">7</span>Portability across placement levels</a></li><li><a href="#s8"><span class="n">8</span>Placement triggers</a></li><li><a href="#s9"><span class="n">9</span>Credentials as a tenancy control</a></li><li><a href="#s10"><span class="n">10</span>Blast radius must be published</a></li><li><a href="#s11"><span class="n">11</span>Commercial expression</a></li><li><a href="#s12"><span class="n">12</span>Methodology — analyze, establish, improve, guard</a></li><li><a href="#s13"><span class="n">13</span>Evidence per level</a></li><li><a href="#s14"><span class="n">14</span>Adoption stance — structure, not tooling</a></li><li><a href="#s15"><span class="n">15</span>Alternatives considered</a></li><li><a href="#s16"><span class="n">16</span>Held against outside practice</a></li><li><a href="#s17"><span class="n">17</span>Scaling demands</a></li><li><a href="#s18"><span class="n">18</span>Consequences</a></li><li><a href="#s19"><span class="n">19</span>Review resolutions and residual questions</a></li><li><a href="#s20"><span class="n">20</span>Ratification path</a></li></ol></nav><main><section id="status"><h2>Status</h2>
 <p><strong>Proposed, draft-13; ratification-ready.</strong> Relocated from <code>the-custodian/canon/architecture</code> on 2026-08-17: multi-tenancy is part of the IT-security framework NetKingdom provides, so this framework belongs in NetKingdom canon beside the IAM Profile and the tenant-engine boundary contract, not in the work-factory canon.</p>
 <ul><li><strong>draft-1</strong> proposed a single model with fixed characteristics. Rejected: it could not describe a repo that is not there yet.</li><li><strong>draft-2</strong> reframed to graduated levels per axis. Externally corroborated (§16), but four of its statements were wrong and one thing it needed was missing.</li><li><strong>draft-3</strong> applied those corrections, added the retention axis, and recorded an adoption stance.</li><li><strong>draft-4</strong> closed the two gaps draft-3 left open: <code>R4</code> had no mechanism beyond waiting, and the noisy-neighbour evidence artifact asserted something shared infrastructure cannot provide.</li><li><strong>draft-5</strong> relocated to NetKingdom and renamed the dimensions from <em>planes</em> to <em>axes</em>, because the word was already taken (§0).</li><li><strong>draft-6</strong> applied <code>tenant-engine</code>'s review: five changes, including an axis that did not fit its data shape.</li><li><strong>draft-7</strong> applies <code>audit-core</code>, <code>railiance-platform</code> and <code>flex-auth</code>. Eleven further changes, two of them corrections to statements this document made as fact about other repos. <strong>Every posture I guessed was too generous, on every repo that has now self-reported.</strong></li><li><strong>draft-8</strong> applies <code>adaptive-pricing</code>'s review, the last of the six, and the consistency review across all declarations. It adds the missing availability axis, a canonical declaration schema, explicit authority for tier assurance, retention/placement coupling, downgrade propagation, and honest sanctioned customer language. It also corrects the distinction between an implemented control and an evidenced current level.</li></ul>
 <ul><li><strong>draft-9</strong> answers <code>zone-engine</code>'s <code>ZONE-WP-0001-T01</code>. It rules that enforcement stance is <strong>not</strong> a seventh axis (Decision 5.6) while reserving <code>zones:</code> in <code>tenancy.yaml</code> so the estate keeps one declaration surface, and it records the reef/<code>P</code>/<code>V</code> reconciliation as an open defect of this document rather than of the repo that noticed it (Decision 8.4).</li><li><strong>draft-10</strong> answers <code>zone-engine</code>'s <code>ZONE-WP-0001-T03</code>. It keeps the workload as the sole security-zone policy subject, makes operational and control-plane execution units part of that term, and requires unresolved workload identity or membership to remain <code>unknown</code> without zone inference (Decision 5.6.1). It also closes the textual reef/<code>P</code> boundary while leaving the substrate-provider declaration and mechanical <code>V</code> join as implementation work (Decision 8.4.2).</li><li><strong>draft-11</strong> makes that ruling declarable. A <code>zones:</code> block now requires an authoritative <code>workload_identity</code> beside it, including for non-<code>rapp</code> operational workloads; multi-service files carry both per service. Missing identity remains absence rather than a guessed join (Decision 5.6.2).</li><li><strong>draft-12</strong> reconciles that declaration with RMGR-ADR-004 and the published <code>security-zones_v0.1</code> proposal. Managed deployables use their authoritative rapp declaration and the exact Repo Manager reference tuple; independently governed operational execution units that are not managed deployables may declare locally. Native actions, actors, lanes, patterns, and resources are explicitly <code>not-applicable</code>, while omitted or unresolved workload references remain <code>unknown</code> (Decision 5.6.2).</li><li><strong>draft-13</strong> advances the <code>audit-core</code> worked example from E1 to E2 after bounded adversarial run <code>WH-ENG-20260822-AUDIT-E2-03</code> supplied the artifact required by §13.2. The claim remains explicitly bounded and freshness-dated: the attempted cross-tenant attacks did not work; this is not a universal isolation proof.</li><li><strong>draft-14</strong> makes evidence freshness and remediation ownership declarable. Adversarial evidence may now carry its observation and expiry timestamps, bounded scope, responsible repository, and replacement action. A separate proposal-only evaluator treats absent authoritative owner or freshness as <code>unknown</code>; it does not infer either or mutate the declared posture.</li></ul>
@ -493,4 +493,4 @@ per consumer:     14 connections (12 runtime + 2 migration)</pre>
 </section>
 <section id="s20"><h2><span class="sn">20</span>Ratification path</h2>
 <ol><li>Reviewed by <code>tenant-engine</code>, <code>flex-auth</code>, <code>audit-core</code>, <code>rapp-postgres</code>, <code>railiance-platform</code> and <code>adaptive-pricing</code> against §19. <strong>Complete in draft-8.</strong></li><li>Each publishes its own posture vector (§5) as part of review. <strong>The framework is validated by whether it can describe them accurately</strong> — if a repo cannot express itself in these six ladders, the ladders are wrong and this document changes, not the repo. <strong>Complete in draft-8; all six root declarations validate against the canonical schema.</strong></li><li>On acceptance, <strong>supersedes</strong> the routing of <code>rapp-postgres/docs/canon-drafts/shared-platform-relational-storage_v0.1-draft.md</code>, whose §§3–8 are absorbed here. That draft is withdrawn rather than left pending.</li><li>On acceptance, <code>rapp-postgres</code> ADR-0001 through ADR-0004 move to <code>accepted</code> and are annotated as the PostgreSQL implementation of the E, P, R and shared-capacity rules.</li></ol>
-</section><footer><span>netkingdom-tenancy-posture · draft-14 · proposed</span><span>net-kingdom · canon/standards/tenancy-posture_v0.1.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3</span></footer></main></div></div></html>
+</section><footer><span>netkingdom-tenancy-posture · draft-14 · proposed</span><span>net-kingdom · canon/standards/tenancy-posture_v0.1.md · 9781102e2971d762ae42fdd5085a6647afd1cd66</span></footer></main></div></div></html>
--- a/build/standards/work-record-types/v0.1/index.html
+++ b/build/standards/work-record-types/v0.1/index.html
@ -1,6 +1,6 @@
 <!doctype html>
 <html lang="en"><meta charset="utf-8">
-<meta name="policy-source-revision" content="4b951be3947f9457cc091a7d359d9232646b4c93">
+<meta name="policy-source-revision" content="f9435cd605cc5b3cb0f2e957ce6287d9f3129aac">
 <meta name="policy-source-digest" content="1a40de294be332ee713cdaab532a32a83718f3952c339fbff835ecee899a8dbc">
 <title>Work Record Types &amp; Identity (Fleet) v0.1</title>
 <style>
@ -191,7 +191,7 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
@media (prefers-reduced-motion:reduce){*{animation:none!important;transition:none!important}}

 </style>
-<div class="wrap"><header><div class="eyebrow"><span>canon-work-record-types</span> <span class="stat">accepted · accepted-1</span> <span>the-custodian</span> <span>reviewed 2026-08-31</span><span>generated from canonical source — do not edit</span></div><h1>Work Record Types &amp; Identity (Fleet) v0.1</h1><p class="sub">Source: <code>the-custodian · canon/standards/work-record-types_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93</code></p><p class="sub">Review due: 2027-02-28</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#purpose"><span class="n">·</span>Purpose</a></li><li><a href="#core-definition"><span class="n">·</span>Core definition</a></li><li><a href="#kind-registry-closed-list"><span class="n">·</span>Kind registry (closed list)</a></li><li><a href="#identity-layering"><span class="n">·</span>Identity layering</a></li><li><a href="#abstract-lifecycles-canon-fixed-minimal"><span class="n">·</span>Abstract lifecycles (canon-fixed, minimal)</a></li><li><a href="#residuals-role-not-kind"><span class="n">·</span>Residuals (role, not kind)</a></li><li><a href="#source-files-index-and-views"><span class="n">·</span>Source files, index, and views</a></li><li><a href="#tags"><span class="n">·</span>Tags</a></li><li><a href="#budgets"><span class="n">·</span>Budgets</a></li><li><a href="#reconciliation-loop-normative"><span class="n">·</span>Reconciliation loop (normative)</a></li><li><a href="#references"><span class="n">·</span>References</a></li></ol></nav><main><div class="rule-quote"><p>Ratified by founder 2026-07-20 (CUST-WP-0060-T01, hub decision f4640f9e). Source: <code>research/WorkOrchestrationArchitectureDraft.md</code> v0.2 (founder-reviewed 2026-07-20). Extends — does not replace — <code>workplan-terminology-fleet_v0.1.md</code> and ADR-001/ADR-005.</p></div>
+<div class="wrap"><header><div class="eyebrow"><span>canon-work-record-types</span> <span class="stat">accepted · accepted-1</span> <span>the-custodian</span> <span>reviewed 2026-08-31</span><span>generated from canonical source — do not edit</span></div><h1>Work Record Types &amp; Identity (Fleet) v0.1</h1><p class="sub">Source: <code>the-custodian · canon/standards/work-record-types_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac</code></p><p class="sub">Review due: 2027-02-28</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#purpose"><span class="n">·</span>Purpose</a></li><li><a href="#core-definition"><span class="n">·</span>Core definition</a></li><li><a href="#kind-registry-closed-list"><span class="n">·</span>Kind registry (closed list)</a></li><li><a href="#identity-layering"><span class="n">·</span>Identity layering</a></li><li><a href="#abstract-lifecycles-canon-fixed-minimal"><span class="n">·</span>Abstract lifecycles (canon-fixed, minimal)</a></li><li><a href="#residuals-role-not-kind"><span class="n">·</span>Residuals (role, not kind)</a></li><li><a href="#source-files-index-and-views"><span class="n">·</span>Source files, index, and views</a></li><li><a href="#tags"><span class="n">·</span>Tags</a></li><li><a href="#budgets"><span class="n">·</span>Budgets</a></li><li><a href="#reconciliation-loop-normative"><span class="n">·</span>Reconciliation loop (normative)</a></li><li><a href="#references"><span class="n">·</span>References</a></li></ol></nav><main><div class="rule-quote"><p>Ratified by founder 2026-07-20 (CUST-WP-0060-T01, hub decision f4640f9e). Source: <code>research/WorkOrchestrationArchitectureDraft.md</code> v0.2 (founder-reviewed 2026-07-20). Extends — does not replace — <code>workplan-terminology-fleet_v0.1.md</code> and ADR-001/ADR-005.</p></div>
 <section id="purpose"><h2>Purpose</h2>
 <p>Define <strong>work record</strong> as the umbrella term for every identified, lifecycle-bearing coordination artefact in the fleet; register the closed list of work-record <strong>kinds</strong>, their id schemes and abstract lifecycles; and fix the two-layer identity rule. This is the backbone convention for all work — planning, development, testing, operations, security &amp; compliance, controlling, billing, marketing, sales — under one conceptual framework (different demands are met by flow profiles and kind-specific fields, never by parallel ontologies).</p>
 </section>
@ -243,4 +243,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
 </section>
 <section id="references"><h2>References</h2>
 <ul><li><code>research/WorkOrchestrationArchitectureDraft.md</code> (v0.2)</li><li><code>research/2026-07-19-work-orchestration-infrastructure-survey.md</code></li><li><code>research/2026-07-19-work-orchestration-best-practices.md</code></li><li><code>canon/architecture/adr-001-workplans-as-repo-artefacts.md</code>, <code>adr-005-…</code></li><li><code>canon/standards/workplan-terminology-fleet_v0.1.md</code></li><li><code>canon/standards/autonomy-lanes_v0.1.md</code></li><li><code>state-hub/docs/task-flow-engine-spec.md</code></li></ul>
-</section><footer><span>canon-work-record-types · accepted-1 · accepted</span><span>the-custodian · canon/standards/work-record-types_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93</span></footer></main></div></div></html>
+</section><footer><span>canon-work-record-types · accepted-1 · accepted</span><span>the-custodian · canon/standards/work-record-types_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac</span></footer></main></div></div></html>
--- a/build/standards/workplan-terminology/v0.1/index.html
+++ b/build/standards/workplan-terminology/v0.1/index.html
@ -1,6 +1,6 @@
 <!doctype html>
 <html lang="en"><meta charset="utf-8">
-<meta name="policy-source-revision" content="4b951be3947f9457cc091a7d359d9232646b4c93">
+<meta name="policy-source-revision" content="f9435cd605cc5b3cb0f2e957ce6287d9f3129aac">
 <meta name="policy-source-digest" content="199812632ac342ca3231498e545e3701e10c191ca144035b36a23c1a0b717712">
 <title>Workplan Terminology (Fleet) v0.1</title>
 <style>
@ -191,7 +191,7 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
@media (prefers-reduced-motion:reduce){*{animation:none!important;transition:none!important}}

 </style>
-<div class="wrap"><header><div class="eyebrow"><span>canon-workplan-terminology-fleet</span> <span class="stat">accepted · accepted-1</span> <span>the-custodian</span> <span>reviewed 2026-08-31</span><span>generated from canonical source — do not edit</span></div><h1>Workplan Terminology (Fleet) v0.1</h1><p class="sub">Source: <code>the-custodian · canon/standards/workplan-terminology-fleet_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93</code></p><p class="sub">Review due: 2027-02-28</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#purpose"><span class="n">·</span>Purpose</a></li><li><a href="#canonical-term"><span class="n">·</span>Canonical term</a></li><li><a href="#work-record-umbrella-v0-2-addendum-cust-wp-0060"><span class="n">·</span>Work-record umbrella (v0.2 addendum, CUST-WP-0060)</a></li><li><a href="#legacy-bridges-keep-until-retired"><span class="n">·</span>Legacy bridges (keep until retired)</a></li><li><a href="#event-subjects-normative"><span class="n">·</span>Event subjects (normative)</a></li><li><a href="#agent-and-documentation-rules"><span class="n">·</span>Agent and documentation rules</a></li><li><a href="#retirement-rule-unchanged"><span class="n">·</span>Retirement rule (unchanged)</a></li><li><a href="#verification"><span class="n">·</span>Verification</a></li><li><a href="#out-of-scope-this-standard"><span class="n">·</span>Out of scope (this standard)</a></li><li><a href="#references"><span class="n">·</span>References</a></li></ol></nav><main><section id="purpose"><h2>Purpose</h2>
+<div class="wrap"><header><div class="eyebrow"><span>canon-workplan-terminology-fleet</span> <span class="stat">accepted · accepted-1</span> <span>the-custodian</span> <span>reviewed 2026-08-31</span><span>generated from canonical source — do not edit</span></div><h1>Workplan Terminology (Fleet) v0.1</h1><p class="sub">Source: <code>the-custodian · canon/standards/workplan-terminology-fleet_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac</code></p><p class="sub">Review due: 2027-02-28</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#purpose"><span class="n">·</span>Purpose</a></li><li><a href="#canonical-term"><span class="n">·</span>Canonical term</a></li><li><a href="#work-record-umbrella-v0-2-addendum-cust-wp-0060"><span class="n">·</span>Work-record umbrella (v0.2 addendum, CUST-WP-0060)</a></li><li><a href="#legacy-bridges-keep-until-retired"><span class="n">·</span>Legacy bridges (keep until retired)</a></li><li><a href="#event-subjects-normative"><span class="n">·</span>Event subjects (normative)</a></li><li><a href="#agent-and-documentation-rules"><span class="n">·</span>Agent and documentation rules</a></li><li><a href="#retirement-rule-unchanged"><span class="n">·</span>Retirement rule (unchanged)</a></li><li><a href="#verification"><span class="n">·</span>Verification</a></li><li><a href="#out-of-scope-this-standard"><span class="n">·</span>Out of scope (this standard)</a></li><li><a href="#references"><span class="n">·</span>References</a></li></ol></nav><main><section id="purpose"><h2>Purpose</h2>
 <p>Define <strong>workplan</strong> as the canonical fleet term for repo-backed deliverable work indexed by State Hub. Preserve explicit <strong>legacy bridges</strong> where APIs, events, generated fields, or historical documents still say <code>workstream</code>, until metered retirement criteria are met.</p>
 <p>This standard complements:</p>
 <ul><li><strong>ADR-001</strong> — workplans originate as repo files; the hub indexes them.</li><li><strong>STATE-WP-0054</strong> — State Hub compatibility layer and <code>legacy-meter</code>.</li><li><strong>STATE-WP-0069</strong> — State Hub legacy interface retirement (child plan).</li><li><strong>CUST-WP-0055</strong> — fleet-wide coordination and prose migration.</li></ul>
@ -233,4 +233,4 @@ python tools/scan_workstream_terminology.py --repo &lt;slug&gt; --json</pre>
 </section>
 <section id="references"><h2>References</h2>
 <ul><li><code>canon/architecture/adr-001-workplans-as-repo-artefacts.md</code></li><li><code>state-hub/docs/workplan-terminology-transition.md</code></li><li><code>state-hub/workplans/STATE-WP-0054-workplan-terminology-transition-legacy-meter.md</code></li><li><code>state-hub/workplans/STATE-WP-0069-workplan-terminology-legacy-retirement.md</code></li><li><code>workplans/CUST-WP-0055-workplan-terminology-fleet-refactor.md</code></li></ul>
-</section><footer><span>canon-workplan-terminology-fleet · accepted-1 · accepted</span><span>the-custodian · canon/standards/workplan-terminology-fleet_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93</span></footer></main></div></div></html>
+</section><footer><span>canon-workplan-terminology-fleet · accepted-1 · accepted</span><span>the-custodian · canon/standards/workplan-terminology-fleet_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac</span></footer></main></div></div></html>