# Relational Trace and Federated Integrity Decision record: 20 September 2026. Based on Daniel Kvist’s Site and Documentation Update memo and the subsequent review. Status: proposed architecture extension, experimental schemas and local demonstrator. Not a production federation implementation or certification. ## Four separate functions - Local relational metadata register: the node’s governed descriptions and current states. Local authority is scoped; it does not establish universal truth. - Relational Trace: attributable, ordered events. Corrections, contestations, withdrawals and supersessions append linked events rather than silently rewriting recorded claims. - Federated index: permitted discovery metadata and references. It is neither the source of truth nor the sole keeper of integrity evidence. - Federated Integrity: authorised retention and comparison of signed checkpoints and precisely scoped attestations across independently governed nodes. The current graph is mutable. Its history is a separate, policy-controlled trace. Existing event logs do not automatically meet this trace profile. Content can remain in its source systems. ## Semantic rules !CURRENT_STATE_IS_NOT_HISTORY: change the current view through attributable events; do not silently replace previously committed history. !INDEX_IS_NOT_AUTHORITY: discovery results do not establish truth, permission, completeness or authoritative custody. !PROOF_IS_NOT_PAYLOAD: integrity evidence can be exchanged without exchanging underlying content, subject to its own disclosure policy. !SIGNATURE_IS_NOT_TRUTH: verification binds bytes to a signing key. Identity, mandate, legitimacy and factual correctness require separate evidence. ## Threat model and boundaries Consider malicious agents, altered indexes, compromised node storage, stolen signing keys, stale clients, unavailable witnesses and colluding witnesses. Attackers may omit, reorder or alter committed events, serve different histories, replay old checkpoints or suppress relationships. A retained checkpoint can reveal changes to committed history. It cannot establish that all real actions were recorded. An unrecorded action requires independent observations, submission receipts or another defined completeness mechanism. A valid index result cannot prove that no permitted result was suppressed: that needs a specified authenticated index/query contract. A projection must state scope and known coverage; omission outside that scope is not proof of attack. Unavailable evidence means incomplete verification, not automatically malicious behaviour. Invalid signatures, historical conflicts, revocation and missing evidence must have distinct outcomes. A conflict is evidence to investigate, not an automatic ruling on which history is correct. ## Event contract RelationalTraceEvent includes identity, event type, subjects, actor participation, mandate, purpose, timestamp, per-scope sequence, previous event, input/output references, policy-decision reference, validation state, originating node, event hash and a node signature. Corrections and supersessions identify the earlier event in input_refs. A node records an actor claim; its signature is not the actor’s signature or proof of the actor’s authority. Sequence is local to (node, trace scope), not a global clock. Genesis uses sequence 1 and a null predecessor. Timestamp is a claim, not trusted time. Hashes exclude event_hash and signature. Checkpoints bind node, scope, sequence interval, tree root, predecessor checkpoint, creation time and signing-key identifier. The detached signature and witness attestations are excluded from checkpoint identity hashing; key ID is included. An attestation binds a witness, checkpoint hash, exact claim and time. The experimental implementation uses a restricted canonical JSON form (recursively sorted keys, strings, arrays, booleans, null and safe integers), UTF-8, SHA-256, P-256 ECDSA/SHA-256, hex digests and base64 signatures. Domain-separated leaf and internal Merkle hashes use 0x00 and 0x01. These choices are experimental, not a frozen wire standard; interoperable serialization, algorithm agility and transport remain to be specified. ## Witnesses and proofs Distinguish checkpoint retention, signature verification and sequence-consistency verification. A witness never attests factual truth merely by retaining a checkpoint. Production federation profiles must state witness eligibility, independent administrative domains, minimum witnesses, tolerated compromises, comparison frequency, freshness limits and disagreement handling. The demo has one simulated witness and no Byzantine fault tolerance. An inclusion proof proves membership in a committed tree. A consistency proof establishes extension of an earlier commitment; neither proves source truth or complete recording of actions. The demo verifies inclusion and compares all supplied earlier event hashes with the prefix of a later sequence. It does not implement compact Merkle consistency proofs or a network witness protocol. ## Keys, compromise and recovery Key IDs must resolve through an authenticated trust policy. A rotation should link old and new keys with an authorised record and a new checkpoint; do not trust a key merely because it accompanies an event. Revocation needs an independently available record, effective time and scope. A stolen key can produce valid signatures, so historical acceptance requires compromise timing and externally retained evidence. The demo checks an explicit revoked-key set; it does not implement rotation or compromise-time adjudication. A mismatch quarantines the demo index view, not the source organisation. Checkpoints detect differences but cannot reconstruct missing records. Recovery requires authorised retained event records or replicas, which must be checked against the commitment before rebuilding a view. If they are unavailable, report incomplete recovery. Preserve conflicting evidence and document the authorised recovery decision; do not choose a majority history without a specified policy. ## Privacy and retention Participation, authority and identity disclosure remain separate decisions. Identified, masked, anonymous and unknown actors are distinct. Context-scoped references are optional for anonymous or unknown participation; never require a real-person identifier to record an event. An operation needing verified authority still requires appropriate evidence. Node signatures authenticate the recording node, not every human contributor. Actor mappings, graph topology, hashes of predictable data, timestamps and witness relationships can expose identity. Evaluate disclosure of proofs as well as payloads. A context-scoped or selective-disclosure proof design is still required before sensitive deployments. Do not redact signed event bytes and claim the original signature validates the altered view; define a separate projection and its evidence. Append-only is a history-integrity rule, not indefinite retention. Define retention, encryption, access restrictions and authorised deletion/erasure records. Losing decryption keys may make payloads unreadable but does not erase already-disclosed copies or all identifying metadata. State which verification remains possible after retention actions. ## Provisional interfaces (not implemented endpoints) POST /v1/federation/checkpoints GET /v1/federation/checkpoints/{node}/{sequence} POST /v1/federation/attestations POST /v1/federation/verify GET /v1/federation/consistency-proof POST /v1/federation/integrity-notices Requests need authenticated node identity, scope, purpose, authorisation, profile/algorithm version, replay protection, idempotency, size limits and explicit error semantics. Neither a universal consensus nor a storage product is prescribed. Exact transport envelopes are unresolved. ## Schemas and conformance Separate experimental schemas cover RelationalTraceEvent, IntegrityCheckpoint and CrossNodeAttestation. Existing Level 0 schemas are unchanged. Schema shape alone cannot verify hashes, signatures, sequence continuity, witness independence or authority. The demo tests cryptographic operations separately from structural fixtures. Conformance targets: trace sequencing and linked corrections; node signatures and key lifecycle; independent witness conflict detection; authorised quarantine and recovery. Passing the local demonstrator is not conformance to a completed FederatedIntegrityProfile. ## Source and migration Source memo: Intertween_Site_and_Documentation_Update_Memo.docx, 20 September 2026 (project source supplied by Daniel Kvist). Cryptographic reference: https://www.rfc-editor.org/rfc/rfc9162.html — Merkle inclusion/consistency mechanisms and split-view limitations. This is an informative reference, not a claim of implementing Certificate Transparency. | Historical term | Current direction | Migration boundary | | --- | --- | --- | | INTW Event Ledger | Relational Trace for the proposed attributable history profile | Retain old anchors and source wording in dated records; do not relabel old logs as cryptographically verified. | | Event log | Generic history function; Relational Trace adds explicit integrity requirements | Existing event logs may remain informative implementations. | | Global register | Local register plus federated index / shared logical register | No central master or universal truth is implied. | Update status: integrated specification/wiki/standards and architecture explanations updated; provisional schemas and local simulated two-node demo added. Network federation, independent production witnesses, compact consistency proofs, full key lifecycle, authenticated index completeness and retention enforcement remain unimplemented. Historical source documents remain unchanged. Earlier broad claims of a reconstructable or immutable history are qualified by the requirements above.