RFC KCP-003: Lineage Conflict Resolution via Merkle DAG + CRDTs

[tgosoul2019]

Context

Suggested by Claude 3.7 Sonnet and partially by Grok during LLM evaluations. This is the most critical missing piece for federated multi-agent scenarios.

Problem

In federated mode, two agents at different nodes can independently derive from the same parent_id. When these nodes sync, there's no protocol-defined way to:

1. Detect the conflict
2. Represent both branches faithfully
3. Resolve or merge without losing lineage information

Proposed RFC Outline

New concept: artifact.lineage.fork_id

When a conflict is detected during sync:

{
  "artifact_id": "uuid-B",
  "lineage": {
    "parent_id": "uuid-A",
    "fork_id": "uuid-A",
    "fork_seq": 1
  }
}

Merkle DAG for auditable proofs

Each artifact's content_hash chain forms a Merkle DAG. Any node can verify a lineage proof without trusting the origin server:

verify_lineage(leaf_id, root_id) → MerkleProof

CRDT-based sync

Artifact sets are modeled as a Grow-Only Set (G-Set) CRDT — artifacts are immutable once published, conflicts are forks (not mutations), and merge is always union.

# Sync two nodes
proof = node_a.sync(node_b)
proof.conflicts  # list of fork pairs
proof.merged     # total artifact count after merge

Acceptance Criteria

• RFC KCP-003 document in rfcs/kcp-003-lineage-conflict.md
• Fork detection algorithm defined
• Merkle proof structure specified
• CRDT merge semantics defined
• Python SDK reference implementation
• Tests: conflict detection + merge

Related

• RFC KCP-001 §5 (Federation)
• RFC KCP-002 (MCP Bridge — context for multi-agent scenarios)
• Suggested by: Claude 3.7, Grok 2