Relational Trace and Federated Integrity

Relational Trace

The local register describes current knowledge. Its current graph can change; Relational Trace records the attributable events through which it changed. Corrections, contestations and supersessions append new linked events. An event is a claim made in a context, not automatic evidence of truth.

RelationalTraceEvent {
  id · event_type · subject_refs · actor · mandate · purpose
  timestamp · sequence · previous_event · input_refs · output_refs
  policy_decision · validation_status · originating_node · trace_scope
  event_hash · signature
}

Sequence is local to a node and trace scope. Actor participation may be masked, anonymous or unknown; the node signs its record without requiring public identification of the contributor. Authority is evaluated separately. An existing event log does not automatically satisfy the proposed integrity requirements.

Evidence beyond one node

Originating nodes sign hash-linked events and checkpoints. Authorised witnesses retain commitments and issue explicitly scoped attestations. Comparing independently retained commitments can reveal altered or conflicting committed histories without creating a central repository or requiring agreement on every interpretation.

IntegrityCheckpoint {
  node · trace_scope · sequence_from · sequence_to · merkle_root
  previous_checkpoint · created_at · signing_key · signature
  witness_attestations
}
CrossNodeAttestation {
  witness · checkpoint_hash · claim · created_at · signature
}

Inclusion proves membership in a committed tree. Consistency establishes extension of an earlier commitment. Neither proves that every real action was recorded or that a search result is complete. Detection needs comparisons and available witnesses; witness independence, compromise thresholds, quorum and freshness must be specified by each federation profile.

Retaining a checkpoint, verifying its signature and verifying sequence consistency are different witness claims. A signing key must be trusted through a separate policy. Rotation, revocation, compromise timing, conflicting histories and recovery require explicit procedures.

Detection is not recovery

Checkpoints cannot reconstruct missing events. Authorised retained records or replicas are required to rebuild a view, after verifying them against retained commitments. Missing evidence means incomplete verification. Preserve conflicts and quarantine the affected view rather than silently choosing a history.

Proofs have privacy and retention rules

Stable references, predictable hashes, timestamps and relationships may reveal an actor. Masking a signed record changes its bytes; a disclosed projection needs its own evidence. Append-only does not require perpetual readability: retention and erasure policies must explain which records and verification capabilities remain.

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

Proposed interfaces only; no endpoints are implemented here. Authentication, authorisation, replay handling, algorithm versions and error semantics remain to be specified.

Threat model, schemas and experiment boundaries ↗ · Run the local tampering experiment ↗

Level 0 remains unchanged. Separate experimental schemas are structural contracts, not proof of secure implementation. The local demo checks selected cryptographic properties using two simulated nodes in one runtime; it is not a deployed federation.

Technical reference: RFC 9162, Merkle proofs and split-view limitations; this is not a claim of Certificate Transparency conformance.

Learning histories

A corrected evaluation, superseded skill, withdrawn authorisation or contested source can be represented as linked events. Dependencies identify candidates for reassessment; they do not automatically invalidate every downstream method. A recorded objection does not prove that execution stopped.

Experimental schemas and test evidence

These schemas do not alter the Level 0 Knowledge Object contract. Structural fixtures check the schema keywords used here; cryptographic tests separately check event alteration, omission, reordering, signed conflicting histories, revoked keys, inclusion proofs and checkpoint succession.

• relational-trace-event · JSON Schema ↗
• integrity-checkpoint · JSON Schema ↗
• cross-node-attestation · JSON Schema ↗

Synthetic signed fixture and test public keys ↗ · Full threat model, wire assumptions, privacy and migration notes ↗

The experiment does not prove production witness independence, permission enforcement, recovery without retained records, compact consistency proofs or complete key lifecycle management. Verification states name exactly what was checked.