RAILIANCE-WP is a family name, not a repository (ADR-007, and the prefix
registry already lists it retired). Three repositories independently used one
number space for unrelated work — RAILIANCE-WP-0012 was openbao extraction here,
a cnpg backup in railiance-apps and a deploy-verify in railiance-cluster. This
repository also carried two files both numbered 0016.
Active workplans move to the successor prefix and are renumbered from 0001 in
historical order. Archived workplans keep their historical identifiers.
Projection UUIDs are re-derived from the new canonical ids. Records already
registered under the old identifiers leave orphaned hub rows behind; that debt
is recorded in CUST-WP-0068 and clears when ADR-012's reset-from-forge lands.
Refs CUST-WP-0068-T03
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
These workplans exist only in the retired local hub. Their random pre-ADR-007
identifiers are refused by C-06 as stale references, so they cannot be
registered. Deriving from the canonical record id takes no identity from
anything: central does not hold them and the old ids die with the cache.
Records central already holds were deliberately left untouched.
Refs CUST-WP-0068-T06
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
Publish capacity, recovery, labor, and allocation-driver evidence for
resource:railiance:apps-pg so resource-control can forecast and allocate
without reading application data or inventing booked cost.
Populates each canonical dimension with Railiance's actual position, canon's
sub-levels, owners where they exist, and honest status.
Findings from doing it:
- Q1 Security and Compliance is already implemented in S3 to a mature standard
(approval gates, delegated apply, revocation, front-door readiness) and was
never named as a dimension. Evidence the dimensions describe real structure
rather than impose vocabulary.
- Plane is operated in full and declared nowhere. P1 workload, P2 control
(ArgoCD, CNPG, ESO, cert-manager), P3 management (State Hub, master,
workplans). Likely to clarify the rail/rapp relationship, since a rail is
essentially a P1 contract.
- Intelligence is already referenced in practice - qonto-assistant cites an I1
isolation profile - and the whole agent operating model is I4-I5. Leaving it
unmodelled understates what this fleet actually is.
- Q3 Operability and Q7 Governance remain unowned; Q5 unaddressed.
Adds a recommended establishing order for railiance-master to ratify: Quality
first (most unowned concerns), Plane second (cheap, descriptive), Capability
third (blocked on the C1 attribution drift), Intelligence fourth, Logic last or
never if Helix Forge owns functional decomposition.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reads all ten local railiance-* INTENT.md files as a statement of intended
architecture, cross-checked against git history, remotes and the live cluster.
Ten repos declare eight distinct intents. The aspiration is coherent and the
handoffs are stated from both sides. Findings: railiance-bootstrap is a second
local clone of railiance-cluster rather than a repo (which means fleet counts
built by scanning ~ overcount, including the 112 figure in the org refactor);
railiance-hosts and railiance-infra are distinct remotes with unrelated
histories and byte-identical INTENT, both claiming S1; railiance-forge is
unplaced in the OAS stack dimension; S4 is aspiration-only at 25 commits and
zero workplans.
The strongest finding is a shared thread nobody named: five layers
independently aspire to be "self-evidencing" or "auditable", and no repo owns
the verification substrate that would evaluate those claims. That is the same
gap as the enforcement control loop, arrived at from the opposite direction.
Also notes missing homes for observability, end-to-end restore proof, and the
cost-attribution interface.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
