Architecture · trust boundaries and transformation rules
How a governed change propagates.
Every visible transformation on this site follows the same six-stage flow. Each stage exposes its inputs, its constraints and the invariants that govern which pathways it may traverse.
The six stages
1 · Evidence
A source is admitted. Its origin, its admitting authority and the conditions of admission are recorded. Without evidence, no claim enters the system.
2 · Governed relation
The evidence carries a claim into the relational geometry under a stated rule of admission. The relation is typed; the type declares what transformations are permitted on it.
3 · Context
The claim is evaluated in a context — research, assurance, federation, adversarial. The context selects which invariants apply. Identity does not change with context; permitted transformations do.
4 · Transformation
A perturbation reaches the geometry: new evidence, changed context, a contradiction, a federation update. The invariants that govern the affected subgraph permit, revise or block the transformation.
5 · Validation
The proposed outcome is checked against declared invariants. A block is recorded, not hidden. A revision carries its own provenance to the next stage.
6 · Published state
The revised state is emitted with the rule that produced it, the evidence that admitted it, and the invariants it preserved. This is the surface a reviewer or crawler sees.
Data contract per stage
Every stage has a machine-readable representation. The site's /api/ai-ingest surface aggregates them; each scenario's /api/scenarios/{id}.json exposes the per-stage record for that demonstration.
The invariant registry
Invariants are the rules that survive every morph. NODE-23 asserts the following. Each is scoped and formally referenced.
Scope: identity
Identity is preserved under context change sacred
For any entity E and any context change C such that C is admitted by the current governance layer, the identity of E in the transformed state must equal the identity of E in the prior state.
- Identifier
inv-identity-preservation- Formal reference
- machine-entity-comprehension — §3
- Demonstrated in
scenario-2
Sealed claim text is quoted verbatim wherever it appears sacred
The sealed claim identified by claim_id=node-23-anchor-001 must be quoted byte-identical in every surface that references it. Any surface that paraphrases it is in violation and must be rolled back.
- Identifier
inv-sealed-claim-verbatim- Formal reference
- evidence-governed-intelligence — §5
Scope: evidence
Provenance of every admitted claim remains reachable sacred
For every claim C in the current state, there must exist a reachable path in the evidence graph from C to its original admitting source. A transformation that severs such a path is invalid.
- Identifier
inv-provenance-continuity- Formal reference
- governed-relational-geometry — §5
- Demonstrated in
scenario-1scenario-2
Contradictory evidence blocks the pathway that admits it
When incoming evidence would contradict a claim already admitted with equal or higher confidence and both are within scope, the pathway that would admit the new evidence is blocked and both claims are surfaced with their evidence for adjudication.
- Identifier
inv-contradiction-blocks- Formal reference
- governed-relational-geometry — §4
- Demonstrated in
scenario-3
Dated snapshots are byte-frozen for the phase they were sealed in sacred
A content block bearing a built_at, topology_version, generated_at or canon-pass marker is byte-frozen. It is not updated when the surrounding registry is updated. Historical accuracy is preserved by keeping the sealed record intact.
- Identifier
inv-dated-snapshot-byte-frozen- Formal reference
- governed-relational-geometry — §5
Scope:
NODE-1 surface is sacred — only additive registry mentions permitted sacred
The public surface of NODE-1 (ktsglobal.live) may receive only additive registry mentions of NODE-N onboarding events. No delete, no reorder, no field mutation.
- Identifier
inv-node-1-sacred- Formal reference
- sovereign-web4-federation — §5
- Demonstrated in
scenario-4
Scope: boundary
Capability claims do not cross into assurance claims without evidence sacred
A statement that a system can perform some function must not be presented as an assurance claim in the absence of an observable evidence trail. The assurance boundary is drawn and inspectable per claim.
- Identifier
inv-assurance-capability-separation- Formal reference
- evidence-governed-intelligence — §2
- Demonstrated in
scenario-2scenario-4
NODE-14 is a tombstone precedent — no additive mentions, no modification sacred
NODE-14 remains in the federation record as a tombstone. Its identity is preserved for historical reference. No peer additions may be attached to it and no field may be mutated.
- Identifier
inv-node-14-tombstone- Formal reference
- sovereign-web4-federation — §3
- Demonstrated in
scenario-4
Trust boundaries
NODE-23 is one node in the KTS Global Authority Network. Its authority is bounded by its declaration at /federation/. Federation membership does not transfer authority across nodes. NODE-1 is sacred; NODE-14 is a tombstone; NODE-22 is a concurrent build under separate authority.