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.
Adopt the repo as the primary workplan anchor: repo_id becomes required,
market-domain is derived from each repo's classification, and the
domain/topic spine is demoted/retired (RepoGoal becomes the goal primitive).
Add task T10 for the re-anchor plus the workstream -> workplan rename across
schema/API/MCP.
Add ADR-005 (Cross-Repo Workplans Live in Dedicated Project Repos): complex
cross-repo efforts get their own project repo (category: project) as the
anchor, retired to archive on completion with results living on in the
modified product repos. Rewrite D1 as resolved and add D1a for the
project-repo naming/archival convention.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Formalises the caching pattern introduced in doi_cache: pre-compute and store
repo-sourced derived data, invalidate by fingerprint (composite of DB timestamps
+ file mtimes), force-refresh on demand.
Names the pattern against the literature (Materialized View, Derived Data Store,
CQRS Read Model, ETag-style invalidation) and mandates its use for all future
repo-sourced derived data with an implementation checklist.
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
- scripts/cleanup_stale_tasks.py: daily script that cancels open tasks
in completed/archived workstreams; handles 307 redirects; emits a
cleanup progress event summarising results
- Makefile: add cleanup-stale target (also suitable for cron)
- ADR-001: append Workstream Closure Protocol section — mandatory closure
review before marking workstream completed, with task classification
table (done/cancelled/carry-forward) and Closure Review file format
- WP-0002 + WP-0005: append Closure Review sections documenting the
2026-03-02 cleanup run (26 stale DB rows cancelled — all were legacy
pre-ADR-001 DB-first records; file status was already done)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
State-hub is a read/cache layer. Workplans and work items must
originate as Markdown files in their native repository so the hub
can rebuild its full representation from registered repos alone
(the rebuild principle).
Establishes:
- canon/architecture/ directory for ADRs
- Workplan file convention (frontmatter schema, task embedding)
- Rebuild sequence (migrate → seed-domains → sync-workplans)
- Marks DB-first v0.3/v0.5 records as legacy pending sync tooling
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
