PRD-003: Internal Federated Ledger (IFL) + Identity Token Subsystem
Product Requirements Document
Version: 1.0
Status: Accepted
Owner: SEA™ Architecture Working Group
Date: 2025-12-21
1. Product Summary
The Internal Federated Ledger (IFL) is a permissioned, low-latency, cryptographically verifiable ledger that provides:
- Tamper-evident provenance
- Distributed coordination across agents
- Governance enforcement
- Semantic artifact identity via Identity Tokens
The IFL replaces traditional “database-only provenance” with a distributed, trust-minimized system aligned with SEA™’s architecture and the constraints of local administrative domains.
The Identity Token subsystem introduces semantic identity tokens (also called “Provenance Tokens” or “Attested Identifiers”) that represent intellectual, cognitive, and informational artifacts across the SEA™ ecosystem, all governed by DomainForge/SEA™ DSL semantics.
Terminology Note: This project uses “Identity Token” rather than “NFT” to clarify these are immutability/provenance primitives. There are no execution fees, execution costs, or token economics.
2. Goals & Non-Goals
2.1 Goals
- Local blockchain-like substrate without execution fees, tokens, or public-chain assumptions.
- Tamper-evident provenance for semantic, CALM, cognitive, and artifact events.
- Semantic identity layer (Identity Tokens) as the primary source of truth for:
- Cognitive artifacts
- CALM models
- DSL/Policy objects
- Knowledge graph components
- Generated architecture artifacts
- Agent behaviors/policies
- Deterministic Identity Fallback for Offline/CI environments (e.g. namespace + name hashing) when IFL is unreachable.
- Attestation Policy: CI/Offline uses
ifl:hash (Pre-mint). Promotion triggers ifl:token (Attested).
- Optional public anchoring for timestamped proof of authorship/IP.
- Fully pluggable consensus, storage, and crypto modules.
- Loose integration with SDS-001..010 services.
2.2 Non-Goals
- Not a cryptocurrency.
- Not a public DAO.
- Not a token marketplace.
- Not meant for global, multi-economic adversarial coordination.
- Not a replacement for Git, databases, or KGS storage — only a provenance and coordination layer.
3. Users & Use Cases
3.1 Primary Users
- SEA™ Services (SDS-001..010)
- CEL Agents
- Developers deploying CALM models
- Governance teams (semantic + architectural)
- IP/knowledge-management stakeholders
3.2 Core Use Cases
| Use Case |
Description |
| UC-1: Anchor Semantic Updates |
Semantic Core publishes updated SEA™ DSL Policy versions anchored in the ledger. |
| UC-2: CALM Promotion Lifecycle |
CALM compliance checks and promotions generate Identity Tokens for architecture models. |
| UC-3: Cognitive Artifact Identity |
CADSL plans and agent-learned policies get Identity Token identity and lineage. |
| UC-4: Distributed Agent Coordination |
Agents reference ledger entries for critical actions (e.g., “lock door”). |
| UC-5: IP Protection |
Artifacts can optionally anchor to an L2 chain for timestamped proof of authorship. |
4. Product Features
4.1 IFL Ledger Core
- Append-only log: Cryptographically signed entries.
- Distributed consensus: Raft (default) with high availability (3–5 nodes).
- Pluggable architecture: Swap consensus engines, storage backends.
- Queryable ledger: Semantic filters for efficient retrieval.
- Key management: Key rotation and digital signature enforcement.
4.2 Identity Token Subsystem
Tangible Features:
- Unique semantic identity (
ifl:token) for every anchored artifact.
- Dual-state identity support:
ifl:hash (Pre-mint) ↔ ifl:token (Attested).
- Immutable content hash + mutable semantic metadata.
- Version lineage & transformation history.
- Ownership and permissions enforced by DSL rules.
- Integration with DomainForge™ semantic types.
- Optional bridging to public chains.
Supported Artifact Categories:
- SEA™ DSL Concepts and Policies
- CALM Models & Compliance Reports
- Ontology versions (KGS)
- Cognitive artifacts (plans, policies)
- Information products (diagrams, specs)
- Generated software artifacts
5. Functional Requirements
FR-1: Append Entry
Clients must be able to append ledger entries signed with local keys.
FR-2: Consensus Commit
Entries are ordered, replicated, and committed via the configured Consensus Engine.
FR-3: Create Identity Token
Token creation must include id, type, version, hash, owner, metadata, lineage, and permissions, validated against DSL.
Semantic metadata may be updated while core identity (id, hash) remains constant.
FR-5: Enforce DomainForge™ Rules
All token creation and update workflows must be validated against DomainForge™ SEA™ DSL policies.
FR-6: CALM Integration
CALM promotions must produce Identity Tokens and ledger anchors automatically.
FR-7: Public Chain Anchoring (Optional)
The system must support periodic Merkle-root checkpoint anchoring to public chains.
6. Non-Functional Requirements
| ID |
Requirement |
Metric |
| NFR-1 |
Low Latency |
<50ms consensus commit latency |
| NFR-2 |
Fault Tolerance |
Tolerate 1 node loss in 3-node cluster |
| NFR-3 |
Privacy |
No raw content leaves local environment |
| NFR-4 |
Throughput |
≥ 2000 entries/sec |
| NFR-5 |
Consistency |
Semantic consistency with DomainForge™ types |
| NFR-6 |
Modularity |
Pluggable consensus/storage/crypto |
7. Dependencies
- SDS-050: Identity & Addressing Scheme
- DomainForge™ (SEA™ DSL system)
- SDS-001..010
- CALM Runtime
- Key Management / Identity Service
- Optional Ethereum L2 connectors
8. Acceptance Criteria
- Full API + SDKs implemented (Python + TS).
- Identity Token model validated by SEA™ DSL.
- CALM integration validated end-to-end.
- Successful test of Raft commit under load.
- Successful optional anchoring to L2 with Merkle root.
9. Risks & Mitigations
| Risk |
Mitigation |
| Policy explosion |
Create standard Identity Token templates + schema constraints. |
| Multi-agent coordination race conditions |
Strong ordering + conflict resolution rules. |
| Semantic bloat |
Use short, canonical Identity Token identifiers. |
10. Open Questions
- Should Identity Tokens support cross-domain export/import automatically?
- Should lineage include “proof-of-derivation” signatures from agents?
- Should CALM models have locked Identity Token lifecycle phases?
References
- SDS-031: Authority and Ownership Boundaries