Archived / superseded document. Current source of truth: docs/strategy/ICN-Roadmap-Live.md

ICN Roadmap

Last Updated: 2026-01-31 Current Focus: Phase 3 State Generalization + Kernel Crate Cleanup Target: Clean kernel with pluggable first-party and third-party apps

Strategic Context

ICN is infrastructure for a parallel political economy — enabling cooperatives, communities, and federations to deliver better material outcomes than traditional capitalist and captured democratic systems.

Core Vision: ICN is not just infrastructure for cooperatives — it is cooperative infrastructure that governs itself democratically. The protocols are adjustable by the organizations using them.

Architecture Reset (2026-01-26)

The previous roadmap (Phases 19-35) has been superseded by the Kernel/App Separation initiative. This architectural reset:

1. Separates kernel from apps - Kernel provides 8 generic primitives; apps implement domain logic
2. Establishes the "Meaning Firewall" - Kernel never understands domain semantics
3. Enables third-party apps - Same APIs as first-party apps
4. Simplifies the codebase - From 27 tightly-coupled crates to ~12 kernel crates + apps

See: KERNEL_APP_SEPARATION.md for full architectural documentation.

Current Status

Completed Phases (1-18)

See PHASE_HISTORY.md for details.

Kernel/App Separation (Current)

Tracking Issue: #856 Branch: architecture/kernel-extraction PR: #855

Additional: #863 - Federation Agreement Support

Completed Epics (Jan 26–30)

Kernel Crate Cleanup

Prerequisites for Phase 6 (Crate Consolidation):

• #912: Remove icn-trust from icn-core ✅ PR #972
• #913: Remove icn-governance from icn-core
• #914: Remove icn-ledger from icn-core
• #915: Remove icn-trust dev-dep from icn-net ✅ PR #973
• #916: Enable strict Meaning Firewall CI ✅ PR #974
• #911: Remove raw_handles transition mechanism ✅
• #918: Move supervisor init_*.rs to app crates

The Meaning Firewall

The core architectural principle driving this work:

CCL Document (constitution / bylaws / treaty)
         ↓
App Interpreter (Governance / Membership / Ledger / Federation)
         ↓
PolicyDecision { constraints }
         ↓
Kernel enforces constraints mechanically

Example: The kernel never sees "constitutional amendment" or "supermajority" — only:

• min_votes = 67
• quorum_required = 50
• deadline = 1706000000

This ensures:

1. Apps can implement any governance model
2. Kernel remains simple and auditable
3. Third-party apps have equal capabilities

Target Architecture

Kernel Crates (~12)

icn-kernel-api/   # Trait definitions (PolicyOracle, primitives)
icn-identity/     # DID + keystore
icn-store/        # Generic storage (KV, Log, Blob)
icn-protocol/     # Gossip + networking
icn-core/         # Runtime + supervisor + app management
icn-services/     # API surfaces (RPC, Gateway)
icn-security/     # Security primitives
icn-crypto/       # Cryptography
icn-obs/          # Observability
icn-encoding/     # Serialization
icn-time/         # Time primitives
icn-testkit/      # Test utilities

First-Party Apps

apps/
  trust/          # Trust graph, attestations, PolicyOracle
  ledger/         # Mutual credit, escrow, budgets
  governance/     # Proposals, voting, CCL-driven rules
  membership/     # Entity management, membership classes
  echo/           # Test app (implemented)

8 Kernel Primitives

CCL: Constitutional Layer

CCL (Cooperative Contract Language) is the declarative layer for expressing:

• Entity constitutions and bylaws
• Governance rules and voting procedures
• Economic policies (surplus allocation, credit limits)
• Federation agreements

Schema v0 complete (PR #855):

• entity.rs - Cooperatives, communities, federations, membership
• governance.rs - Bodies, decisions, delegation
• economics.rs - Capital, surplus, credit
• agreement.rs - Federation agreements, boundary protocols

Key Insight: Federation agreements use binary boundary outcomes:

boundary_outcome:
  type: binary  # approved | rejected

Federation A uses consensus. Federation B uses majority vote. The agreement doesn't care — it only asks "Did each party approve?"

Internal process is sovereign. Boundary outcomes are interoperable.

Timeline Estimate

Total remaining: ~16-20 days of focused work (Phase 2 complete)

Post-Separation Work

After kernel/app separation is complete:

1. Pilot Deployment - Deploy with first cooperative partner
2. SDK Development - TypeScript/React Native SDKs for app developers
3. Third-Party App Ecosystem - Documentation and tooling for external developers
4. Federation Testing - Multi-federation scenarios with diverse governance models

Related Documents

• KERNEL_APP_SEPARATION.md - Full architectural documentation
• PHASE_HISTORY.md - Completed phases 1-18
• ARCHITECTURE.md - System architecture overview