tenant-engine assessed itself against the ladders and came back with
corrections. All five are adopted, because the ratification test says that if a
repo cannot express itself the ladders are wrong - and it could not, in three
places.
I2 conflated authority with verification. Its text named tenant-engine as the
source of existence, which made the level describing canonical identity
unclaimable by the service that provides it. An axis is assessed on a service's
own inbound surface, never on its authority over the concept. tenant-engine is
the source of tenant records and is at I1, because the acting identity arrives
in the request body rather than in a verified token.
A level now reports the weakest surface. tenant-engine has PDP-authorized
mutations and three unauthorized read routes - including the one flex-auth
calls for aal2-class decisions - and reported A2 rather than A3. Publishing the
stronger surface would be accurate about that surface and misleading about the
service. A per-surface vector was considered and rejected as premature.
The E ladder assumed all data is tenant-keyed. A registry whose rows ARE the
tenants has no predicate to scope a policy by, and enforcing one would break
the service rather than secure it. Mixed-shape services now declare an E level
plus a named registry exception; an unnamed exception is an overclaim. Without
this they overclaim or sit at E2 forever, which is what tenant-engine was
facing.
Retention and erasure are two dimensions and one level cannot carry both.
tenant-engine is R1 on backup and R0 on erasure - its lifecycle contract
deliberately defines no hard-delete, so a tenant record cannot be deleted ever,
by design, while carrying display_name and contact_email. Declared R1/R0 now.
And the compounding - personal data, no erasure path, a backup window set by
the longest-retaining co-resident - is the substrate owner's to surface,
because each part looks locally reasonable alone.
My own error, corrected: I listed tenant-engine as a live P1 occupant in both
the ladder and the E/P matrix. They are on SQLite. P1 is TEN-WP-0009's target
and the provisioning is my own unapplied intake. Asserting a placement that a
workplan exists to create is exactly the kind of claim this document forbids.
Worth recording: they found an unfiltered cross-tenant read in their own event
accessor while assessing against the ladder, before publishing anything.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
An earlier revision of this section asserted the adversarial facility was
deliberately not NetKingdom's, on independence grounds. Overruled, and the
counter-argument is better: offensive security is security work.
The facility is also framed more broadly than this document assumed - it is
pointed at infrastructure we choose, our own estate among them, and testing
conformance to this framework is one use of a general capability rather than
its purpose.
The tension I raised is left in the text rather than deleted, because it is
real: NetKingdom now owns both this framework and the facility that tests
conformance to it. The mitigation is that findings leave for risk-nexus under
separate ownership instead of being closed in place, and the trigger to
revisit is conformance findings starting to close quietly.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Question 12 asked whether to add a quality-of-service dimension. No - because
we could not enforce it. Community PostgreSQL has no resource governor, so a
declared priority would be an unenforced claim in a declaration, which is what
retiring tenantIsolation was about. An axis implies graduation and enforcement
and this has neither.
Co-residents are equal, and a consumer whose latency cannot survive an
unprioritised neighbour escalates to P2. Service class is still declared, as a
category not a level: it informs placement, acts as a trigger, and gives
"acceptable degradation" in the noisy-neighbour artifact something to be
acceptable relative to - what batch tolerates is an outage for latency-critical.
Class mixture must be visible, because an unenforceable risk nobody can see is
worse than one that is stated. rapp-postgres now reports it and the live
instance already flags latency-critical beside batch.
Gateway-level prioritisation in a connection proxy is recorded as the known
escalation short of P2 - real, and infrastructure we do not run.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
whitehat-security takes the adversarial evidence artifacts - the framework's
highest-severity gap, unowned since it was drafted. audit-core and tenant-engine
were right to decline it as fleet-scope work; the answer was a home of its own
rather than a volunteer.
Recorded here with the part that bears on this document: the facility is
deliberately not owned by NetKingdom, which owns this framework. Verifying
conformance to a standard while reporting to the standard's owner is
self-grading one level up.
Two consequences land back on the framework. Cadence becomes a security
parameter rather than a schedule, since for a detection-based control the
interval between runs is the exposure window. And a passing suite is proof that
the attacks attempted did not work, not proof of isolation - recording a green
run as "E2 verified" would be exactly the overclaim section 6 prohibits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Settles two questions raised by bringing NetKingdom under Railiance
governance:
1. Separate rapp-* repos per engine (rapp-tenant-engine, rapp-user-engine),
following repository-axes.md's one-workload rule. The decisive property is
independent rollback -- a single rapp would need one rollback contract
across independently versioned services. secrets-engine is not packaged as
a rapp: it has no deployed workload.
2. CloudNative PG via rapp-postgres is the default relational platform for
production. Per-workload SQLite-on-a-PVC is dev/test only, and
rail-kubernetes wave-1 does not support the persistent-storage contract it
depends on. tenant-engine migrates; its TenantStore Protocol makes this a
backend swap behind an existing seam.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Register coulomb-social with mfaRequired: false, roll key-cape image that
honors client policy, and track NK-WP-0025 public registration orchestration.
