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>
Four search-and-read passes against AWS Well-Architected SaaS Lens, Azure
Architecture Center, OWASP, the OpenID Foundation, and PostgreSQL practitioner
literature. Each digest holds one of our ladders against outside practice and
lists its sources.
Headline: the draft-1 -> draft-2 reframe is corroborated. Microsoft states
"isolation is a spectrum, not a discrete property" and derives our E/P coupling
independently. The shape is sound; the details are not.
Five corrections draft-2 needs:
- E3 overclaims. Any session can re-SET the GUC, so RLS is strong against a
forgotten predicate and useless against SQL injection or a compromised
process. The ADR says "the application cannot trivially route around" - the
exact overclaim it prohibits elsewhere.
- The pooling claim in section 16 is backwards. Transaction-scoped SET LOCAL is
what makes E3 safe under pooling; statement-level pooling is what serves
other tenants' rows, only under production concurrency.
- E3 layers on E2 rather than superseding it.
- Placement cannot be expressed per tenant, but the commercial section requires
exactly that - a tier bought by some tenants puts a service at two P levels
at once, which the posture vector cannot represent.
- FORCE ROW LEVEL SECURITY is mandatory: ADR-0001 already established that our
migration role owns the tables it creates, so it would silently bypass every
policy.
Also: pgTAP and pgrls make the E3 evidence artifact far cheaper than assumed;
OWASP publishes a Multi-Tenant Security Cheat Sheet we reference nowhere; our
tenant-boundary gap is BOLA, OWASP API1, top of that list since it launched;
AuthZEN 1.0 went Final in January and flex-auth is pre-standard; and no plane
covers tenant offboarding, which OWASP makes a MUST.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Resolves a contradiction in accepted canon: ADR-007 decision 1's globally
unique forward-only running numbers require a central allocator, the exact
dependency federation must survive. Amended to namespace-scoped uniqueness
with PREFIX-WP-NNNN@namespace qualification; unqualified still means the
local namespace. C2's UUIDv5 derivation input becomes (namespace,
identifier) — free now, expensive after it ships.
States reconciliation limits rather than implying convergence. T0 fork, T1
sync and T2 reintegration are partly automatable; T3 amalgamation, where a
fork established distinct operational infrastructure, is an M&A-class
governed programme rather than a merge, and may legitimately end in
permanent coexistence or divestment. prj-state-hub-retirement is cited as
measured T3 cost under the most favourable possible conditions.
Coexistence, not merging, is the normal case: client instances per
CUST-WP-0058 are forks that never return. Records fork; effects do not.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Draft-1 proposed one model of multi-tenancy with fixed characteristics.
Rejected: the estate needs a framework that can hold several situations at
once, including repos that do not separate tenants rigorously today and must
be developed toward doing so.
What changed:
- Every plane now carries an ordered ladder (I0-I3, A0-A3, E0-E4, P0-P4),
not just placement. A service is a posture vector, not a verdict.
- D3 reversed. Draft-1 forbade RLS as a control that "looks like a database
guarantee without being one". The observation was right, the conclusion
wrong: RLS is E3, materially stronger than E2, and the actual error was
calling E3 by E4's name. Platform enforcement is now the direction of
travel and an obligation on the platform, not only on consumers.
- New governing rule: conformance is accuracy, not altitude. Declaring E0 is
conformant; concealing it is not. Overclaiming is the only violation.
- Fixed a flaw of draft-1's own making: R0 "shared tables, tenant column" was
an enforcement state mislabelled as placement. Removed; P ladder renumbered.
- Added methodology (analyze/establish/improve/guard) and per-level evidence
artifacts. Guarding checks a service against its own declaration, which is
what makes the verification problem tractable at all.
- D7 softened per operator: tiers carry minimum levels internally, marketing
language stays free, the constraint is on evidence not vocabulary. One hard
line kept: "another tenant cannot reach your data" requires E4.
Ratification now also tests the framework — each reviewing repo publishes its
posture vector, and if a repo cannot express itself in these ladders the
ladders are wrong, not the repo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Central hub on railiance is authoritative as a reading of the repositories;
local instances become rebuildable caches, never peer databases. Local work
requires no hub at all — repo files are self-describing.
Classifies hub data by origin: file-derived (central derives, never accepts
pushes, conflicts are git conflicts) vs hub-native (central owns, needs a
write path and an append-only offline buffer). Neither kind needs a hub-side
conflict model.
Measured divergence: 955 local / 649 primary / 320 local-only, of which 288
are backed by files that all exist on disk. Only 28 orphans need
disposition, and they are the ADR-001 violations.
Corrects ADR-007's 'development read replica' wording — the workstation
instance was the larger of the two by 306 workplans.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The estate has built multi-tenancy across five documents that each cover a
slice and do not compose. This records the whole model and names what is
missing.
Core framing: multi-tenancy here is four orthogonal planes — identity,
authorization, data isolation, placement — not one property. Identity and
authorization are ratified and solid. Data isolation is stated but
unverified. Placement is owned by nobody and is precedent-by-accident.
Three findings that motivated the draft:
- R0 -> R1 -> R2 does not improve tenant isolation at all. Those rungs buy
consumer isolation and capacity. Only R3 makes the tenant boundary
structural. A plan tier selling R2 as isolation would be false.
- No fleet mechanism verifies that any consumer actually enforces the tenant
boundary it is obliged to enforce. A missing WHERE tenant_id would be a
cross-tenant breach that no probe fails and no log shows as an error.
Highest-severity gap; needs an appointed owner.
- platform-pg holds roughly six consumers (100 max_connections, 14 each) and
memory likely binds before connections do. Two are provisioned. The runway
is shorter than the ladder implies.
Also reconciles two already-ratified and contradictory defaults:
instance-per-client for business apps, pooled for platform services, with no
rule for telling a new service which it is.
Proposed, not ratified. Carries a ratification path so it does not join the
shared-platform-relational-storage draft in limbo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Neither repo keeps the shared prefix. railiance-cluster switches active and
future plans (0007 backlog, 0014 ready) to RCLUSTER-WP- preserving running
numbers; railiance-bootstrap takes RBS-WP- starting at 0010, above its
historical maximum, so its finished plans could be adopted later without
collision. Finished files keep RAIL-BS-WP- per the option 2 ruling.
RAILIANCE-WP- should be retired the same way rather than awarded to one
repo; successor prefixes still outstanding.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Verified: all five duplicated identifiers are finished, and no workplan in a
live state shares an identifier. Option 2 therefore requires no renumbering
today; historical duplicates stay, RAILIANCE-WP-0015 ambiguity included.
Separates remediation from conformance: three shared prefixes remain in use
across seven repos as single concurrently-allocated number lines. RAIL-BS-
and RAILIANCE- are still growing, so the 0015/0016 collisions will recur at
the next concurrent allocation. Prefix ownership assignment tracked as
RMGR-WP-0004-T09 under decision 1, which option 2 does not exempt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
custodian-sync@railiance.local is a hardcoded default git identity in
consistency_check.py, not proof of which machine synced. The real evidence
is the timezone split (+0000 and +0200) across sync commits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Decision 2 reframed: the defect is a database-local key stored in a shared
artifact, which also inverts ADR-001. Target is UUIDv5 derived from the
globally unique PREFIX-WP-NNNN, making writeback idempotent across any
number of hub instances. Prerequisite: decision 1 uniqueness must be
enforced first, or derivation from PRJ-WP- style collisions manufactures
duplicate UUIDs.
Interim: one writer only, the automated production instance. Rejected:
collapsing to a shared database, which kills offline capability against
STATE-WP-0068. Both land in repo-manager per 747011c6.
Migration scope: 758 workplan files carry these fields. Remediation of the
3 shared prefixes and 5 duplicated identifiers stays an open ruling.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Evidence, Evidence Source, Adjudication Outcome and the general
evidence-strength dimension get a dedicated InfoTechCanon model, imported by
itc-gov, itc-ident and commerce-canon. Three named consumers predate the
model, which is the required demand signal.
itc-gov stops owning Evidence and becomes an importer; it retains
AssuranceCase, AssuranceConclusion, Audit and the Policy-Control-Evidence
pattern expressed over imported concepts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
R1 Scope -> itc-ident (itc-access keeps narrower ResourceScope).
R2 Assurance Level -> itc-ident, distinct from governance AssuranceCase.
R3 Evidence + Evidence Source are a general pair (container vs extracted
assertion), owned together, not by commerce; itc-gov no longer owns
Evidence.
R4 Relationship Tuple -> itc-access (already modelled there).
R5 Adjudication Outcome follows R3; general, not commerce-owned.
assurance_tier splits: general strength dimension vs commerce's named
Counterparty Assurance Gradient.
R6 Community + Household extend itc-org CollectiveActor; Family rejected as
a collective actor and given its own seeded concept area.
One open question remains: the home for the evidence pair (dedicated
itc-evid model vs itc-gov incumbency). Recommendation: dedicated model.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Globally unique PREFIX-WP-NNNN; one prefix per repo; forward-only running
numbers; prefixes never derived from flavor markers. Exactly one registrar
mints hub IDs into git-tracked files. Automated normalization may not
promote proposed to active. Repo manipulation defaults to a worker agent in
that repo; prj- repos may act across their declared participants.
Fleet scan of 955 workplans found 3 shared prefixes and 5 duplicated
identifiers. Migration of existing collisions deliberately left for a
separate ruling.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Proposes three federated canons (Custodian, InfoTech, Commerce) with
declared concept ownership. Renames identity-canon to commerce-canon in
place; identity content emigrates to a new InfoTechCanon model.
Assigns all ~60 identity-canon glossary concepts to exactly one owner and
lists six unresolved collisions as open questions rather than deciding
them silently.
Status is proposed — canon changes are review-gated.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Publish project-repository-flavor_v0.1 with naming, GOAL.md (not durable
INTENT.md), authority boundary, lifecycle, residuals, and archive rules.
Close ADR-005 deferred naming and CUST-WP-0050 D1a; cross-link from the
repo classification standard.
coulomb-social is registered under domain communication / topic
coulomb-social; CSOC-WP-0001 lives in that repo. Convert the seed doc
from "no owning repo" to a historical pointer.
Maintainer decision, 2026-07-29/30: adopts TRSL V1C1 as this repo's preliminary governing license, per target-revenue's workplans/TREV-WP-0008-governance-and-pilot-rollout.md T05. Full specialist legal review is deferred until out of beta (target-revenue SCOPE.md section 1). No Phase is yet declared for this repo.
This repo previously carried a Proprietary and Confidential license, explicitly confirmed by the maintainer to be superseded here rather than kept as an exception (2026-07-30).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Canon work-record-types: residuals use intake/workplan/decision with
origin residual|handoff and origin_ref parent WP. Schema origin_ref;
agent close protocol aligned.
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Stage 3 delivered end-to-end: intake hub entity (T01), fix-consistency
registration (T02), the promotion transition (T03, the actual point of
this workplan), generated per-repo index (T04), queue closures
retargeted to it (T05), suggestions retired with a real-data migration
(T06). All live-verified against the running API/DB, not just tests --
including catching and fixing a real bug in T03 (silent false-success
on a missing repo_id). 563 tests green throughout.
Carried forward, not blocking: full transclusion rendering (markitect,
T04 follow-on), an engagement hub entity (T02's honest deferral), the
pre-existing sync_schedules bug found 2026-07-20 (TD f29e49eb, out of
scope), and the 10 migrated intake findings needing their actual domain
owners to pick them up.
The reconciliation that started with AWQ-010 is complete.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
One-time close-out of the legacy suggestions table, per the
founder-reviewed decision to retire it (fresh intake entity, not a
rename-bridge). At retirement, 10 records were still open (stage:
suggestion, never promoted/declined) -- real signal from other domains'
agents: 7 ops-warden WARDEN-WP-0012 gated routing scenarios, 2
state-hub STATE-WP-0069/0073 items, 1 binky-control repo-classification
finding. Rather than discard the signal, migrated each into a proper
file-backed intake record (CUST-IN-0001..0010) landing in this repo --
the fleet's natural holding ground for cross-domain findings with no
specific owning repo yet, since none of these ever had a file origin
(hub-first creation is exactly the anti-pattern this whole effort
exists to close).
Each carries origin: "legacy-suggestion:<uuid>" back to the retired
record. All 10 registered live against the real hub via C-32 (state_hub_intake_id
written back). WORK-RECORDS.md regenerated to include them.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
52 workplans, 332 tasks -- the-custodian's cross-cutting work-record
index, generated by the new C-33 fix-consistency check. Verified
idempotent (second run: no C-33 fix, index already current) and
performant at this repo's scale (~1.5min full fix-consistency run,
the new scan is a small fraction of that).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Traced the origin of the-custodian issues #1-5 (opened 2026-07-08, all
reviewed and closed 2026-07-20): this ActivityDefinition's matched rule
always produces a TaskSpec (rules/actions.py::_task_spec_for_rule), and
RunActivityWorkflow unconditionally routes TaskSpecs through emit_tasks
-> the deployment-wide IssueSink (ISSUE_SINK_TYPE=rest -> issue-core ->
Forgejo). It is the fleet's only consumer of the task_template rule
action -- confirmed via grep across activity-definitions/.
Per current policy (Forgejo issue tracking is not the fleet coordination
mechanism), paused rather than left to recreate the same sidetrack daily:
enabled: false, status: paused, re-enable path documented in the file
(needs a new activity-core report-sink authoring a kind: intake work
record instead of an IssueSink task spec). Added as item 6 to
CUST-WP-0060's stage-3 successor seed, including the reminder to grep the
fleet for any other task_template consumer before stage 3 ships.
This is the ADR-001 file-level fix; the live activity-core DB row and
Temporal schedule pick it up on the next Railiance-deployed
'make sync-activity-definitions' run -- not something I have credentials
or standing to trigger directly from this session.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Root-caused the xfail left in place at end of the test-coverage review:
git history (commit e0f9330, CUST-WP-0055 T02/T06/T07, 2026-07-08) shows
the agentic-resources exclude_repo: true -> path_prefixes narrowing was
deliberate, done to bring the repo's real source under the terminology
scan while still excluding the generated session_memory/.store/ tree.
The test was never updated to match and had been silently failing since.
Replaced the stale whole-repo-exclusion assertion with one that checks
the actual current contract: session_memory/.store/ stays excluded,
README.md (and everything else) is now in scope. No xfail marker needed
-- config was correct, only the test was wrong.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Critical review of CUST-WP-0060 (T03-T06) found: shipped mechanism proven
only by manual/live-repo runs, no repeatable test suite; tests/ never
wired to CI at all (pre-existing gap, not introduced here).
- tests/test_validate_work_records.py: 30 tests against the live canon
registry/schemas — classify() incl. all grandfathered legacy id
schemes, per-kind schema gates (intake open/closed/promoted, decision
prepared/resolved, engagement prepared), multi-doc yaml handling,
malformed-yaml-only-errors-if-id-registered, main() end-to-end via
subprocess (exit codes, template placeholders, --strict escalation,
terminal-record historical grace incl. the boundary case that grace
must NOT mask real enum violations), and the jsonschema-unavailable
fallback path (the exact failure mode that broke the first Forgejo
CI run before the runner-substrate fix)
- tools/validate_work_records.py: docstring said 'authoritative detector
is fix-consistency C-25' — wrong, it landed as C-31 (C-25..C-30 were
already taken); comment now correct
- .forgejo/workflows/python-tests.yaml: wires tests/ to CI for the first
time in this repo (apt python3/pytest/jsonschema/yaml on the
node:20-bookworm substrate, same pattern as work-records.yaml)
- tests/test_scan_workstream_terminology.py: found one pre-existing,
unrelated failure while establishing the CI-representative baseline
(agentic-resources allowlist entry no longer sets exclude_repo — a
policy question, not a bug this task should resolve silently); marked
xfail(strict=True) with the finding recorded so CI has a clean signal
and a silent 'fix' doesn't go unnoticed either
Local verification with apt-sourced deps (jsonschema 4.10.3, matching the
CI runner's package source, not just pip): 34 passed, 1 known xfailed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
