ADR-011: Internal Federated Ledger (IFL) for Local Agent Governance

Status: Proposed Version: 1.0 Date: 2025-12-21 Supersedes: N/A Related ADRs: ADR-001, ADR-002, ADR-003 Related PRDs: N/A

Context

SEA™ increasingly assumes:

• Distributed agents (CEL agents, smart services, edge devices) that execute semantics (from DSL/SBVR), enforce CALM-governed architectures, and collaborate via CADSL-based plans
• Local or scoped administrative domains such as a single organization’s semantic environment, a smart-home/smart-building deployment, or an internal cluster of SEA™ agents on edge + cloud

In these deployments, the system needs:

1. Tamper-evident provenance for semantic rule changes, CALM model promotions, and cross-agent commands
2. Trust-minimized coordination between agents without public blockchain fees or token economics
3. Low-latency, privacy-preserving operations with millisecond decisions and no sensitive data leaving the domain

Public DAOs and blockchains are overkill and misaligned for this scenario — they assume global adversaries, economic incentives, and fee markets while leaking sensitive data.

Decision

Introduce an Internal Federated Ledger (IFL) as a core infrastructure service in SEA™ deployments.

Core Design

1. Local-only, permissioned ledger

   • All participating nodes explicitly authorized by domain owner
   • Membership & keys managed by local identity/credential system
   • No external validators or miners

2. Lightweight consensus, zero-cost attestation

   • Consensus via Raft (default) / Multi-Paxos / PBFT / PoA-style
   • No transaction fees, no token economics (unlike public blockchains)
   • Resource usage bounded by local hardware

3. Ledger as provenance + coordination substrate

   • SEA™ entities anchored by content hash: SemanticVersion, CALMModel, OntologyVersion, AgentConfig, CADSLPlan, GovernanceDecision
   • Critical cross-agent interactions posted as signed events

4. Owner/admin-controlled authority

   • Domain owner retains ultimate authority: add/remove nodes, rotate keys, configure consensus
   • Ledger provides distributed execution and visibility, not external governance
   • For complete role definitions (Ledger Custodian, Security Officer, etc.) and key management protocols, see SDS-031: Authority & Ownership Boundaries

5. New shared type: LedgerAnchorRef

   • Canonical reference type to embed in SEA™ schemas
   • Links artifacts to their ledger anchors

Architecture

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[User / Org Admin]
    |
    v
[Identity & Membership Manager]
    |
    v
[IFL Cluster] <----> [SEA™ Services (SDS-001..040)]
  |  \
  |   \-- [Edge / Agent Nodes]
  |
  +---> Exposes:
        - /ledger/entries
        - /ledger/anchors
        - /ledger/proofs

Consensus Recommendation

Default: Raft for internal ledger cluster.

Pluggable Architecture

Core pluggable interfaces:

1. Consensus Engine — orders entries, produces log/blocks
2. Storage Backend — writes ordered log to durable storage
3. Crypto Provider — hashing, signing, verification
4. Anchor Bridge — optional outbound anchoring to public chains

Public Chain Bridges (Optional)

For compliance or cross-org verification, optionally bridge IFL entries to public chains:

• Hash-only anchoring (no raw content on-chain)
• Merkle root publishing at configurable intervals
• Support for L2s (Optimism, Arbitrum) for low fees

Rationale

Why not a public DAO / public chain?

• Latency: SEA™ agents need sub-second responses; public chains are orders of magnitude slower
• Privacy: Internal semantic artifacts are often sensitive
• Complexity: Adversarial token governance is unnecessary in single admin domain
• Cost: Gas and token mechanics add operational and legal overhead

Why an internal ledger at all? Why not just a database?

• We need distributed, tamper-evident event sequence shared by multiple agents/services
• Supports stronger provenance, verifiable safety properties, independent validation
• Lightweight consensus + signed entries gives “database” ergonomics with “blockchain” integrity

This aligns with SEA™’s isomorphic architecture — the ledger is a shared structural substrate.

Alternatives Considered

Constraints

• MUST use local-only, permissioned ledger architecture
• MUST use Raft consensus by default
• MUST anchor SEA™ entities by content hash
• MUST support pluggable consensus, storage, crypto, and anchor bridge interfaces
• MUST NOT use public blockchain with token economics for internal governance
• MUST NOT expose sensitive data to external validators

Quality Attributes

• Tamper-evident provenance
• Sub-second latency for agent coordination
• Privacy preservation within domain boundaries
• Auditability and verifiability of cross-agent actions
• Cryptographically backed integrity

Bounded Contexts Impacted

• Semantic Core
• Knowledge Graph
• CALM Governance
• CEL Agents
• Identity & Membership Management

Consequences

Positive

• Strong, cryptographically backed provenance across SEA™ subsystems
• Cross-agent coordination is auditable and verifiable
• Maintains privacy and low latency with blockchain-style integrity
• Clear integration points for advanced governance patterns

Negative

• Additional operational complexity: running internal ledger cluster
• Need to maintain identity, membership, and consensus configurations
• Requires updates to SDS data schemas to support LedgerAnchorRef

Additional Notes

Data Types

LedgerAnchorRef

1
2
3
4
5
6
7
{
  "entryId": "string",
  "clusterId": "string",
  "hash": "string",
  "timestamp": "date-time",
  "proof": { "type": "raft-log-index", "logIndex": 123, "term": 4 }
}

LedgerEntry

1
2
3
4
5
6
7
8
9
10
11
{
  "id": "string",
  "type": "SemanticVersionAnchored | CALMModelApproved | AgentAction",
  "agentId": "string",
  "domainContext": "string",
  "hash": "string",
  "payload": { "additionalProperties": true },
  "signature": "string",
  "timestamp": "date-time",
  "blockIndex": "integer"
}

SDS Integration Hooks

• SDS-002 (Semantic Core): Anchor SemanticVersion changes
• SDS-003 (Knowledge Graph): Anchor ontology/schema changes
• SDS-039 (CALM): Anchor CALM model promotions and compliance runs
• CEL Agents: Log critical actions and cross-agent commands

Related Specifications

• SDS-001 through SDS-040

⏳ Post-MVP (infrastructure layer)

References

• SDS-050: Semantic Identity Provenance