diff --git a/README.md b/README.md index f3f1868..01bce2d 100644 --- a/README.md +++ b/README.md @@ -3,10 +3,10 @@ Permanent publication for the estate's policy surface. Serves `policy.coulomb.social`. -This repo publishes estate **canon and architecture decision records** from -the repositories that own them, at stable URLs, with visible status and -currency. Pages are generated, never authored here: the source of truth stays -upstream and this repo never writes back. +This repo publishes estate **canon, architecture decisions, and explicitly +disclosed risk records** from the repositories that own them, at stable URLs, +with visible status and currency. Pages are generated, never authored here: +the source of truth stays upstream and this repo never writes back. Regulatory intake and disclosure decisions belong to `risk-nexus`; publishable records may arrive from it like any other source. This repo does not interpret diff --git a/build/adr/addressing-and-permanence/v1/index.html b/build/adr/addressing-and-permanence/v1/index.html index ac3df5e..110d603 100644 --- a/build/adr/addressing-and-permanence/v1/index.html +++ b/build/adr/addressing-and-permanence/v1/index.html @@ -1,6 +1,6 @@ - + Policy addressing and permanence -
policy-nexus-adr-0001 accepted · accepted-1 the-custodian reviewed 2026-08-18generated from canonical source — do not edit

Policy addressing and permanence

Source: policy-nexus · docs/adr/ADR-0001-addressing-and-permanence.md · 885c6bb1cb805b64cbcfa99dd2c5817f6d4a1373

Review due: 2027-02-18

  • Status: accepted
  • Date: 2026-08-18
  • Owner: the-custodian
+
policy-nexus-adr-0001 accepted · accepted-1 the-custodian reviewed 2026-08-18generated from canonical source — do not edit

Policy addressing and permanence

Source: policy-nexus · docs/adr/ADR-0001-addressing-and-permanence.md · 4c8a7b966600976aac595e8f49f3ef38929ccd20

Review due: 2027-02-18

  • Status: accepted
  • Date: 2026-08-18
  • Owner: the-custodian

Decision

A document has one stable current address and immutable revision addresses:

/<kind>/<document>/<version>/
@@ -211,4 +211,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

Consequences

  • Builds fail if a source disappears, an id differs, a path collides, or an immutable revision would change; stale output is not silently called fresh.
  • Pages show status, revision, owner, last review and exact source revision.
  • Availability remains restart recovery on the single-node rail. This contract promises stable addressing, not a high-availability SLA.
-
policy-nexus-adr-0001 · accepted-1 · acceptedpolicy-nexus · docs/adr/ADR-0001-addressing-and-permanence.md · 885c6bb1cb805b64cbcfa99dd2c5817f6d4a1373
+
diff --git a/build/adr/custodian-agent-runtime/v1/index.html b/build/adr/custodian-agent-runtime/v1/index.html index 40ca7c5..c73ea62 100644 --- a/build/adr/custodian-agent-runtime/v1/index.html +++ b/build/adr/custodian-agent-runtime/v1/index.html @@ -1,6 +1,6 @@ - + Custodian Agent Runtime — v0.1 Bootstrap Design -
CUST-ADR-002 accepted · accepted-1 the-custodian reviewed 2026-03-12generated from canonical source — do not edit

Custodian Agent Runtime — v0.1 Bootstrap Design

Source: the-custodian · canon/architecture/adr-002-custodian-agent-runtime-design.md · 4b951be3947f9457cc091a7d359d9232646b4c93

Review due: 2026-09-12

Status

+
CUST-ADR-002 accepted · accepted-1 the-custodian reviewed 2026-03-12generated from canonical source — do not edit

Custodian Agent Runtime — v0.1 Bootstrap Design

Source: the-custodian · canon/architecture/adr-002-custodian-agent-runtime-design.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac

Review due: 2026-09-12

Status

Accepted.

Context

@@ -239,4 +239,4 @@ Act — Execute only sanctioned write operations from the plan

Deferred

  • Async event loop / daemon mode (Phase 2)
  • RAG over canon (Phase 1 roadmap item)
  • Tool adapters beyond state-hub HTTP (planned in runtime/tool_adapters/)
  • Deployment on Railiance k3s as a scheduled CronJob
-
CUST-ADR-002 · accepted-1 · acceptedthe-custodian · canon/architecture/adr-002-custodian-agent-runtime-design.md · 4b951be3947f9457cc091a7d359d9232646b4c93
+
diff --git a/build/adr/custodian-canon-federation/v1/index.html b/build/adr/custodian-canon-federation/v1/index.html index 4bc6a00..5d4bcfe 100644 --- a/build/adr/custodian-canon-federation/v1/index.html +++ b/build/adr/custodian-canon-federation/v1/index.html @@ -1,6 +1,6 @@ - + Canon Federation and Concept Ownership Across InfoTech and Commerce -
CUST-ADR-006 accepted · accepted-1 the-custodian reviewed 2026-08-17generated from canonical source — do not edit

Canon Federation and Concept Ownership Across InfoTech and Commerce

Source: the-custodian · canon/architecture/adr-006-canon-federation-concept-ownership.md · 4b951be3947f9457cc091a7d359d9232646b4c93

Review due: 2027-02-17

Status

+
CUST-ADR-006 accepted · accepted-1 the-custodian reviewed 2026-08-17generated from canonical source — do not edit

Canon Federation and Concept Ownership Across InfoTech and Commerce

Source: the-custodian · canon/architecture/adr-006-canon-federation-concept-ownership.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac

Review due: 2027-02-17

Status

Accepted 2026-08-17. All seven ownership questions are resolved (see Resolutions); content may now move under CFED-WP-0001.

Context

@@ -250,4 +250,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

References

  • ADR-001 — workplans originate as repo files; hub is a read model
  • ADR-005 — cross-repo workplans live in dedicated project repos
  • info-tech-canon/infospace/models/organization/InfoTechCanonOrganizationModel.md:55
  • info-tech-canon/infospace/models/access-control/InfoTechCanonAccessControlModel.md:106, :214
  • info-tech-canon/infospace/models/governance/InfoTechCanonGovernanceModel.md:107
  • info-tech-canon/demand/CapabilityProvisionEconomics.md
  • identity-canon/canon/CanonicalGlossary.md, canon/DesignPrinciples.md
-
CUST-ADR-006 · accepted-1 · acceptedthe-custodian · canon/architecture/adr-006-canon-federation-concept-ownership.md · 4b951be3947f9457cc091a7d359d9232646b4c93
+
diff --git a/build/adr/custodian-connectivity-first/v1/index.html b/build/adr/custodian-connectivity-first/v1/index.html index 29979dd..c1c358d 100644 --- a/build/adr/custodian-connectivity-first/v1/index.html +++ b/build/adr/custodian-connectivity-first/v1/index.html @@ -1,6 +1,6 @@ - + Connectivity-First Network Posture for Custodian Infrastructure -
CUST-ADR-004 accepted · accepted-1 the-custodian reviewed 2026-03-26generated from canonical source — do not edit

Connectivity-First Network Posture for Custodian Infrastructure

Source: the-custodian · canon/architecture/adr-004-connectivity-first-network-posture.md · 4b951be3947f9457cc091a7d359d9232646b4c93

Review due: 2026-09-26

Status

+
CUST-ADR-004 accepted · accepted-1 the-custodian reviewed 2026-03-26generated from canonical source — do not edit

Connectivity-First Network Posture for Custodian Infrastructure

Source: the-custodian · canon/architecture/adr-004-connectivity-first-network-posture.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac

Review due: 2026-09-26

Status

Accepted.

Context

@@ -233,4 +233,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

Considered briefly. VPN would solve the connectivity problem but introduces a persistent network layer that all traffic traverses, reducing the explicitness of individual access paths. ops-bridge tunnels are per-service and per-actor, which gives better observability and blast-radius control. VPN is not ruled out as a future complement but is not the primary approach.

Ad-hoc SSH (no ops-bridge)

The pre-ops-bridge approach. Rejected because it has no health checks, no actor attribution, no audit log, and requires manual intervention to restore. ops-bridge formalises the same SSH tunnel pattern with operational discipline.

-
CUST-ADR-004 · accepted-1 · acceptedthe-custodian · canon/architecture/adr-004-connectivity-first-network-posture.md · 4b951be3947f9457cc091a7d359d9232646b4c93
+
diff --git a/build/adr/custodian-cross-repo-workplans/v1/index.html b/build/adr/custodian-cross-repo-workplans/v1/index.html index e59f533..b83e0c5 100644 --- a/build/adr/custodian-cross-repo-workplans/v1/index.html +++ b/build/adr/custodian-cross-repo-workplans/v1/index.html @@ -1,6 +1,6 @@ - + Cross-Repo Workplans Live in Dedicated Project Repos -
CUST-ADR-005 accepted · accepted-1 the-custodian reviewed 2026-06-22generated from canonical source — do not edit

Cross-Repo Workplans Live in Dedicated Project Repos

Source: the-custodian · canon/architecture/adr-005-cross-repo-workplans-project-repos.md · 4b951be3947f9457cc091a7d359d9232646b4c93

Review due: 2026-12-22

Status

+
CUST-ADR-005 accepted · accepted-1 the-custodian reviewed 2026-06-22generated from canonical source — do not edit

Cross-Repo Workplans Live in Dedicated Project Repos

Source: the-custodian · canon/architecture/adr-005-cross-repo-workplans-project-repos.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac

Review due: 2026-12-22

Status

Accepted.

Context

@@ -222,4 +222,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
CUST-ADR-005 · accepted-1 · acceptedthe-custodian · canon/architecture/adr-005-cross-repo-workplans-project-repos.md · 4b951be3947f9457cc091a7d359d9232646b4c93
+
diff --git a/build/adr/custodian-federated-namespaces/v1/index.html b/build/adr/custodian-federated-namespaces/v1/index.html index 83be492..e7d1085 100644 --- a/build/adr/custodian-federated-namespaces/v1/index.html +++ b/build/adr/custodian-federated-namespaces/v1/index.html @@ -1,6 +1,6 @@ - + Federated Namespaces -
CUST-ADR-011 proposed · draft-2 the-custodian reviewed 2026-08-17generated from canonical source — do not edit

Federated Namespaces

Source: the-custodian · canon/architecture/adr-011-federated-namespaces-and-reconciliation-limits.md · 4b951be3947f9457cc091a7d359d9232646b4c93

Review due: 2027-02-17

Status

+
CUST-ADR-011 proposed · draft-2 the-custodian reviewed 2026-08-17generated from canonical source — do not edit

Federated Namespaces

Source: the-custodian · canon/architecture/adr-011-federated-namespaces-and-reconciliation-limits.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac

Review due: 2027-02-17

Status

Proposed, draft-2. Amends ADR-007 decisions 1 and 2; extends ADR-010 decision 4; adopts the plane/ladder/posture form and the accuracy-not-altitude conformance rule from ADR-008 (Multi-Tenancy Framework).

Context

@@ -281,4 +281,4 @@ any participant below R2 -> T1 at best; manual thereafter

References

  • canon/standards/federated-organization-standard_v1.0.md — bounded autonomy, escalation, sovereignty by default, rebuildability
  • ADR-001 — workplans originate as repo files
  • ADR-007 — identifier uniqueness and derived identifiers (amended here)
  • ADR-008 — Multi-Tenancy Framework; source of the plane/ladder/posture form and the accuracy-not-altitude conformance rule
  • ADR-010 — hub authority, local cache, and the two kinds of hub data
  • CUST-WP-0058 — instance-per-client tenancy
  • SHR-INV-0001 — 425-item disposition inventory, T3 cost evidence
  • RMGR-WP-0004-T02 — rmgr conform, the guard machinery
-
CUST-ADR-011 · draft-2 · proposedthe-custodian · canon/architecture/adr-011-federated-namespaces-and-reconciliation-limits.md · 4b951be3947f9457cc091a7d359d9232646b4c93
+
diff --git a/build/adr/custodian-hub-authority/v1/index.html b/build/adr/custodian-hub-authority/v1/index.html index 3ac2bc3..4e1f7ff 100644 --- a/build/adr/custodian-hub-authority/v1/index.html +++ b/build/adr/custodian-hub-authority/v1/index.html @@ -1,6 +1,6 @@ - + Hub Authority, Local Cache, and the Two Kinds of Hub Data -
CUST-ADR-010 proposed · draft-2 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Hub Authority, Local Cache, and the Two Kinds of Hub Data

Source: the-custodian · canon/architecture/adr-010-hub-authority-and-local-cache-model.md · 4b951be3947f9457cc091a7d359d9232646b4c93

Review due: 2027-02-28

Status

+
CUST-ADR-010 proposed · draft-2 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Hub Authority, Local Cache, and the Two Kinds of Hub Data

Source: the-custodian · canon/architecture/adr-010-hub-authority-and-local-cache-model.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac

Review due: 2027-02-28

Status

Proposed, and partially superseded by ADR-012 (accepted 2026-08-25). Decisions 1, 5 and 6 are sharpened or given a mechanism there; see the notes on each below. Everything else in this ADR remains in force.

Context

@@ -250,4 +250,4 @@ same filename, different UUID 4 duplicate registration

Outcome (2026-08-28)

Added by CUST-WP-0068. The 2026-08-24 outcome closed the repository divergence. The work-record divergence this ADR originally measured — 955 local / 649 primary — remained, because the retired instance's database was still load-bearing. That is now closed.

  • Central holds 1167 workplans. Records that existed only in the cache were re-derived from their files, renamed onto the canonical scheme, or given a written disposition (docs/recovery/cache-only-disposition-2026-08-28.md).
  • No open work record exists only in the cache. Remaining cache-only slugs are aliases of recovered records, clay-borg product files (not workplans), or prefix-migration residue.
  • The cache database is discarded. Final dump ~/backups/state-hub-cache-2026-08-28.dump. Container infra-postgres-1 and volume infra_pg_data removed. Port 5432 is free.
  • The local instance is no longer load-bearing for any record type. Decision 3 is now true in operation, not only in argument.
-
CUST-ADR-010 · draft-2 · proposedthe-custodian · canon/architecture/adr-010-hub-authority-and-local-cache-model.md · 4b951be3947f9457cc091a7d359d9232646b4c93
+
diff --git a/build/adr/custodian-materialized-derived-state/v1/index.html b/build/adr/custodian-materialized-derived-state/v1/index.html index 7c6ff55..350277c 100644 --- a/build/adr/custodian-materialized-derived-state/v1/index.html +++ b/build/adr/custodian-materialized-derived-state/v1/index.html @@ -1,6 +1,6 @@ - + Materialized Derived State with Fingerprint Invalidation for Repo-Sourced Data -
CUST-ADR-003 accepted · accepted-2 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Materialized Derived State with Fingerprint Invalidation for Repo-Sourced Data

Source: the-custodian · canon/architecture/adr-003-materialized-derived-state.md · 4b951be3947f9457cc091a7d359d9232646b4c93

Review due: 2027-02-28

Status

+
CUST-ADR-003 accepted · accepted-2 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Materialized Derived State with Fingerprint Invalidation for Repo-Sourced Data

Source: the-custodian · canon/architecture/adr-003-materialized-derived-state.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac

Review due: 2027-02-28

Status

Accepted, and partially superseded by ADR-012 (accepted 2026-08-25). Decision 2's fingerprint composition is invalidated in part; decision 5's rebuild principle is given a concrete source and a required operation. See the notes on each.

Context

@@ -245,4 +245,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
CUST-ADR-003 · accepted-2 · acceptedthe-custodian · canon/architecture/adr-003-materialized-derived-state.md · 4b951be3947f9457cc091a7d359d9232646b4c93
+
diff --git a/build/adr/custodian-projection-source-overlay/v1/index.html b/build/adr/custodian-projection-source-overlay/v1/index.html index aaa371b..918af8c 100644 --- a/build/adr/custodian-projection-source-overlay/v1/index.html +++ b/build/adr/custodian-projection-source-overlay/v1/index.html @@ -1,6 +1,6 @@ - + What the Hub Projects -
CUST-ADR-012 accepted · 1.0 the-custodian reviewed 2026-08-25generated from canonical source — do not edit

What the Hub Projects

Source: the-custodian · canon/architecture/adr-012-projection-source-and-preliminary-overlay.md · 4b951be3947f9457cc091a7d359d9232646b4c93

Review due: 2027-02-25

Status

+
CUST-ADR-012 accepted · 1.0 the-custodian reviewed 2026-08-25generated from canonical source — do not edit

What the Hub Projects

Source: the-custodian · canon/architecture/adr-012-projection-source-and-preliminary-overlay.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac

Review due: 2027-02-25

Status

Accepted 2026-08-25 by Bernd Worsch. Supersedes ADR-010 decision 1's phrase "authoritative as a reading of the repositories" by making the reading concrete, and implements decision 6's unbuilt notion of "preliminary".

Context

@@ -245,4 +245,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

References

  • ADR-001 — workplans originate as repo files; hub is a read model
  • ADR-010 — hub authority, local cache, and the two kinds of hub data
  • ADR-007 — identifier uniqueness and derived identifiers
  • CUST-WP-0067 — hub target resolution; retired the impersonating local instance
  • CUST-WP-0068 — cache-only work-record recovery; surfaced the stale git_fingerprint and the duplicate registrations
  • Verification, 2026-08-25: central pod holds no repository files; sweep disabled; 117 repositories record a laptop path; the-custodian git_fingerprint is the initial commit while last_state_synced_at is current
-
CUST-ADR-012 · 1.0 · acceptedthe-custodian · canon/architecture/adr-012-projection-source-and-preliminary-overlay.md · 4b951be3947f9457cc091a7d359d9232646b4c93
+
diff --git a/build/adr/custodian-workplan-identity/v1/index.html b/build/adr/custodian-workplan-identity/v1/index.html index 80d32aa..3f80f65 100644 --- a/build/adr/custodian-workplan-identity/v1/index.html +++ b/build/adr/custodian-workplan-identity/v1/index.html @@ -1,6 +1,6 @@ - + Workplan Identity Uniqueness, Single Registrar, and Repo Worker Topology -
CUST-ADR-007 accepted · accepted-2 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Workplan Identity Uniqueness, Single Registrar, and Repo Worker Topology

Source: the-custodian · canon/architecture/adr-007-workplan-identity-and-repo-worker-topology.md · 4b951be3947f9457cc091a7d359d9232646b4c93

Review due: 2027-02-28

Status

+
CUST-ADR-007 accepted · accepted-2 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Workplan Identity Uniqueness, Single Registrar, and Repo Worker Topology

Source: the-custodian · canon/architecture/adr-007-workplan-identity-and-repo-worker-topology.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac

Review due: 2027-02-28

Status

Accepted 2026-08-17. Identifier uniqueness, the registrar model, lifecycle protection, and worker topology are settled.

Remediation of existing collisions (§ Migration) remains an open ruling. It is disruptive, touches six repositories, and no active work depends on it — all five duplicated identifiers are finished.

@@ -276,4 +276,4 @@ CUST-WP- the-custodian 50 plans

References

  • Decision 747011c6 — repository standards belong to Repo Manager
  • ADR-001 — workplans originate as repo files; hub is a read model
  • RMGR-WP-0004 — repository standards conformance and governed scaffolding
  • STATE-WP-0080 — register scaffolding handoff
  • Fleet scan 2026-08-16: 955 hub workplans, 525 parseable identifiers, 3 reused prefixes, 5 reused identifiers
-
+ diff --git a/build/adr/custodian-workplans-as-repo-artefacts/v1/index.html b/build/adr/custodian-workplans-as-repo-artefacts/v1/index.html index 77a778d..69ed1eb 100644 --- a/build/adr/custodian-workplans-as-repo-artefacts/v1/index.html +++ b/build/adr/custodian-workplans-as-repo-artefacts/v1/index.html @@ -1,6 +1,6 @@ - + Workplans and Work Items Are Repository Artefacts -
CUST-ADR-001 accepted · accepted-2 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Workplans and Work Items Are Repository Artefacts

Source: the-custodian · canon/architecture/adr-001-workplans-as-repo-artefacts.md · 4b951be3947f9457cc091a7d359d9232646b4c93

Review due: 2027-02-28

Status

+
CUST-ADR-001 accepted · accepted-2 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Workplans and Work Items Are Repository Artefacts

Source: the-custodian · canon/architecture/adr-001-workplans-as-repo-artefacts.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac

Review due: 2027-02-28

Status

Accepted 2026-02-28.

Amended 2026-08-31 to distinguish file-backed work records from hub-native records, identify the Forge default branch as the central projection baseline, and align identity, lifecycle, reconciliation, and closure with ADR-007, ADR-010, ADR-011, ADR-012, and the work-record standards. The central decision is unchanged.

@@ -254,4 +254,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
+ diff --git a/build/adr/netkingdom-iam-profile-governance/v1/index.html b/build/adr/netkingdom-iam-profile-governance/v1/index.html index f105ef2..b76ef0b 100644 --- a/build/adr/netkingdom-iam-profile-governance/v1/index.html +++ b/build/adr/netkingdom-iam-profile-governance/v1/index.html @@ -1,6 +1,6 @@ - + NetKingdom IAM Profile Ownership And Version Governance -
NK-ADR-0011 accepted · 1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

NetKingdom IAM Profile Ownership And Version Governance

Source: net-kingdom · docs/adr/ADR-0011-iam-profile-ownership-and-version-governance.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3

Review due: 2027-02-22

Status: Accepted Date: 2026-05-22 Deciders: Bernd Worsch, Codex

+
NK-ADR-0011 accepted · 1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

NetKingdom IAM Profile Ownership And Version Governance

Source: net-kingdom · docs/adr/ADR-0011-iam-profile-ownership-and-version-governance.md · 9781102e2971d762ae42fdd5085a6647afd1cd66

Review due: 2027-02-22

Status: Accepted Date: 2026-05-22 Deciders: Bernd Worsch, Codex

Context

The IAM Profile is the identity contract that applications, flex-auth, key-cape, Keycloak, and bootstrap identity tooling all target. It defines the OIDC discovery, flow, token, claim, assurance, tenant, and conformance requirements that make lightweight and expanded identity modes interchangeable at the application boundary.

A draft IAM Profile v0.1 existed in the-custodian canon with an all-hubs scope. That draft captured useful material: OIDC discovery, Authorization Code + PKCE, service-account tokens, required claims, token lifecycle, emergency access, and local-development behavior. However, NetKingdom now owns the platform identity domain. SCOPE.md names the NetKingdom IAM Profile as an in-scope, versioned standard, and ADR-0006 requires key-cape and Keycloak to be implementations of the profile rather than the canonical source of authorization semantics.

@@ -224,4 +224,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

Keycloak is the expanded-mode implementation and remains important for enterprise federation. Making it the reference provider would make lightweight mode, local bootstrap, and future identity adapters secondary to one implementation. The accepted model keeps providers interchangeable behind the profile.

Put Scope And Role Vocabulary In The Core Profile

A shared vocabulary is useful, but core identity must stay stable across applications and tenants. Downstream systems can define extension scopes and roles as long as they map to the core claim shapes and flex-auth decision inputs.

-
NK-ADR-0011 · 1 · acceptednet-kingdom · docs/adr/ADR-0011-iam-profile-ownership-and-version-governance.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3
+
diff --git a/build/adr/netkingdom-object-storage-sts-credential-vending/v1/index.html b/build/adr/netkingdom-object-storage-sts-credential-vending/v1/index.html index f19f43f..7d65305 100644 --- a/build/adr/netkingdom-object-storage-sts-credential-vending/v1/index.html +++ b/build/adr/netkingdom-object-storage-sts-credential-vending/v1/index.html @@ -1,6 +1,6 @@ - + Object Storage STS Credential Vending Boundary -
NK-ADR-0008 accepted · 1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

Object Storage STS Credential Vending Boundary

Source: net-kingdom · docs/adr/ADR-0008-object-storage-sts-credential-vending.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3

Review due: 2027-02-22

Status: Accepted Date: 2026-05-18 Deciders: Bernd Worsch, Codex

+
NK-ADR-0008 accepted · 1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

Object Storage STS Credential Vending Boundary

Source: net-kingdom · docs/adr/ADR-0008-object-storage-sts-credential-vending.md · 9781102e2971d762ae42fdd5085a6647afd1cd66

Review due: 2027-02-22

Status: Accepted Date: 2026-05-18 Deciders: Bernd Worsch, Codex

Context

NetKingdom needs a canonical pattern for issuing short-lived object-storage credentials to platform and tenant workloads. The first known consumer is artifact-store, but the pattern must work for future S3-compatible consumers without making each application repo own identity, authorization, root object-store credentials, or backend-specific STS differences.

The backend landscape is not uniform. AWS S3, Ceph RGW, and MinIO/AIStor can use web-identity STS-style flows. Cloudflare R2 exposes temporary credentials through a provider API or local signing with parent access material. OpenBao is now part of the Railiance platform stack as runtime secret authority, but it is not an identity provider or authorization policy engine.

@@ -213,4 +213,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

OpenBao is valuable for secret custody, broker configuration, leases, and audit records. Making it the policy decision point would duplicate flex-auth, blur the platform/tenant boundary, and make authorization semantics backend-specific.

Require One Backend Everywhere

A single backend would simplify implementation but does not match the platform direction. Railiance and NetKingdom need a stable security interface across AWS, self-hosted S3-compatible stores, and Cloudflare R2-like APIs.

-
NK-ADR-0008 · 1 · acceptednet-kingdom · docs/adr/ADR-0008-object-storage-sts-credential-vending.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3
+
diff --git a/build/adr/netkingdom-orchestration-dependency-intent/v1/index.html b/build/adr/netkingdom-orchestration-dependency-intent/v1/index.html index d629fe1..e55009b 100644 --- a/build/adr/netkingdom-orchestration-dependency-intent/v1/index.html +++ b/build/adr/netkingdom-orchestration-dependency-intent/v1/index.html @@ -1,6 +1,6 @@ - + Orchestration vs Dependency, and Self-Coherent Intent -
NK-ADR-0010 accepted · 1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

Orchestration vs Dependency, and Self-Coherent Intent

Source: net-kingdom · docs/adr/ADR-0010-orchestration-vs-dependency-self-coherent-intent.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3

Review due: 2027-02-22

Status: Accepted (repo classification subject to ongoing refinement) Date: 2026-05-21 Deciders: Bernd Worsch, Codex

+
NK-ADR-0010 accepted · 1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

Orchestration vs Dependency, and Self-Coherent Intent

Source: net-kingdom · docs/adr/ADR-0010-orchestration-vs-dependency-self-coherent-intent.md · 9781102e2971d762ae42fdd5085a6647afd1cd66

Review due: 2027-02-22

Status: Accepted (repo classification subject to ongoing refinement) Date: 2026-05-21 Deciders: Bernd Worsch, Codex

Context

While aligning the ecosystem's INTENT.md files, two relationships that had been blurred turned out to be fundamentally different, and a content principle for intent emerged. Both are foundational enough that future interface and boundary refinements should be measured against them.

NetKingdom performs meta-orchestration (ADR-0007): it selects, parametrizes, and assigns responsibility across an IT landscape. But "things NetKingdom meta-orchestrates" is not the same as "things NetKingdom depends on," and the two had been conflated.

@@ -218,4 +218,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

Simpler, but it conflates "manages the resources this service holds" with "uses this tool," which produces an incoherent responsibility map and tempts downstream repos to encode NetKingdom into their intent.

Record relationships inside each repo's intent

Convenient for a reader of a single repo, but it couples intents to each other and to NetKingdom, making the most-stable layer the least stable. Relationships belong in interface contracts and the responsibility map.

-
NK-ADR-0010 · 1 · acceptednet-kingdom · docs/adr/ADR-0010-orchestration-vs-dependency-self-coherent-intent.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3
+
diff --git a/build/adr/netkingdom-playbook-capability-ownership/v1/index.html b/build/adr/netkingdom-playbook-capability-ownership/v1/index.html index b88c9c2..ea05e32 100644 --- a/build/adr/netkingdom-playbook-capability-ownership/v1/index.html +++ b/build/adr/netkingdom-playbook-capability-ownership/v1/index.html @@ -1,6 +1,6 @@ - + Playbook Capability Contract Ownership -
NK-ADR-0012 accepted · 1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

Playbook Capability Contract Ownership

Source: net-kingdom · docs/adr/ADR-0012-playbook-capability-contract-ownership.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3

Review due: 2027-02-22

Status: Accepted Date: 2026-05-22 Deciders: Bernd Worsch, Codex

+
NK-ADR-0012 accepted · 1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

Playbook Capability Contract Ownership

Source: net-kingdom · docs/adr/ADR-0012-playbook-capability-contract-ownership.md · 9781102e2971d762ae42fdd5085a6647afd1cd66

Review due: 2027-02-22

Status: Accepted Date: 2026-05-22 Deciders: Bernd Worsch, Codex

Context

ADR-0007 refined NetKingdom's orchestration role into a meta-orchestration layer. NetKingdom selects the services and playbooks a scenario needs, decides which parameters may be tuned, and holds the responsibility map. Railiance remains the execution-orchestration layer: Railiance playbooks provision and converge the actual infrastructure, cluster, platform services, and application layers.

That split requires a stable interface. If a Railiance playbook only describes behavior implicitly, NetKingdom cannot safely compose it into a scenario, compare it with another playbook, or know which parameter changes are safe. The IAM Profile provides the precedent: the consumer that needs a stable contract defines the contract, and providers conform to it.

@@ -224,4 +224,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

Free-form docs are readable but not safely composable. NetKingdom needs a validator and controlled vocabulary so a playbook change cannot silently break a scenario.

Build A Dedicated Execution-Orchestration Repo Now

ADR-0007 explicitly defers that. The contract is useful now and does not require a new runner or repo boundary.

-
NK-ADR-0012 · 1 · acceptednet-kingdom · docs/adr/ADR-0012-playbook-capability-contract-ownership.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3
+
diff --git a/build/adr/netkingdom-railiance-workload-packaging/v1/index.html b/build/adr/netkingdom-railiance-workload-packaging/v1/index.html index 9996e60..7782aac 100644 --- a/build/adr/netkingdom-railiance-workload-packaging/v1/index.html +++ b/build/adr/netkingdom-railiance-workload-packaging/v1/index.html @@ -1,6 +1,6 @@ - + NetKingdom Railiance Workload Packaging and Relational Platform -
NK-ADR-0015 accepted · 1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

NetKingdom Railiance Workload Packaging and Relational Platform

Source: net-kingdom · docs/adr/ADR-0015-netkingdom-railiance-workload-packaging-and-relational-platform.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3

Review due: 2027-02-22

Status: Accepted Date: 2026-08-11 Deciders: Bernd Worsch, Claude

+
NK-ADR-0015 accepted · 1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

NetKingdom Railiance Workload Packaging and Relational Platform

Source: net-kingdom · docs/adr/ADR-0015-netkingdom-railiance-workload-packaging-and-relational-platform.md · 9781102e2971d762ae42fdd5085a6647afd1cd66

Review due: 2027-02-22

Status: Accepted Date: 2026-08-11 Deciders: Bernd Worsch, Claude

Context

NetKingdom's runtime services are deployed today outside the Railiance reef/rail/rapp model. tenant-engine and user-engine run on the coulomb substrate with digest-pinned images (forgejo.coulomb.social/coulomb/{tenant,user}-engine@sha256:…), but their Kubernetes manifests live in this repo at sso-mfa/k8s/<service>/runtime.yaml — a canon repo holding runtime YAML — applied imperatively, with verify-t0*.sh scripts as verification. Neither service declares railiance/app.toml, appears in reef-railiance/bindings/rapps.yaml, or is reconciled by a GitOps controller.

The decision to bring NetKingdom under Railiance governance forces two questions this ADR settles.

@@ -226,4 +226,4 @@ rapp-user-engine ownership_repo: user-engine

Follow-Up

  • Create rapp-tenant-engine and rapp-user-engine; move runtime manifests out of net-kingdom/sso-mfa/k8s/.
  • Add both bindings to reef-railiance/bindings/rapps.yaml at declared.
  • Add railiance/app.toml to tenant-engine and user-engine.
  • Open a tenant-engine workplan for the cnpg backend and data migration; reconcile with TEN-WP-0005-T05, whose rollout currently targets SQLite.
  • Confirm whether secrets-engine is intended to remain a non-deployed control layer. This ADR assumes it is.
  • Record the NetKingdom-wide threat model that both bindings will reference.
-
NK-ADR-0015 · 1 · acceptednet-kingdom · docs/adr/ADR-0015-netkingdom-railiance-workload-packaging-and-relational-platform.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3
+
diff --git a/build/adr/netkingdom-recursive-multi-tenant-identity-authorization/v1/index.html b/build/adr/netkingdom-recursive-multi-tenant-identity-authorization/v1/index.html index 3f541e9..a97bf9d 100644 --- a/build/adr/netkingdom-recursive-multi-tenant-identity-authorization/v1/index.html +++ b/build/adr/netkingdom-recursive-multi-tenant-identity-authorization/v1/index.html @@ -1,6 +1,6 @@ - + Recursive Multi-Tenant Identity and Authorization Architecture -
NK-ADR-0006 accepted · 1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

Recursive Multi-Tenant Identity and Authorization Architecture

Source: net-kingdom · docs/adr/ADR-0006-recursive-multi-tenant-identity-authorization.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3

Review due: 2027-02-22

Status: Accepted Date: 2026-05-17 Deciders: Bernd Worsch

+
NK-ADR-0006 accepted · 1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

Recursive Multi-Tenant Identity and Authorization Architecture

Source: net-kingdom · docs/adr/ADR-0006-recursive-multi-tenant-identity-authorization.md · 9781102e2971d762ae42fdd5085a6647afd1cd66

Review due: 2027-02-22

Status: Accepted Date: 2026-05-17 Deciders: Bernd Worsch

Context

The Coulomb platform is being built from the same repositories and services that will later support other use cases. This creates a recursive architecture problem: Coulomb needs to use the shared identity, security, policy, and deployment capabilities, while those capabilities are themselves part of the infrastructure being built.

If this recursion is left implicit, the first internal use case can drift into being treated as the platform root of trust. That would make future multi-tenant use harder, blur operational authority, and make secure bootstrap/recovery decisions harder to reason about.

@@ -216,4 +216,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

Follow-Up

  • Refine bootstrapping around explicit trust-state transitions.
  • Add tenant/control-plane language to flex-auth authorization workplans.
  • Define the first production Topaz integration boundary for flex-auth.
  • Decide when key-cape is sufficient and when Keycloak expanded mode is required.
  • Decide what, if anything, should live in a future orchestration repo.
-
NK-ADR-0006 · 1 · acceptednet-kingdom · docs/adr/ADR-0006-recursive-multi-tenant-identity-authorization.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3
+
diff --git a/build/adr/netkingdom-security-orchestration-boundary/v1/index.html b/build/adr/netkingdom-security-orchestration-boundary/v1/index.html index adbdb9f..5870aa9 100644 --- a/build/adr/netkingdom-security-orchestration-boundary/v1/index.html +++ b/build/adr/netkingdom-security-orchestration-boundary/v1/index.html @@ -1,6 +1,6 @@ - + Security Orchestration Boundary -
NK-ADR-0007 accepted · 1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

Security Orchestration Boundary

Source: net-kingdom · docs/adr/ADR-0007-security-orchestration-boundary.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3

Review due: 2027-02-22

Status: Accepted Date: 2026-05-18 Refined: 2026-05-21 (meta-orchestration layer — see below) Deciders: Bernd Worsch, Codex

+
NK-ADR-0007 accepted · 1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

Security Orchestration Boundary

Source: net-kingdom · docs/adr/ADR-0007-security-orchestration-boundary.md · 9781102e2971d762ae42fdd5085a6647afd1cd66

Review due: 2027-02-22

Status: Accepted Date: 2026-05-18 Refined: 2026-05-21 (meta-orchestration layer — see below) Deciders: Bernd Worsch, Codex

Context

The recursive platform security architecture needs careful sequencing: host trust, cluster trust, bootstrap secrets, runtime secret authority, runtime identity, runtime authorization, tenant onboarding, and readiness verification.

That sequencing crosses NetKingdom and Railiance ownership boundaries. NetKingdom owns the canonical security architecture, IAM Profile, credential/bootstrap standards, and authorization semantics. Railiance owns deployment layering for infrastructure, clusters, platform services, and applications. OpenBao adds an important runtime-secret authority to the platform control plane, but it does not change those ownership boundaries.

@@ -227,4 +227,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

For NetKingdom to select and parametrize reliably, Railiance playbooks must publish a declared interface: the capability each playbook provisions, its parameters (with defaults and constraints), and the responsibility it claims. This catalog is the orchestration-layer analog of the IAM Profile. Without it, meta-orchestration composes against implicit behavior and breaks when a playbook changes. Establishing this contract is the prerequisite for any concrete meta-orchestration work.

Effect on the Future Repo Trigger

Meta-orchestration logic now has a clear home (NetKingdom) regardless of whether a dedicated execution-orchestration repo is later created under the Future Repo Trigger above. A future repo, if created, would host reusable execution sequencing — not the scenario-composition and responsibility-mapping role, which remains NetKingdom's.

-
NK-ADR-0007 · 1 · acceptednet-kingdom · docs/adr/ADR-0007-security-orchestration-boundary.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3
+
diff --git a/build/adr/netkingdom-tenant-capability-ownership/v1/index.html b/build/adr/netkingdom-tenant-capability-ownership/v1/index.html index 03b23cf..28648e3 100644 --- a/build/adr/netkingdom-tenant-capability-ownership/v1/index.html +++ b/build/adr/netkingdom-tenant-capability-ownership/v1/index.html @@ -1,6 +1,6 @@ - + Tenant Capability Roles, Carrying Mechanism, and Tenant-Engine Ownership -
NK-ADR-0014 accepted · 1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

Tenant Capability Roles, Carrying Mechanism, and Tenant-Engine Ownership

Source: net-kingdom · docs/adr/ADR-0014-tenant-capability-roles-and-tenant-engine-ownership.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3

Review due: 2027-02-22

Status: Accepted Date: 2026-07-23 Deciders: Bernd Worsch, Codex

+
NK-ADR-0014 accepted · 1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

Tenant Capability Roles, Carrying Mechanism, and Tenant-Engine Ownership

Source: net-kingdom · docs/adr/ADR-0014-tenant-capability-roles-and-tenant-engine-ownership.md · 9781102e2971d762ae42fdd5085a6647afd1cd66

Review due: 2027-02-22

Status: Accepted Date: 2026-07-23 Deciders: Bernd Worsch, Codex

Context

ADR-0013 introduced the tenant onboarding grouping taxonomy (trial/friendly/single/.../agentic), deliberately orthogonal to a separate, unratified capability-role model sketched in docs/princedom-isolation-exploration.md: PLTF (operates the platform), IAM (organizes its own users/auth/secrets), VEN (provides apps/services to others), CUS (consumes apps/services from PLTF or VEN tenants) — non-exclusive, a tenant may hold several at once.

That exploration left open where capability roles actually live (a per-token claim vs. a registry), who owns them, how they're granted or revoked, and how this interacts with the IAM Profile's existing roles claim — which is a per-subject claim ("coarse identity roles" for the human/service/agent holding the token), a different concept from a per-tenant capability fact. Conflating the two would be a category error: roles: ["VEN"] on a token would ambiguously mean "this subject has vendor-role" vs. "this subject's tenant is a vendor."

@@ -222,4 +222,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

Follow-Up

  • tenant-engine repository creation and its own workplan (Bernd).
  • key-cape integration: source tenant_roles from tenant-engine at token issuance.
  • flex-auth policy package updates: live tenant-engine re-validation gate for privileged actions.
  • Guardrail/quota policy design for trial (and eventually all) tenants: spend limits, entity/action count limits, enforcement point, override process.
  • Resolve whether VEN needs an approval gate beyond payment-plan state.
-
NK-ADR-0014 · 1 · acceptednet-kingdom · docs/adr/ADR-0014-tenant-capability-roles-and-tenant-engine-ownership.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3
+
diff --git a/build/adr/netkingdom-tenant-onboarding-taxonomy/v1/index.html b/build/adr/netkingdom-tenant-onboarding-taxonomy/v1/index.html index cae956d..b0e2873 100644 --- a/build/adr/netkingdom-tenant-onboarding-taxonomy/v1/index.html +++ b/build/adr/netkingdom-tenant-onboarding-taxonomy/v1/index.html @@ -1,6 +1,6 @@ - + Tenant Onboarding Grouping Taxonomy -
NK-ADR-0013 accepted · 2 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

Tenant Onboarding Grouping Taxonomy

Source: net-kingdom · docs/adr/ADR-0013-tenant-onboarding-grouping-taxonomy.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3

Review due: 2027-02-22

Status: Accepted Date: 2026-07-23 Amended: 2026-08-22 (current classification versus historical identifier segment) Deciders: Bernd Worsch, Codex

+
NK-ADR-0013 accepted · 2 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

Tenant Onboarding Grouping Taxonomy

Source: net-kingdom · docs/adr/ADR-0013-tenant-onboarding-grouping-taxonomy.md · 9781102e2971d762ae42fdd5085a6647afd1cd66

Review due: 2027-02-22

Status: Accepted Date: 2026-07-23 Amended: 2026-08-22 (current classification versus historical identifier segment) Deciders: Bernd Worsch, Codex

Context

canon/standards/iam-profile_v0.2.md's "Tenant Claim" section lists four suggested (not exhaustive) tenant identifiers: tenant:platform, tenant:coulomb, tenant:sandbox:<name>, tenant:customer:<name>.

Separately, an unratified exploration (docs/princedom-isolation-exploration.md) proposes a non-exclusive capability-role model for tenants: PLTF (operates the platform), IAM (organizes its own users/secrets), VEN (provides apps/services to others), CUS (consumes apps/services from PLTF or VEN tenants) — one tenant can hold multiple roles simultaneously.

@@ -238,4 +238,4 @@ agentic - financially enabled AI entities

Follow-Up

  • Edit canon/standards/iam-profile_v0.2.md's Tenant Claim section to replace the old suggested identifiers with this taxonomy (separate, reviewable change).
  • Confirm the tenant:platform/tenant:coulomb reserved/ungrouped treatment explicitly.
  • ADR-0014 and the Tenant Engine Boundary Contract define how capability-role metadata is carried alongside grouping.
  • Keep tenant-engine's identifier parser vocabulary-validating for creation and lookup compatibility, but do not expose parsed grouping as current classification.
-
NK-ADR-0013 · 2 · acceptednet-kingdom · docs/adr/ADR-0013-tenant-onboarding-grouping-taxonomy.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3
+
diff --git a/build/adr/ops-warden-build-stage-credential-disclosure/v1/index.html b/build/adr/ops-warden-build-stage-credential-disclosure/v1/index.html index a848e6e..7ebc1b9 100644 --- a/build/adr/ops-warden-build-stage-credential-disclosure/v1/index.html +++ b/build/adr/ops-warden-build-stage-credential-disclosure/v1/index.html @@ -1,6 +1,6 @@ - + ADR-0007 — Build-stage permissiveness stops at credential disclosure -
ops-warden-adr-0007 accepted · 1 ops-warden reviewed 2026-08-19generated from canonical source — do not edit

ADR-0007 — Build-stage permissiveness stops at credential disclosure

Source: ops-warden · docs/adr/ADR-0007-build-stage-stops-at-credential-disclosure.md · 4e267179db741b27a3e62f81f753cd9752c97412

Review due: 2027-02-19

Status

+
ops-warden-adr-0007 accepted · 1 ops-warden reviewed 2026-08-19generated from canonical source — do not edit

ADR-0007 — Build-stage permissiveness stops at credential disclosure

Source: ops-warden · docs/adr/ADR-0007-build-stage-stops-at-credential-disclosure.md · 8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5

Review due: 2027-02-19

Status

Accepted 2026-08-19, alongside grading the last 14 ungraded catalog lanes.

Context

@@ -214,4 +214,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
ops-warden-adr-0007 · 1 · acceptedops-warden · docs/adr/ADR-0007-build-stage-stops-at-credential-disclosure.md · 4e267179db741b27a3e62f81f753cd9752c97412
+
diff --git a/build/adr/ops-warden-catalog-pointer-layer/v1/index.html b/build/adr/ops-warden-catalog-pointer-layer/v1/index.html index 716a151..4f89875 100644 --- a/build/adr/ops-warden-catalog-pointer-layer/v1/index.html +++ b/build/adr/ops-warden-catalog-pointer-layer/v1/index.html @@ -1,6 +1,6 @@ - + ADR-0001 — The routing catalog is a pointer layer, never a second copy -
ops-warden-adr-0001 accepted · 1 ops-warden reviewed 2026-08-18generated from canonical source — do not edit

ADR-0001 — The routing catalog is a pointer layer, never a second copy

Source: ops-warden · docs/adr/ADR-0001-catalog-is-a-pointer-layer.md · 4e267179db741b27a3e62f81f753cd9752c97412

Review due: 2027-02-18

Status

+
ops-warden-adr-0001 accepted · 1 ops-warden reviewed 2026-08-18generated from canonical source — do not edit

ADR-0001 — The routing catalog is a pointer layer, never a second copy

Source: ops-warden · docs/adr/ADR-0001-catalog-is-a-pointer-layer.md · 8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5

Review due: 2027-02-18

Status

Accepted. Decided during WARDEN-WP-0010 (access routing charter), enforced in code since WARDEN-WP-0011. Restated here because it binds repos other than ops-warden and had, until now, no address they could cite.

Context

@@ -213,4 +213,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
ops-warden-adr-0001 · 1 · acceptedops-warden · docs/adr/ADR-0001-catalog-is-a-pointer-layer.md · 4e267179db741b27a3e62f81f753cd9752c97412
+
diff --git a/build/adr/ops-warden-conduit-not-broker/v1/index.html b/build/adr/ops-warden-conduit-not-broker/v1/index.html index 5deb9dd..47c7705 100644 --- a/build/adr/ops-warden-conduit-not-broker/v1/index.html +++ b/build/adr/ops-warden-conduit-not-broker/v1/index.html @@ -1,6 +1,6 @@ - + ADR-0002 — ops-warden is a transparent conduit, never a secret broker -
ops-warden-adr-0002 accepted · 1 ops-warden reviewed 2026-08-18generated from canonical source — do not edit

ADR-0002 — ops-warden is a transparent conduit, never a secret broker

Source: ops-warden · docs/adr/ADR-0002-conduit-not-broker.md · 4e267179db741b27a3e62f81f753cd9752c97412

Review due: 2027-02-18

Status

+
ops-warden-adr-0002 accepted · 1 ops-warden reviewed 2026-08-18generated from canonical source — do not edit

ADR-0002 — ops-warden is a transparent conduit, never a secret broker

Source: ops-warden · docs/adr/ADR-0002-conduit-not-broker.md · 8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5

Review due: 2027-02-18

Status

Accepted. Decided during WARDEN-WP-0014 (operator access assist), tightened by WARDEN-WP-0026 (disclosure hygiene).

Context

@@ -213,4 +213,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
ops-warden-adr-0002 · 1 · acceptedops-warden · docs/adr/ADR-0002-conduit-not-broker.md · 4e267179db741b27a3e62f81f753cd9752c97412
+
diff --git a/build/adr/ops-warden-cover-gaps/v1/index.html b/build/adr/ops-warden-cover-gaps/v1/index.html index 1b531a6..894c891 100644 --- a/build/adr/ops-warden-cover-gaps/v1/index.html +++ b/build/adr/ops-warden-cover-gaps/v1/index.html @@ -1,6 +1,6 @@ - + ADR-0003 — Cover gaps, but never silently own them -
ops-warden-adr-0003 accepted · 1 ops-warden reviewed 2026-08-18generated from canonical source — do not edit

ADR-0003 — Cover gaps, but never silently own them

Source: ops-warden · docs/adr/ADR-0003-cover-gaps-never-silently-own-them.md · 4e267179db741b27a3e62f81f753cd9752c97412

Review due: 2027-02-18

Status

+
ops-warden-adr-0003 accepted · 1 ops-warden reviewed 2026-08-18generated from canonical source — do not edit

ADR-0003 — Cover gaps, but never silently own them

Source: ops-warden · docs/adr/ADR-0003-cover-gaps-never-silently-own-them.md · 8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5

Review due: 2027-02-18

Status

Accepted. Stated as INTENT §9, made structural by WARDEN-WP-0030 (delegation register).

Context

@@ -215,4 +215,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
ops-warden-adr-0003 · 1 · acceptedops-warden · docs/adr/ADR-0003-cover-gaps-never-silently-own-them.md · 4e267179db741b27a3e62f81f753cd9752c97412
+
diff --git a/build/adr/ops-warden-grade-disclosure-path/v1/index.html b/build/adr/ops-warden-grade-disclosure-path/v1/index.html index fe4d585..2b88322 100644 --- a/build/adr/ops-warden-grade-disclosure-path/v1/index.html +++ b/build/adr/ops-warden-grade-disclosure-path/v1/index.html @@ -1,6 +1,6 @@ - + ADR-0008 — A lane's risk grade covers every field its path discloses -
ops-warden-adr-0008 accepted · 1 ops-warden reviewed 2026-08-21generated from canonical source — do not edit

ADR-0008 — A lane's risk grade covers every field its path discloses

Source: ops-warden · docs/adr/ADR-0008-grade-the-path-not-the-field.md · 4e267179db741b27a3e62f81f753cd9752c97412

Review due: 2027-02-21

Status

+
ops-warden-adr-0008 accepted · 1 ops-warden reviewed 2026-08-21generated from canonical source — do not edit

ADR-0008 — A lane's risk grade covers every field its path discloses

Source: ops-warden · docs/adr/ADR-0008-grade-the-path-not-the-field.md · 8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5

Review due: 2027-02-21

Status

Accepted 2026-08-21, after secrets-engine found two under-graded lanes while reviewing ops-warden's own catalog metadata.

Context

@@ -212,4 +212,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
ops-warden-adr-0008 · 1 · acceptedops-warden · docs/adr/ADR-0008-grade-the-path-not-the-field.md · 4e267179db741b27a3e62f81f753cd9752c97412
+
diff --git a/build/adr/ops-warden-high-risk-read-boundary/v1/index.html b/build/adr/ops-warden-high-risk-read-boundary/v1/index.html index b82662d..c38e5f1 100644 --- a/build/adr/ops-warden-high-risk-read-boundary/v1/index.html +++ b/build/adr/ops-warden-high-risk-read-boundary/v1/index.html @@ -1,6 +1,6 @@ - + ADR-0004 — High-risk lanes refuse raw value streaming to agent sessions -
ops-warden-adr-0004 accepted · 1 ops-warden reviewed 2026-08-18generated from canonical source — do not edit

ADR-0004 — High-risk lanes refuse raw value streaming to agent sessions

Source: ops-warden · docs/adr/ADR-0004-agent-read-boundary-on-high-risk-lanes.md · 4e267179db741b27a3e62f81f753cd9752c97412

Review due: 2027-02-18

Status

+
ops-warden-adr-0004 accepted · 1 ops-warden reviewed 2026-08-18generated from canonical source — do not edit

ADR-0004 — High-risk lanes refuse raw value streaming to agent sessions

Source: ops-warden · docs/adr/ADR-0004-agent-read-boundary-on-high-risk-lanes.md · 8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5

Review due: 2027-02-18

Status

Accepted. Decided during WARDEN-WP-0026 (credential disclosure hygiene), in response to a real disclosure on 2026-07-16.

Context

@@ -213,4 +213,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
ops-warden-adr-0004 · 1 · acceptedops-warden · docs/adr/ADR-0004-agent-read-boundary-on-high-risk-lanes.md · 4e267179db741b27a3e62f81f753cd9752c97412
+
diff --git a/build/adr/ops-warden-implement-narrowly/v1/index.html b/build/adr/ops-warden-implement-narrowly/v1/index.html index aad62ae..f4c2e35 100644 --- a/build/adr/ops-warden-implement-narrowly/v1/index.html +++ b/build/adr/ops-warden-implement-narrowly/v1/index.html @@ -1,6 +1,6 @@ - + ADR-0005 — Implement one lane narrowly, route everything else -
ops-warden-adr-0005 accepted · 1 ops-warden reviewed 2026-08-18generated from canonical source — do not edit

ADR-0005 — Implement one lane narrowly, route everything else

Source: ops-warden · docs/adr/ADR-0005-implement-narrowly-route-broadly.md · 4e267179db741b27a3e62f81f753cd9752c97412

Review due: 2027-02-18

Status

+
ops-warden-adr-0005 accepted · 1 ops-warden reviewed 2026-08-18generated from canonical source — do not edit

ADR-0005 — Implement one lane narrowly, route everything else

Source: ops-warden · docs/adr/ADR-0005-implement-narrowly-route-broadly.md · 8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5

Review due: 2027-02-18

Status

Accepted. The founding charter decision, taken 2026-06-18 (history/2026-06-18-access-routing-intent-shift-assessment.md).

Context

@@ -211,4 +211,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
ops-warden-adr-0005 · 1 · acceptedops-warden · docs/adr/ADR-0005-implement-narrowly-route-broadly.md · 4e267179db741b27a3e62f81f753cd9752c97412
+
diff --git a/build/adr/ops-warden-security-zones-consumer/v1/index.html b/build/adr/ops-warden-security-zones-consumer/v1/index.html index b2b68a1..f587c6a 100644 --- a/build/adr/ops-warden-security-zones-consumer/v1/index.html +++ b/build/adr/ops-warden-security-zones-consumer/v1/index.html @@ -1,6 +1,6 @@ - + ADR-0009 — Adopt security-zones v0.1 as a consumer -
ops-warden-adr-0009 accepted · 1 ops-warden reviewed 2026-08-22generated from canonical source — do not edit

ADR-0009 — Adopt security-zones v0.1 as a consumer

Source: ops-warden · docs/adr/ADR-0009-adopt-security-zones-as-a-consumer.md · 4e267179db741b27a3e62f81f753cd9752c97412

Review due: 2026-11-22

Status

+
ops-warden-adr-0009 accepted · 1 ops-warden reviewed 2026-08-22generated from canonical source — do not edit

ADR-0009 — Adopt security-zones v0.1 as a consumer

Source: ops-warden · docs/adr/ADR-0009-adopt-security-zones-as-a-consumer.md · 8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5

Review due: 2026-11-22

Status

Accepted 2026-08-22 after zone-engine completed ZONE-WP-0001-T03/T05 and published the declaration, compilation, stance, and failure-mode contract in canon revision 337484a; zone-engine's reference compiler is revision 9b6ada7.

Context

@@ -212,4 +212,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
ops-warden-adr-0009 · 1 · acceptedops-warden · docs/adr/ADR-0009-adopt-security-zones-as-a-consumer.md · 4e267179db741b27a3e62f81f753cd9752c97412
+
diff --git a/build/adr/ops-warden-staff-layer/v1/index.html b/build/adr/ops-warden-staff-layer/v1/index.html index f46abe7..6b1a8b9 100644 --- a/build/adr/ops-warden-staff-layer/v1/index.html +++ b/build/adr/ops-warden-staff-layer/v1/index.html @@ -1,6 +1,6 @@ - + ADR-0010 — ops-warden is Staff -
ops-warden-adr-0010 accepted · 1 ops-warden reviewed 2026-08-28generated from canonical source — do not edit

ADR-0010 — ops-warden is Staff

Source: ops-warden · docs/adr/ADR-0010-ops-warden-is-staff.md · 4e267179db741b27a3e62f81f753cd9752c97412

Review due: 2026-11-28

Status

+
ops-warden-adr-0010 accepted · 1 ops-warden reviewed 2026-08-28generated from canonical source — do not edit

ADR-0010 — ops-warden is Staff

Source: ops-warden · docs/adr/ADR-0010-ops-warden-is-staff.md · 8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5

Review due: 2026-11-28

Status

Accepted 2026-08-28, answering intake WARDEN-IN-0001 from gate-house, which carries decision GH-DEC-2026-001. The standard being adopted — net-kingdom/canon/standards/security-layer-model_v0.1.md — is proposed, and was proposed pending assent from flex-auth, kings-guard, and ops-warden. This ADR is ops-warden's half of that assent.

Context

@@ -215,4 +215,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off
ops-warden-adr-0010 · 1 · acceptedops-warden · docs/adr/ADR-0010-ops-warden-is-staff.md · 4e267179db741b27a3e62f81f753cd9752c97412
+
diff --git a/build/adr/railiance-decisions-live-in-the-repo/v1/index.html b/build/adr/railiance-decisions-live-in-the-repo/v1/index.html index 58092c9..0a9c43a 100644 --- a/build/adr/railiance-decisions-live-in-the-repo/v1/index.html +++ b/build/adr/railiance-decisions-live-in-the-repo/v1/index.html @@ -1,6 +1,6 @@ - + ADR-0003 — Decisions that bind others live in docs/adr, not only in the State Hub -
RPLAT-ADR-0003 accepted · 1.0 railiance-platform reviewed 2026-08-17generated from canonical source — do not edit

ADR-0003 — Decisions that bind others live in docs/adr, not only in the State Hub

Source: railiance-platform · docs/adr/ADR-0003-decisions-live-in-the-repo.md · e5f3497337575e1fd85fe2bfde5b2183c690d94e

Review due: 2027-02-17

Context

+
RPLAT-ADR-0003 accepted · 1.0 railiance-platform reviewed 2026-08-17generated from canonical source — do not edit

ADR-0003 — Decisions that bind others live in docs/adr, not only in the State Hub

Source: railiance-platform · docs/adr/ADR-0003-decisions-live-in-the-repo.md · 62423fd0925d75f5a2b27034044dc1080823d341

Review due: 2027-02-17

Context

This repo recorded decisions with the State Hub's record_decision() and wrote governing content as prose in docs/ — 24 files on 2026-08-17, none carrying a status, owner, revision or review date. It held no ADRs at all.

Two things made that a defect rather than a style.

The hub is a read model. The estate's standing rule is that local files are the source of truth and the hub reflects them. A decision that exists only as a hub record inverts that for the one class of content where it matters most.

@@ -208,4 +208,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

Alternatives considered

Keep decisions in the hub and have policy-nexus read it. Rejected on both sides: it would make a read model authoritative, and it would give the publication surface a source that no repo can diff or review.

Add frontmatter to all 24 existing docs/ files. Rejected. Most are runbooks that should not be published, and stamping them with a status would assert a decision that was never made.

-
RPLAT-ADR-0003 · 1.0 · acceptedrailiance-platform · docs/adr/ADR-0003-decisions-live-in-the-repo.md · e5f3497337575e1fd85fe2bfde5b2183c690d94e
+
diff --git a/build/adr/railiance-placement-policy-ownership/v1/index.html b/build/adr/railiance-placement-policy-ownership/v1/index.html index e78a2e6..41d74fe 100644 --- a/build/adr/railiance-placement-policy-ownership/v1/index.html +++ b/build/adr/railiance-placement-policy-ownership/v1/index.html @@ -1,6 +1,6 @@ - + ADR-0002 — S3 owns the placement rule; the package repo owns the number -
RPLAT-ADR-0002 proposed · 1.0 railiance-platform reviewed 2026-08-17generated from canonical source — do not edit

ADR-0002 — S3 owns the placement rule; the package repo owns the number

Source: railiance-platform · docs/adr/ADR-0002-placement-policy-ownership.md · e5f3497337575e1fd85fe2bfde5b2183c690d94e

Review due: 2027-02-17

Context

+
RPLAT-ADR-0002 proposed · 1.0 railiance-platform reviewed 2026-08-17generated from canonical source — do not edit

ADR-0002 — S3 owns the placement rule; the package repo owns the number

Source: railiance-platform · docs/adr/ADR-0002-placement-policy-ownership.md · 62423fd0925d75f5a2b27034044dc1080823d341

Review due: 2027-02-17

Context

An earlier draft of net-kingdom/canon/standards/tenancy-posture_v0.1.md §8.2 proposed that database placement policy — dedicated versus shared, and when that changes — be owned by railiance-platform, co-signed by adaptive-pricing. tenant-engine raised the same gap independently on 2026-08-16: both patterns are live on railiance01, neither is written down, and each new service copies whichever neighbour it looked at.

The complication is that this repo no longer holds the specs. RAILIANCE-WP-0012 and RAILIANCE-WP-0015 moved the deployable surface to the rapp-* repos. platform-pg's instances, max_connections, memory limit and retention are rapp-postgres's cluster CR. Tenancy Posture §19.8 nonetheless asks this repo for platform-pg's declared maximum size — a question one hop from where its answer lives.

Accepting ownership without stating this would produce either an answer we cannot substantiate or a quiet non-answer.

@@ -209,4 +209,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

Alternatives considered

Decline ownership; route it to rapp-postgres. They hold the specs and the operational knowledge. Rejected: placement is a cross-cluster question and rapp-postgres owns one package. A policy owned by one substrate's operator cannot govern movement between substrates.

Accept whole, including the numbers. Rejected: it would either re-import the deployable surface this repo deliberately gave up, or produce numbers restated here that drift from the CR — a second source of truth for exactly the values a consumer must be able to trust.

-
RPLAT-ADR-0002 · 1.0 · proposedrailiance-platform · docs/adr/ADR-0002-placement-policy-ownership.md · e5f3497337575e1fd85fe2bfde5b2183c690d94e
+
diff --git a/build/adr/railiance-s3-platform-service-boundary/v1/index.html b/build/adr/railiance-s3-platform-service-boundary/v1/index.html index 05f5967..d3cbbc1 100644 --- a/build/adr/railiance-s3-platform-service-boundary/v1/index.html +++ b/build/adr/railiance-s3-platform-service-boundary/v1/index.html @@ -1,6 +1,6 @@ - + ADR-0001 — S3 owns platform services, not the substrate beneath them -
RPLAT-ADR-0001 accepted · 1.0 railiance-platform reviewed 2026-08-17generated from canonical source — do not edit

ADR-0001 — S3 owns platform services, not the substrate beneath them

Source: railiance-platform · docs/adr/ADR-0001-s3-platform-service-boundary.md · e5f3497337575e1fd85fe2bfde5b2183c690d94e

Review due: 2027-02-17

Context

+
RPLAT-ADR-0001 accepted · 1.0 railiance-platform reviewed 2026-08-17generated from canonical source — do not edit

ADR-0001 — S3 owns platform services, not the substrate beneath them

Source: railiance-platform · docs/adr/ADR-0001-s3-platform-service-boundary.md · 62423fd0925d75f5a2b27034044dc1080823d341

Review due: 2027-02-17

Context

railiance-platform is S3 on the OAS Stack: the shared services several applications depend on — PostgreSQL, secrets, cache, object storage. The layers around it are S1 railiance-infra (OS and host concerns), S2 railiance-cluster (Kubernetes runtime, ingress), S4 railiance-enablement (tooling and CI), S5 railiance-apps (workloads).

This boundary has been stated in SCOPE.md and in ADR-003 of railiance-infra since the five-repo split, and it has been tested twice. RAIL-PL-WP-0001 existed to extract platform services out of S2 subcharts. On 2026-08-17 POLICY-NEXUS-WP-0001 assigned this repo "the substrate — DNS, TLS, ingress, hosting" for policy.coulomb.social, which would move the boundary back the other way.

The pressure is predictable and will recur: S3 is the layer that looks like it owns infrastructure, because it owns things that feel infrastructural. Recording the rule as an ADR rather than as a line in SCOPE.md gives future requests something to be answered against.

@@ -206,4 +206,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

Alternatives considered

Accept the substrate assignment as written. Fastest, and the requester had already resolved it with the operator. Rejected: it re-imports the coupling RAIL-PL-WP-0001 spent a workplan removing, and a boundary that yields to whoever asks most recently is not a boundary.

Own ingress for S3-adjacent services only. A narrower version, and it fails on the first argument about what counts as adjacent. The line has to be drawn where it can be checked.

-
RPLAT-ADR-0001 · 1.0 · acceptedrailiance-platform · docs/adr/ADR-0001-s3-platform-service-boundary.md · e5f3497337575e1fd85fe2bfde5b2183c690d94e
+
diff --git a/build/architecture/coulomb-estate/v0.1/index.html b/build/architecture/coulomb-estate/v0.1/index.html index 4e18fd1..86a5fd2 100644 --- a/build/architecture/coulomb-estate/v0.1/index.html +++ b/build/architecture/coulomb-estate/v0.1/index.html @@ -1,6 +1,6 @@ - + Coulomb estate architecture -
coulomb-estate-architecture proposed · draft-3 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Coulomb estate architecture

Source: the-custodian · canon/architecture/coulomb-estate_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93

Review due: 2027-02-28

About this document

+
coulomb-estate-architecture proposed · draft-3 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Coulomb estate architecture

Source: the-custodian · canon/architecture/coulomb-estate_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac

Review due: 2027-02-28

About this document

This is the first-wave estate map. It describes how the Coulomb / Custodian estate is put together: canons, hubs, rails, and publication. System-level arc42 documents (Railiance, NetKingdom, State Hub, Policy Nexus) live in their owning repos. Chapter 9 lists estate ADRs; it does not paste them.

01Introduction and Goals

@@ -271,4 +271,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

12Glossary

TermMeaning
EstateThe set of Coulomb / Custodian repos, canons, hubs, and rails.
CanonGoverning documents owned by one of the three federated canons.
Read modelA derived index. Never the origin of work or decisions.
Publication entryOne explicit object in policy-nexus publication.json.
First-wave completeChapters 1, 3, 4, 5.1, 9 and 12 are real; others real or N/A.
Project repoA prj-* repo that coordinates cross-repo work (ADR-005).
-
coulomb-estate-architecture · draft-3 · proposedthe-custodian · canon/architecture/coulomb-estate_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93
+
diff --git a/build/architecture/net-kingdom/v0.1/index.html b/build/architecture/net-kingdom/v0.1/index.html index 97ff62c..d3d4c23 100644 --- a/build/architecture/net-kingdom/v0.1/index.html +++ b/build/architecture/net-kingdom/v0.1/index.html @@ -1,6 +1,6 @@ - + NetKingdom architecture -
net-kingdom-architecture proposed · draft-3 net-kingdom reviewed 2026-08-31generated from canonical source — do not edit

NetKingdom architecture

Source: net-kingdom · docs/architecture/net-kingdom_v0.1.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3

Review due: 2027-02-28

About this document

+
net-kingdom-architecture proposed · draft-3 net-kingdom reviewed 2026-08-31generated from canonical source — do not edit

NetKingdom architecture

Source: net-kingdom · docs/architecture/net-kingdom_v0.1.md · 9781102e2971d762ae42fdd5085a6647afd1cd66

Review due: 2027-02-28

About this document

First-wave arc42 for NetKingdom: the estate's identity and tenancy security core. Chapter 9 lists governing ADRs and standards; it does not paste them.

01Introduction and Goals

@@ -241,4 +241,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

12Glossary

TermMeaning
IAM ProfileProvider-neutral OIDC contract owned here.
Tenancy PostureGraduated axes for describing multi-tenancy.
Tenant-engineLifecycle and capability roles for tenants.
-
net-kingdom-architecture · draft-3 · proposednet-kingdom · docs/architecture/net-kingdom_v0.1.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3
+
diff --git a/build/architecture/policy-nexus/v0.1/index.html b/build/architecture/policy-nexus/v0.1/index.html index 91b66d5..4007ffb 100644 --- a/build/architecture/policy-nexus/v0.1/index.html +++ b/build/architecture/policy-nexus/v0.1/index.html @@ -1,6 +1,6 @@ - + Policy Nexus architecture -
policy-nexus-architecture proposed · draft-1 the-custodian reviewed 2026-08-18generated from canonical source — do not edit

Policy Nexus architecture

Source: policy-nexus · docs/architecture/policy-nexus_v0.1.md · 885c6bb1cb805b64cbcfa99dd2c5817f6d4a1373

Review due: 2027-02-18

About this document

+
policy-nexus-architecture proposed · draft-1 the-custodian reviewed 2026-08-18generated from canonical source — do not edit

Policy Nexus architecture

Source: policy-nexus · docs/architecture/policy-nexus_v0.1.md · 4c8a7b966600976aac595e8f49f3ef38929ccd20

Review due: 2027-02-18

About this document

This document follows the arc42 template for the publication surface at policy.coulomb.social. It is the first-wave architecture document this repository is allowed to author. Other first-wave systems are written in their owning repos.

01Introduction and Goals

@@ -245,4 +245,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

12Glossary

TermMeaning
Current addressThe stable URL for the document as it now stands.
Revision addressWrite-once URL for one source digest.
Publication entryOne object in publication.json. Discovery is not publication.
First-wave completeChapters 1, 3, 4, 5.1, 9 and 12 are real; others real or N/A.
-
policy-nexus-architecture · draft-1 · proposedpolicy-nexus · docs/architecture/policy-nexus_v0.1.md · 885c6bb1cb805b64cbcfa99dd2c5817f6d4a1373
+
diff --git a/build/architecture/state-hub/v0.1/index.html b/build/architecture/state-hub/v0.1/index.html index 2d30d8f..f4cb5ac 100644 --- a/build/architecture/state-hub/v0.1/index.html +++ b/build/architecture/state-hub/v0.1/index.html @@ -1,6 +1,6 @@ - + State Hub architecture -
state-hub-architecture proposed · draft-3 state-hub reviewed 2026-08-31generated from canonical source — do not edit

State Hub architecture

Source: state-hub · docs/architecture/state-hub_v0.1.md · 0e35f84ad5f2f9397d76ffacb99f9973544f08ac

Review due: 2027-02-28

About this document

+
state-hub-architecture proposed · draft-3 state-hub reviewed 2026-08-31generated from canonical source — do not edit

State Hub architecture

Source: state-hub · docs/architecture/state-hub_v0.1.md · 803bb95e1d071f188f4202d53a235f8721a8ecdc

Review due: 2027-02-28

About this document

First-wave arc42 for State Hub, the estate's live coordination read-model. This service is in active retirement planning; new permanent ownership should not land here. Chapter 9 points at the estate ADRs that still bind it.

01Introduction and Goals

@@ -244,4 +244,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

12Glossary

TermMeaning
Read modelDerived index; never the origin.
RegistrarThe single instance allowed to mint workplan UUIDs.
RetirementCoordinated move of capabilities out of this repo.
-
state-hub-architecture · draft-3 · proposedstate-hub · docs/architecture/state-hub_v0.1.md · 0e35f84ad5f2f9397d76ffacb99f9973544f08ac
+
diff --git a/build/findings/audit-retention-legal-basis/v1/index.html b/build/findings/audit-retention-legal-basis/v1/index.html new file mode 100644 index 0000000..9aa9f6f --- /dev/null +++ b/build/findings/audit-retention-legal-basis/v1/index.html @@ -0,0 +1,274 @@ + + + + +The legal basis for retaining audit facts against an erasure request has been assumed, never established + +
RISK-F-0008 accepted · published-1 risk-nexus reviewed 2026-08-20generated from canonical source — do not edit

The legal basis for retaining audit facts against an erasure request has been assumed, never established

The estate retains personal data in audit records on grounds nobody had established. Published as a question, because it is one.

Source: risk-nexus · findings/RISK-F-0008-audit-retention-legal-basis-assumed.md · c5517c754bd84b0ebf47878ba0f26df0ecb3b4a4

Review due: 2027-02-20

What is true

+

audit-core holds audit evidence across tenants, targets R2 on the Tenancy Posture retention ladder, and has declared R4 — verified erasure — unreachable by design. The technical reasoning is sound and documented (audit-core/docs/erasure-and-audit.md, framework Decision 4.5.3): crypto-shredding would destroy the evidence the service exists to hold, and their integrity chain commits to a SHA-256 of the cleartext record, which survives key destruction as a confirmation oracle against low-entropy audit rows. Destroying a key does not erase content a surviving commitment can still be tested against.

+

The consequence is that if an Article 17 request arrives naming a data subject in the audit trail, audit-core has no mechanism. The answer would rest on audit evidence being exempt — legal obligation, or legitimate interest in fraud and security investigation.

+

Those grounds are ordinary. Nobody in this estate has actually reached them. audit-core routed the question here on 2026-08-18 rather than absorbing it, saying plainly that they are not competent to answer it and that they have been assuming it. §19.11 of the framework says the same in its own words: the legal basis for retaining audit facts remains a risk/legal question outside the framework.

+
+

Why this repo owns it

+

This is the first finding where fix_owner is risk-nexus.

+

INTENT.md moved regulatory intake here from policy-nexus on 2026-08-17, precisely because deciding what a rule demands of us is a judgement about risk rather than an act of publishing. audit-core routed it by both available routes and asked for an owner rather than an opinion. Refusing it would be this repo declining its own remit.

+

What this repo owns is the record: what the source says, when, and what therefore is or is not established. It does not own legal advice — INTENT.md is explicit — and it does not own the redesign. If the basis does not hold, audit-core owns encrypt-then-hash at accept time, and that is not retrofittable onto events already accepted.

+
+

The three questions, as asked

+
  1. On what basis does the estate retain personal data inside audit records against an erasure request, and does that basis hold for the categories audit-core stores?
  2. Does it hold across the full 30-day recoverable window and beyond, given that at P1 the real erasure horizon is the maximum across every co-resident on platform-pg, not the value audit-core declares?
  3. If it does not hold, R4 is urgent rather than theoretical, and the answer is a substantial redesign with a long lead time.
+
+

Register ruling — 2026-08-19

+

medium today (I3 × L2), high at production, public, escalated on trigger 2.

+

I3: an unmet retention obligation in the audit store crosses from a technical question to an obligation with an outside counterparty, and the remediation is a non-retrofittable redesign rather than a patch. L2: no request has arrived and the estate holds no real data subject's records yet, but the trigger is somebody else's to pull and needs no foothold here.

+

production_rescore: true. The likelihood of an Article 17 request is a function of having real users; that is exactly what production means.

+

Escalation, trigger 2 — "creates or reveals an obligation with an outside counterparty". It reveals one. The estate cannot decide unilaterally that this obligation is small, and the operator is the only party who can commission an answer that is more than an assumption. The ask is narrow: authorise someone to establish the basis, or record that the estate knowingly runs on the assumption and for how long.

+

Disclosure public. Nothing here shortens a path to a defect: it is a question about a legal basis, published as a question. audit-core's technical reasoning is already written down and worth reading.

+
+

How it got here

+

Ruled a note on 2026-08-19 (RISK-N-0002) on the reasoning that no obligation exists yet. That ruling was made without reading audit-core's message, which had been in this repo's inbox since 2026-08-18 and asks specifically for an owner. The note was wrong on the second floor test: recording this does change a decision, because the redesign it might force cannot be retrofitted and therefore has to be decided early or not at all.

+

RISK-N-0002 is superseded by this record.

+
+

Reviews

+
  • 2026-08-19 — promoted from note, graded, escalated. Open at review: has the basis been established or the assumption recorded; has anything changed about what categories audit-core stores.
+
+

Suggested disposition — 2026-08-20, proposed by risk-nexus

+

Offered because this repo owns the finding and the operator asked for a direction. It is not legal advice, and this repo cannot make it into one: what follows is a route to an answer and a hedge against the answer being no.

+

The reframe: the expensive thing is not the legal question

+

audit-core asks whether the exemption holds. That question is cheap to answer badly and expensive to answer properly, and the temptation is to schedule the proper version and wait.

+

But the cost of a "no" is not fixed — it grows daily. The remedy they name, encrypt-then-hash at accept time, cannot be retrofitted onto events already accepted. Every day the estate accepts events under the current scheme, the un-erasable set grows by one day. So the decision that actually needs taking now is not "is it exempt" but "do we keep manufacturing records we could never erase while we find out".

+

That splits the finding into two decisions with very different prices.

+

1. Establish the basis internally, now, for the cost of an afternoon

+

Not a legal opinion — a written determination that says which ground is being relied on, for which category of data, and for how long. Today the estate has no such document; that is the whole finding.

+

The shape it should take, per category of personal data in the audit trail:

+
CategoryLikely groundThe part that is actually arguable
Operator and agent identifiersArt 6(1)(f) legitimate interest in security, with Recital 49 squarely on pointlittle — this is the ordinary case
Counterparty or end-user identifiers in event payloadsArt 17(3)(e), defence of legal claims; Art 6(1)(f)duration, not existence
Commercial records that happen to pass through auditArt 17(3)(b) plus German §257 HGB / §147 AO retentionscope — retention duties cover books and invoices, not application logs generally
+

Where such determinations usually fail is not the ground. It is the retention period: a blanket "we keep audit forever under legitimate interest" is much weaker than "we keep these fields for N months because X". That lands precisely on audit-core's question 2 — the real horizon being the maximum across every co-resident on platform-pg rather than the declared value.

+

Recording the determination converts an assumption into a position that can be argued with. That is what this register exists to produce, and it does not require a lawyer to write down.

+

2. Stop the un-erasable set from growing — a cheaper hedge than the redesign

+

audit-core's stated obstacle is precise and correct: their chain commits to SHA-256(cleartext), audit records are low-entropy, so the retained hash survives key destruction as a confirmation oracle. Guess, hash, compare.

+

The oracle exists because the commitment is over cleartext with no secret in it. A keyed commitment removes it: replace the digest with an HMAC (or a hash over record plus a high-entropy per-subject salt) where the key or salt lives outside the audit store and is destroyable per subject.

+

What that buys, and why it is cheaper than the redesign they costed:

+
  • Destroying the per-subject key makes the commitment untestable — no guess can be confirmed. That is crypto-shredding restored, which their analysis correctly found unavailable under a plain hash.
  • The integrity chain still verifies. It chains over commitment values, and those persist after key destruction; what is lost is the ability to re-derive a commitment from cleartext, which is exactly what erasure means.
  • It is a change at accept time only. No re-processing of stored events, no new storage layer, no change to the read path.
+

This is a suggestion to audit-core, not an instruction, and they own whether it is sound — they know their chain and this repo does not. The claim worth testing with them is narrow: does a keyed commitment restore erasability without breaking chain verification? If yes, the expensive redesign becomes a contingency rather than a plan, and the daily accrual stops.

+

3. Buy the real answer only when something triggers it

+

An external determination costs money and needs a real question. Propose three triggers, any of which fires it:

+
  • the estate first holds a real person's data;
  • a counterparty contract requires a stated erasure position;
  • an actual Art 17 request arrives.
+

Until one fires, the internal determination plus the hedge is a proportionate posture, and severity_at_production: high plus production_rescore: true already guarantee this is re-read before production completes.

+

What this repo would record if the operator agrees

+

status: accepted with the determination attached, escalation answered as rule, and the review kept at 90 days. The finding stays open and visible until the determination exists — an accepted risk with no written basis is the same assumption it started as, wearing a different word.

+

Also worth saying, because it is the cheapest fix of all

+

Every field of personal data that never enters the audit trail is a field with no erasure question. Where an opaque subject identifier would carry the same evidentiary weight as a name or an address, the identifier is strictly better, and that is a audit-core design choice available today at no legal cost.

+
+

Operator decision — 2026-08-20: minimise the identity, keep the accountability

+

The custodian ruled on what goes into an audit record, which is the half of this finding that shrinks the question rather than answering it:

+
  1. Opaque subject identifiers are preferred. Where an opaque id carries the same evidentiary weight as a name or an address, it is the id that goes in.
  2. Agent identifiers where possible. Agents act; attribute to the acting agent identity rather than to a person behind it.
  3. Operator credentials only where necessary. Not as a convenience, not as a default — where the record genuinely requires the operator.
  4. Policy decisions are tracked to the responsible party. Accountability is preserved by linking a decision to who is answerable for it, not by retaining personal data in the record itself.
  5. Zone guarantees may raise the floor. If a zone establishes additional privacy, pseudonymity or anonymity guarantees, those apply — the current level is not a permanent ceiling. That work is zone-engine's (ZONE-WP-0001), and this finding should be re-read when a zone lands one.
+

Why this is more than a preference. Personal data that never enters the audit trail has no erasure question, no exemption to establish, and nothing to argue about with a regulator. Points 1-3 shrink the population the legal basis has to cover; point 4 is what stops that shrinking from costing accountability, which is the usual objection to minimising an audit log.

+

It also changes the shape of the accrual problem. The un-erasable set still grows daily, but each day's records now carry less that would need erasing — so the cost of a "no" answer falls with every event accepted under the new rule rather than rising.

+

What is still outstanding, and stays escalated:

+
  • The written determination of the retention basis — which ground, for which category, for how long. risk-nexus owns writing it; it needs no further authorisation and is scheduled into the next workplan.
  • The trigger list for buying an external answer (first real person's data, first counterparty contract requiring a stated position, first Art 17 request). Proposed, not yet ruled on.
+

The escalation is therefore partially-answered, not closed. make check will keep listing it.

+

Routed to audit-core on 2026-08-20, together with the keyed-commitment question — which remains theirs to judge, because they know their chain.

+
+

The determination exists — 2026-08-20

+

docs/regulatory/RISK-REG-0001 (audit-retention-basis.md). The estate now has a written position rather than an assumption, which was this finding's substance.

+

What it says, in short: Art 6(1)(f) with Art 32 for operator and agent audit records; Art 17(3)(e) for records evidencing a counterparty transaction; Art 17(3)(b) only where a commercial or tax retention duty independently applies, and not extended to application logs generally.

+

The weak part is duration, not existence, and the record says so rather than sounding confident. A position of the form "we keep audit forever because it is audit" is the one that fails; a period per category is what holds. The estate does not have one yet, and the reason is audit-core's own question 2 — at P1 the real horizon is the maximum across every co-resident on platform-pg, not the declared value. That infrastructure fact is the most likely point of failure in the whole position.

+

The operator's minimisation ruling improves this materially: it shrinks the category whose retention is hardest to justify, leaving mostly the row where the ground is strong. A weak argument avoided by holding less data beats a strong one relied upon.

+

The finding stays open. What remains is a retention period per category, which waits on the co-residency horizon, and the trigger list for buying an external determination. The record is reviewed every 90 days with this finding, or immediately on any trigger.

+
  • 2026-08-20 — not clean: The determination now exists: RISK-REG-0001 states the grounds per category and names duration as the weak point. Cadence instant → instant; checked again immediately.
+
+

Operator decision — 2026-08-20: no external determination, and a policy set instead

+

Ruled: the estate will not buy an external determination while it is building. The internal determination (RISK-REG-0001) stands as the recorded position, and the finding moves to accepted — deliberately carried, with a named accepter and a condition that ends it.

+

That is not the same as the trigger list being rejected. The triggers survive as what ends the acceptance: a real person's data, or a counterparty requiring a stated position. What was declined is spending money in advance of either.

+

The compensating control is the thing that makes this defensible. Rather than defer the question, the operator directed that the estate define and keep a set of legal policies for reuse, because future work contexts will need specific positions in place and should retrieve them rather than research them.

+

docs/regulatory/policies/ now catalogues thirteen, keyed by activation condition. Two of them turned out to be already active and unowned: commercial and tax retention (RISK-POL-0009), and the e-invoicing receiving obligation (RISK-POL-0012), live since 2025 with no system in the estate named as the receiving point.

+

Finding an unnoticed live obligation in the first hour of building the catalogue is the argument for having built it. The reason this repo exists is that regulation was previously "consulted and discarded"; a set that answers "what applies if we do X" before anyone does X is the opposite of that.

+

Still open under the acceptance, and unchanged by this ruling: audit-core on whether a keyed commitment restores erasability, and the platform-pg co-residency horizon that decides whether the stated retention periods are achievable. An accepted risk still gets checked.

+
  • 2026-08-20 — not clean: Trigger list ruled: no external determination in build mode; accepted with the legal policy set as the compensating control. Cadence instant → instant; checked again immediately.
+
diff --git a/build/findings/audit-retention-legal-basis/v1/revisions/published-1/index.html b/build/findings/audit-retention-legal-basis/v1/revisions/published-1/index.html new file mode 100644 index 0000000..ef0392f --- /dev/null +++ b/build/findings/audit-retention-legal-basis/v1/revisions/published-1/index.html @@ -0,0 +1,274 @@ + + + + +The legal basis for retaining audit facts against an erasure request has been assumed, never established + +
RISK-F-0008 accepted · published-1 risk-nexus reviewed 2026-08-20generated from canonical source — do not edit

The legal basis for retaining audit facts against an erasure request has been assumed, never established

The estate retains personal data in audit records on grounds nobody had established. Published as a question, because it is one.

Source: risk-nexus · findings/RISK-F-0008-audit-retention-legal-basis-assumed.md · a13d954f8597fd92201746e2d52f031a5a88d969

Review due: 2027-02-20

What is true

+

audit-core holds audit evidence across tenants, targets R2 on the Tenancy Posture retention ladder, and has declared R4 — verified erasure — unreachable by design. The technical reasoning is sound and documented (audit-core/docs/erasure-and-audit.md, framework Decision 4.5.3): crypto-shredding would destroy the evidence the service exists to hold, and their integrity chain commits to a SHA-256 of the cleartext record, which survives key destruction as a confirmation oracle against low-entropy audit rows. Destroying a key does not erase content a surviving commitment can still be tested against.

+

The consequence is that if an Article 17 request arrives naming a data subject in the audit trail, audit-core has no mechanism. The answer would rest on audit evidence being exempt — legal obligation, or legitimate interest in fraud and security investigation.

+

Those grounds are ordinary. Nobody in this estate has actually reached them. audit-core routed the question here on 2026-08-18 rather than absorbing it, saying plainly that they are not competent to answer it and that they have been assuming it. §19.11 of the framework says the same in its own words: the legal basis for retaining audit facts remains a risk/legal question outside the framework.

+
+

Why this repo owns it

+

This is the first finding where fix_owner is risk-nexus.

+

INTENT.md moved regulatory intake here from policy-nexus on 2026-08-17, precisely because deciding what a rule demands of us is a judgement about risk rather than an act of publishing. audit-core routed it by both available routes and asked for an owner rather than an opinion. Refusing it would be this repo declining its own remit.

+

What this repo owns is the record: what the source says, when, and what therefore is or is not established. It does not own legal advice — INTENT.md is explicit — and it does not own the redesign. If the basis does not hold, audit-core owns encrypt-then-hash at accept time, and that is not retrofittable onto events already accepted.

+
+

The three questions, as asked

+
  1. On what basis does the estate retain personal data inside audit records against an erasure request, and does that basis hold for the categories audit-core stores?
  2. Does it hold across the full 30-day recoverable window and beyond, given that at P1 the real erasure horizon is the maximum across every co-resident on platform-pg, not the value audit-core declares?
  3. If it does not hold, R4 is urgent rather than theoretical, and the answer is a substantial redesign with a long lead time.
+
+

Register ruling — 2026-08-19

+

medium today (I3 × L2), high at production, public, escalated on trigger 2.

+

I3: an unmet retention obligation in the audit store crosses from a technical question to an obligation with an outside counterparty, and the remediation is a non-retrofittable redesign rather than a patch. L2: no request has arrived and the estate holds no real data subject's records yet, but the trigger is somebody else's to pull and needs no foothold here.

+

production_rescore: true. The likelihood of an Article 17 request is a function of having real users; that is exactly what production means.

+

Escalation, trigger 2 — "creates or reveals an obligation with an outside counterparty". It reveals one. The estate cannot decide unilaterally that this obligation is small, and the operator is the only party who can commission an answer that is more than an assumption. The ask is narrow: authorise someone to establish the basis, or record that the estate knowingly runs on the assumption and for how long.

+

Disclosure public. Nothing here shortens a path to a defect: it is a question about a legal basis, published as a question. audit-core's technical reasoning is already written down and worth reading.

+
+

How it got here

+

Ruled a note on 2026-08-19 (RISK-N-0002) on the reasoning that no obligation exists yet. That ruling was made without reading audit-core's message, which had been in this repo's inbox since 2026-08-18 and asks specifically for an owner. The note was wrong on the second floor test: recording this does change a decision, because the redesign it might force cannot be retrofitted and therefore has to be decided early or not at all.

+

RISK-N-0002 is superseded by this record.

+
+

Reviews

+
  • 2026-08-19 — promoted from note, graded, escalated. Open at review: has the basis been established or the assumption recorded; has anything changed about what categories audit-core stores.
+
+

Suggested disposition — 2026-08-20, proposed by risk-nexus

+

Offered because this repo owns the finding and the operator asked for a direction. It is not legal advice, and this repo cannot make it into one: what follows is a route to an answer and a hedge against the answer being no.

+

The reframe: the expensive thing is not the legal question

+

audit-core asks whether the exemption holds. That question is cheap to answer badly and expensive to answer properly, and the temptation is to schedule the proper version and wait.

+

But the cost of a "no" is not fixed — it grows daily. The remedy they name, encrypt-then-hash at accept time, cannot be retrofitted onto events already accepted. Every day the estate accepts events under the current scheme, the un-erasable set grows by one day. So the decision that actually needs taking now is not "is it exempt" but "do we keep manufacturing records we could never erase while we find out".

+

That splits the finding into two decisions with very different prices.

+

1. Establish the basis internally, now, for the cost of an afternoon

+

Not a legal opinion — a written determination that says which ground is being relied on, for which category of data, and for how long. Today the estate has no such document; that is the whole finding.

+

The shape it should take, per category of personal data in the audit trail:

+
CategoryLikely groundThe part that is actually arguable
Operator and agent identifiersArt 6(1)(f) legitimate interest in security, with Recital 49 squarely on pointlittle — this is the ordinary case
Counterparty or end-user identifiers in event payloadsArt 17(3)(e), defence of legal claims; Art 6(1)(f)duration, not existence
Commercial records that happen to pass through auditArt 17(3)(b) plus German §257 HGB / §147 AO retentionscope — retention duties cover books and invoices, not application logs generally
+

Where such determinations usually fail is not the ground. It is the retention period: a blanket "we keep audit forever under legitimate interest" is much weaker than "we keep these fields for N months because X". That lands precisely on audit-core's question 2 — the real horizon being the maximum across every co-resident on platform-pg rather than the declared value.

+

Recording the determination converts an assumption into a position that can be argued with. That is what this register exists to produce, and it does not require a lawyer to write down.

+

2. Stop the un-erasable set from growing — a cheaper hedge than the redesign

+

audit-core's stated obstacle is precise and correct: their chain commits to SHA-256(cleartext), audit records are low-entropy, so the retained hash survives key destruction as a confirmation oracle. Guess, hash, compare.

+

The oracle exists because the commitment is over cleartext with no secret in it. A keyed commitment removes it: replace the digest with an HMAC (or a hash over record plus a high-entropy per-subject salt) where the key or salt lives outside the audit store and is destroyable per subject.

+

What that buys, and why it is cheaper than the redesign they costed:

+
  • Destroying the per-subject key makes the commitment untestable — no guess can be confirmed. That is crypto-shredding restored, which their analysis correctly found unavailable under a plain hash.
  • The integrity chain still verifies. It chains over commitment values, and those persist after key destruction; what is lost is the ability to re-derive a commitment from cleartext, which is exactly what erasure means.
  • It is a change at accept time only. No re-processing of stored events, no new storage layer, no change to the read path.
+

This is a suggestion to audit-core, not an instruction, and they own whether it is sound — they know their chain and this repo does not. The claim worth testing with them is narrow: does a keyed commitment restore erasability without breaking chain verification? If yes, the expensive redesign becomes a contingency rather than a plan, and the daily accrual stops.

+

3. Buy the real answer only when something triggers it

+

An external determination costs money and needs a real question. Propose three triggers, any of which fires it:

+
  • the estate first holds a real person's data;
  • a counterparty contract requires a stated erasure position;
  • an actual Art 17 request arrives.
+

Until one fires, the internal determination plus the hedge is a proportionate posture, and severity_at_production: high plus production_rescore: true already guarantee this is re-read before production completes.

+

What this repo would record if the operator agrees

+

status: accepted with the determination attached, escalation answered as rule, and the review kept at 90 days. The finding stays open and visible until the determination exists — an accepted risk with no written basis is the same assumption it started as, wearing a different word.

+

Also worth saying, because it is the cheapest fix of all

+

Every field of personal data that never enters the audit trail is a field with no erasure question. Where an opaque subject identifier would carry the same evidentiary weight as a name or an address, the identifier is strictly better, and that is a audit-core design choice available today at no legal cost.

+
+

Operator decision — 2026-08-20: minimise the identity, keep the accountability

+

The custodian ruled on what goes into an audit record, which is the half of this finding that shrinks the question rather than answering it:

+
  1. Opaque subject identifiers are preferred. Where an opaque id carries the same evidentiary weight as a name or an address, it is the id that goes in.
  2. Agent identifiers where possible. Agents act; attribute to the acting agent identity rather than to a person behind it.
  3. Operator credentials only where necessary. Not as a convenience, not as a default — where the record genuinely requires the operator.
  4. Policy decisions are tracked to the responsible party. Accountability is preserved by linking a decision to who is answerable for it, not by retaining personal data in the record itself.
  5. Zone guarantees may raise the floor. If a zone establishes additional privacy, pseudonymity or anonymity guarantees, those apply — the current level is not a permanent ceiling. That work is zone-engine's (ZONE-WP-0001), and this finding should be re-read when a zone lands one.
+

Why this is more than a preference. Personal data that never enters the audit trail has no erasure question, no exemption to establish, and nothing to argue about with a regulator. Points 1-3 shrink the population the legal basis has to cover; point 4 is what stops that shrinking from costing accountability, which is the usual objection to minimising an audit log.

+

It also changes the shape of the accrual problem. The un-erasable set still grows daily, but each day's records now carry less that would need erasing — so the cost of a "no" answer falls with every event accepted under the new rule rather than rising.

+

What is still outstanding, and stays escalated:

+
  • The written determination of the retention basis — which ground, for which category, for how long. risk-nexus owns writing it; it needs no further authorisation and is scheduled into the next workplan.
  • The trigger list for buying an external answer (first real person's data, first counterparty contract requiring a stated position, first Art 17 request). Proposed, not yet ruled on.
+

The escalation is therefore partially-answered, not closed. make check will keep listing it.

+

Routed to audit-core on 2026-08-20, together with the keyed-commitment question — which remains theirs to judge, because they know their chain.

+
+

The determination exists — 2026-08-20

+

docs/regulatory/RISK-REG-0001 (audit-retention-basis.md). The estate now has a written position rather than an assumption, which was this finding's substance.

+

What it says, in short: Art 6(1)(f) with Art 32 for operator and agent audit records; Art 17(3)(e) for records evidencing a counterparty transaction; Art 17(3)(b) only where a commercial or tax retention duty independently applies, and not extended to application logs generally.

+

The weak part is duration, not existence, and the record says so rather than sounding confident. A position of the form "we keep audit forever because it is audit" is the one that fails; a period per category is what holds. The estate does not have one yet, and the reason is audit-core's own question 2 — at P1 the real horizon is the maximum across every co-resident on platform-pg, not the declared value. That infrastructure fact is the most likely point of failure in the whole position.

+

The operator's minimisation ruling improves this materially: it shrinks the category whose retention is hardest to justify, leaving mostly the row where the ground is strong. A weak argument avoided by holding less data beats a strong one relied upon.

+

The finding stays open. What remains is a retention period per category, which waits on the co-residency horizon, and the trigger list for buying an external determination. The record is reviewed every 90 days with this finding, or immediately on any trigger.

+
  • 2026-08-20 — not clean: The determination now exists: RISK-REG-0001 states the grounds per category and names duration as the weak point. Cadence instant → instant; checked again immediately.
+
+

Operator decision — 2026-08-20: no external determination, and a policy set instead

+

Ruled: the estate will not buy an external determination while it is building. The internal determination (RISK-REG-0001) stands as the recorded position, and the finding moves to accepted — deliberately carried, with a named accepter and a condition that ends it.

+

That is not the same as the trigger list being rejected. The triggers survive as what ends the acceptance: a real person's data, or a counterparty requiring a stated position. What was declined is spending money in advance of either.

+

The compensating control is the thing that makes this defensible. Rather than defer the question, the operator directed that the estate define and keep a set of legal policies for reuse, because future work contexts will need specific positions in place and should retrieve them rather than research them.

+

docs/regulatory/policies/ now catalogues thirteen, keyed by activation condition. Two of them turned out to be already active and unowned: commercial and tax retention (RISK-POL-0009), and the e-invoicing receiving obligation (RISK-POL-0012), live since 2025 with no system in the estate named as the receiving point.

+

Finding an unnoticed live obligation in the first hour of building the catalogue is the argument for having built it. The reason this repo exists is that regulation was previously "consulted and discarded"; a set that answers "what applies if we do X" before anyone does X is the opposite of that.

+

Still open under the acceptance, and unchanged by this ruling: audit-core on whether a keyed commitment restores erasability, and the platform-pg co-residency horizon that decides whether the stated retention periods are achievable. An accepted risk still gets checked.

+
  • 2026-08-20 — not clean: Trigger list ruled: no external determination in build mode; accepted with the legal policy set as the compensating control. Cadence instant → instant; checked again immediately.
+
diff --git a/build/findings/flex-auth-unauthenticated-check/v1/index.html b/build/findings/flex-auth-unauthenticated-check/v1/index.html new file mode 100644 index 0000000..97cc6d9 --- /dev/null +++ b/build/findings/flex-auth-unauthenticated-check/v1/index.html @@ -0,0 +1,245 @@ + + + + +flex-auth /v1/check authenticates no caller + +
RISK-F-0001 fixed · published-1 risk-nexus reviewed 2026-08-20generated from canonical source — do not edit

flex-auth /v1/check authenticates no caller

The estate's authorization oracle authenticated no caller for as long as the endpoint existed. Found by reading, not by monitoring; fixed in two days.

Source: risk-nexus · findings/RISK-F-0001-flex-auth-unauthenticated-check.md · c5517c754bd84b0ebf47878ba0f26df0ecb3b4a4

Review due: 2027-02-20

What is true

+

POST /v1/check and POST /v1/batch_check authenticate no caller. Any workload with network reach to the ClusterIP Service can assert any subject and any tenant and receive an authoritative allow.

+

flex-auth is the estate's authorization oracle. Every service that delegates a decision to it is relying on an answer that anyone able to reach the pod can obtain for any identity they care to name.

+

Self-reported by flex-auth as A0 on their own inbound surface, in their Tenancy Posture review. Their words: "flex-auth is the estate's authorization oracle and it trusts its callers completely."

+
+

How it was found

+

Not by a probe, an incident, or an alert. By flex-auth assessing themselves against the Tenancy Posture A ladder during a review they were asked to do — and their own note says they did not know they were carrying it.

+

That provenance matters for triage: nothing was watching for this, and nothing would have found it. It has presumably been true for as long as the endpoint has existed.

+
+

Exposure, as far as the reporter stated it

+
  • The Service is ClusterIP, so reach requires a workload inside the cluster.
  • No claim was made that network policy restricts which workloads can reach it, and this record does not assume one. If a default-deny NetworkPolicy fronts the service, that materially changes the exposure and should be verified rather than inferred — flex-auth did not state it either way, and I have not checked, because doing so would be reporting on a system I do not own.
+
+

What makes it worse than a single service's defect

+

A false allow from this endpoint is not confined to flex-auth. It is the answer other services act on. tenant-engine separately reports that its own mutations are authorized by flex-auth and that direct authority over its rows would mean "privilege escalation across NetKingdom rather than data tampering confined to one store". The same reasoning applies to a forged allow.

+
+

Owner and state

+

flex-auth owns the fix and has tracked it as FLEX-WP-0015-T02, to ship through the staged-promotion path rather than a direct apply. They classify it as the only urgent item of their five follow-ups. Nothing is asked of them by this record beyond what they have already committed to.

+
+

What this repo is asked to decide

+
  1. Severity. Not the reporter's to set.
  2. Disclosure. Build mode is currently public-by-default, and this is precisely the class of finding where that stops being obviously right — a live authorization bypass in the service every other service trusts. The controlled-disclosure scheme this repo anticipates does not exist yet, so the choice today is publish or hold, with no mechanism between them.
  3. Escalation. Whether this reaches the operator personally. The candidate triggers in INTENT include "anything exposing real tenant data" — this exposes the decision that governs access to it, which may or may not be the same thing, and that judgement is this repo's.
+
+ +

Register ruling — 2026-08-19

+

critical (I4 × L3, no fidelity modifier), embargoed until FLEX-WP-0015-T02 ships, escalated to the operator on trigger 1.

+

The question this finding put — whether governing access to tenant data counts as exposing it — is answered yes. An authorization oracle that can be forged is not one step removed from the data; it is the step.

+

Impact is I4 because a forged allow does not stay here: it is the answer other services act on, and tenant-engine has stated what direct authority over its rows would mean. Likelihood is L3 — the normal working set, inside the cluster, no additional step — and the register follows the reporter in neither assuming a default-deny NetworkPolicy nor assuming its absence.

+

No fidelity modifier: this endpoint answers honestly about a caller it never checked. The false-record hazard lives in RISK-F-0002's constraint, where a consumer of this endpoint would begin signing records asserting an authorization that was never made. That constraint binds this finding's remediation: ops-warden's policy.enabled must not be turned on until /v1/check authenticates its callers, and the ordering is

+
flex-auth warn-only -> ops-warden gate presents its SA token -> logs clean
+                    -> flex-auth fail-closed -> ops-warden policy.enabled: true
+

Nothing further is asked of flex-auth beyond what they have committed to, except one fact only they can supply: is there a default-deny NetworkPolicy in front of the Service? It is the single fact that would most change this grade, and it is the first question at review.

+

Reasoning: docs/rulings/2026-08-19-first-grading.md.

+
+

Reviews

+
  • 2026-08-19 — graded. Next review 2026-08-26 (critical → 7 days). Open at review: the NetworkPolicy question; whether FLEX-WP-0015-T02 has moved; whether the embargo still holds.
+
+

Re-grade and close — 2026-08-19 (same day)

+

Corrected from critical to high, and closed as fixed. Both changes come from messages that were already in this repo's inbox when the first grade was set. The register graded before it read them.

+

The exposure was narrower than graded. flex-auth answered the NetworkPolicy question on 2026-08-18: both production Deployments ship a NetworkPolicy in the same manifest, and it is narrower than default-deny — ingress restricted to one namespaceSelector plus one podSelector on port 8080, egress empty. In force since before the period the A0 describes. So the reachable set was never "any pod in the cluster"; it was the single paired workload per Deployment.

+

That is L2, not L3. Impact stays I4 — what a forged allow reaches does not change — so the grade is high. flex-auth also corrected their own earlier phrasing to ops-warden in the same message, unprompted, and that correction is why the fact reached this register at all.

+

Three caveats flex-auth asked to be recorded rather than taken from them, and they are why the grade did not fall further: label selectors are network position, not identity; the policy could not bind the asserted resource.system, which is what made cross-system impersonation possible; and enforcement depends on a CNI they could not verify from a cluster where kubectl returned Unauthorized. They said so rather than letting a manifest stand in for a probe.

+

It is fixed. On 2026-08-19 flex-auth reported both production Deployments enforcing ADR-0004 TokenReview, with live unbound-request probes returning 401 rather than a decision, on both the user-engine and tenant-engine pins. FLEX-WP-0015 is finished and tenancy.current.A is 2. That is a probe against the running system, which is the standard docs/method/review.md sets for closing: something concrete read, not something been told.

+

Disclosure flips to public. The embargo condition was "FLEX-WP-0015-T02 ships to production" and it is met. Handover to policy-nexus is the next step and is not done yet.

+

The escalation is withdrawn without being sent. It was pending-operator for roughly four hours, and the fix landed first. Withdrawing it is correct — escalating a fixed defect makes the operator the queue for history — but the register does not get to be pleased about it. The escalation would have been sent on facts that were already stale, and only luck put the fix on the same day.

+

What this cost, recorded because it is the register's own defect. The NetworkPolicy answer arrived 2026-08-18. The fix notice arrived 2026-08-19 at 12:35. The first grading ran at 21:14 the same day, on neither. Reading the inbox is now step 0 of grading and question 0 of every review — see docs/method/review.md — and this finding is the case that bought it.

+
+

Reviews

+
  • 2026-08-19 — re-graded high, closed fixed, disclosure public, escalation withdrawn. Remaining: handover to policy-nexus; the CNI enforcement question is flex-auth's and no longer this finding's.
  • 2026-08-20 — not clean: Publication handover requested; publication front-matter applied and the wait on policy-nexus typed. Cadence instant → instant; checked again immediately.
+
diff --git a/build/findings/flex-auth-unauthenticated-check/v1/revisions/published-1/index.html b/build/findings/flex-auth-unauthenticated-check/v1/revisions/published-1/index.html new file mode 100644 index 0000000..7f3a3a0 --- /dev/null +++ b/build/findings/flex-auth-unauthenticated-check/v1/revisions/published-1/index.html @@ -0,0 +1,245 @@ + + + + +flex-auth /v1/check authenticates no caller + +
RISK-F-0001 fixed · published-1 risk-nexus reviewed 2026-08-20generated from canonical source — do not edit

flex-auth /v1/check authenticates no caller

The estate's authorization oracle authenticated no caller for as long as the endpoint existed. Found by reading, not by monitoring; fixed in two days.

Source: risk-nexus · findings/RISK-F-0001-flex-auth-unauthenticated-check.md · a13d954f8597fd92201746e2d52f031a5a88d969

Review due: 2027-02-20

What is true

+

POST /v1/check and POST /v1/batch_check authenticate no caller. Any workload with network reach to the ClusterIP Service can assert any subject and any tenant and receive an authoritative allow.

+

flex-auth is the estate's authorization oracle. Every service that delegates a decision to it is relying on an answer that anyone able to reach the pod can obtain for any identity they care to name.

+

Self-reported by flex-auth as A0 on their own inbound surface, in their Tenancy Posture review. Their words: "flex-auth is the estate's authorization oracle and it trusts its callers completely."

+
+

How it was found

+

Not by a probe, an incident, or an alert. By flex-auth assessing themselves against the Tenancy Posture A ladder during a review they were asked to do — and their own note says they did not know they were carrying it.

+

That provenance matters for triage: nothing was watching for this, and nothing would have found it. It has presumably been true for as long as the endpoint has existed.

+
+

Exposure, as far as the reporter stated it

+
  • The Service is ClusterIP, so reach requires a workload inside the cluster.
  • No claim was made that network policy restricts which workloads can reach it, and this record does not assume one. If a default-deny NetworkPolicy fronts the service, that materially changes the exposure and should be verified rather than inferred — flex-auth did not state it either way, and I have not checked, because doing so would be reporting on a system I do not own.
+
+

What makes it worse than a single service's defect

+

A false allow from this endpoint is not confined to flex-auth. It is the answer other services act on. tenant-engine separately reports that its own mutations are authorized by flex-auth and that direct authority over its rows would mean "privilege escalation across NetKingdom rather than data tampering confined to one store". The same reasoning applies to a forged allow.

+
+

Owner and state

+

flex-auth owns the fix and has tracked it as FLEX-WP-0015-T02, to ship through the staged-promotion path rather than a direct apply. They classify it as the only urgent item of their five follow-ups. Nothing is asked of them by this record beyond what they have already committed to.

+
+

What this repo is asked to decide

+
  1. Severity. Not the reporter's to set.
  2. Disclosure. Build mode is currently public-by-default, and this is precisely the class of finding where that stops being obviously right — a live authorization bypass in the service every other service trusts. The controlled-disclosure scheme this repo anticipates does not exist yet, so the choice today is publish or hold, with no mechanism between them.
  3. Escalation. Whether this reaches the operator personally. The candidate triggers in INTENT include "anything exposing real tenant data" — this exposes the decision that governs access to it, which may or may not be the same thing, and that judgement is this repo's.
+
+ +

Register ruling — 2026-08-19

+

critical (I4 × L3, no fidelity modifier), embargoed until FLEX-WP-0015-T02 ships, escalated to the operator on trigger 1.

+

The question this finding put — whether governing access to tenant data counts as exposing it — is answered yes. An authorization oracle that can be forged is not one step removed from the data; it is the step.

+

Impact is I4 because a forged allow does not stay here: it is the answer other services act on, and tenant-engine has stated what direct authority over its rows would mean. Likelihood is L3 — the normal working set, inside the cluster, no additional step — and the register follows the reporter in neither assuming a default-deny NetworkPolicy nor assuming its absence.

+

No fidelity modifier: this endpoint answers honestly about a caller it never checked. The false-record hazard lives in RISK-F-0002's constraint, where a consumer of this endpoint would begin signing records asserting an authorization that was never made. That constraint binds this finding's remediation: ops-warden's policy.enabled must not be turned on until /v1/check authenticates its callers, and the ordering is

+
flex-auth warn-only -> ops-warden gate presents its SA token -> logs clean
+                    -> flex-auth fail-closed -> ops-warden policy.enabled: true
+

Nothing further is asked of flex-auth beyond what they have committed to, except one fact only they can supply: is there a default-deny NetworkPolicy in front of the Service? It is the single fact that would most change this grade, and it is the first question at review.

+

Reasoning: docs/rulings/2026-08-19-first-grading.md.

+
+

Reviews

+
  • 2026-08-19 — graded. Next review 2026-08-26 (critical → 7 days). Open at review: the NetworkPolicy question; whether FLEX-WP-0015-T02 has moved; whether the embargo still holds.
+
+

Re-grade and close — 2026-08-19 (same day)

+

Corrected from critical to high, and closed as fixed. Both changes come from messages that were already in this repo's inbox when the first grade was set. The register graded before it read them.

+

The exposure was narrower than graded. flex-auth answered the NetworkPolicy question on 2026-08-18: both production Deployments ship a NetworkPolicy in the same manifest, and it is narrower than default-deny — ingress restricted to one namespaceSelector plus one podSelector on port 8080, egress empty. In force since before the period the A0 describes. So the reachable set was never "any pod in the cluster"; it was the single paired workload per Deployment.

+

That is L2, not L3. Impact stays I4 — what a forged allow reaches does not change — so the grade is high. flex-auth also corrected their own earlier phrasing to ops-warden in the same message, unprompted, and that correction is why the fact reached this register at all.

+

Three caveats flex-auth asked to be recorded rather than taken from them, and they are why the grade did not fall further: label selectors are network position, not identity; the policy could not bind the asserted resource.system, which is what made cross-system impersonation possible; and enforcement depends on a CNI they could not verify from a cluster where kubectl returned Unauthorized. They said so rather than letting a manifest stand in for a probe.

+

It is fixed. On 2026-08-19 flex-auth reported both production Deployments enforcing ADR-0004 TokenReview, with live unbound-request probes returning 401 rather than a decision, on both the user-engine and tenant-engine pins. FLEX-WP-0015 is finished and tenancy.current.A is 2. That is a probe against the running system, which is the standard docs/method/review.md sets for closing: something concrete read, not something been told.

+

Disclosure flips to public. The embargo condition was "FLEX-WP-0015-T02 ships to production" and it is met. Handover to policy-nexus is the next step and is not done yet.

+

The escalation is withdrawn without being sent. It was pending-operator for roughly four hours, and the fix landed first. Withdrawing it is correct — escalating a fixed defect makes the operator the queue for history — but the register does not get to be pleased about it. The escalation would have been sent on facts that were already stale, and only luck put the fix on the same day.

+

What this cost, recorded because it is the register's own defect. The NetworkPolicy answer arrived 2026-08-18. The fix notice arrived 2026-08-19 at 12:35. The first grading ran at 21:14 the same day, on neither. Reading the inbox is now step 0 of grading and question 0 of every review — see docs/method/review.md — and this finding is the case that bought it.

+
+

Reviews

+
  • 2026-08-19 — re-graded high, closed fixed, disclosure public, escalation withdrawn. Remaining: handover to policy-nexus; the CNI enforcement question is flex-auth's and no longer this finding's.
  • 2026-08-20 — not clean: Publication handover requested; publication front-matter applied and the wait on policy-nexus typed. Cadence instant → instant; checked again immediately.
+
diff --git a/build/index.html b/build/index.html index ef95de9..4d1e747 100644 --- a/build/index.html +++ b/build/index.html @@ -183,4 +183,4 @@ footer{border-top:2px solid var(--ink);margin-top:20px;padding-top:22px;font-fam .route .tag{font-family:var(--font-mono);font-size:9px;letter-spacing:.1em;text-transform:uppercase;color:var(--brass);display:block;margin-bottom:8px} a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-offset:3px} @media (prefers-reduced-motion:reduce){*{animation:none!important;transition:none!important}} -
policy surfacegenerated from canonical sources — do not edit

Coulomb Policy Nexus

Canon and architecture decisions at stable addresses, with visible currency.

DocumentStatusLifecycleRevisionOwnerReviewedReview dueCurrency
NetKingdom Tenancy Posture v0.1proposedactivedraft-14net-kingdom2026-08-232027-02-23current
Autonomy Lanes (Fleet) v0.1acceptedactiveaccepted-1the-custodian2026-08-312027-02-28current
Contribution Convention v0.1acceptedactiveaccepted-1the-custodian2026-08-312027-02-28current
Project Repository Flavor (prj-) v0.1acceptedactiveaccepted-1the-custodian2026-08-312027-02-28current
Work Record Types & Identity (Fleet) v0.1acceptedactiveaccepted-1the-custodian2026-08-312027-02-28current
Workplan Terminology (Fleet) v0.1acceptedactiveaccepted-1the-custodian2026-08-312027-02-28current
Coulomb estate architectureproposedactivedraft-3the-custodian2026-08-312027-02-28current
Railiance architectureproposedactivedraft-3railiance-master2026-08-312027-02-28current
NetKingdom architectureproposedactivedraft-3net-kingdom2026-08-312027-02-28current
State Hub architectureproposedactivedraft-3state-hub2026-08-312027-02-28current
Policy Nexus architectureproposedactivedraft-1the-custodian2026-08-182027-02-18current
Policy addressing and permanenceacceptedactiveaccepted-1the-custodian2026-08-182027-02-18current
Repository Prefix Architectureacceptedactiveaccepted-1railiance-master2026-07-252027-01-25current
Wave 1 rail-kubernetes Boundaryacceptedactiveaccepted-1railiance-master2026-07-252027-01-25current
First-Wave rapp Selectionacceptedactiveaccepted-1railiance-master2026-07-252027-01-25current
First-Wave reef Rolloutacceptedactiveaccepted-1railiance-master2026-07-262027-01-26current
Derived Rail Compositionacceptedactiveaccepted-1railiance-master2026-07-262027-01-26current
Reef Production Admissionacceptedactiveaccepted-2railiance-master2026-08-292027-02-28current
Rapp Declaration Contractacceptedactiveaccepted-2railiance-master2026-08-232027-02-23current
Private-by-default Exposureacceptedactiveaccepted-2railiance-master2026-08-292027-02-28current
Activity-Core as Coulomb Org Event Bridgeacceptedactiveaccepted-2activity-core2026-05-142026-11-14current
Markdown-as-Definition Format for Event Types and ActivityDefinitionsacceptedactiveaccepted-2activity-core2026-05-142026-11-14current
Rule vs. Instruction Model and Expression DSLacceptedactiveaccepted-2activity-core2026-05-142026-11-14current
The Producer Trust Boundary — Guardrails and Error-Correction for Untrusted Outputacceptedactiveaccepted-2activity-core2026-06-262026-12-26current
Ops runs vs development work records — claim queue and plane splitacceptedactiveaccepted-2activity-core2026-08-032027-02-03current
ADR-0001 — The routing catalog is a pointer layer, never a second copyacceptedactive1ops-warden2026-08-182027-02-18current
ADR-0002 — ops-warden is a transparent conduit, never a secret brokeracceptedactive1ops-warden2026-08-182027-02-18current
ADR-0003 — Cover gaps, but never silently own themacceptedactive1ops-warden2026-08-182027-02-18current
ADR-0004 — High-risk lanes refuse raw value streaming to agent sessionsacceptedactive1ops-warden2026-08-182027-02-18current
ADR-0005 — Implement one lane narrowly, route everything elseacceptedactive1ops-warden2026-08-182027-02-18current
Workplans and Work Items Are Repository Artefactsacceptedactiveaccepted-2the-custodian2026-08-312027-02-28current
Custodian Agent Runtime — v0.1 Bootstrap Designacceptedactiveaccepted-1the-custodian2026-03-122026-09-12current
Materialized Derived State with Fingerprint Invalidation for Repo-Sourced Dataacceptedactiveaccepted-2the-custodian2026-08-312027-02-28current
Connectivity-First Network Posture for Custodian Infrastructureacceptedactiveaccepted-1the-custodian2026-03-262026-09-26current
Cross-Repo Workplans Live in Dedicated Project Reposacceptedactiveaccepted-1the-custodian2026-06-222026-12-22current
Canon Federation and Concept Ownership Across InfoTech and Commerceacceptedactiveaccepted-1the-custodian2026-08-172027-02-17current
Workplan Identity Uniqueness, Single Registrar, and Repo Worker Topologyacceptedactiveaccepted-2the-custodian2026-08-312027-02-28current
Hub Authority, Local Cache, and the Two Kinds of Hub Dataproposedactivedraft-2the-custodian2026-08-312027-02-28current
Federated Namespaces: Four Planes, Declared Posture, and the Limits of Reconciliationproposedactivedraft-2the-custodian2026-08-172027-02-17current
ADR-0001 — S3 owns platform services, not the substrate beneath themacceptedactive1.0railiance-platform2026-08-172027-02-17current
ADR-0002 — S3 owns the placement rule; the package repo owns the numberproposedactive1.0railiance-platform2026-08-172027-02-17current
ADR-0003 — Decisions that bind others live in docs/adr, not only in the State Hubacceptedactive1.0railiance-platform2026-08-172027-02-17current
NetKingdom IAM Profile v0.3acceptedactiveaccepted-1net-kingdom2026-08-222027-02-22current
Recursive Multi-Tenant Identity and Authorization Architectureacceptedactive1net-kingdom2026-08-222027-02-22current
Security Orchestration Boundaryacceptedactive1net-kingdom2026-08-222027-02-22current
Object Storage STS Credential Vending Boundaryacceptedactive1net-kingdom2026-08-222027-02-22current
Orchestration vs Dependency, and Self-Coherent Intentacceptedactive1net-kingdom2026-08-222027-02-22current
NetKingdom IAM Profile Ownership And Version Governanceacceptedactive1net-kingdom2026-08-222027-02-22current
Playbook Capability Contract Ownershipacceptedactive1net-kingdom2026-08-222027-02-22current
Tenant Onboarding Grouping Taxonomyacceptedactive2net-kingdom2026-08-222027-02-22current
Tenant Capability Roles, Carrying Mechanism, and Tenant-Engine Ownershipacceptedactive1net-kingdom2026-08-222027-02-22current
NetKingdom Railiance Workload Packaging and Relational Platformacceptedactive1net-kingdom2026-08-222027-02-22current
k3s API is tunnel-onlyacceptedactiveaccepted-1railiance-infra2026-08-222027-02-22current
Profile-driven execution selection over the ops_run pull queueacceptedactiveaccepted-1activity-core2026-08-212027-02-21current
Code-registered bounded operations are the only local mutation exceptionacceptedactiveaccepted-1activity-core2026-08-232027-02-23current
ADR-0007 — Build-stage permissiveness stops at credential disclosureacceptedactive1ops-warden2026-08-192027-02-19current
ADR-0008 — A lane's risk grade covers every field its path disclosesacceptedactive1ops-warden2026-08-212027-02-21current
ADR-0009 — Adopt security-zones v0.1 as a consumeracceptedactive1ops-warden2026-08-222026-11-22current
ADR-0010 — ops-warden is Staff: lanes, not rules, and one declared engine gapacceptedactive1ops-warden2026-08-282026-11-28current
NetKingdom Security-Layer Interaction Boundaryacceptedactiveaccepted-1railiance-master2026-08-292027-02-28current
What the Hub Projects: Forge as Projection Source, Working Copies as Preliminary Overlayacceptedactive1.0the-custodian2026-08-252027-02-25current
NetKingdom Posture Feedback v0.1proposedactive0.1net-kingdom2026-08-232026-11-23current
NetKingdom Security Layer Model v0.7acceptedactive0.7gate-house2026-08-282026-11-28current
NetKingdom Security Scenario Composition v0.1proposedactive0.1net-kingdom2026-08-232026-11-23current
NetKingdom Security Zones v0.1proposedactive0.1zone-engine2026-08-222026-11-22current
+
policy surfacegenerated from canonical sources — do not edit

Coulomb Policy Nexus

Governing documents and public risk records at stable addresses, with visible currency.

DocumentStatusLifecycleRevisionOwnerReviewedReview dueCurrency
NetKingdom Tenancy Posture v0.1proposedactivedraft-14net-kingdom2026-08-232027-02-23current
Autonomy Lanes (Fleet) v0.1acceptedactiveaccepted-1the-custodian2026-08-312027-02-28current
Contribution Convention v0.1acceptedactiveaccepted-1the-custodian2026-08-312027-02-28current
Project Repository Flavor (prj-) v0.1acceptedactiveaccepted-1the-custodian2026-08-312027-02-28current
Work Record Types & Identity (Fleet) v0.1acceptedactiveaccepted-1the-custodian2026-08-312027-02-28current
Workplan Terminology (Fleet) v0.1acceptedactiveaccepted-1the-custodian2026-08-312027-02-28current
Coulomb estate architectureproposedactivedraft-3the-custodian2026-08-312027-02-28current
Railiance architectureproposedactivedraft-3railiance-master2026-08-312027-02-28current
NetKingdom architectureproposedactivedraft-3net-kingdom2026-08-312027-02-28current
State Hub architectureproposedactivedraft-3state-hub2026-08-312027-02-28current
Policy Nexus architectureproposedactivedraft-1the-custodian2026-08-182027-02-18current
Policy addressing and permanenceacceptedactiveaccepted-1the-custodian2026-08-182027-02-18current
Repository Prefix Architectureacceptedactiveaccepted-1railiance-master2026-07-252027-01-25current
Wave 1 rail-kubernetes Boundaryacceptedactiveaccepted-1railiance-master2026-07-252027-01-25current
First-Wave rapp Selectionacceptedactiveaccepted-1railiance-master2026-07-252027-01-25current
First-Wave reef Rolloutacceptedactiveaccepted-1railiance-master2026-07-262027-01-26current
Derived Rail Compositionacceptedactiveaccepted-1railiance-master2026-07-262027-01-26current
Reef Production Admissionacceptedactiveaccepted-2railiance-master2026-08-292027-02-28current
Rapp Declaration Contractacceptedactiveaccepted-2railiance-master2026-08-232027-02-23current
Private-by-default Exposureacceptedactiveaccepted-2railiance-master2026-08-292027-02-28current
Activity-Core as Coulomb Org Event Bridgeacceptedactiveaccepted-2activity-core2026-05-142026-11-14current
Markdown-as-Definition Format for Event Types and ActivityDefinitionsacceptedactiveaccepted-2activity-core2026-05-142026-11-14current
Rule vs. Instruction Model and Expression DSLacceptedactiveaccepted-2activity-core2026-05-142026-11-14current
The Producer Trust Boundary — Guardrails and Error-Correction for Untrusted Outputacceptedactiveaccepted-2activity-core2026-06-262026-12-26current
Ops runs vs development work records — claim queue and plane splitacceptedactiveaccepted-2activity-core2026-08-032027-02-03current
ADR-0001 — The routing catalog is a pointer layer, never a second copyacceptedactive1ops-warden2026-08-182027-02-18current
ADR-0002 — ops-warden is a transparent conduit, never a secret brokeracceptedactive1ops-warden2026-08-182027-02-18current
ADR-0003 — Cover gaps, but never silently own themacceptedactive1ops-warden2026-08-182027-02-18current
ADR-0004 — High-risk lanes refuse raw value streaming to agent sessionsacceptedactive1ops-warden2026-08-182027-02-18current
ADR-0005 — Implement one lane narrowly, route everything elseacceptedactive1ops-warden2026-08-182027-02-18current
Workplans and Work Items Are Repository Artefactsacceptedactiveaccepted-2the-custodian2026-08-312027-02-28current
Custodian Agent Runtime — v0.1 Bootstrap Designacceptedactiveaccepted-1the-custodian2026-03-122026-09-12current
Materialized Derived State with Fingerprint Invalidation for Repo-Sourced Dataacceptedactiveaccepted-2the-custodian2026-08-312027-02-28current
Connectivity-First Network Posture for Custodian Infrastructureacceptedactiveaccepted-1the-custodian2026-03-262026-09-26current
Cross-Repo Workplans Live in Dedicated Project Reposacceptedactiveaccepted-1the-custodian2026-06-222026-12-22current
Canon Federation and Concept Ownership Across InfoTech and Commerceacceptedactiveaccepted-1the-custodian2026-08-172027-02-17current
Workplan Identity Uniqueness, Single Registrar, and Repo Worker Topologyacceptedactiveaccepted-2the-custodian2026-08-312027-02-28current
Hub Authority, Local Cache, and the Two Kinds of Hub Dataproposedactivedraft-2the-custodian2026-08-312027-02-28current
Federated Namespaces: Four Planes, Declared Posture, and the Limits of Reconciliationproposedactivedraft-2the-custodian2026-08-172027-02-17current
ADR-0001 — S3 owns platform services, not the substrate beneath themacceptedactive1.0railiance-platform2026-08-172027-02-17current
ADR-0002 — S3 owns the placement rule; the package repo owns the numberproposedactive1.0railiance-platform2026-08-172027-02-17current
ADR-0003 — Decisions that bind others live in docs/adr, not only in the State Hubacceptedactive1.0railiance-platform2026-08-172027-02-17current
NetKingdom IAM Profile v0.3acceptedactiveaccepted-1net-kingdom2026-08-222027-02-22current
Recursive Multi-Tenant Identity and Authorization Architectureacceptedactive1net-kingdom2026-08-222027-02-22current
Security Orchestration Boundaryacceptedactive1net-kingdom2026-08-222027-02-22current
Object Storage STS Credential Vending Boundaryacceptedactive1net-kingdom2026-08-222027-02-22current
Orchestration vs Dependency, and Self-Coherent Intentacceptedactive1net-kingdom2026-08-222027-02-22current
NetKingdom IAM Profile Ownership And Version Governanceacceptedactive1net-kingdom2026-08-222027-02-22current
Playbook Capability Contract Ownershipacceptedactive1net-kingdom2026-08-222027-02-22current
Tenant Onboarding Grouping Taxonomyacceptedactive2net-kingdom2026-08-222027-02-22current
Tenant Capability Roles, Carrying Mechanism, and Tenant-Engine Ownershipacceptedactive1net-kingdom2026-08-222027-02-22current
NetKingdom Railiance Workload Packaging and Relational Platformacceptedactive1net-kingdom2026-08-222027-02-22current
k3s API is tunnel-onlyacceptedactiveaccepted-1railiance-infra2026-08-222027-02-22current
Profile-driven execution selection over the ops_run pull queueacceptedactiveaccepted-1activity-core2026-08-212027-02-21current
Code-registered bounded operations are the only local mutation exceptionacceptedactiveaccepted-1activity-core2026-08-232027-02-23current
ADR-0007 — Build-stage permissiveness stops at credential disclosureacceptedactive1ops-warden2026-08-192027-02-19current
ADR-0008 — A lane's risk grade covers every field its path disclosesacceptedactive1ops-warden2026-08-212027-02-21current
ADR-0009 — Adopt security-zones v0.1 as a consumeracceptedactive1ops-warden2026-08-222026-11-22current
ADR-0010 — ops-warden is Staff: lanes, not rules, and one declared engine gapacceptedactive1ops-warden2026-08-282026-11-28current
NetKingdom Security-Layer Interaction Boundaryacceptedactiveaccepted-1railiance-master2026-08-292027-02-28current
What the Hub Projects: Forge as Projection Source, Working Copies as Preliminary Overlayacceptedactive1.0the-custodian2026-08-252027-02-25current
NetKingdom Posture Feedback v0.1proposedactive0.1net-kingdom2026-08-232026-11-23current
NetKingdom Security Layer Model v0.7acceptedactive0.7gate-house2026-08-282026-11-28current
NetKingdom Security Scenario Composition v0.1proposedactive0.1net-kingdom2026-08-232026-11-23current
NetKingdom Security Zones v0.1proposedactive0.1zone-engine2026-08-222026-11-22current
flex-auth /v1/check authenticates no callerfixedactivepublished-1risk-nexus2026-08-202027-02-20current
The legal basis for retaining audit facts against an erasure request has been assumed, never establishedacceptedactivepublished-1risk-nexus2026-08-202027-02-20current
Severity: how bad, how likely, and what is not a risk at alladoptedactiveadopted-1risk-nexus2026-08-202027-02-20current
Disclosure: publish now, hold, or restrictadoptedactiveadopted-1risk-nexus2026-08-202027-02-20current
Review and expiry: what happens when nobody looksadoptedactiveadopted-1risk-nexus2026-08-202027-02-20current
What this register may verify for itself, and what it must take from ownersadoptedactiveadopted-1risk-nexus2026-08-202027-02-20current
Waiting: how this register depends on other people without becoming a queueadoptedactiveadopted-1risk-nexus2026-08-202027-02-20current
diff --git a/build/methods/risk-dependencies/v1/index.html b/build/methods/risk-dependencies/v1/index.html new file mode 100644 index 0000000..ce1db22 --- /dev/null +++ b/build/methods/risk-dependencies/v1/index.html @@ -0,0 +1,238 @@ + + + + +Waiting + +
RISK-METHOD-DEPENDENCIES adopted · adopted-1 risk-nexus reviewed 2026-08-20generated from canonical source — do not edit

Waiting

Source: risk-nexus · docs/method/dependencies.md · c5517c754bd84b0ebf47878ba0f26df0ecb3b4a4

Review due: 2027-02-20

By 2026-08-20 the register had accumulated nine waits in four days, one of them four hops deep: RISK-F-0003's embargo waited on RISK-F-0009, which waited on railiance-platform fixing a deny set, which waited on someone verifying it against live OpenBao, which waited on a credential nobody has.

+

Nothing in that chain is anyone's fault, and every link was individually reasonable. That is exactly why it needs a rule: deep dependencies are not built deliberately, they accrete one sensible step at a time.

+

The principle

+

The register never waits to decide. It decides, and revises when told.

+

A wait is a refinement pending, not a decision pending. If the register cannot act until someone answers, the register has made that person's silence into its own paralysis — and INTENT.md is explicit that a register nobody acts on is worse than none.

+
+

The four rules

+

1. Every wait is typed

+

No record may say "waiting on X". A wait carries six things:

+
waiting_on:
+  - who: tenant-engine
+    what: "confirm or correct the unfiltered events() read; open fix tracking"
+    since: "2026-08-19"
+    would_change: "grade rises if the log carries payload rather than metadata"
+    default: "grade stands as recorded; absent fix tracking noted as a stall"
+    default_at: "2026-09-03"
+

would_change is the discipline. If nobody can say what the answer would change, there is nothing being waited for, and the wait should be deleted rather than carried.

+

2. Depth one

+

A record may wait on at most one other record, and never on a record that is itself waiting.

+

When the chain would go deeper, the far end is cut: the record takes its own default and says which unresolved thing it declined to wait for. Two hops is the point at which nobody can see the whole line any more, and a wait nobody can see is indistinguishable from a thing that was dropped.

+

Applied 2026-08-20: RISK-F-0009's embargo condition was "verified against live OpenBao", which no one in the estate can currently do. It now lifts on railiance-platform reporting the coverage, with live verification recorded as a refinement rather than a condition. That cut the RISK-F-0003 chain from four hops to two.

+

3. Defaults are dates, and defaults are pessimistic

+

Every wait resolves on a date whether or not anyone answers. The default is the reading the stated facts already support — never a hold, never a downgrade earned by silence.

+

This is what removes the incentive to wait. Silence does not buy an owner a softer grade or a quieter register; it costs them the grade the evidence supports, which is usually the one they would want corrected. Answering is how a grade improves, and that is the right shape for the incentive.

+

The register says so in advance, to the owner, in writing. A default nobody was warned about is an ambush, not a rule.

+

4. A condition naming somebody else's action carries a date beside it

+

"Embargo lifts when X ships" is a dependency with no end. "Lifts when X ships, or is re-decided on 2026-09-20" terminates.

+

Re-decided is not the same as lifted — the re-decision may extend the hold with a fresh reason. What it may not do is extend by default, which is how holds quietly become permanent.

+
+

What this does not solve

+

Some dependencies are real and cannot be defaulted away. Nobody can verify an OpenBao policy without a token, and no rule here conjures one.

+

What the rules do is stop that from propagating: the register grades on what is stated, records what it could not verify, and keeps its own position independent of the blockage. docs/method/verification.md bounds what this repo can establish itself, and every grade resting on a document rather than a probe says so on its face.

+
+

Waits outlive statuses

+

A finding that is fixed can still owe something. RISK-F-0001 was closed on 2026-08-19 and is still waiting on policy-nexus for the publication entry that turns disclosure: public into an actual address.

+

So the waiting list is built from every finding, not from the watched ones. A closed record with an open obligation is precisely the thing that goes quiet, because nothing is prompting anyone to look at it any more.

+
+

A wait is not a findings-only idea

+

Adopting a rule is nobody's finding. Registering a canon kind is nobody's finding. Publishing a document is nobody's finding. All three are obligations someone owes, and each one that lived outside the mechanism was invisible to it.

+

So waits attach to any record this repo keeps — findings, regulatory records, workplans — and make check reports them together. RISK-WP-0001 carries two: the escalation rule that is producing decisions while still status: proposed, and the canon question about what kind of thing a finding is.

+

The first of those has the most uncomfortable default in the register, and it points inward: if the rule is not adopted by 2026-09-17, it is recorded as de facto in force but unratified, and every escalation sent under it says so on its face. That is worse than either adopting or rejecting it, which is the point — a draft that quietly governs is the thing this register was built to notice.

+
+

Where the waits are visible

+

make check reports every open wait with its age, its owner and its default date, flags any default that has come due, and flags any wait that points at a record which is itself waiting — a depth-two violation, caught by tooling rather than by someone noticing.

+
diff --git a/build/methods/risk-dependencies/v1/revisions/adopted-1/index.html b/build/methods/risk-dependencies/v1/revisions/adopted-1/index.html new file mode 100644 index 0000000..5739518 --- /dev/null +++ b/build/methods/risk-dependencies/v1/revisions/adopted-1/index.html @@ -0,0 +1,238 @@ + + + + +Waiting + +
RISK-METHOD-DEPENDENCIES adopted · adopted-1 risk-nexus reviewed 2026-08-20generated from canonical source — do not edit

Waiting

Source: risk-nexus · docs/method/dependencies.md · a13d954f8597fd92201746e2d52f031a5a88d969

Review due: 2027-02-20

By 2026-08-20 the register had accumulated nine waits in four days, one of them four hops deep: RISK-F-0003's embargo waited on RISK-F-0009, which waited on railiance-platform fixing a deny set, which waited on someone verifying it against live OpenBao, which waited on a credential nobody has.

+

Nothing in that chain is anyone's fault, and every link was individually reasonable. That is exactly why it needs a rule: deep dependencies are not built deliberately, they accrete one sensible step at a time.

+

The principle

+

The register never waits to decide. It decides, and revises when told.

+

A wait is a refinement pending, not a decision pending. If the register cannot act until someone answers, the register has made that person's silence into its own paralysis — and INTENT.md is explicit that a register nobody acts on is worse than none.

+
+

The four rules

+

1. Every wait is typed

+

No record may say "waiting on X". A wait carries six things:

+
waiting_on:
+  - who: tenant-engine
+    what: "confirm or correct the unfiltered events() read; open fix tracking"
+    since: "2026-08-19"
+    would_change: "grade rises if the log carries payload rather than metadata"
+    default: "grade stands as recorded; absent fix tracking noted as a stall"
+    default_at: "2026-09-03"
+

would_change is the discipline. If nobody can say what the answer would change, there is nothing being waited for, and the wait should be deleted rather than carried.

+

2. Depth one

+

A record may wait on at most one other record, and never on a record that is itself waiting.

+

When the chain would go deeper, the far end is cut: the record takes its own default and says which unresolved thing it declined to wait for. Two hops is the point at which nobody can see the whole line any more, and a wait nobody can see is indistinguishable from a thing that was dropped.

+

Applied 2026-08-20: RISK-F-0009's embargo condition was "verified against live OpenBao", which no one in the estate can currently do. It now lifts on railiance-platform reporting the coverage, with live verification recorded as a refinement rather than a condition. That cut the RISK-F-0003 chain from four hops to two.

+

3. Defaults are dates, and defaults are pessimistic

+

Every wait resolves on a date whether or not anyone answers. The default is the reading the stated facts already support — never a hold, never a downgrade earned by silence.

+

This is what removes the incentive to wait. Silence does not buy an owner a softer grade or a quieter register; it costs them the grade the evidence supports, which is usually the one they would want corrected. Answering is how a grade improves, and that is the right shape for the incentive.

+

The register says so in advance, to the owner, in writing. A default nobody was warned about is an ambush, not a rule.

+

4. A condition naming somebody else's action carries a date beside it

+

"Embargo lifts when X ships" is a dependency with no end. "Lifts when X ships, or is re-decided on 2026-09-20" terminates.

+

Re-decided is not the same as lifted — the re-decision may extend the hold with a fresh reason. What it may not do is extend by default, which is how holds quietly become permanent.

+
+

What this does not solve

+

Some dependencies are real and cannot be defaulted away. Nobody can verify an OpenBao policy without a token, and no rule here conjures one.

+

What the rules do is stop that from propagating: the register grades on what is stated, records what it could not verify, and keeps its own position independent of the blockage. docs/method/verification.md bounds what this repo can establish itself, and every grade resting on a document rather than a probe says so on its face.

+
+

Waits outlive statuses

+

A finding that is fixed can still owe something. RISK-F-0001 was closed on 2026-08-19 and is still waiting on policy-nexus for the publication entry that turns disclosure: public into an actual address.

+

So the waiting list is built from every finding, not from the watched ones. A closed record with an open obligation is precisely the thing that goes quiet, because nothing is prompting anyone to look at it any more.

+
+

A wait is not a findings-only idea

+

Adopting a rule is nobody's finding. Registering a canon kind is nobody's finding. Publishing a document is nobody's finding. All three are obligations someone owes, and each one that lived outside the mechanism was invisible to it.

+

So waits attach to any record this repo keeps — findings, regulatory records, workplans — and make check reports them together. RISK-WP-0001 carries two: the escalation rule that is producing decisions while still status: proposed, and the canon question about what kind of thing a finding is.

+

The first of those has the most uncomfortable default in the register, and it points inward: if the rule is not adopted by 2026-09-17, it is recorded as de facto in force but unratified, and every escalation sent under it says so on its face. That is worse than either adopting or rejecting it, which is the point — a draft that quietly governs is the thing this register was built to notice.

+
+

Where the waits are visible

+

make check reports every open wait with its age, its owner and its default date, flags any default that has come due, and flags any wait that points at a record which is itself waiting — a depth-two violation, caught by tooling rather than by someone noticing.

+
diff --git a/build/methods/risk-disclosure/v1/index.html b/build/methods/risk-disclosure/v1/index.html new file mode 100644 index 0000000..661bdc6 --- /dev/null +++ b/build/methods/risk-disclosure/v1/index.html @@ -0,0 +1,232 @@ + + + + +Disclosure + +
RISK-METHOD-DISCLOSURE adopted · adopted-1 risk-nexus reviewed 2026-08-20generated from canonical source — do not edit

Disclosure

Source: risk-nexus · docs/method/disclosure.md · c5517c754bd84b0ebf47878ba0f26df0ecb3b4a4

Review due: 2027-02-20

Whether and when a finding is published. policy-nexus is the surface; this document decides what it is handed.

+

What disclosure is not

+

A finding file in this repo is not a publication. This repo is a private checkout on a private forge. Holding a finding means not routing it to policy-nexus; it does not mean hiding it from the estate, from the owning repo, or from the operator. Every state below is fully visible internally.

+
+

The states

+
StateMeaningEntry condition
publicPublished through policy-nexus now.The finding is fixed, or reading it gives no one an advantage they do not already have.
embargoedHeld, with a stated condition that lifts it.Live, unfixed, and the text would help someone reach the defect faster than they could without it.
restrictedHeld with no expected lift.Publication would remain harmful after the fix — third-party material, a named person, or a credential-shaped detail that survives remediation.
+

There is no fourth state and no unset after grading. A finding whose disclosure has not been decided is an ungraded finding.

+
+

Embargo is a record, not a silence

+

INTENT.md requires the record that a delay was deliberate rather than a document quietly going missing. An embargoed finding therefore carries:

+
disclosure: embargoed
+embargo_condition: "FLEX-WP-0015-T02 ships to production"
+embargo_since: "2026-08-19"
+embargo_review: "2026-08-26"
+

embargo_condition must be an event someone can observe, not a mood. "Until it is safer" is not a condition. embargo_review follows the finding's severity interval from docs/method/review.md; when it passes, the embargo is re-decided, not extended by default.

+

An embargo that has outlived two consecutive reviews without its condition moving is itself a finding — the remediation has stalled, and the hold is now doing the work the fix was supposed to do.

+
+

The build-mode deferral, re-taken

+

INTENT.md recorded controlled disclosure as deferred to production, reasoning that build mode has no users to expose. RISK-F-0001 arrived and tested it: a live authorization bypass in the service every other service trusts, with publish-or-forget as the only available choice.

+

The deferral is narrowed, not kept and not abandoned.

+

What was right about it: build mode does have no consumers to protect, and building an embargo mechanism — timed release, staged notification, coordinated disclosure with third parties — before there is anyone to coordinate with would be machinery for its own sake.

+

What was wrong about it: it conflated the mechanism with the decision. The argument for publishing in build mode is that there are no users to expose. That argument says nothing about attackers, and RISK-F-0001 is exactly the class where the two come apart — the finding names an unauthenticated decision surface and the service that carries it. Publishing that while it is live helps precisely one kind of reader.

+

So the ruling is:

+
  1. Build-mode default stays publish. Architecture, method, fixed findings, and findings whose exposure is already bounded go out. The estate publishing what it knows is wrong remains the norm and does not need a case made for it each time.
  2. Live-and-reachable is the exception, and it exists now. A finding that is unfixed and whose text shortens the path to the defect is embargoed until the fix lands. That is the missing middle INTENT.md said did not exist. It costs one front-matter field and a line in REGISTER.md.
  3. The mechanism stays deferred. No timed release, no coordinated disclosure protocol, no notification tiers. Those wait for real users, as originally reasoned. What is not deferred is the decision, because RISK-F-0001 demonstrated the decision is needed before the machinery is.
+

This is a decision of this repo, taken 2026-08-19 with RISK-F-0001, RISK-F-0002 and RISK-F-0003 in hand rather than hypothetically. It is revisable, and the production transition is the scheduled moment to revisit it.

+
+

Test for "shortens the path"

+

Ask: does the finding tell a reader something that materially reduces the work of reaching the defect, beyond what reading the repo would give them?

+
  • A file path and line number in a private repo — no, that is already there.
  • "This surface authenticates nobody, here is its cluster address" — yes.
  • "These five named lanes vend real secret values without the boundary firing" — yes.
  • "This system had no backups configured" — no, once backups exist; yes, while they do not, because it names when destruction is unrecoverable.
+

When the answer is genuinely unclear, embargo and re-decide at the review. The cost of a wrong embargo is a delayed publication; the cost of a wrong publish is not recoverable.

+
+

Publication happens elsewhere

+

A public finding is handed to policy-nexus under its publication contract and gets a permanent address there. This repo never serves it and never edits it after handover; corrections go through the same route as the original.

+
+

The standing route, when an embargo lifts

+

RISK-WP-0002-T03. Written down because publication will arrive in a trickle as conditions clear, not as a batch, and a route improvised each time is a route that eventually is not taken.

+
  1. The check that lifts the embargo records it. make checked on the finding, with the lift as the reason. An embargo lifting is never a clean check — something moved.
  2. The finding gets publication front-matter, in the shape policy-nexus already requires of everyone: owner, revision, last_reviewed, review_interval. No body rewrite.
  3. This repo asks policy-nexus for an entry, giving source_repo, source_path, a proposed canonical_path under findings/<id>/<version>/, and a one-line subtitle. Addressing and permanence are theirs (POLICY-NEXUS-WP-0001); this repo does not invent a scheme.
  4. publication: published is recorded back on the finding, with the URL. A finding that says public but has no address is a claim, not a publication — the same class of error as a backup nobody has restored from.
+

The contract publishes a file from the owning repo, so what is handed over is exactly what a reader gets. That makes the whole-versus-summary decision (T01) a decision about what a finding file contains, not about how it is rendered.

+
diff --git a/build/methods/risk-disclosure/v1/revisions/adopted-1/index.html b/build/methods/risk-disclosure/v1/revisions/adopted-1/index.html new file mode 100644 index 0000000..9f947b7 --- /dev/null +++ b/build/methods/risk-disclosure/v1/revisions/adopted-1/index.html @@ -0,0 +1,232 @@ + + + + +Disclosure + +
RISK-METHOD-DISCLOSURE adopted · adopted-1 risk-nexus reviewed 2026-08-20generated from canonical source — do not edit

Disclosure

Source: risk-nexus · docs/method/disclosure.md · a13d954f8597fd92201746e2d52f031a5a88d969

Review due: 2027-02-20

Whether and when a finding is published. policy-nexus is the surface; this document decides what it is handed.

+

What disclosure is not

+

A finding file in this repo is not a publication. This repo is a private checkout on a private forge. Holding a finding means not routing it to policy-nexus; it does not mean hiding it from the estate, from the owning repo, or from the operator. Every state below is fully visible internally.

+
+

The states

+
StateMeaningEntry condition
publicPublished through policy-nexus now.The finding is fixed, or reading it gives no one an advantage they do not already have.
embargoedHeld, with a stated condition that lifts it.Live, unfixed, and the text would help someone reach the defect faster than they could without it.
restrictedHeld with no expected lift.Publication would remain harmful after the fix — third-party material, a named person, or a credential-shaped detail that survives remediation.
+

There is no fourth state and no unset after grading. A finding whose disclosure has not been decided is an ungraded finding.

+
+

Embargo is a record, not a silence

+

INTENT.md requires the record that a delay was deliberate rather than a document quietly going missing. An embargoed finding therefore carries:

+
disclosure: embargoed
+embargo_condition: "FLEX-WP-0015-T02 ships to production"
+embargo_since: "2026-08-19"
+embargo_review: "2026-08-26"
+

embargo_condition must be an event someone can observe, not a mood. "Until it is safer" is not a condition. embargo_review follows the finding's severity interval from docs/method/review.md; when it passes, the embargo is re-decided, not extended by default.

+

An embargo that has outlived two consecutive reviews without its condition moving is itself a finding — the remediation has stalled, and the hold is now doing the work the fix was supposed to do.

+
+

The build-mode deferral, re-taken

+

INTENT.md recorded controlled disclosure as deferred to production, reasoning that build mode has no users to expose. RISK-F-0001 arrived and tested it: a live authorization bypass in the service every other service trusts, with publish-or-forget as the only available choice.

+

The deferral is narrowed, not kept and not abandoned.

+

What was right about it: build mode does have no consumers to protect, and building an embargo mechanism — timed release, staged notification, coordinated disclosure with third parties — before there is anyone to coordinate with would be machinery for its own sake.

+

What was wrong about it: it conflated the mechanism with the decision. The argument for publishing in build mode is that there are no users to expose. That argument says nothing about attackers, and RISK-F-0001 is exactly the class where the two come apart — the finding names an unauthenticated decision surface and the service that carries it. Publishing that while it is live helps precisely one kind of reader.

+

So the ruling is:

+
  1. Build-mode default stays publish. Architecture, method, fixed findings, and findings whose exposure is already bounded go out. The estate publishing what it knows is wrong remains the norm and does not need a case made for it each time.
  2. Live-and-reachable is the exception, and it exists now. A finding that is unfixed and whose text shortens the path to the defect is embargoed until the fix lands. That is the missing middle INTENT.md said did not exist. It costs one front-matter field and a line in REGISTER.md.
  3. The mechanism stays deferred. No timed release, no coordinated disclosure protocol, no notification tiers. Those wait for real users, as originally reasoned. What is not deferred is the decision, because RISK-F-0001 demonstrated the decision is needed before the machinery is.
+

This is a decision of this repo, taken 2026-08-19 with RISK-F-0001, RISK-F-0002 and RISK-F-0003 in hand rather than hypothetically. It is revisable, and the production transition is the scheduled moment to revisit it.

+
+

Test for "shortens the path"

+

Ask: does the finding tell a reader something that materially reduces the work of reaching the defect, beyond what reading the repo would give them?

+
  • A file path and line number in a private repo — no, that is already there.
  • "This surface authenticates nobody, here is its cluster address" — yes.
  • "These five named lanes vend real secret values without the boundary firing" — yes.
  • "This system had no backups configured" — no, once backups exist; yes, while they do not, because it names when destruction is unrecoverable.
+

When the answer is genuinely unclear, embargo and re-decide at the review. The cost of a wrong embargo is a delayed publication; the cost of a wrong publish is not recoverable.

+
+

Publication happens elsewhere

+

A public finding is handed to policy-nexus under its publication contract and gets a permanent address there. This repo never serves it and never edits it after handover; corrections go through the same route as the original.

+
+

The standing route, when an embargo lifts

+

RISK-WP-0002-T03. Written down because publication will arrive in a trickle as conditions clear, not as a batch, and a route improvised each time is a route that eventually is not taken.

+
  1. The check that lifts the embargo records it. make checked on the finding, with the lift as the reason. An embargo lifting is never a clean check — something moved.
  2. The finding gets publication front-matter, in the shape policy-nexus already requires of everyone: owner, revision, last_reviewed, review_interval. No body rewrite.
  3. This repo asks policy-nexus for an entry, giving source_repo, source_path, a proposed canonical_path under findings/<id>/<version>/, and a one-line subtitle. Addressing and permanence are theirs (POLICY-NEXUS-WP-0001); this repo does not invent a scheme.
  4. publication: published is recorded back on the finding, with the URL. A finding that says public but has no address is a claim, not a publication — the same class of error as a backup nobody has restored from.
+

The contract publishes a file from the owning repo, so what is handed over is exactly what a reader gets. That makes the whole-versus-summary decision (T01) a decision about what a finding file contains, not about how it is rendered.

+
diff --git a/build/methods/risk-review/v1/index.html b/build/methods/risk-review/v1/index.html new file mode 100644 index 0000000..a718a41 --- /dev/null +++ b/build/methods/risk-review/v1/index.html @@ -0,0 +1,244 @@ + + + + +Review and expiry + +
RISK-METHOD-REVIEW adopted · adopted-1 risk-nexus reviewed 2026-08-20generated from canonical source — do not edit

Review and expiry

Source: risk-nexus · docs/method/review.md · c5517c754bd84b0ebf47878ba0f26df0ecb3b4a4

Review due: 2027-02-20

INTENT.md: a finding that has sat untouched past its review date is itself a finding. Silence is not resolution. This document makes that operable.

+

The cadence ladder

+

Operator ruling, 2026-08-20. Intervals are not set by severity. They are earned by outcomes.

+

A finding is checked, and the check comes back clean or it does not. Clean climbs one rung. Anything wrong drops straight back to the bottom.

+
RungWait before the next check
instantnow, and again immediately until a check comes back clean
1hone hour
8height hours
24hone day
48htwo days
96hfour days
7done week
14dtwo weeks
1moone month
1qone quarter — the ceiling; nothing is ever checked less often than this
+

Two rules and one escape:

+
  • Climb on clean. One rung per clean check, never two.
  • Reset on anything wrong. Not a slide down one rung — straight to instant. A matter that has just moved has no track record, whatever it had before.
  • The operator may defer. An instant finding can be deferred to a stated future date by explicit operator decision, recorded as deferred_to. That is the only way out of the bottom rung other than a clean check, and it is a decision with a name on it rather than a check quietly not happening.
+

Who checked, and when anyone last did

+

RISK-WP-0005-T06. Two defences against the rung telling a lie:

+
  • checked_by on every check. record_check.py writes it. A rung earned by nobody in particular is visible as such.
  • A heartbeat. If nothing anywhere in the register has been checked for two days, make check says so before anything else. A 1q rung means "stable for a quarter" and "nobody looked for a quarter", and those read identically from the outside — the heartbeat is what separates them.
+

The rung is the signal

+

This is the point of the design, not a side effect. The cadence a finding sits on is a statement about how stable the estate has been on that matter.

+

RISK-F-0002 at 1q (9) says the signing gate has been examined ten times over three months and nothing has moved. RISK-F-0002 at instant (0) says something changed within the day. The number carries information that no severity does — severity says how bad it would be, the rung says how settled it is — and the two are independent. A low finding that keeps resetting is telling you something a critical one at the ceiling is not.

+

It is also self-correcting in the direction that matters. Anything volatile gets attention often, automatically, without anyone deciding it deserves it; anything genuinely quiet stops consuming attention, without anyone deciding to stop looking. Neither of those judgements has to be made by a person who might be wrong or busy.

+

What "clean" means

+

A check is clean when nothing about the assessment moved: the grade still holds, every stated blocker is still true, the fix state is unchanged, the disclosure state is still right, and no new fact has arrived.

+

A check is not clean when any of those moved — including when they moved in a good direction. RISK-F-0001 being fixed is not a clean check; it is a large change, and the next check comes immediately. Good news resets the ladder exactly like bad news, because the ladder measures stillness, not health.

+

Starting position

+

Every finding starts at instant. A register with no check history has no grounds to wait, and the first clean check is what buys the first hour.

+

The whole register sat at instant (0) on 2026-08-20, which is correct and temporary: everything in it had been graded, re-graded or ruled on within the preceding day.

+
+

What a review is

+

Five questions, answered in writing on the finding. It takes minutes; it is not an investigation.

+
  1. Has the inbox said anything? Read the messages addressed to this repo before anything else. This is question zero because on 2026-08-19 the register graded RISK-F-0001 critical while two messages sat unread in its own inbox — one narrowing the exposure, one reporting the fix. Both changed the grade. A register that does not read its own inbox is guessing with a straight face.
  2. Is the grade still right? Re-read impact and likelihood against what has changed. New facts move the grade in both directions.
  3. Is the blocker still true? This is the one RISK-F-0002 bought with evidence: a blocker is a claim about the world at a date. Its own stated blocker — "flex-auth is not deployed yet" — was invalidated within a day by RISK-F-0001, and nothing would have re-checked it. Every review re-checks every stated blocker.
  4. Has the fix moved? Read the owner's tracking record, not our memory of it. Confirm the record still exists and still refers to this defect.
  5. Is the disclosure state still right? An embargo whose condition has been met is published; an embargo whose condition has not moved in two reviews is a stall.
+

The finding gets a dated line under ## Reviews, last_reviewed is updated, and review_by is pushed by one interval. A review that changes nothing still writes the line — "checked, nothing moved" is the evidence that the silence was observed rather than accidental.

+
+

When a check is missed

+

Overdue is not a status change on the finding. It is a fact about this repo, and it surfaces in three places:

+
  • make check lists it under "Checks due", with how late it is and which rung it is on.
  • REGISTER.md shows the next check as due.
  • A finding sitting at the bottom rung for more than fourteen days with no movement fires escalation trigger 5. Bottom rung means it keeps failing or keeps being skipped; fourteen days of that is a stall whichever it is.
+

The register does not auto-escalate severity for lateness and does not auto-close anything. Both would be the register lying about its own state to make a number look better.

+
+

The production re-score

+

Every finding carries severity_at_production alongside severity (docs/method/severity.md). Where the two differ, the finding is flagged production_rescore: true.

+

On the day any part of the estate declares production readiness, every flagged finding is re-scored before that declaration completes. This is not a review date — it is an event, and it fires regardless of where the review dates happen to sit.

+

Until then, make check lists the flagged findings so the size of that obligation is visible rather than discovered on the day.

+
+

Front-matter this adds

+
last_checked: "2026-08-20T05:40:00Z"
+next_check: "2026-08-20T06:40:00Z"
+cadence: 1h
+clean_streak: 1
+production_rescore: true
+deferred_to: ""        # only by explicit operator decision
+

next_check is what the nag reads, and it is an absolute moment rather than a duration, so nothing has to recompute an interval to know whether a check is late. The rungs run in hours as well as days, so it carries a time.

+
+

Closing a finding

+

A finding leaves open for exactly one of:

+
  • fixed — the owner's record shows the defect gone, and this repo has read something concrete rather than been told. Publication follows if the disclosure state was embargoed.
  • accepted — the estate is deliberately carrying it. Requires who accepted it, why, and what ends the acceptance. accepted is not closed: it stays on the ladder forever, and it climbs like anything else.
  • mitigated — the live gap is closed but the finding is not. RISK-F-0003 is the case: the boundary now fires, and the omission that let it not fire is still there. Stays watched.
  • withdrawn — the finding was wrong, or the defect never existed. Say which.
+

Any status the tooling does not recognise keeps the finding watched, and the unrecognised word is reported. RISK-F-0003 arrived as mitigated on 2026-08-20, before that word existed here, and dropped silently out of make check — a finding vanishing from the nag because someone used an unfamiliar word is precisely the failure this register exists to prevent. The tooling now fails loud instead of quiet.

+

There is no stale, no wontfix and no silent expiry. A finding that nobody will fix and nobody will accept stays open and keeps arriving in the nag, because that is the true state.

+
diff --git a/build/methods/risk-review/v1/revisions/adopted-1/index.html b/build/methods/risk-review/v1/revisions/adopted-1/index.html new file mode 100644 index 0000000..36030ad --- /dev/null +++ b/build/methods/risk-review/v1/revisions/adopted-1/index.html @@ -0,0 +1,244 @@ + + + + +Review and expiry + +
RISK-METHOD-REVIEW adopted · adopted-1 risk-nexus reviewed 2026-08-20generated from canonical source — do not edit

Review and expiry

Source: risk-nexus · docs/method/review.md · a13d954f8597fd92201746e2d52f031a5a88d969

Review due: 2027-02-20

INTENT.md: a finding that has sat untouched past its review date is itself a finding. Silence is not resolution. This document makes that operable.

+

The cadence ladder

+

Operator ruling, 2026-08-20. Intervals are not set by severity. They are earned by outcomes.

+

A finding is checked, and the check comes back clean or it does not. Clean climbs one rung. Anything wrong drops straight back to the bottom.

+
RungWait before the next check
instantnow, and again immediately until a check comes back clean
1hone hour
8height hours
24hone day
48htwo days
96hfour days
7done week
14dtwo weeks
1moone month
1qone quarter — the ceiling; nothing is ever checked less often than this
+

Two rules and one escape:

+
  • Climb on clean. One rung per clean check, never two.
  • Reset on anything wrong. Not a slide down one rung — straight to instant. A matter that has just moved has no track record, whatever it had before.
  • The operator may defer. An instant finding can be deferred to a stated future date by explicit operator decision, recorded as deferred_to. That is the only way out of the bottom rung other than a clean check, and it is a decision with a name on it rather than a check quietly not happening.
+

Who checked, and when anyone last did

+

RISK-WP-0005-T06. Two defences against the rung telling a lie:

+
  • checked_by on every check. record_check.py writes it. A rung earned by nobody in particular is visible as such.
  • A heartbeat. If nothing anywhere in the register has been checked for two days, make check says so before anything else. A 1q rung means "stable for a quarter" and "nobody looked for a quarter", and those read identically from the outside — the heartbeat is what separates them.
+

The rung is the signal

+

This is the point of the design, not a side effect. The cadence a finding sits on is a statement about how stable the estate has been on that matter.

+

RISK-F-0002 at 1q (9) says the signing gate has been examined ten times over three months and nothing has moved. RISK-F-0002 at instant (0) says something changed within the day. The number carries information that no severity does — severity says how bad it would be, the rung says how settled it is — and the two are independent. A low finding that keeps resetting is telling you something a critical one at the ceiling is not.

+

It is also self-correcting in the direction that matters. Anything volatile gets attention often, automatically, without anyone deciding it deserves it; anything genuinely quiet stops consuming attention, without anyone deciding to stop looking. Neither of those judgements has to be made by a person who might be wrong or busy.

+

What "clean" means

+

A check is clean when nothing about the assessment moved: the grade still holds, every stated blocker is still true, the fix state is unchanged, the disclosure state is still right, and no new fact has arrived.

+

A check is not clean when any of those moved — including when they moved in a good direction. RISK-F-0001 being fixed is not a clean check; it is a large change, and the next check comes immediately. Good news resets the ladder exactly like bad news, because the ladder measures stillness, not health.

+

Starting position

+

Every finding starts at instant. A register with no check history has no grounds to wait, and the first clean check is what buys the first hour.

+

The whole register sat at instant (0) on 2026-08-20, which is correct and temporary: everything in it had been graded, re-graded or ruled on within the preceding day.

+
+

What a review is

+

Five questions, answered in writing on the finding. It takes minutes; it is not an investigation.

+
  1. Has the inbox said anything? Read the messages addressed to this repo before anything else. This is question zero because on 2026-08-19 the register graded RISK-F-0001 critical while two messages sat unread in its own inbox — one narrowing the exposure, one reporting the fix. Both changed the grade. A register that does not read its own inbox is guessing with a straight face.
  2. Is the grade still right? Re-read impact and likelihood against what has changed. New facts move the grade in both directions.
  3. Is the blocker still true? This is the one RISK-F-0002 bought with evidence: a blocker is a claim about the world at a date. Its own stated blocker — "flex-auth is not deployed yet" — was invalidated within a day by RISK-F-0001, and nothing would have re-checked it. Every review re-checks every stated blocker.
  4. Has the fix moved? Read the owner's tracking record, not our memory of it. Confirm the record still exists and still refers to this defect.
  5. Is the disclosure state still right? An embargo whose condition has been met is published; an embargo whose condition has not moved in two reviews is a stall.
+

The finding gets a dated line under ## Reviews, last_reviewed is updated, and review_by is pushed by one interval. A review that changes nothing still writes the line — "checked, nothing moved" is the evidence that the silence was observed rather than accidental.

+
+

When a check is missed

+

Overdue is not a status change on the finding. It is a fact about this repo, and it surfaces in three places:

+
  • make check lists it under "Checks due", with how late it is and which rung it is on.
  • REGISTER.md shows the next check as due.
  • A finding sitting at the bottom rung for more than fourteen days with no movement fires escalation trigger 5. Bottom rung means it keeps failing or keeps being skipped; fourteen days of that is a stall whichever it is.
+

The register does not auto-escalate severity for lateness and does not auto-close anything. Both would be the register lying about its own state to make a number look better.

+
+

The production re-score

+

Every finding carries severity_at_production alongside severity (docs/method/severity.md). Where the two differ, the finding is flagged production_rescore: true.

+

On the day any part of the estate declares production readiness, every flagged finding is re-scored before that declaration completes. This is not a review date — it is an event, and it fires regardless of where the review dates happen to sit.

+

Until then, make check lists the flagged findings so the size of that obligation is visible rather than discovered on the day.

+
+

Front-matter this adds

+
last_checked: "2026-08-20T05:40:00Z"
+next_check: "2026-08-20T06:40:00Z"
+cadence: 1h
+clean_streak: 1
+production_rescore: true
+deferred_to: ""        # only by explicit operator decision
+

next_check is what the nag reads, and it is an absolute moment rather than a duration, so nothing has to recompute an interval to know whether a check is late. The rungs run in hours as well as days, so it carries a time.

+
+

Closing a finding

+

A finding leaves open for exactly one of:

+
  • fixed — the owner's record shows the defect gone, and this repo has read something concrete rather than been told. Publication follows if the disclosure state was embargoed.
  • accepted — the estate is deliberately carrying it. Requires who accepted it, why, and what ends the acceptance. accepted is not closed: it stays on the ladder forever, and it climbs like anything else.
  • mitigated — the live gap is closed but the finding is not. RISK-F-0003 is the case: the boundary now fires, and the omission that let it not fire is still there. Stays watched.
  • withdrawn — the finding was wrong, or the defect never existed. Say which.
+

Any status the tooling does not recognise keeps the finding watched, and the unrecognised word is reported. RISK-F-0003 arrived as mitigated on 2026-08-20, before that word existed here, and dropped silently out of make check — a finding vanishing from the nag because someone used an unfamiliar word is precisely the failure this register exists to prevent. The tooling now fails loud instead of quiet.

+

There is no stale, no wontfix and no silent expiry. A finding that nobody will fix and nobody will accept stays open and keeps arriving in the nag, because that is the true state.

+
diff --git a/build/methods/risk-severity/v1/index.html b/build/methods/risk-severity/v1/index.html new file mode 100644 index 0000000..e48825f --- /dev/null +++ b/build/methods/risk-severity/v1/index.html @@ -0,0 +1,256 @@ + + + + +Severity + +
RISK-METHOD-SEVERITY adopted · adopted-1 risk-nexus reviewed 2026-08-20generated from canonical source — do not edit

Severity

Source: risk-nexus · docs/method/severity.md · c5517c754bd84b0ebf47878ba0f26df0ecb3b4a4

Review due: 2027-02-20

This is risk-nexus's judgement instrument. It is not canon, it is not a standard, and it binds nobody else. It exists so that two findings graded a month apart are graded the same way, and so that a grade can be argued with.

+

It was written against three real findings (RISK-F-0001, RISK-F-0002, RISK-F-0003) and it must keep grading those three sensibly or it is wrong.

+

The two axes

+

Impact — what happens if it goes wrong once

+
BandNameTest
I1negligibleConfined to one component. No data leaves it, no record is falsified, no recovery is lost.
I2limitedOne system's data or availability. Recoverable. Confined to a single tenant, actor or lane.
I3seriousCrosses a boundary — tenant, system, or trust — or removes recoverability for one system.
I4severeCrosses the estate. What is compromised here propagates to everything that trusts it, or the data loss is unbounded.
+

Impact is scored at one occurrence, not at the worst imaginable campaign. "An attacker who already owns the cluster could do this too" is not an impact argument.

+

Likelihood — how far anyone has to reach

+
BandNameTest
L1remoteRequires access nobody currently holds and no ordinary process grants.
L2possibleRequires a foothold the estate does grant somewhere — an in-cluster workload, an agent session, a scoped token.
L3likelyReachable from inside the normal working set with no additional step.
L4presentNo barrier at all, or it is already happening.
+

Likelihood is about reach, not about intent or about whether anyone has bothered. risk-nexus does not model attackers; it models what the system permits.

+

Where the reporter has not established exposure, the finding says so and the grade uses the band the stated facts support — not the worst case, and not zero. RISK-F-0001 explicitly declines to assume a default-deny NetworkPolicy exists; the grade must decline with it, and the unverified fact becomes a review item rather than a silent assumption in either direction.

+
+

The grid

+
L1L2L3L4
I4mediumhighcriticalcritical
I3lowmediumhighcritical
I2lowlowmediumhigh
I1notelowlowmedium
+

Four severities: low, medium, high, critical. note is not a severity; see the floor.

+
+

The fidelity modifier

+

A control that lies is one impact band worse than the same control absent.

+

Apply +1 impact band (capped at I4) when the failure mode produces a false record rather than no record: an attestation that a check passed when nothing checked, an audit line asserting an authorization that was never made, a green signal derived from an unreachable test.

+

The reasoning is RISK-F-0002's and the register adopts it: an absent control is a gap you can find by looking; a lying control is a gap that survives looking, because the evidence you would look at is the thing that is wrong. Only one of the two states misleads the person investigating afterwards.

+

The modifier applies to the state being scored. A finding that describes both states — control absent today, control lying if switched on in the wrong order — gets two scores and one of them is the register's headline; see "Which state is scored".

+
+

Which state is scored

+

The headline severity is the state of the world today. A hazard that would be created by a future action is not the headline, because a register that scores hypotheticals stops describing the estate.

+

The hazard is not lost. It is recorded on the finding as a named constraint with its own grade, and it attaches to whatever action would trigger it — usually another finding's remediation. RISK-F-0002 is the worked example: the gate being off is today (headline), the gate being switched on while the oracle is forgeable is a constraint on RISK-F-0001's fix, graded separately and higher.

+

If the constraint's grade is higher than the headline, the finding says so in its ruling. A reader must not be able to come away with the low number and miss the high one.

+
+

Build mode

+

Every finding is graded twice:

+
  • severity — today, in build mode, with today's likelihood.
  • severity_at_production — the same impact, with likelihood re-read for a system carrying real users and real tenant data.
+

Build mode legitimately lowers both axes, for different reasons: likelihood, where the reach itself depends on a production deployment that has not happened; and impact, where the data that would be exposed does not exist yet. What it must never lower is severity_at_production — the defect does not improve because the calendar has not reached it.

+

Amended 2026-08-19 (RISK-WP-0001-T07). This paragraph originally said build mode was a likelihood input and never an impact one. Grading the unverified tenant boundary broke that: what build mode changes there is the consequence of an occurrence, not the reach of it. The instrument was wrong on first hard use and is corrected rather than worked around.

+

Where the two grades differ, the production transition is a mandatory re-score. docs/method/review.md binds the review date to it, so the re-score is a scheduled event and not somebody's memory.

+
+

Non-adversarial findings

+

Likelihood is written as reach because most findings are about someone getting somewhere. Where a finding is about loss, corruption or outage — no backup, no recovery path, an eviction-prone deployment — there is no attacker to model.

+

For those, likelihood reads as the chance of the triggering event inside one review interval: L1 would be surprising, L2 is an ordinary failure the estate has seen before, L3 is expected in the normal course of running, L4 is already happening. Impact is unchanged: what is lost, and whether it comes back.

+

Added 2026-08-19 (RISK-WP-0001-T07). Forced by RISK-F-0006, where the defect is an absent backup and the reach reading produced nonsense.

+
+

Live incidents

+

Everything above assumes a latent defect — something reachable that nobody is currently reaching. When someone is, three things change:

+
  • Likelihood is L4. The band means "already happening" and this is what it is for.
  • Impact is scored on what has occurred plus what is still reachable, not on the worst case. An incident in progress has facts; use them.
  • The grade is provisional and expected to move. File first, grade within the hour, re-grade as facts arrive. docs/method/intake.md has the rest, including the 72-hour clock that first_observed starts.
+
+

The floor

+

INTENT.md: if a finding would not change anyone's decision, it is a note, not a risk. Concretely, a register entry requires both:

+
  1. An owner who could act. Some repo, or the operator, can do something about it. No actor, no entry.
  2. A decision that changes. Recording it alters what someone does, when they do it, or what they must not do first.
+

Fails either test → it is a note in notes/, not a finding in findings/. Notes are not graded, not reviewed, and not published. They exist so that "we saw it" survives without inflating the register.

+

An I1/L1 cell is note in the grid for the same reason: something that is both negligible and unreachable is a thing we know, not a risk we carry.

+

Two things the floor does not exclude:

+
  • Known and deliberate. RISK-F-0002 is a decision somebody made on purpose. It still passes the floor, because it changes what may be switched on and in what order. Deliberate is not the same as tracked.
  • Omission-shaped. RISK-F-0003 is a default that silently produces ungoverned lanes. The individual lane is small; the default is not.
+
+

Provenance is a grading input

+

All four defects known to this register were found by repos reading their own code against a ladder, within days of each other. None was found by monitoring.

+

Where a finding's provenance is "we happened to look", the register does not get to assume that similar defects would have been caught. That raises likelihood for the class, not for the instance, and it belongs in the ruling's reasoning rather than in a modifier — the register grades what is filed, and notes when the filing was luck.

+
+

Recording a grade

+

The finding's front-matter carries:

+
severity: critical              # headline, today
+severity_at_production: critical
+impact: I4                      # band, before modifiers
+likelihood: L3
+fidelity_modifier: false        # true if +1 applied, with the reason in the ruling
+

and the ruling section states impact, likelihood, any modifier, and the one sentence that would have to become false for the grade to change.

+
diff --git a/build/methods/risk-severity/v1/revisions/adopted-1/index.html b/build/methods/risk-severity/v1/revisions/adopted-1/index.html new file mode 100644 index 0000000..33b5462 --- /dev/null +++ b/build/methods/risk-severity/v1/revisions/adopted-1/index.html @@ -0,0 +1,256 @@ + + + + +Severity + +
RISK-METHOD-SEVERITY adopted · adopted-1 risk-nexus reviewed 2026-08-20generated from canonical source — do not edit

Severity

Source: risk-nexus · docs/method/severity.md · a13d954f8597fd92201746e2d52f031a5a88d969

Review due: 2027-02-20

This is risk-nexus's judgement instrument. It is not canon, it is not a standard, and it binds nobody else. It exists so that two findings graded a month apart are graded the same way, and so that a grade can be argued with.

+

It was written against three real findings (RISK-F-0001, RISK-F-0002, RISK-F-0003) and it must keep grading those three sensibly or it is wrong.

+

The two axes

+

Impact — what happens if it goes wrong once

+
BandNameTest
I1negligibleConfined to one component. No data leaves it, no record is falsified, no recovery is lost.
I2limitedOne system's data or availability. Recoverable. Confined to a single tenant, actor or lane.
I3seriousCrosses a boundary — tenant, system, or trust — or removes recoverability for one system.
I4severeCrosses the estate. What is compromised here propagates to everything that trusts it, or the data loss is unbounded.
+

Impact is scored at one occurrence, not at the worst imaginable campaign. "An attacker who already owns the cluster could do this too" is not an impact argument.

+

Likelihood — how far anyone has to reach

+
BandNameTest
L1remoteRequires access nobody currently holds and no ordinary process grants.
L2possibleRequires a foothold the estate does grant somewhere — an in-cluster workload, an agent session, a scoped token.
L3likelyReachable from inside the normal working set with no additional step.
L4presentNo barrier at all, or it is already happening.
+

Likelihood is about reach, not about intent or about whether anyone has bothered. risk-nexus does not model attackers; it models what the system permits.

+

Where the reporter has not established exposure, the finding says so and the grade uses the band the stated facts support — not the worst case, and not zero. RISK-F-0001 explicitly declines to assume a default-deny NetworkPolicy exists; the grade must decline with it, and the unverified fact becomes a review item rather than a silent assumption in either direction.

+
+

The grid

+
L1L2L3L4
I4mediumhighcriticalcritical
I3lowmediumhighcritical
I2lowlowmediumhigh
I1notelowlowmedium
+

Four severities: low, medium, high, critical. note is not a severity; see the floor.

+
+

The fidelity modifier

+

A control that lies is one impact band worse than the same control absent.

+

Apply +1 impact band (capped at I4) when the failure mode produces a false record rather than no record: an attestation that a check passed when nothing checked, an audit line asserting an authorization that was never made, a green signal derived from an unreachable test.

+

The reasoning is RISK-F-0002's and the register adopts it: an absent control is a gap you can find by looking; a lying control is a gap that survives looking, because the evidence you would look at is the thing that is wrong. Only one of the two states misleads the person investigating afterwards.

+

The modifier applies to the state being scored. A finding that describes both states — control absent today, control lying if switched on in the wrong order — gets two scores and one of them is the register's headline; see "Which state is scored".

+
+

Which state is scored

+

The headline severity is the state of the world today. A hazard that would be created by a future action is not the headline, because a register that scores hypotheticals stops describing the estate.

+

The hazard is not lost. It is recorded on the finding as a named constraint with its own grade, and it attaches to whatever action would trigger it — usually another finding's remediation. RISK-F-0002 is the worked example: the gate being off is today (headline), the gate being switched on while the oracle is forgeable is a constraint on RISK-F-0001's fix, graded separately and higher.

+

If the constraint's grade is higher than the headline, the finding says so in its ruling. A reader must not be able to come away with the low number and miss the high one.

+
+

Build mode

+

Every finding is graded twice:

+
  • severity — today, in build mode, with today's likelihood.
  • severity_at_production — the same impact, with likelihood re-read for a system carrying real users and real tenant data.
+

Build mode legitimately lowers both axes, for different reasons: likelihood, where the reach itself depends on a production deployment that has not happened; and impact, where the data that would be exposed does not exist yet. What it must never lower is severity_at_production — the defect does not improve because the calendar has not reached it.

+

Amended 2026-08-19 (RISK-WP-0001-T07). This paragraph originally said build mode was a likelihood input and never an impact one. Grading the unverified tenant boundary broke that: what build mode changes there is the consequence of an occurrence, not the reach of it. The instrument was wrong on first hard use and is corrected rather than worked around.

+

Where the two grades differ, the production transition is a mandatory re-score. docs/method/review.md binds the review date to it, so the re-score is a scheduled event and not somebody's memory.

+
+

Non-adversarial findings

+

Likelihood is written as reach because most findings are about someone getting somewhere. Where a finding is about loss, corruption or outage — no backup, no recovery path, an eviction-prone deployment — there is no attacker to model.

+

For those, likelihood reads as the chance of the triggering event inside one review interval: L1 would be surprising, L2 is an ordinary failure the estate has seen before, L3 is expected in the normal course of running, L4 is already happening. Impact is unchanged: what is lost, and whether it comes back.

+

Added 2026-08-19 (RISK-WP-0001-T07). Forced by RISK-F-0006, where the defect is an absent backup and the reach reading produced nonsense.

+
+

Live incidents

+

Everything above assumes a latent defect — something reachable that nobody is currently reaching. When someone is, three things change:

+
  • Likelihood is L4. The band means "already happening" and this is what it is for.
  • Impact is scored on what has occurred plus what is still reachable, not on the worst case. An incident in progress has facts; use them.
  • The grade is provisional and expected to move. File first, grade within the hour, re-grade as facts arrive. docs/method/intake.md has the rest, including the 72-hour clock that first_observed starts.
+
+

The floor

+

INTENT.md: if a finding would not change anyone's decision, it is a note, not a risk. Concretely, a register entry requires both:

+
  1. An owner who could act. Some repo, or the operator, can do something about it. No actor, no entry.
  2. A decision that changes. Recording it alters what someone does, when they do it, or what they must not do first.
+

Fails either test → it is a note in notes/, not a finding in findings/. Notes are not graded, not reviewed, and not published. They exist so that "we saw it" survives without inflating the register.

+

An I1/L1 cell is note in the grid for the same reason: something that is both negligible and unreachable is a thing we know, not a risk we carry.

+

Two things the floor does not exclude:

+
  • Known and deliberate. RISK-F-0002 is a decision somebody made on purpose. It still passes the floor, because it changes what may be switched on and in what order. Deliberate is not the same as tracked.
  • Omission-shaped. RISK-F-0003 is a default that silently produces ungoverned lanes. The individual lane is small; the default is not.
+
+

Provenance is a grading input

+

All four defects known to this register were found by repos reading their own code against a ladder, within days of each other. None was found by monitoring.

+

Where a finding's provenance is "we happened to look", the register does not get to assume that similar defects would have been caught. That raises likelihood for the class, not for the instance, and it belongs in the ruling's reasoning rather than in a modifier — the register grades what is filed, and notes when the filing was luck.

+
+

Recording a grade

+

The finding's front-matter carries:

+
severity: critical              # headline, today
+severity_at_production: critical
+impact: I4                      # band, before modifiers
+likelihood: L3
+fidelity_modifier: false        # true if +1 applied, with the reason in the ruling
+

and the ruling section states impact, likelihood, any modifier, and the one sentence that would have to become false for the grade to change.

+
diff --git a/build/methods/risk-verification/v1/index.html b/build/methods/risk-verification/v1/index.html new file mode 100644 index 0000000..98450bb --- /dev/null +++ b/build/methods/risk-verification/v1/index.html @@ -0,0 +1,222 @@ + + + + +What this register may verify for itself, and what it must take from owners + +
RISK-METHOD-VERIFICATION adopted · adopted-1 risk-nexus reviewed 2026-08-20generated from canonical source — do not edit

What this register may verify for itself, and what it must take from owners

Source: risk-nexus · docs/method/verification.md · c5517c754bd84b0ebf47878ba0f26df0ecb3b4a4

Review due: 2027-02-20

RISK-WP-0004-T05 asked what this repo can legitimately establish itself, because two gradings were resting on file comparison. The answer was found by trying, on 2026-08-20, rather than by reasoning about it.

+

The rule

+

A register may look. It may not touch, and it may not conclude on a system's behalf.

+

Verification here means: running a read-only command a reporter has already named, or that answers a question the register itself wrote down as open, and recording exactly what came back.

+

Permitted:

+
  • read-only reads of live state (kubectl get, bao policy read, an HTTP probe of a documented endpoint);
  • comparing what is deployed against what a repo said is deployed;
  • recording the discrepancy and routing it as a question.
+

Not permitted:

+
  • any write, apply, patch, restart or rotation — including one that would obviously improve things;
  • concluding what a defect means for a system this repo does not own. The system stays authoritative about itself (INTENT.md);
  • verifying instead of asking. The owner is asked first; verification settles what an owner cannot see or has invited someone to check.
+

rapp-postgres declined to check the NetworkPolicy on flex-auth's behalf, saying that would be reporting on a system they do not own. That was right for a reporter. This register is the downstream party whose grade depended on the answer, and flex-auth explicitly named the command and asked for someone with credentials to run it. Those two positions are compatible.

+
+

What this host can actually reach — established 2026-08-20

+
TargetResultConsequence
Kubernetes (railiance01)reads work — kubectl get ns, get networkpolicy -o jsonLive cluster state is verifiable by this register
OpenBao (bao.coulomb.social)403 permission denied on token lookup and policy readPolicy claims are not verifiable here; RISK-F-0009 rests on file comparison
+

The asymmetry is worth stating plainly: the register can check what the cluster admits, and cannot check what the secret store permits. Every grade touching an OpenBao policy is therefore a grade on a document, and says so.

+

That is not a gap to close by acquiring credentials. A risk register holding production secret-store access has traded a verification problem for a much worse one. If OpenBao claims need verifying, the right answer is for the owner to run the read and report it, which is what ops-warden did — the obstacle there was an expired token, not the arrangement.

+
+

A file is not a safe proxy for the server

+

Established 2026-08-21, by evidence rather than by caution. ops-warden ran the live OpenBao read that RISK-F-0009 had been graded without, and the deployed policy differs from the committed file. No lane maps to the drifted path, so nothing was exposed — but the general claim is now proven rather than suspected.

+

Consequences this register accepts:

+
  • Every grade made off a checkout is a grade on a document, and says so on its face. RISK-F-0009 does.
  • A verification that reads a file is a weaker artifact than one that reads a server, and the record must not blur them. RISK-V-0001 reads a server; the OpenBao comparison in RISK-F-0009 reads a file.
  • Where only the owner can reach the server, the owner's probe is the evidence and the register says whose it is. That is not a lesser standard — it is the correct one, given verification.md's own limits.
+

The corollary is uncomfortable and worth stating: drift between file and server is invisible to anyone reading files, which is most of this estate's tooling, including fix_tracker.py. What that tool reads is what a repo recorded, and a record can be as stale as any other claim — as four self-reported stale blockers in twelve hours demonstrated on 2026-08-21.

+
+

Recording a verification

+

One file per verification in docs/verifications/, RISK-V-NNNN, stating the command, the raw result, what it confirms, what it contradicts, and what it does not establish. It names the findings it bears on, and those findings link back.

+

A verification is evidence, not a ruling. It can move a grade; it does not close a finding on its own, and it never speaks for the owning repo.

+
+

Verification and the cadence ladder

+

A verification that contradicts something is a check that is not clean: the affected findings reset to instant. A verification that confirms what was already recorded is clean, and may be exactly the evidence a rung is built on.

+

The first one (RISK-V-0001) did both — it confirmed the ingress claim RISK-F-0001 was graded on, contradicted the egress claim in the same message, and surfaced a third policy nobody had mentioned that bears on RISK-F-0002.

+
diff --git a/build/methods/risk-verification/v1/revisions/adopted-1/index.html b/build/methods/risk-verification/v1/revisions/adopted-1/index.html new file mode 100644 index 0000000..2fa3f10 --- /dev/null +++ b/build/methods/risk-verification/v1/revisions/adopted-1/index.html @@ -0,0 +1,222 @@ + + + + +What this register may verify for itself, and what it must take from owners + +
RISK-METHOD-VERIFICATION adopted · adopted-1 risk-nexus reviewed 2026-08-20generated from canonical source — do not edit

What this register may verify for itself, and what it must take from owners

Source: risk-nexus · docs/method/verification.md · a13d954f8597fd92201746e2d52f031a5a88d969

Review due: 2027-02-20

RISK-WP-0004-T05 asked what this repo can legitimately establish itself, because two gradings were resting on file comparison. The answer was found by trying, on 2026-08-20, rather than by reasoning about it.

+

The rule

+

A register may look. It may not touch, and it may not conclude on a system's behalf.

+

Verification here means: running a read-only command a reporter has already named, or that answers a question the register itself wrote down as open, and recording exactly what came back.

+

Permitted:

+
  • read-only reads of live state (kubectl get, bao policy read, an HTTP probe of a documented endpoint);
  • comparing what is deployed against what a repo said is deployed;
  • recording the discrepancy and routing it as a question.
+

Not permitted:

+
  • any write, apply, patch, restart or rotation — including one that would obviously improve things;
  • concluding what a defect means for a system this repo does not own. The system stays authoritative about itself (INTENT.md);
  • verifying instead of asking. The owner is asked first; verification settles what an owner cannot see or has invited someone to check.
+

rapp-postgres declined to check the NetworkPolicy on flex-auth's behalf, saying that would be reporting on a system they do not own. That was right for a reporter. This register is the downstream party whose grade depended on the answer, and flex-auth explicitly named the command and asked for someone with credentials to run it. Those two positions are compatible.

+
+

What this host can actually reach — established 2026-08-20

+
TargetResultConsequence
Kubernetes (railiance01)reads work — kubectl get ns, get networkpolicy -o jsonLive cluster state is verifiable by this register
OpenBao (bao.coulomb.social)403 permission denied on token lookup and policy readPolicy claims are not verifiable here; RISK-F-0009 rests on file comparison
+

The asymmetry is worth stating plainly: the register can check what the cluster admits, and cannot check what the secret store permits. Every grade touching an OpenBao policy is therefore a grade on a document, and says so.

+

That is not a gap to close by acquiring credentials. A risk register holding production secret-store access has traded a verification problem for a much worse one. If OpenBao claims need verifying, the right answer is for the owner to run the read and report it, which is what ops-warden did — the obstacle there was an expired token, not the arrangement.

+
+

A file is not a safe proxy for the server

+

Established 2026-08-21, by evidence rather than by caution. ops-warden ran the live OpenBao read that RISK-F-0009 had been graded without, and the deployed policy differs from the committed file. No lane maps to the drifted path, so nothing was exposed — but the general claim is now proven rather than suspected.

+

Consequences this register accepts:

+
  • Every grade made off a checkout is a grade on a document, and says so on its face. RISK-F-0009 does.
  • A verification that reads a file is a weaker artifact than one that reads a server, and the record must not blur them. RISK-V-0001 reads a server; the OpenBao comparison in RISK-F-0009 reads a file.
  • Where only the owner can reach the server, the owner's probe is the evidence and the register says whose it is. That is not a lesser standard — it is the correct one, given verification.md's own limits.
+

The corollary is uncomfortable and worth stating: drift between file and server is invisible to anyone reading files, which is most of this estate's tooling, including fix_tracker.py. What that tool reads is what a repo recorded, and a record can be as stale as any other claim — as four self-reported stale blockers in twelve hours demonstrated on 2026-08-21.

+
+

Recording a verification

+

One file per verification in docs/verifications/, RISK-V-NNNN, stating the command, the raw result, what it confirms, what it contradicts, and what it does not establish. It names the findings it bears on, and those findings link back.

+

A verification is evidence, not a ruling. It can move a grade; it does not close a finding on its own, and it never speaks for the owning repo.

+
+

Verification and the cadence ladder

+

A verification that contradicts something is a check that is not clean: the affected findings reset to instant. A verification that confirms what was already recorded is clean, and may be exactly the evidence a rung is built on.

+

The first one (RISK-V-0001) did both — it confirmed the ingress claim RISK-F-0001 was graded on, contradicted the egress claim in the same message, and surfaced a third policy nobody had mentioned that bears on RISK-F-0002.

+
diff --git a/build/publication-manifest.json b/build/publication-manifest.json index 2c36b0c..ae9f671 100644 --- a/build/publication-manifest.json +++ b/build/publication-manifest.json @@ -13,7 +13,7 @@ "source_digest": "27d6878c68310619877de516000d9af78d5456a92572a709884ed052d765b876", "source_path": "canon/standards/tenancy-posture_v0.1.md", "source_repo": "net-kingdom", - "source_revision": "d4e57e63126d2cca1d381c025170e4b1f678c3f3", + "source_revision": "9781102e2971d762ae42fdd5085a6647afd1cd66", "status": "proposed", "title": "NetKingdom Tenancy Posture v0.1" }, @@ -30,7 +30,7 @@ "source_digest": "106cb0c99f73983199c9f1d8491143aa2a2eb41ee450a02ec7968d3763f30399", "source_path": "canon/standards/autonomy-lanes_v0.1.md", "source_repo": "the-custodian", - "source_revision": "4b951be3947f9457cc091a7d359d9232646b4c93", + "source_revision": "f9435cd605cc5b3cb0f2e957ce6287d9f3129aac", "status": "accepted", "title": "Autonomy Lanes (Fleet) v0.1" }, @@ -47,7 +47,7 @@ "source_digest": "6dfc1d7b2b82ab18228a84660c1c7dff607aad1d9da37ac12084cdd2ab8ae112", "source_path": "canon/standards/contribution-convention_v0.1.md", "source_repo": "the-custodian", - "source_revision": "4b951be3947f9457cc091a7d359d9232646b4c93", + "source_revision": "f9435cd605cc5b3cb0f2e957ce6287d9f3129aac", "status": "accepted", "title": "Contribution Convention v0.1" }, @@ -64,7 +64,7 @@ "source_digest": "61889b2f18a82a08b66ef90d758efe5c028a4f52aced1721a23e69c6f24a8224", "source_path": "canon/standards/project-repository-flavor_v0.1.md", "source_repo": "the-custodian", - "source_revision": "4b951be3947f9457cc091a7d359d9232646b4c93", + "source_revision": "f9435cd605cc5b3cb0f2e957ce6287d9f3129aac", "status": "accepted", "title": "Project Repository Flavor (prj-) v0.1" }, @@ -81,7 +81,7 @@ "source_digest": "1a40de294be332ee713cdaab532a32a83718f3952c339fbff835ecee899a8dbc", "source_path": "canon/standards/work-record-types_v0.1.md", "source_repo": "the-custodian", - "source_revision": "4b951be3947f9457cc091a7d359d9232646b4c93", + "source_revision": "f9435cd605cc5b3cb0f2e957ce6287d9f3129aac", "status": "accepted", "title": "Work Record Types & Identity (Fleet) v0.1" }, @@ -98,7 +98,7 @@ "source_digest": "199812632ac342ca3231498e545e3701e10c191ca144035b36a23c1a0b717712", "source_path": "canon/standards/workplan-terminology-fleet_v0.1.md", "source_repo": "the-custodian", - "source_revision": "4b951be3947f9457cc091a7d359d9232646b4c93", + "source_revision": "f9435cd605cc5b3cb0f2e957ce6287d9f3129aac", "status": "accepted", "title": "Workplan Terminology (Fleet) v0.1" }, @@ -115,7 +115,7 @@ "source_digest": "3b4f93acdedc6f6d1a1c737c3327d9d55061506c5a879be09e6b0a2ea7f5f9bc", "source_path": "canon/architecture/coulomb-estate_v0.1.md", "source_repo": "the-custodian", - "source_revision": "4b951be3947f9457cc091a7d359d9232646b4c93", + "source_revision": "f9435cd605cc5b3cb0f2e957ce6287d9f3129aac", "status": "proposed", "title": "Coulomb estate architecture" }, @@ -149,7 +149,7 @@ "source_digest": "b9f89f706a801d54961fc67d725ca433b7c3b6a083c54793de6e8b60d1dd42a8", "source_path": "docs/architecture/net-kingdom_v0.1.md", "source_repo": "net-kingdom", - "source_revision": "d4e57e63126d2cca1d381c025170e4b1f678c3f3", + "source_revision": "9781102e2971d762ae42fdd5085a6647afd1cd66", "status": "proposed", "title": "NetKingdom architecture" }, @@ -166,7 +166,7 @@ "source_digest": "e7104b2182612efe90c9a12168757506402490229814d454e94917ae62d2bfac", "source_path": "docs/architecture/state-hub_v0.1.md", "source_repo": "state-hub", - "source_revision": "0e35f84ad5f2f9397d76ffacb99f9973544f08ac", + "source_revision": "803bb95e1d071f188f4202d53a235f8721a8ecdc", "status": "proposed", "title": "State Hub architecture" }, @@ -183,7 +183,7 @@ "source_digest": "179cbb86bca95f71f46f51ca1971ff1c274eed7d900adf0672b537d4bcc5b480", "source_path": "docs/architecture/policy-nexus_v0.1.md", "source_repo": "policy-nexus", - "source_revision": "885c6bb1cb805b64cbcfa99dd2c5817f6d4a1373", + "source_revision": "4c8a7b966600976aac595e8f49f3ef38929ccd20", "status": "proposed", "title": "Policy Nexus architecture" }, @@ -200,7 +200,7 @@ "source_digest": "a28668fb4b8b6c5ec8c94baac000061276d85ef1849ec7ab8d132b913dbfe3be", "source_path": "docs/adr/ADR-0001-addressing-and-permanence.md", "source_repo": "policy-nexus", - "source_revision": "885c6bb1cb805b64cbcfa99dd2c5817f6d4a1373", + "source_revision": "4c8a7b966600976aac595e8f49f3ef38929ccd20", "status": "accepted", "title": "Policy addressing and permanence" }, @@ -438,7 +438,7 @@ "source_digest": "7df0bb364276e382cbee9383e7e67d399b0ac1b0353246e0ab323e629e732a6d", "source_path": "docs/adr/ADR-0001-catalog-is-a-pointer-layer.md", "source_repo": "ops-warden", - "source_revision": "4e267179db741b27a3e62f81f753cd9752c97412", + "source_revision": "8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5", "status": "accepted", "title": "ADR-0001 \u2014 The routing catalog is a pointer layer, never a second copy" }, @@ -455,7 +455,7 @@ "source_digest": "7dcc31732d774ddf2c98636b69ee12e2d74034836ed0def81b7e06461309b53a", "source_path": "docs/adr/ADR-0002-conduit-not-broker.md", "source_repo": "ops-warden", - "source_revision": "4e267179db741b27a3e62f81f753cd9752c97412", + "source_revision": "8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5", "status": "accepted", "title": "ADR-0002 \u2014 ops-warden is a transparent conduit, never a secret broker" }, @@ -472,7 +472,7 @@ "source_digest": "45b47c02afa575fbfe5be980e426c331a1d99bb9cd9c7a8de80bf8e319469f81", "source_path": "docs/adr/ADR-0003-cover-gaps-never-silently-own-them.md", "source_repo": "ops-warden", - "source_revision": "4e267179db741b27a3e62f81f753cd9752c97412", + "source_revision": "8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5", "status": "accepted", "title": "ADR-0003 \u2014 Cover gaps, but never silently own them" }, @@ -489,7 +489,7 @@ "source_digest": "5db38dcb754af1ba639f4ceca056df842bc7b91fa48dd8bad21611aee29f682d", "source_path": "docs/adr/ADR-0004-agent-read-boundary-on-high-risk-lanes.md", "source_repo": "ops-warden", - "source_revision": "4e267179db741b27a3e62f81f753cd9752c97412", + "source_revision": "8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5", "status": "accepted", "title": "ADR-0004 \u2014 High-risk lanes refuse raw value streaming to agent sessions" }, @@ -506,7 +506,7 @@ "source_digest": "31eafe4d8d9362a3446739d63c3af83fd9138cfdc6ad120086312a67dc0d27d0", "source_path": "docs/adr/ADR-0005-implement-narrowly-route-broadly.md", "source_repo": "ops-warden", - "source_revision": "4e267179db741b27a3e62f81f753cd9752c97412", + "source_revision": "8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5", "status": "accepted", "title": "ADR-0005 \u2014 Implement one lane narrowly, route everything else" }, @@ -523,7 +523,7 @@ "source_digest": "183023ee57bae9c29e726fec5ee0361633fe3a2b182436a57869ae4b2a27af24", "source_path": "canon/architecture/adr-001-workplans-as-repo-artefacts.md", "source_repo": "the-custodian", - "source_revision": "4b951be3947f9457cc091a7d359d9232646b4c93", + "source_revision": "f9435cd605cc5b3cb0f2e957ce6287d9f3129aac", "status": "accepted", "title": "Workplans and Work Items Are Repository Artefacts" }, @@ -540,7 +540,7 @@ "source_digest": "6aef66cd5cf71a48f5b4e14401dc19a755e2b182445b272d5952df0eb0dea8ec", "source_path": "canon/architecture/adr-002-custodian-agent-runtime-design.md", "source_repo": "the-custodian", - "source_revision": "4b951be3947f9457cc091a7d359d9232646b4c93", + "source_revision": "f9435cd605cc5b3cb0f2e957ce6287d9f3129aac", "status": "accepted", "title": "Custodian Agent Runtime \u2014 v0.1 Bootstrap Design" }, @@ -557,7 +557,7 @@ "source_digest": "fcb49719e2b85b9120c0bd5bebd5e82748ca713f16b44951c028b60205514e2b", "source_path": "canon/architecture/adr-003-materialized-derived-state.md", "source_repo": "the-custodian", - "source_revision": "4b951be3947f9457cc091a7d359d9232646b4c93", + "source_revision": "f9435cd605cc5b3cb0f2e957ce6287d9f3129aac", "status": "accepted", "title": "Materialized Derived State with Fingerprint Invalidation for Repo-Sourced Data" }, @@ -574,7 +574,7 @@ "source_digest": "3b68adfa6ab329e73f857cf691dc405136d2d66a0135e2c37c236aabe4659557", "source_path": "canon/architecture/adr-004-connectivity-first-network-posture.md", "source_repo": "the-custodian", - "source_revision": "4b951be3947f9457cc091a7d359d9232646b4c93", + "source_revision": "f9435cd605cc5b3cb0f2e957ce6287d9f3129aac", "status": "accepted", "title": "Connectivity-First Network Posture for Custodian Infrastructure" }, @@ -591,7 +591,7 @@ "source_digest": "13195a721d0e579715f5f39ca6f72b5e49c583611e6ca089e6d4618708ae917f", "source_path": "canon/architecture/adr-005-cross-repo-workplans-project-repos.md", "source_repo": "the-custodian", - "source_revision": "4b951be3947f9457cc091a7d359d9232646b4c93", + "source_revision": "f9435cd605cc5b3cb0f2e957ce6287d9f3129aac", "status": "accepted", "title": "Cross-Repo Workplans Live in Dedicated Project Repos" }, @@ -608,7 +608,7 @@ "source_digest": "a454df0e1d227f99ebb36c4abd45c76cc12579086d34f0c0ccfccfd7f4790823", "source_path": "canon/architecture/adr-006-canon-federation-concept-ownership.md", "source_repo": "the-custodian", - "source_revision": "4b951be3947f9457cc091a7d359d9232646b4c93", + "source_revision": "f9435cd605cc5b3cb0f2e957ce6287d9f3129aac", "status": "accepted", "title": "Canon Federation and Concept Ownership Across InfoTech and Commerce" }, @@ -625,7 +625,7 @@ "source_digest": "1169f0c1f485a2bb7241a8f64f3167c060c04f83341b12586fd9be5c2b3693f8", "source_path": "canon/architecture/adr-007-workplan-identity-and-repo-worker-topology.md", "source_repo": "the-custodian", - "source_revision": "4b951be3947f9457cc091a7d359d9232646b4c93", + "source_revision": "f9435cd605cc5b3cb0f2e957ce6287d9f3129aac", "status": "accepted", "title": "Workplan Identity Uniqueness, Single Registrar, and Repo Worker Topology" }, @@ -642,7 +642,7 @@ "source_digest": "5979da20799118259fc19246f51e8cc8f2c0c1be3d414318bd51d5a27d9ad565", "source_path": "canon/architecture/adr-010-hub-authority-and-local-cache-model.md", "source_repo": "the-custodian", - "source_revision": "4b951be3947f9457cc091a7d359d9232646b4c93", + "source_revision": "f9435cd605cc5b3cb0f2e957ce6287d9f3129aac", "status": "proposed", "title": "Hub Authority, Local Cache, and the Two Kinds of Hub Data" }, @@ -659,7 +659,7 @@ "source_digest": "f94f429c72f6cfd01ee83f1e5689d2d10ae52d7588d7cbd3ca40aca7eef46fb0", "source_path": "canon/architecture/adr-011-federated-namespaces-and-reconciliation-limits.md", "source_repo": "the-custodian", - "source_revision": "4b951be3947f9457cc091a7d359d9232646b4c93", + "source_revision": "f9435cd605cc5b3cb0f2e957ce6287d9f3129aac", "status": "proposed", "title": "Federated Namespaces: Four Planes, Declared Posture, and the Limits of Reconciliation" }, @@ -676,7 +676,7 @@ "source_digest": "63697581401b53a8437835c2bb8b40f8054cc40d0bc7a2972f83a4a10377f6ba", "source_path": "docs/adr/ADR-0001-s3-platform-service-boundary.md", "source_repo": "railiance-platform", - "source_revision": "e5f3497337575e1fd85fe2bfde5b2183c690d94e", + "source_revision": "62423fd0925d75f5a2b27034044dc1080823d341", "status": "accepted", "title": "ADR-0001 \u2014 S3 owns platform services, not the substrate beneath them" }, @@ -693,7 +693,7 @@ "source_digest": "cfc0ad202c2eeeefd963127ff1defa127c715c001ecc684ab8759733bd8fb9f8", "source_path": "docs/adr/ADR-0002-placement-policy-ownership.md", "source_repo": "railiance-platform", - "source_revision": "e5f3497337575e1fd85fe2bfde5b2183c690d94e", + "source_revision": "62423fd0925d75f5a2b27034044dc1080823d341", "status": "proposed", "title": "ADR-0002 \u2014 S3 owns the placement rule; the package repo owns the number" }, @@ -710,7 +710,7 @@ "source_digest": "9b12ab6aa0e6f9eba03465782c35d6ff4683b682191599e38f4f9614cde9fa1b", "source_path": "docs/adr/ADR-0003-decisions-live-in-the-repo.md", "source_repo": "railiance-platform", - "source_revision": "e5f3497337575e1fd85fe2bfde5b2183c690d94e", + "source_revision": "62423fd0925d75f5a2b27034044dc1080823d341", "status": "accepted", "title": "ADR-0003 \u2014 Decisions that bind others live in docs/adr, not only in the State Hub" }, @@ -727,7 +727,7 @@ "source_digest": "6c47b596ea145fa197c9665081c84902482d90f5bb94d185c1223af65279be1d", "source_path": "canon/standards/iam-profile_v0.3.md", "source_repo": "net-kingdom", - "source_revision": "d4e57e63126d2cca1d381c025170e4b1f678c3f3", + "source_revision": "9781102e2971d762ae42fdd5085a6647afd1cd66", "status": "accepted", "title": "NetKingdom IAM Profile v0.3" }, @@ -744,7 +744,7 @@ "source_digest": "e92a43649bb6e14e53ec62ecc819405bf3a44bda9557487f7177402f107bbd13", "source_path": "docs/adr/ADR-0006-recursive-multi-tenant-identity-authorization.md", "source_repo": "net-kingdom", - "source_revision": "d4e57e63126d2cca1d381c025170e4b1f678c3f3", + "source_revision": "9781102e2971d762ae42fdd5085a6647afd1cd66", "status": "accepted", "title": "Recursive Multi-Tenant Identity and Authorization Architecture" }, @@ -761,7 +761,7 @@ "source_digest": "b4fcff8448f07aca1fcb6908618bdb19f6c0e7dce25d4c5c8b85eec2f175233b", "source_path": "docs/adr/ADR-0007-security-orchestration-boundary.md", "source_repo": "net-kingdom", - "source_revision": "d4e57e63126d2cca1d381c025170e4b1f678c3f3", + "source_revision": "9781102e2971d762ae42fdd5085a6647afd1cd66", "status": "accepted", "title": "Security Orchestration Boundary" }, @@ -778,7 +778,7 @@ "source_digest": "f47276f4953f62b783397ee7fb1d3693da060103247e425a9a5b40d019fb4272", "source_path": "docs/adr/ADR-0008-object-storage-sts-credential-vending.md", "source_repo": "net-kingdom", - "source_revision": "d4e57e63126d2cca1d381c025170e4b1f678c3f3", + "source_revision": "9781102e2971d762ae42fdd5085a6647afd1cd66", "status": "accepted", "title": "Object Storage STS Credential Vending Boundary" }, @@ -795,7 +795,7 @@ "source_digest": "b7c4f6a13f2f5add08bd03cb39c4f18ca25b202747dde883a309d1b3eaa1f571", "source_path": "docs/adr/ADR-0010-orchestration-vs-dependency-self-coherent-intent.md", "source_repo": "net-kingdom", - "source_revision": "d4e57e63126d2cca1d381c025170e4b1f678c3f3", + "source_revision": "9781102e2971d762ae42fdd5085a6647afd1cd66", "status": "accepted", "title": "Orchestration vs Dependency, and Self-Coherent Intent" }, @@ -812,7 +812,7 @@ "source_digest": "b5c7fd1e78026063b4a2ca4017202512d4f94ab5e12dc8498a34d04d3a48c7a9", "source_path": "docs/adr/ADR-0011-iam-profile-ownership-and-version-governance.md", "source_repo": "net-kingdom", - "source_revision": "d4e57e63126d2cca1d381c025170e4b1f678c3f3", + "source_revision": "9781102e2971d762ae42fdd5085a6647afd1cd66", "status": "accepted", "title": "NetKingdom IAM Profile Ownership And Version Governance" }, @@ -829,7 +829,7 @@ "source_digest": "e269fabfc376f97f2a03ea66e34059d54016a445a7f30b351a6774b65c96c2ee", "source_path": "docs/adr/ADR-0012-playbook-capability-contract-ownership.md", "source_repo": "net-kingdom", - "source_revision": "d4e57e63126d2cca1d381c025170e4b1f678c3f3", + "source_revision": "9781102e2971d762ae42fdd5085a6647afd1cd66", "status": "accepted", "title": "Playbook Capability Contract Ownership" }, @@ -846,7 +846,7 @@ "source_digest": "3a6030a8958176a902942ffd29154104ba3441a09d06edf3deaeadc7291ee0d4", "source_path": "docs/adr/ADR-0013-tenant-onboarding-grouping-taxonomy.md", "source_repo": "net-kingdom", - "source_revision": "d4e57e63126d2cca1d381c025170e4b1f678c3f3", + "source_revision": "9781102e2971d762ae42fdd5085a6647afd1cd66", "status": "accepted", "title": "Tenant Onboarding Grouping Taxonomy" }, @@ -863,7 +863,7 @@ "source_digest": "843f7a65f0fc145d08a73e364bc9a1dee0f7b8af934abf1584ee39dffa903ee0", "source_path": "docs/adr/ADR-0014-tenant-capability-roles-and-tenant-engine-ownership.md", "source_repo": "net-kingdom", - "source_revision": "d4e57e63126d2cca1d381c025170e4b1f678c3f3", + "source_revision": "9781102e2971d762ae42fdd5085a6647afd1cd66", "status": "accepted", "title": "Tenant Capability Roles, Carrying Mechanism, and Tenant-Engine Ownership" }, @@ -880,7 +880,7 @@ "source_digest": "2000985ef211aeedd3656e15cedb289e655526c2dcc4a161a64ffc27f0289db1", "source_path": "docs/adr/ADR-0015-netkingdom-railiance-workload-packaging-and-relational-platform.md", "source_repo": "net-kingdom", - "source_revision": "d4e57e63126d2cca1d381c025170e4b1f678c3f3", + "source_revision": "9781102e2971d762ae42fdd5085a6647afd1cd66", "status": "accepted", "title": "NetKingdom Railiance Workload Packaging and Relational Platform" }, @@ -948,7 +948,7 @@ "source_digest": "868f953688988b11ce48f4141833bbca51abdb4e86d5b495a8a905002830d7b0", "source_path": "docs/adr/ADR-0007-build-stage-stops-at-credential-disclosure.md", "source_repo": "ops-warden", - "source_revision": "4e267179db741b27a3e62f81f753cd9752c97412", + "source_revision": "8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5", "status": "accepted", "title": "ADR-0007 \u2014 Build-stage permissiveness stops at credential disclosure" }, @@ -965,7 +965,7 @@ "source_digest": "2e22863ba592802cceb40b32d395168b42ace747741f5188307505eaa89ff764", "source_path": "docs/adr/ADR-0008-grade-the-path-not-the-field.md", "source_repo": "ops-warden", - "source_revision": "4e267179db741b27a3e62f81f753cd9752c97412", + "source_revision": "8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5", "status": "accepted", "title": "ADR-0008 \u2014 A lane's risk grade covers every field its path discloses" }, @@ -982,7 +982,7 @@ "source_digest": "73fff22177b4bec2c56ff737e06e4225eb02d39669be3ea1b723906245f878b8", "source_path": "docs/adr/ADR-0009-adopt-security-zones-as-a-consumer.md", "source_repo": "ops-warden", - "source_revision": "4e267179db741b27a3e62f81f753cd9752c97412", + "source_revision": "8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5", "status": "accepted", "title": "ADR-0009 \u2014 Adopt security-zones v0.1 as a consumer" }, @@ -999,7 +999,7 @@ "source_digest": "064455bcb2870abf8e243f5a8c154e50bfc1c537cfba7996a792f9e314dd78ae", "source_path": "docs/adr/ADR-0010-ops-warden-is-staff.md", "source_repo": "ops-warden", - "source_revision": "4e267179db741b27a3e62f81f753cd9752c97412", + "source_revision": "8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5", "status": "accepted", "title": "ADR-0010 \u2014 ops-warden is Staff: lanes, not rules, and one declared engine gap" }, @@ -1033,7 +1033,7 @@ "source_digest": "b5e8582459f546ae789ad5fd62f458454aa19997b520e32b6b9f792d6af55987", "source_path": "canon/architecture/adr-012-projection-source-and-preliminary-overlay.md", "source_repo": "the-custodian", - "source_revision": "4b951be3947f9457cc091a7d359d9232646b4c93", + "source_revision": "f9435cd605cc5b3cb0f2e957ce6287d9f3129aac", "status": "accepted", "title": "What the Hub Projects: Forge as Projection Source, Working Copies as Preliminary Overlay" }, @@ -1050,7 +1050,7 @@ "source_digest": "dd2628b9f0c2a662ac44af22657d91918da228f307ebc7ceb09fc856162985db", "source_path": "canon/standards/posture-feedback_v0.1.md", "source_repo": "net-kingdom", - "source_revision": "d4e57e63126d2cca1d381c025170e4b1f678c3f3", + "source_revision": "9781102e2971d762ae42fdd5085a6647afd1cd66", "status": "proposed", "title": "NetKingdom Posture Feedback v0.1" }, @@ -1067,7 +1067,7 @@ "source_digest": "8155e7b123be1e84377d8278525b1bad8961007b6bb8ff012dd01ba24ff8065b", "source_path": "canon/standards/security-layer-model_v0.7.md", "source_repo": "net-kingdom", - "source_revision": "d4e57e63126d2cca1d381c025170e4b1f678c3f3", + "source_revision": "9781102e2971d762ae42fdd5085a6647afd1cd66", "status": "accepted", "title": "NetKingdom Security Layer Model v0.7" }, @@ -1084,7 +1084,7 @@ "source_digest": "17b715d78e04470a0f83b8bc8c7313ab16e13e9e741d5ec445172d9008fce937", "source_path": "canon/standards/security-scenario-composition_v0.1.md", "source_repo": "net-kingdom", - "source_revision": "d4e57e63126d2cca1d381c025170e4b1f678c3f3", + "source_revision": "9781102e2971d762ae42fdd5085a6647afd1cd66", "status": "proposed", "title": "NetKingdom Security Scenario Composition v0.1" }, @@ -1101,11 +1101,130 @@ "source_digest": "32e71e9c0d6946bb14099eb66193822da26f199de0e11d8488464207f3bd9906", "source_path": "canon/standards/security-zones_v0.1.md", "source_repo": "net-kingdom", - "source_revision": "d4e57e63126d2cca1d381c025170e4b1f678c3f3", + "source_revision": "9781102e2971d762ae42fdd5085a6647afd1cd66", "status": "proposed", "title": "NetKingdom Security Zones v0.1" + }, + { + "canonical_path": "findings/flex-auth-unauthenticated-check/v1/index.html", + "currency": "current", + "id": "RISK-F-0001", + "last_reviewed": "2026-08-20", + "lifecycle": "active", + "owner": "risk-nexus", + "review_due": "2027-02-20", + "revision": "published-1", + "revision_path": "findings/flex-auth-unauthenticated-check/v1/revisions/published-1/index.html", + "source_digest": "b2d1d0c526d5c9b5729b8353877bb9f29096667145f1498cfde73c9711206fda", + "source_path": "findings/RISK-F-0001-flex-auth-unauthenticated-check.md", + "source_repo": "risk-nexus", + "source_revision": "c5517c754bd84b0ebf47878ba0f26df0ecb3b4a4", + "status": "fixed", + "title": "flex-auth /v1/check authenticates no caller" + }, + { + "canonical_path": "findings/audit-retention-legal-basis/v1/index.html", + "currency": "current", + "id": "RISK-F-0008", + "last_reviewed": "2026-08-20", + "lifecycle": "active", + "owner": "risk-nexus", + "review_due": "2027-02-20", + "revision": "published-1", + "revision_path": "findings/audit-retention-legal-basis/v1/revisions/published-1/index.html", + "source_digest": "8bf47414a9f958afb57649f087a2617f91a8f2aeaa4f34d04d8fb3a0f453e840", + "source_path": "findings/RISK-F-0008-audit-retention-legal-basis-assumed.md", + "source_repo": "risk-nexus", + "source_revision": "c5517c754bd84b0ebf47878ba0f26df0ecb3b4a4", + "status": "accepted", + "title": "The legal basis for retaining audit facts against an erasure request has been assumed, never established" + }, + { + "canonical_path": "methods/risk-severity/v1/index.html", + "currency": "current", + "id": "RISK-METHOD-SEVERITY", + "last_reviewed": "2026-08-20", + "lifecycle": "active", + "owner": "risk-nexus", + "review_due": "2027-02-20", + "revision": "adopted-1", + "revision_path": "methods/risk-severity/v1/revisions/adopted-1/index.html", + "source_digest": "f064c591aeef9425bbfbd5fa2aae659abb0ef83b8586848300077f41dd4ffaab", + "source_path": "docs/method/severity.md", + "source_repo": "risk-nexus", + "source_revision": "c5517c754bd84b0ebf47878ba0f26df0ecb3b4a4", + "status": "adopted", + "title": "Severity: how bad, how likely, and what is not a risk at all" + }, + { + "canonical_path": "methods/risk-disclosure/v1/index.html", + "currency": "current", + "id": "RISK-METHOD-DISCLOSURE", + "last_reviewed": "2026-08-20", + "lifecycle": "active", + "owner": "risk-nexus", + "review_due": "2027-02-20", + "revision": "adopted-1", + "revision_path": "methods/risk-disclosure/v1/revisions/adopted-1/index.html", + "source_digest": "bd825a87736c8fb019d4224c3ef4fe3882b8f3028035225b4b8ff8cad62fdb81", + "source_path": "docs/method/disclosure.md", + "source_repo": "risk-nexus", + "source_revision": "c5517c754bd84b0ebf47878ba0f26df0ecb3b4a4", + "status": "adopted", + "title": "Disclosure: publish now, hold, or restrict" + }, + { + "canonical_path": "methods/risk-review/v1/index.html", + "currency": "current", + "id": "RISK-METHOD-REVIEW", + "last_reviewed": "2026-08-20", + "lifecycle": "active", + "owner": "risk-nexus", + "review_due": "2027-02-20", + "revision": "adopted-1", + "revision_path": "methods/risk-review/v1/revisions/adopted-1/index.html", + "source_digest": "8f873d105bf6bd711a1a15ebd739b2abe97365b4e854be9d1c82e3ff3b162cfd", + "source_path": "docs/method/review.md", + "source_repo": "risk-nexus", + "source_revision": "c5517c754bd84b0ebf47878ba0f26df0ecb3b4a4", + "status": "adopted", + "title": "Review and expiry: what happens when nobody looks" + }, + { + "canonical_path": "methods/risk-verification/v1/index.html", + "currency": "current", + "id": "RISK-METHOD-VERIFICATION", + "last_reviewed": "2026-08-20", + "lifecycle": "active", + "owner": "risk-nexus", + "review_due": "2027-02-20", + "revision": "adopted-1", + "revision_path": "methods/risk-verification/v1/revisions/adopted-1/index.html", + "source_digest": "562b6eb3031ffe35e712c5e11e35aae23ce84a90e0090438dc89513f9685052b", + "source_path": "docs/method/verification.md", + "source_repo": "risk-nexus", + "source_revision": "c5517c754bd84b0ebf47878ba0f26df0ecb3b4a4", + "status": "adopted", + "title": "What this register may verify for itself, and what it must take from owners" + }, + { + "canonical_path": "methods/risk-dependencies/v1/index.html", + "currency": "current", + "id": "RISK-METHOD-DEPENDENCIES", + "last_reviewed": "2026-08-20", + "lifecycle": "active", + "owner": "risk-nexus", + "review_due": "2027-02-20", + "revision": "adopted-1", + "revision_path": "methods/risk-dependencies/v1/revisions/adopted-1/index.html", + "source_digest": "a5e7b42043b0bb366add9bbc5f606e134ef5b0454532480203d5d87099296240", + "source_path": "docs/method/dependencies.md", + "source_repo": "risk-nexus", + "source_revision": "c5517c754bd84b0ebf47878ba0f26df0ecb3b4a4", + "status": "adopted", + "title": "Waiting: how this register depends on other people without becoming a queue" } ], - "generated_as_of": "2026-08-31", + "generated_as_of": "2026-09-01", "schema_version": 1 } diff --git a/build/standards/autonomy-lanes/v0.1/index.html b/build/standards/autonomy-lanes/v0.1/index.html index c59a452..21a3d4b 100644 --- a/build/standards/autonomy-lanes/v0.1/index.html +++ b/build/standards/autonomy-lanes/v0.1/index.html @@ -1,6 +1,6 @@ - + Autonomy Lanes (Fleet) v0.1 -
canon-autonomy-lanes accepted · accepted-1 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Autonomy Lanes (Fleet) v0.1

Source: the-custodian · canon/standards/autonomy-lanes_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93

Review due: 2027-02-28

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 AutonomyPolicy.md remains the company-level policy instance; this standard makes the lane vocabulary and enforcement rules fleet-wide.

+
canon-autonomy-lanes accepted · accepted-1 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Autonomy Lanes (Fleet) v0.1

Source: the-custodian · canon/standards/autonomy-lanes_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac

Review due: 2027-02-28

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 AutonomyPolicy.md remains the company-level policy instance; this standard makes the lane vocabulary and enforcement rules fleet-wide.

The rule

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.

Valid states: proceeding | prepared for review | deferred by policy. Invalid state: waiting because unsure. Uncertainty triggers research, comparison, preparation, or risk classification — not paralysis. "Ask the human" is never the default.

@@ -219,4 +219,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

References

  • binky-control/AutonomyPolicy.md (origin instance)
  • canon/standards/work-record-types_v0.1.md
  • research/2026-07-19-work-orchestration-best-practices.md §2
-
canon-autonomy-lanes · accepted-1 · acceptedthe-custodian · canon/standards/autonomy-lanes_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93
+
diff --git a/build/standards/contribution-convention/v0.1/index.html b/build/standards/contribution-convention/v0.1/index.html index ec65d3b..62c56cc 100644 --- a/build/standards/contribution-convention/v0.1/index.html +++ b/build/standards/contribution-convention/v0.1/index.html @@ -1,6 +1,6 @@ - + Contribution Convention v0.1 -
canon-contrib-convention accepted · accepted-1 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Contribution Convention v0.1

Source: the-custodian · canon/standards/contribution-convention_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93

Review due: 2027-02-28

Purpose

+
canon-contrib-convention accepted · accepted-1 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Contribution Convention v0.1

Source: the-custodian · canon/standards/contribution-convention_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac

Review due: 2027-02-28

Purpose

This document defines the canonical convention for tracking upstream contributions across all custodian-ecosystem repositories. A contribution is any intentional engagement with an external upstream project: a bug report, feature request, extension-point proposal, or pull request.

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.

@@ -270,4 +270,4 @@ draft_pr_body: |

Relationship to State Hub

Once an artifact is registered via register_contribution() MCP tool or POST /contributions/ API, the State Hub assigns a UUID and returns it. That UUID is written back into state_hub_contribution_id in the frontmatter.

The State Hub is a read/cache layer — the Markdown file is always the authoritative source of truth. If the DB is reset, contributions can be re-ingested from the files.

-
canon-contrib-convention · accepted-1 · acceptedthe-custodian · canon/standards/contribution-convention_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93
+
diff --git a/build/standards/iam-profile/v0.3/index.html b/build/standards/iam-profile/v0.3/index.html index bdbc92c..c351db0 100644 --- a/build/standards/iam-profile/v0.3/index.html +++ b/build/standards/iam-profile/v0.3/index.html @@ -1,6 +1,6 @@ - + NetKingdom IAM Profile v0.3 -
netkingdom-iam-profile-v0.3 accepted · accepted-1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

NetKingdom IAM Profile v0.3

Source: net-kingdom · canon/standards/iam-profile_v0.3.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3

Review due: 2027-02-22

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; tenant_roles and the revised Tenant Claim guidance are additive.

+
netkingdom-iam-profile-v0.3 accepted · accepted-1 net-kingdom reviewed 2026-08-22generated from canonical source — do not edit

NetKingdom IAM Profile v0.3

Source: net-kingdom · canon/standards/iam-profile_v0.3.md · 9781102e2971d762ae42fdd5085a6647afd1cd66

Review due: 2027-02-22

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; tenant_roles and the revised Tenant Claim guidance are additive.

Purpose

The NetKingdom IAM Profile is the provider-neutral OIDC contract that identity implementations issue and applications consume.

It defines:

@@ -316,4 +316,4 @@ agentic - financially enabled AI entities

Validation Checklist

A service or implementation is profile-ready when:

  • it reads OIDC discovery rather than hardcoding endpoints;
  • it validates issuer, audience, expiry, nbf, algorithm, and signature;
  • it refreshes JWKS on unknown kid;
  • it supports Authorization Code + PKCE for human login;
  • it supports service-account or workload identity tokens;
  • it emits tenant, principal_type, groups, roles, scope/scp, and assurance;
  • it uses the ADR-0013 grouping vocabulary for new tenant identifiers;
  • if it consumes tenant_roles, it treats the claim as a cache and re-validates live against tenant-engine before any aal2-class decision;
  • it maps provider-native claims into the canonical core claims;
  • it rejects local-development issuers in production;
  • it logs emergency access with a durable audit trail;
  • flex-auth receives identity facts from the profile, not from provider-specific sessions.
-
netkingdom-iam-profile-v0.3 · accepted-1 · acceptednet-kingdom · canon/standards/iam-profile_v0.3.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3
+
diff --git a/build/standards/posture-feedback/v0.1/index.html b/build/standards/posture-feedback/v0.1/index.html index aa3a9d6..fb4c59b 100644 --- a/build/standards/posture-feedback/v0.1/index.html +++ b/build/standards/posture-feedback/v0.1/index.html @@ -1,6 +1,6 @@ - + NetKingdom Posture Feedback v0.1 -
netkingdom-posture-feedback-v0.1 proposed net-kingdom reviewed 2026-08-23generated from canonical source — do not edit

NetKingdom Posture Feedback v0.1

Source: net-kingdom · canon/standards/posture-feedback_v0.1.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3

Review due: 2026-11-23

01Purpose

+
netkingdom-posture-feedback-v0.1 proposed net-kingdom reviewed 2026-08-23generated from canonical source — do not edit

NetKingdom Posture Feedback v0.1

Source: net-kingdom · canon/standards/posture-feedback_v0.1.md · 9781102e2971d762ae42fdd5085a6647afd1cd66

Review due: 2026-11-23

01Purpose

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 proposals.

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.

@@ -221,4 +221,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

06Exit behavior

The CLI emits a report conforming to posture-feedback-report_v0.1.schema.json. --fail-on high exits non-zero when at least one high-severity finding exists; medium includes medium and high; low includes every finding; none reports without a finding-based failure. Invalid declarations always exit non-zero.

-
+ diff --git a/build/standards/project-repository-flavor/v0.1/index.html b/build/standards/project-repository-flavor/v0.1/index.html index 650f068..4815225 100644 --- a/build/standards/project-repository-flavor/v0.1/index.html +++ b/build/standards/project-repository-flavor/v0.1/index.html @@ -1,6 +1,6 @@ - + Project Repository Flavor (prj-) v0.1 -
canon-project-repository-flavor accepted · accepted-1 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Project Repository Flavor (prj-) v0.1

Source: the-custodian · canon/standards/project-repository-flavor_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93

Review due: 2027-02-28

Purpose

+
canon-project-repository-flavor accepted · accepted-1 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Project Repository Flavor (prj-) v0.1

Source: the-custodian · canon/standards/project-repository-flavor_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac

Review due: 2027-02-28

Purpose

Define the durable project repository flavor used for complex cross-repository efforts: naming, required files, authority boundary, lifecycle, residual handoff, and archive procedure.

This standard implements and completes ADR-005 (Cross-Repo Workplans Live in Dedicated Project Repos). It does not replace the Repo Classification Standard: project repositories still use category: project in .repo-classification.yaml.

@@ -276,4 +276,4 @@ reviewed: "YYYY-MM-DD"
+ diff --git a/build/standards/security-layer-model/v0.7/index.html b/build/standards/security-layer-model/v0.7/index.html index af28982..3719b3b 100644 --- a/build/standards/security-layer-model/v0.7/index.html +++ b/build/standards/security-layer-model/v0.7/index.html @@ -1,6 +1,6 @@ - + NetKingdom Security Layer Model v0.7 -
netkingdom-security-layer-model-v0.7 accepted gate-house reviewed 2026-08-28generated from canonical source — do not edit

NetKingdom Security Layer Model v0.7

Source: net-kingdom · canon/standards/security-layer-model_v0.7.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3

Review due: 2026-11-28

01Purpose

+
netkingdom-security-layer-model-v0.7 accepted gate-house reviewed 2026-08-28generated from canonical source — do not edit

NetKingdom Security Layer Model v0.7

Source: net-kingdom · canon/standards/security-layer-model_v0.7.md · 9781102e2971d762ae42fdd5085a6647afd1cd66

Review due: 2026-11-28

01Purpose

This standard states how NetKingdom's IT-security estate is layered, and what each layer may and may not do. It answers one question:

Given a repository, which layer is it in, and what does that permit it to own?

The layers are distinguished by determinism and by the kind of artifact the layer produces, not by technical tier, deployment topology, or team.

@@ -458,4 +458,4 @@ Taxonomy cross-cutting language
  • A rapp-* is the most likely resource a decision is rendered about, but nothing states its identity form in a request claim.
  • A rail-* 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 carry an obligation is unwritten.
  • A reef-* answers where a workload is bound, which is adjacent to a security zone (security-zones_v0.1) without being one. zone-engine records that a reef capping availability for everything bound to it is a canon composition problem. That composition is unwritten.
  • The railiance-* ownership axis 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.
  • glas-harness and reins 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.

20.4 How this boundary changes

An interaction boundary between two frameworks is owned by neither alone. Changes to §20 require assent from railiance-master for the axis definitions and from glas-harness 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 is.

-
netkingdom-security-layer-model-v0.7 · · acceptednet-kingdom · canon/standards/security-layer-model_v0.7.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3
+
diff --git a/build/standards/security-scenario-composition/v0.1/index.html b/build/standards/security-scenario-composition/v0.1/index.html index 952157e..b2e9afd 100644 --- a/build/standards/security-scenario-composition/v0.1/index.html +++ b/build/standards/security-scenario-composition/v0.1/index.html @@ -1,6 +1,6 @@ - + NetKingdom Security Scenario Composition v0.1 -
netkingdom-security-scenario-composition-v0.1 proposed net-kingdom reviewed 2026-08-23generated from canonical source — do not edit

NetKingdom Security Scenario Composition v0.1

Source: net-kingdom · canon/standards/security-scenario-composition_v0.1.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3

Review due: 2026-11-23

01Purpose

+
netkingdom-security-scenario-composition-v0.1 proposed net-kingdom reviewed 2026-08-23generated from canonical source — do not edit

NetKingdom Security Scenario Composition v0.1

Source: net-kingdom · canon/standards/security-scenario-composition_v0.1.md · 9781102e2971d762ae42fdd5085a6647afd1cd66

Review due: 2026-11-23

01Purpose

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.

Composition answers what is selected, in which trust order, with which safe parameters, and who must execute and evidence it. It does not run a playbook, mint a credential, infer authority, or declare a runtime ready.

@@ -236,4 +236,4 @@ parameter_overrides: 
python3 tools/security-scenario-composer/security_scenario_composer.py \
   --scenario <scenario.yaml> <declaration.yaml> [<declaration.yaml> ...]

Exit zero means the declarations and scenario compose deterministically. It does not mean the plan was executed or its readiness evidence was observed.

-
+ diff --git a/build/standards/security-zones/v0.1/index.html b/build/standards/security-zones/v0.1/index.html index 03b9be0..763806c 100644 --- a/build/standards/security-zones/v0.1/index.html +++ b/build/standards/security-zones/v0.1/index.html @@ -1,6 +1,6 @@ - + NetKingdom Security Zones v0.1 -
netkingdom-security-zones-v0.1 proposed zone-engine reviewed 2026-08-22generated from canonical source — do not edit

NetKingdom Security Zones v0.1

Source: net-kingdom · canon/standards/security-zones_v0.1.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3

Review due: 2026-11-22

01Purpose

+
netkingdom-security-zones-v0.1 proposed zone-engine reviewed 2026-08-22generated from canonical source — do not edit

NetKingdom Security Zones v0.1

Source: net-kingdom · canon/standards/security-zones_v0.1.md · 9781102e2971d762ae42fdd5085a6647afd1cd66

Review due: 2026-11-22

01Purpose

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.

This standard is a sibling of tenancy-posture_v0.1. It owns zone identity, membership, admission, resolution, and the time-boxed exception lifecycle. flex-auth remains the only PDP for decisions it renders. Every other control continues to be owned and evaluated at its existing enforcement point.

@@ -317,4 +317,4 @@ controls:

Net-kingdom published this standard at revision 337484a. Adoption requires:

  1. flex-auth and ops-warden accept the initial control profile or publish a versioned replacement with total zone and unknown coverage;
  2. at least two workload owners declare authoritative identities and zones;
  3. a third consumer compiles or reads the resolved view; and
  4. ops-warden retires policy.enabled and the dormant trust_zone constant in the same migration.

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 docs/evidence/security-zone-adoption-2026-08-22.md.

-
+ diff --git a/build/standards/tenancy-posture/v0.1/index.html b/build/standards/tenancy-posture/v0.1/index.html index d8e41d9..1347183 100644 --- a/build/standards/tenancy-posture/v0.1/index.html +++ b/build/standards/tenancy-posture/v0.1/index.html @@ -1,6 +1,6 @@ - + NetKingdom Tenancy Posture v0.1 -
netkingdom-tenancy-posture proposed · draft-14 net-kingdom reviewed 2026-08-23generated from canonical source — do not edit

NetKingdom Tenancy Posture v0.1

A framework for describing, holding and improving multi-tenancy — including where we are not there yet.

Source: net-kingdom · canon/standards/tenancy-posture_v0.1.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3

Review due: 2027-02-23

Status

+
netkingdom-tenancy-posture proposed · draft-14 net-kingdom reviewed 2026-08-23generated from canonical source — do not edit

NetKingdom Tenancy Posture v0.1

A framework for describing, holding and improving multi-tenancy — including where we are not there yet.

Source: net-kingdom · canon/standards/tenancy-posture_v0.1.md · 9781102e2971d762ae42fdd5085a6647afd1cd66

Review due: 2027-02-23

Status

Proposed, draft-13; ratification-ready. Relocated from the-custodian/canon/architecture 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.

  • draft-1 proposed a single model with fixed characteristics. Rejected: it could not describe a repo that is not there yet.
  • draft-2 reframed to graduated levels per axis. Externally corroborated (§16), but four of its statements were wrong and one thing it needed was missing.
  • draft-3 applied those corrections, added the retention axis, and recorded an adoption stance.
  • draft-4 closed the two gaps draft-3 left open: R4 had no mechanism beyond waiting, and the noisy-neighbour evidence artifact asserted something shared infrastructure cannot provide.
  • draft-5 relocated to NetKingdom and renamed the dimensions from planes to axes, because the word was already taken (§0).
  • draft-6 applied tenant-engine's review: five changes, including an axis that did not fit its data shape.
  • draft-7 applies audit-core, railiance-platform and flex-auth. Eleven further changes, two of them corrections to statements this document made as fact about other repos. Every posture I guessed was too generous, on every repo that has now self-reported.
  • draft-8 applies adaptive-pricing'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.
  • draft-9 answers zone-engine's ZONE-WP-0001-T01. It rules that enforcement stance is not a seventh axis (Decision 5.6) while reserving zones: in tenancy.yaml so the estate keeps one declaration surface, and it records the reef/P/V reconciliation as an open defect of this document rather than of the repo that noticed it (Decision 8.4).
  • draft-10 answers zone-engine's ZONE-WP-0001-T03. 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 unknown without zone inference (Decision 5.6.1). It also closes the textual reef/P boundary while leaving the substrate-provider declaration and mechanical V join as implementation work (Decision 8.4.2).
  • draft-11 makes that ruling declarable. A zones: block now requires an authoritative workload_identity beside it, including for non-rapp operational workloads; multi-service files carry both per service. Missing identity remains absence rather than a guessed join (Decision 5.6.2).
  • draft-12 reconciles that declaration with RMGR-ADR-004 and the published security-zones_v0.1 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 not-applicable, while omitted or unresolved workload references remain unknown (Decision 5.6.2).
  • draft-13 advances the audit-core worked example from E1 to E2 after bounded adversarial run WH-ENG-20260822-AUDIT-E2-03 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.
  • draft-14 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 unknown; it does not infer either or mutate the declared posture.
@@ -493,4 +493,4 @@ per consumer: 14 connections (12 runtime + 2 migration)

20Ratification path

  1. Reviewed by tenant-engine, flex-auth, audit-core, rapp-postgres, railiance-platform and adaptive-pricing against §19. Complete in draft-8.
  2. Each publishes its own posture vector (§5) as part of review. The framework is validated by whether it can describe them accurately — if a repo cannot express itself in these six ladders, the ladders are wrong and this document changes, not the repo. Complete in draft-8; all six root declarations validate against the canonical schema.
  3. On acceptance, supersedes the routing of rapp-postgres/docs/canon-drafts/shared-platform-relational-storage_v0.1-draft.md, whose §§3–8 are absorbed here. That draft is withdrawn rather than left pending.
  4. On acceptance, rapp-postgres ADR-0001 through ADR-0004 move to accepted and are annotated as the PostgreSQL implementation of the E, P, R and shared-capacity rules.
-
netkingdom-tenancy-posture · draft-14 · proposednet-kingdom · canon/standards/tenancy-posture_v0.1.md · d4e57e63126d2cca1d381c025170e4b1f678c3f3
+
diff --git a/build/standards/work-record-types/v0.1/index.html b/build/standards/work-record-types/v0.1/index.html index c7f38af..ff41ddc 100644 --- a/build/standards/work-record-types/v0.1/index.html +++ b/build/standards/work-record-types/v0.1/index.html @@ -1,6 +1,6 @@ - + Work Record Types & Identity (Fleet) v0.1 -
canon-work-record-types accepted · accepted-1 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Work Record Types & Identity (Fleet) v0.1

Source: the-custodian · canon/standards/work-record-types_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93

Review due: 2027-02-28

Ratified by founder 2026-07-20 (CUST-WP-0060-T01, hub decision f4640f9e). Source: research/WorkOrchestrationArchitectureDraft.md v0.2 (founder-reviewed 2026-07-20). Extends — does not replace — workplan-terminology-fleet_v0.1.md and ADR-001/ADR-005.

+
canon-work-record-types accepted · accepted-1 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Work Record Types & Identity (Fleet) v0.1

Source: the-custodian · canon/standards/work-record-types_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac

Review due: 2027-02-28

Ratified by founder 2026-07-20 (CUST-WP-0060-T01, hub decision f4640f9e). Source: research/WorkOrchestrationArchitectureDraft.md v0.2 (founder-reviewed 2026-07-20). Extends — does not replace — workplan-terminology-fleet_v0.1.md and ADR-001/ADR-005.

Purpose

Define work record as the umbrella term for every identified, lifecycle-bearing coordination artefact in the fleet; register the closed list of work-record kinds, 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 & compliance, controlling, billing, marketing, sales — under one conceptual framework (different demands are met by flow profiles and kind-specific fields, never by parallel ontologies).

@@ -243,4 +243,4 @@ a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-off

References

  • research/WorkOrchestrationArchitectureDraft.md (v0.2)
  • research/2026-07-19-work-orchestration-infrastructure-survey.md
  • research/2026-07-19-work-orchestration-best-practices.md
  • canon/architecture/adr-001-workplans-as-repo-artefacts.md, adr-005-…
  • canon/standards/workplan-terminology-fleet_v0.1.md
  • canon/standards/autonomy-lanes_v0.1.md
  • state-hub/docs/task-flow-engine-spec.md
-
canon-work-record-types · accepted-1 · acceptedthe-custodian · canon/standards/work-record-types_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93
+
diff --git a/build/standards/workplan-terminology/v0.1/index.html b/build/standards/workplan-terminology/v0.1/index.html index 3f13d54..66904cb 100644 --- a/build/standards/workplan-terminology/v0.1/index.html +++ b/build/standards/workplan-terminology/v0.1/index.html @@ -1,6 +1,6 @@ - + Workplan Terminology (Fleet) v0.1 -
canon-workplan-terminology-fleet accepted · accepted-1 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Workplan Terminology (Fleet) v0.1

Source: the-custodian · canon/standards/workplan-terminology-fleet_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93

Review due: 2027-02-28

Purpose

+
canon-workplan-terminology-fleet accepted · accepted-1 the-custodian reviewed 2026-08-31generated from canonical source — do not edit

Workplan Terminology (Fleet) v0.1

Source: the-custodian · canon/standards/workplan-terminology-fleet_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac

Review due: 2027-02-28

Purpose

Define workplan as the canonical fleet term for repo-backed deliverable work indexed by State Hub. Preserve explicit legacy bridges where APIs, events, generated fields, or historical documents still say workstream, until metered retirement criteria are met.

This standard complements:

  • ADR-001 — workplans originate as repo files; the hub indexes them.
  • STATE-WP-0054 — State Hub compatibility layer and legacy-meter.
  • STATE-WP-0069 — State Hub legacy interface retirement (child plan).
  • CUST-WP-0055 — fleet-wide coordination and prose migration.
@@ -233,4 +233,4 @@ python tools/scan_workstream_terminology.py --repo <slug> --json

References

  • canon/architecture/adr-001-workplans-as-repo-artefacts.md
  • state-hub/docs/workplan-terminology-transition.md
  • state-hub/workplans/STATE-WP-0054-workplan-terminology-transition-legacy-meter.md
  • state-hub/workplans/STATE-WP-0069-workplan-terminology-legacy-retirement.md
  • workplans/CUST-WP-0055-workplan-terminology-fleet-refactor.md
-
canon-workplan-terminology-fleet · accepted-1 · acceptedthe-custodian · canon/standards/workplan-terminology-fleet_v0.1.md · 4b951be3947f9457cc091a7d359d9232646b4c93
+
diff --git a/docs/publication-contract.md b/docs/publication-contract.md index 4e5eece..a650213 100644 --- a/docs/publication-contract.md +++ b/docs/publication-contract.md @@ -16,8 +16,13 @@ not write back. | `architecture` | One arc42 document per system | `docs/architecture/_v0.1.md` or `canon/architecture/_v0.1.md` | | `constitution` | Estate constitution | `canon/constitution/` | | `adr` | Architecture decision record | `docs/adr/.md` | +| `findings` | A finding explicitly marked public by `risk-nexus` | `findings/RISK-F-NNNN-.md` | +| `methods` | A public risk judgement instrument | `docs/method/.md` | -Workplans, evidence, runbooks, review ledgers, and general docs are out. +Risk findings and methods are published only after `risk-nexus` has made the +disclosure decision and an explicit `publication.json` entry names the file. +Embargoed or restricted findings fail that admission test. Workplans, evidence, +runbooks, review ledgers, rulings, and general docs are out. An ADR is published only after an explicit `publication.json` entry. Architecture documents follow the same rule. Discovery @@ -29,7 +34,7 @@ Architecture documents follow the same rule. Discovery --- id: title: "Human title" -status: proposed | accepted | superseded | withdrawn +status: proposed | accepted | adopted | fixed | superseded | withdrawn owner: revision: "accepted-1" last_reviewed: "YYYY-MM-DD" @@ -59,7 +64,7 @@ From ADR-0001: ////revisions// ``` -- `` is one of the four kinds above. +- `` is one of the six kinds above. - `` is a kebab-case slug, unique on the site. If two systems would share a short name, prefix with the system slug (`railiance-repository-prefix`, not `repository-prefix`). @@ -75,6 +80,8 @@ Examples: /architecture/policy-nexus/v0.1/ /adr/addressing-and-permanence/v1/ /adr/railiance-repository-prefix/v1/ +/findings/flex-auth-unauthenticated-check/v1/ +/methods/risk-severity/v1/ ``` No URL is derived from a checkout path, branch, or build number. diff --git a/publication.json b/publication.json index 650f800..7f43ec2 100644 --- a/publication.json +++ b/publication.json @@ -39,6 +39,9 @@ }, "railiance-infra": { "path": "../railiance-infra" + }, + "risk-nexus": { + "path": "../risk-nexus" } }, "documents": [ @@ -565,6 +568,64 @@ "canonical_path": "standards/security-zones/v0.1/index.html", "revision_path": "standards/security-zones/v0.1/revisions/{revision}/index.html", "review_interval": "3m" + }, + { + "id": "RISK-F-0001", + "source_repo": "risk-nexus", + "source_path": "findings/RISK-F-0001-flex-auth-unauthenticated-check.md", + "canonical_path": "findings/flex-auth-unauthenticated-check/v1/index.html", + "revision_path": "findings/flex-auth-unauthenticated-check/v1/revisions/{revision}/index.html", + "subtitle": "The estate's authorization oracle authenticated no caller for as long as the endpoint existed. Found by reading, not by monitoring; fixed in two days.", + "review_interval": "6m" + }, + { + "id": "RISK-F-0008", + "source_repo": "risk-nexus", + "source_path": "findings/RISK-F-0008-audit-retention-legal-basis-assumed.md", + "canonical_path": "findings/audit-retention-legal-basis/v1/index.html", + "revision_path": "findings/audit-retention-legal-basis/v1/revisions/{revision}/index.html", + "subtitle": "The estate retains personal data in audit records on grounds nobody had established. Published as a question, because it is one.", + "review_interval": "6m" + }, + { + "id": "RISK-METHOD-SEVERITY", + "source_repo": "risk-nexus", + "source_path": "docs/method/severity.md", + "canonical_path": "methods/risk-severity/v1/index.html", + "revision_path": "methods/risk-severity/v1/revisions/{revision}/index.html", + "review_interval": "6m" + }, + { + "id": "RISK-METHOD-DISCLOSURE", + "source_repo": "risk-nexus", + "source_path": "docs/method/disclosure.md", + "canonical_path": "methods/risk-disclosure/v1/index.html", + "revision_path": "methods/risk-disclosure/v1/revisions/{revision}/index.html", + "review_interval": "6m" + }, + { + "id": "RISK-METHOD-REVIEW", + "source_repo": "risk-nexus", + "source_path": "docs/method/review.md", + "canonical_path": "methods/risk-review/v1/index.html", + "revision_path": "methods/risk-review/v1/revisions/{revision}/index.html", + "review_interval": "6m" + }, + { + "id": "RISK-METHOD-VERIFICATION", + "source_repo": "risk-nexus", + "source_path": "docs/method/verification.md", + "canonical_path": "methods/risk-verification/v1/index.html", + "revision_path": "methods/risk-verification/v1/revisions/{revision}/index.html", + "review_interval": "6m" + }, + { + "id": "RISK-METHOD-DEPENDENCIES", + "source_repo": "risk-nexus", + "source_path": "docs/method/dependencies.md", + "canonical_path": "methods/risk-dependencies/v1/index.html", + "revision_path": "methods/risk-dependencies/v1/revisions/{revision}/index.html", + "review_interval": "6m" } ] } diff --git a/source-inventory.config.json b/source-inventory.config.json index 7538c18..140ba79 100644 --- a/source-inventory.config.json +++ b/source-inventory.config.json @@ -90,6 +90,19 @@ "remote": "https://forgejo.coulomb.social/coulomb/railiance-platform.git", "selectors": ["docs/adr/*.md"] }, + "risk-nexus": { + "branch": "main", + "remote": "https://forgejo.coulomb.social/coulomb/risk-nexus.git", + "selectors": [ + "findings/RISK-F-0001-flex-auth-unauthenticated-check.md", + "findings/RISK-F-0008-audit-retention-legal-basis-assumed.md", + "docs/method/severity.md", + "docs/method/disclosure.md", + "docs/method/review.md", + "docs/method/verification.md", + "docs/method/dependencies.md" + ] + }, "rapp-postgres": { "branch": "main", "remote": "https://forgejo.coulomb.social/coulomb/rapp-postgres.git", diff --git a/source-inventory.json b/source-inventory.json index fd119b1..2632fde 100644 --- a/source-inventory.json +++ b/source-inventory.json @@ -655,6 +655,48 @@ "source_path": "docs/adr/ADR-002-governed-execution-responsibility-chain.md", "source_repo": "rein-aharness" }, + { + "disposition": "published", + "reason": "Published through an explicit publication.json document entry.", + "source_path": "docs/method/dependencies.md", + "source_repo": "risk-nexus" + }, + { + "disposition": "published", + "reason": "Published through an explicit publication.json document entry.", + "source_path": "docs/method/disclosure.md", + "source_repo": "risk-nexus" + }, + { + "disposition": "published", + "reason": "Published through an explicit publication.json document entry.", + "source_path": "docs/method/review.md", + "source_repo": "risk-nexus" + }, + { + "disposition": "published", + "reason": "Published through an explicit publication.json document entry.", + "source_path": "docs/method/severity.md", + "source_repo": "risk-nexus" + }, + { + "disposition": "published", + "reason": "Published through an explicit publication.json document entry.", + "source_path": "docs/method/verification.md", + "source_repo": "risk-nexus" + }, + { + "disposition": "published", + "reason": "Published through an explicit publication.json document entry.", + "source_path": "findings/RISK-F-0001-flex-auth-unauthenticated-check.md", + "source_repo": "risk-nexus" + }, + { + "disposition": "published", + "reason": "Published through an explicit publication.json document entry.", + "source_path": "findings/RISK-F-0008-audit-retention-legal-basis-assumed.md", + "source_repo": "risk-nexus" + }, { "disposition": "published", "reason": "Published through an explicit publication.json document entry.", diff --git a/tests/test_publication.py b/tests/test_publication.py index 571a079..85e9091 100644 --- a/tests/test_publication.py +++ b/tests/test_publication.py @@ -255,6 +255,25 @@ class PublicationTest(unittest.TestCase): with self.assertRaisesRegex(ValueError, "owner is required"): build_site.build(manifest, root / "site") + def test_build_rejects_non_public_risk_record(self) -> None: + with tempfile.TemporaryDirectory() as directory: + root = Path(directory) + manifest = _fixture(root) + value = json.loads(manifest.read_text(encoding="utf-8")) + value["repositories"] = {"risk-nexus": {"path": "canon-repo"}} + value["documents"][0]["source_repo"] = "risk-nexus" + manifest.write_text(json.dumps(value), encoding="utf-8") + source = root / "canon-repo/canon/standards/example.md" + source.write_text( + source.read_text(encoding="utf-8").replace( + "status: proposed\n", "status: proposed\ndisclosure: embargoed\n" + ), + encoding="utf-8", + ) + + with self.assertRaisesRegex(ValueError, "require disclosure: public"): + build_site.build(manifest, root / "site") + if __name__ == "__main__": unittest.main() diff --git a/tools/build_site.py b/tools/build_site.py index 61e9bdf..4cded5a 100644 --- a/tools/build_site.py +++ b/tools/build_site.py @@ -165,7 +165,7 @@ def _index_page(site: dict[str, Any], records: list[dict[str, str]]) -> str: '
policy surface' "generated from canonical sources — do not edit
" f"

{html.escape(site['title'])}

" - '

Canon and architecture decisions at stable addresses, with visible currency.

' + '

Governing documents and public risk records at stable addresses, with visible currency.

' "
" "" "" @@ -201,6 +201,13 @@ def build( raise ValueError( f"{source}: manifest id {document['id']!r} does not match {meta.get('id')!r}" ) + if ( + document["source_repo"] == "risk-nexus" + and meta.get("disclosure") != "public" + ): + raise ValueError( + f"{source}: risk-nexus publications require disclosure: public" + ) for required_field in ("title", "status", "owner"): if not meta.get(required_field): raise ValueError(f"{source}: {required_field} is required for publication")
DocumentStatusLifecycleRevisionOwnerReviewedReview dueCurrency