ADR-011 decision 7 keys derivation on (namespace, identifier), which
separates forks but not collisions inside one namespace. The ecosystem is at
N1, a single implied namespace, and a 2026-08-21 fleet scan finds 20 reused
identifiers across 48 files all inside it. So ADR-011 alone does not satisfy
decision 2's uniqueness prerequisite.
Ruled: C2 derives for live records only; archived records keep frozen minted
identifiers. This reconciles Migration option 2 with the uniqueness
derivation needs, and cuts the remediation surface from 48 files to 11.
Records the two consequences that follow -- un-archiving is a collision
hazard, and derivation is not retroactive -- and why treating a repository as
the namespace was rejected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Complete contents of the suggestion-backlog capability at retirement: 10
suggestions, 10 notes, 5 relevance bumps, raised 2026-07-06 to 2026-07-16.
All closed as declined in the 2026-07-21 intake migration; none promoted.
Kept here rather than in state-hub because state-hub is being archived and
this record must outlive it -- same reasoning as retired-legacy-interfaces.md.
Mutations already 410 since CUST-WP-0061-T06; reads were held open only to
keep this history reachable. This file is what makes removing them safe
(slice E1, STATE-WP-0079-T05).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fleet-level record of legacy interfaces retired under the State Hub
retirement program. Kept here rather than in state-hub because state-hub is
being archived -- once it is read-only its legacy-meter tables stop being
queryable in practice, and this needs to outlive that.
Records the 15 workstream->workplan aliases retired on 2026-08-20 under
STATE-WP-0079-T05 slice E2, the one retired earlier, and the 4 still held
with the reason each is held. Documents the retirement standard including
the volume-scaled quiet ladder and why it exists.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reworks federation from binary rules into the plane/ladder/posture form from
ADR-008 (Four Planes), reusing its vocabulary rather than adding a second
maturity language to the canon.
Four planes: Namespace, Autonomy, Reconciliation, Substrate, each with a
ladder. Draft-1's 'records fork, effects do not' becomes the S ladder.
Posture is declared in the repo per ADR-010 decision 4; the ecosystem's own
posture is recorded honestly as N1 U1 R1 S1.
Key additions: conformance is accuracy not altitude; an anti-overclaim rule
stating that namespace qualification is N-plane movement only and does not
make anything federation-capable, with a commercial clause for
instance-per-client claims; the reconciliation tier is now DERIVED from
participants' postures (any S3 entails T3), so rejoining cost is computable
before a fork exists rather than discovered during reconciliation; evidence
definitions per level; and guard via rmgr conform.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Multi-tenancy is part of the IT-security framework NetKingdom provides, so it
belongs beside the IAM Profile and the tenant-engine boundary contract rather
than in the work-factory canon. Operator decision.
Relocation surfaced two things a review would have caught embarrassingly late.
NetKingdom's accepted platform-identity-security-architecture has used the word
plane since July for a trust and deployment layer - bootstrap, platform
control, tenant. This framework was using the same word for an independent
dimension of concern. Two senses of one word in one canon is precisely the
concept-ownership collision the estate is careful about, and the newcomer
yields: they are now axes. The rename is also just better, since a posture
vector is a point in five-dimensional space.
That same document also disproves the framework's opening line. It has
described the trust model, the tenant model and a capability progression since
2026-07-23, so the claim that the estate had never written down what it was
building was wrong. The accurate and narrower claim is that nothing said how
far a given service had got, or could hold several answers at once.
Stub left behind so the ADR-008 identifier resolves. The renderer moved to
policy-nexus, which owns publication.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The page and the ADR had already diverged once. They are now one source: the
markdown is authoritative and the page is generated, never hand-edited.
The renderer recognises conventions the document already uses rather than
requiring extra markup, so the source stays a readable document. A table whose
first column is **X0**/**X1** becomes a level ladder; a table headed Threat
becomes the threat matrix; a table with a Kind column gets mechanical and
adversarial chips; a table headed "E \ P" becomes the two-axis grid; ## N.
headings build the section rail.
Stdlib only, per the structure-not-tooling stance. A publishing step that needs
its own toolchain is a publishing step that stops being run - the same
reasoning tenant-engine used for its pin check.
One real consequence beyond deduplication: the E x P matrix had existed only on
the page, so the canonical document did not contain its own central diagram.
It is now a table in the markdown, which is where it should always have been.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
R4 now has a mechanism. It splits into horizon-elapsed (wait out a window
somebody else's retention set - available to all, proves little) and
key-destroyed (encrypt per entity, destroy the key, immediate). A service must
name which route it uses.
The regulatory position is stated rather than implied: DPAs have accepted key
destruction as erasure where physical deletion is disproportionate, under
conditions, and the EDPB has not formally endorsed it. Section 11.4 now says a
service may make that claim but not in language implying a regulator blessed
it. Overclaiming here would be worse than anywhere else in the document.
Third coupling recorded: shredding a single tenant's data needs the application
to encrypt under a per-tenant key before writing, so the top of the retention
ladder is an enforcement-plane capability. Reaching R4 is not a retention
project.
The noisy-neighbour artifact was replaced. It had required proof that a
saturating consumer does not breach another's allowance, which shared
infrastructure cannot provide - an artifact that can only fail, or passes by
being run gently, is an overclaim in the costume of evidence. It now measures:
baseline, saturation run, proof the controls bind, recorded degradation.
Generalised as decision 13.4.
The connection ceiling is reframed. Seven consumers each politely inside a
14-connection allowance still exhaust the instance, so the number is the
aggregate noisy-neighbour bound, and our per-consumer governance guards the
other shape entirely.
Also: quota transparency as a disclosure obligation (10.2) - a consumer
learning its statement timeout by hitting it in production is our failure, not
theirs; and two new open questions - crypto-shredding an audit trail destroys
what audit-core exists to hold, and we have no QoS vocabulary despite a
latency-critical consumer sharing an instance with a batch one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Both findings change a level definition in draft-3, so neither is decoration.
R4 had no mechanism. As drafted it meant erasure completes by waiting out a
horizon somebody else's retention set, which is honest and useless as proof.
Crypto-shredding is the established answer: encrypt per entity, destroy the
key, leave the immutable backup unreadable. DPAs have accepted it where
physical deletion is disproportionate; the EDPB has not formally endorsed it,
and R4 should say that rather than imply a clean yes.
The finding underneath it is that shredding granularity is bounded by the key
boundary. Per-consumer shred of logical exports is close - the age lane and
OpenBao already exist. Per-consumer shred of physical backups is not available,
for the same reason retention is not per-consumer. And per-TENANT shred needs
the application to encrypt under a tenant key before writing, which makes the
top of the retention ladder an enforcement-plane capability. That is a third
coupling the ADR does not record.
Also flagged: crypto-shredding an audit trail destroys the evidence audit-core
exists to hold. A naive R4-everywhere target would instruct it to do exactly
that. A question for audit-core, not an answer this framework should give.
The noisy-neighbour artifact asserted something unachievable - that one
consumer saturating its allowance does not breach another's. Azure's first line
of solution text is that the risk cannot be completely avoided. An artifact
that can only fail, or that passes by being run gently, is an overclaim dressed
as evidence. Replaced with characterisation: a recorded baseline, a saturation
run, proof the controls bind, and the measured degradation written down.
That research also reframes the connection ceiling. Seven consumers each
politely inside a 14-connection allowance still exhaust the instance, which is
the aggregate noisy-neighbour shape - so the number in the scaling section is
not a capacity statistic, it is the bound.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Renamed to Tenancy Posture. Four Planes stopped being true and a name that
encodes a count breaks every time the framework grows; the posture vector is
the durable centre.
Corrections from the research digests:
- E3 no longer claims the application cannot route around it. Any session can
re-SET the GUC, so E3 is decisive against a forgotten predicate and useless
against SQL injection or a compromised process. Replaced the claim with a
threat-model table. Draft-2 was overclaiming in exactly the way section 6
prohibits, which is the correction I most wanted made before review.
- E3 layers on E2 rather than replacing it; claiming E3 now requires the E2
artifact too, because E3 alone fails open under injection.
- The GUC is set transaction-locally, not at pool checkout, and the scaling
section's pooling claim was backwards: SET LOCAL is what makes E3 safe under
a pooler; statement-level pooling is what leaks.
- Placement is a default plus per-tenant exceptions. One P level per service
could not express the isolation tiers section 11 already sells.
Added plane R for retention and erasure, implementing the rapp-postgres
ADR-0002 interface: N-day retention defaulting to 30, a published erasure
horizon, and dataset sweeps whose policy the consumer owns. R exists because
deleting a row does not remove it from yesterday's backup, and the estate had
never written that down.
Also: A4 for a standard PDP interface now that AuthZEN is Final; evidence split
into mechanical and adversarial, since a green CI run is not E2 evidence; the
tenant boundary named as OWASP API1; and section 14 recording the
structure-not-tooling stance.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Operator decision: use research as design input, adopt tooling only where it is
an established standard with broad application, otherwise build ground up so we
can refactor freely.
Settles two open recommendations. AuthZEN qualifies (OpenID Final Spec,
multi-vendor interop) and stays as the proposed A4 rung; OWASP stays as a
baseline; PostgreSQL RLS mechanics are facts, not tooling. pgrls and pgTAP are
out as dependencies - we take pgrls's rule taxonomy as a checklist for probes
we write into the existing isolation-test.sh harness, which already found four
real defects and has no dependency tree. Its SAFE/BREAKING policy-diff idea is
the structural contribution worth reimplementing.
Also records that gap G1 was designed rather than deferred, and the finding
that came out of it: per-consumer physical retention is not implementable on
CNPG, so the erasure horizon is the instance maximum and retention becomes a
placement trigger.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Checked the repo rather than trusting the search snippet. Confirms the
capability claims (MIT, 67 rules, 54 of them security, Z3 isolation proofs,
SAFE/BREAKING policy-diff for CI gating, pytest plugin, PG 15-17) and corrects
the auto-fixable count from 20 to 19.
It is also 26 stars and self-described beta. That does not change the
recommendation to adopt the approach, but it does change the recommendation to
adopt the tool: it is a supply-chain decision, not a free win. pgTAP is
long-established and carries no such caveat. Saying so now is cheaper than
having a reviewer discover it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ADR-008 and ADR-009 were concurrently allocated by two authors on
2026-08-17. adr-008-multi-tenancy-model.md (Four Planes) has earlier
provenance and keeps 008; 009 is left free for that lane. Hub authority
becomes ADR-010, federated namespaces ADR-011. Cross-references in ADR-007
updated.
A live demonstration of ADR-007 decision 1's own subject: sequential
allocation with concurrent writers. ADR numbering is not covered by that
decision, which governs PREFIX-WP-NNNN only — gap to close.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
