Swarm

A single AIEP node is a publisher with a Mirror endpoint, a normaliser, a divergence detector, and a governed execution substrate. A swarm is a network of such nodes that reason collectively — reaching consensus on which knowledge branches are dominant, preserving dissenting branches without discarding them, and doing all of this without a central coordinator.

The swarm architecture is defined in GB2519803.7 (the hierarchical multi-node substrate) and P90 (the evidence-weighted consensus mechanism).

The coordination problem

Distributed AI reasoning faces a classical problem: how do multiple independent agents reach agreement without either:

• A central coordinator that becomes a single point of failure and control
• Voting-based consensus that is susceptible to Sybil attacks and majority manipulation
• Probabilistic gossip protocols that produce non-reproducible outcomes

AIEP’s swarm architecture solves this through evidence-weighted dominance evaluation. No node has authority over another. No vote is taken. Consensus emerges from the accumulated evidence weight of each reasoning branch — deterministically computed, cryptographically verifiable, reproducible across all nodes receiving the same inputs.

Evidence-weighted consensus (P90)

Each node in the swarm maintains an EvidenceWeightVector — a canonical ordered representation of the accumulated evidence weight for each active reasoning branch visible to that node.

The consensus cycle:

The ConsensusRecord contains: branch identifier, GlobalDominanceState value, contributing LocalDominanceHash values, schema version applied, and timestamp.

If no branch meets the dominance threshold — if the evidence is genuinely split — execution of consensus-dependent operations is suppressed in a fail-closed manner until the state resolves. The swarm does not force a decision when the evidence does not support one.

Hierarchical sharding (GB2519803.7)

At large scale, naive full-mesh dissent comparison approaches O(N²) complexity as the number of nodes grows. The hierarchical swarm architecture solves this through sharding:

Critically: external consensus publication is cryptographically gated by mandatory cross-shard participation. A shard cannot publish a dominant consensus to the wider swarm unless it has collected dissent vectors from the required number of shards. Shard-local dominance — a majority within one shard but not across the swarm — cannot be published as global consensus.

This prevents a minority of nodes from establishing dominance by staying in their own shard.

Cross-session continuity (P95–P98)

A single AI agent session is ephemeral. When the session ends, the agent’s reasoning state could be lost — and with it, the governance context that constrained its behaviour.

AIEP’s cross-session continuity mechanism ensures that governance state persists across session boundaries:

When an agent is restarted, it does not begin with a blank slate. It retrieves its accumulated reasoning fingerprint, its GoalVector history, and its certification status from the evidence ledger. The governance context that was in force at the end of the previous session is the starting state for the new session.

Sub-swarm formation (P97)

A sub-swarm is a bounded, purpose-specific cluster of nodes that forms to address a specific task, operates under its own governance scope, and dissolves when the task is complete — with all state records preserved in the parent swarm’s ledger.

Formation steps:

1. A node issues a sub-swarm formation request, declaring the task scope and required node capabilities
2. Eligible nodes evaluate the request against their GoalVector and certification status
3. A sub-swarm is formed when the required quorum of eligible nodes commit
4. The sub-swarm operates within a declared governance scope — it cannot exceed the constraints of the parent swarm
5. On dissolution, all sub-swarm state is merged into the parent ledger with signed provenance

Sub-swarms enable task-specific specialisation without creating permanent governance structures. They exist for a purpose and dissolve cleanly.

Hardware attestation in the swarm

In high-stakes swarm deployments, consensus records can be bound to hardware governance chips (P89, P99). Each node’s LocalDominanceHash is countersigned by its governance chip before being shared with peers. Nodes receiving a LocalDominanceHash can verify not just the cryptographic validity of the hash but the hardware witness to its generation.

Secure substrate migration (P99) handles the case where a governance chip must be replaced — the migration is a dual-signed handover record appended to the ledger, preserving the continuity of the node’s governance history.

What the swarm is for

The swarm architecture enables AIEP to scale to real-world distributed knowledge publishing:

• Millions of publishers each running a Mirror node
• Evidence-weighted consensus on which knowledge branches are dominant across the entire network
• Dissenting branches preserved at every shard boundary
• No central authority capable of silently suppressing a minority view
• Every consensus transition cryptographically verifiable and replayable

This is the mechanism by which the jigsaw puzzle described in /architecture-of-knowing operates at scale. Each publisher is a piece. The swarm is the process by which pieces are compared, fitted, and — when they do not fit — preserved for later.

Architecture · Constitutional substrate · Goal generation · GENOME SDK · Patents — GB2519803.7, P90–P103