Raft Made Consensus Understandable. It Did Not Make Consensus Scope-Aware.

1. Protocol and Product Reality

Raft was introduced by Diego Ongaro and John Ousterhout in 2014 with the explicit goal of being more understandable than Paxos while providing equivalent safety. The decomposition into leader election, log replication, and safety — together with a clear specification of how membership changes and snapshots are handled — produced a protocol that practitioners could implement correctly from the paper alone. That accessibility is the reason Raft is now the dominant consensus algorithm in commercial distributed systems. etcd uses Raft to coordinate Kubernetes control-plane state. HashiCorp Consul uses Raft for its catalog and KV store. CockroachDB and TiKV run thousands of Raft groups per cluster to scale horizontally. MongoDB rewrote its replication protocol around Raft semantics. Even cloud control planes — AWS, Azure, GCP internal coordination services — use Raft or Raft-derived protocols.

The protocol's commercial footprint is supported by mature implementations: etcd's library, hashicorp/raft in Go, the C++ Raft used inside CockroachDB, and the formal-methods-verified TLA+ specification that gives implementers a reference oracle. Operational tooling is equally mature: leader-failover dashboards, quorum-loss runbooks, snapshot-and-restore procedures, and learner-replica patterns for safe membership change. Raft's contribution to distributed systems is foundational and earned. The gap discussed here is not about correctness, throughput, or implementation quality.

The shape of Raft is well-understood. A single elected leader serializes client requests into an append-only log. The leader replicates entries to followers and commits an entry once a majority quorum acknowledges receipt. Election timeouts and term numbers prevent split-brain. Safety properties — election safety, leader append-only, log matching, leader completeness, and state-machine safety — compose into a protocol whose correctness can be proved end-to-end. Within the scope of "one replicated log governed by one elected leader," Raft is rigorous and production-defensible.

2. The Architectural Gap

The structural property Raft does not exhibit is scope-awareness over the state space it governs. Raft assumes one consensus group governs one log, and the log is the state. Every mutation, regardless of which region of the state machine it touches, is globally ordered through the same leader and committed under the same quorum rule. Two mutations to entirely unrelated state regions still contend for the leader's sequencing slot, and a critical security-policy mutation and a routine counter increment receive identical consensus treatment. The protocol is governance-uniform by design, and that uniformity is load-bearing in its safety proofs — relaxing it inside a single Raft group would invalidate leader-completeness and state-machine safety.

Multi-Raft, as deployed in CockroachDB and TiKV, partly mitigates this by running many Raft groups in one cluster, each governing a key range. But Multi-Raft is a sharding strategy, not a governance primitive. The boundaries between groups are determined by range splits driven by load and key distribution, not by the governance requirements of the data inside the range. Each individual Raft group remains internally monolithic and governance-uniform; cross-group coordination requires distributed transactions that re-introduce the very contention Multi-Raft was meant to avoid. The protocol has no notion of a scope authority, no notion of differential trust slopes between anchors, no notion of consensus requirements that vary with the criticality of the mutation, and no notion of cross-scope admissibility evaluation.

The gap matters because real systems are not governance-uniform. A control plane mixes catalog mutations (which need durable consensus), service-discovery heartbeats (which need lightweight liveness consensus), and configuration changes (which need authority-credentialed approval). A multi-tenant database mixes tenants whose criticality, regulatory exposure, and trust relationships are heterogeneous. A cyber-physical system mixes safety-critical commands (which need quorum across multiple authorities) with telemetry (which needs only single-witness durability). Forcing all of these through one log under one quorum rule either over-spends consensus on routine traffic or under-spends it on critical traffic. Raft cannot patch this from inside the protocol because the governance shape is wired into the log: one leader, one quorum, one commitment rule.

3. What the AQ Adaptive-Indexing Primitive Provides

The Adaptive Query adaptive-indexing primitive specifies a namespace-structured index in which every scope segment carries its own anchor group, its own consensus rule, its own trust slope, and its own admissibility criteria. Anchors are not a single elected leader but a credentialed group whose composition and weighting are properties of the scope. A scope holding a regulator-credentialed policy has anchors drawn from regulatory authorities and requires trust-weighted quorum across them. A scope holding ephemeral telemetry has lightweight anchors and confirms with single-witness durability. The same physical cluster runs both scopes simultaneously without one scope's consensus contending with another's.

The primitive treats consensus requirements as a function of scope rather than a global constant. A mutation to a scope is admitted by the scope's anchor group under that scope's rule; a mutation that crosses scope boundaries triggers a cross-scope admissibility evaluation in which both participating scopes' anchor groups participate. Trust slopes — the credentialed continuity of authority across the namespace — are first-class structural objects, so an anchor's weight in one scope can differ from its weight in another, and downgrade events propagate along the slope rather than being invisible to the protocol. Adaptive structural mutation — splitting a scope when its consensus load grows, merging when it shrinks, re-anchoring when authority composition changes — is governed by the index itself, not by an external operator running range-split heuristics.

Raft's log replication and leader election can serve as concrete implementations within a scope; the primitive is consensus-algorithm-neutral. What it adds above Raft is the namespace-shaped governance layer: scope authority, differential anchor composition, trust-weighted quorum, cross-scope admissibility, and structural adaptation as protocol behavior rather than operational tooling. The inventive step disclosed under USPTO provisional 64/049,409 is the closed coupling of namespace, anchors, trust, and adaptive structural mutation as a single primitive — not the consensus algorithm running underneath.

4. Composition Pathway

Raft and adaptive indexing compose cleanly because they live at different architectural layers. Raft remains the in-scope consensus engine: leader election, log replication, snapshots, membership change, and the safety proofs that production operators already trust. Adaptive indexing wraps Raft with a namespace-shaped governance substrate that decides which scope a mutation belongs to, which anchor group governs that scope, what consensus rule applies, and whether a cross-scope admissibility evaluation is required before the mutation is handed to the in-scope Raft group.

The integration points are well-defined. A client mutation arrives with a scope identifier (or one is computed from the mutation's key). The adaptive index resolves the scope's anchor group and consensus rule. If the mutation is in-scope, it is forwarded to the scope's Raft group, which runs its standard leader-election and log-replication machinery. If the mutation crosses scopes, the index orchestrates a cross-scope admissibility evaluation across the participating anchor groups, and the mutation is committed under the joint rule. Structural adaptation — splitting a scope, merging two scopes, re-anchoring — is itself a governed mutation that runs through the same admissibility pipeline, so the index's evolution is auditable and credentialed.

For systems already running Multi-Raft (CockroachDB, TiKV, etcd-as-a-fleet), the adaptive index replaces the range-split heuristic with a governance-aware one and adds cross-scope admissibility above it. Existing Raft implementations do not need to be modified; they are called as-is. For greenfield deployments, a single Raft library serves all scopes, with the index supplying the per-scope configuration. The composition is intentionally minimal at the Raft boundary because Raft's value is its proven correctness — the primitive does not relitigate consensus, it adds the governance layer Raft was never designed to carry.

5. Commercial and Licensing Implication

The fitting arrangement for vendors whose products embed Raft is an embedded substrate license: the adaptive-indexing primitive is licensed into the product as the namespace-and-governance layer above the existing Raft implementation, with sub-licensing to the vendor's customers as part of their standard subscription. Pricing aligns to credentialed-anchor count or scope-mutation rate rather than node count, which matches how regulated and multi-tenant customers actually consume governed consensus.

What the vendor gains: a structural answer to the multi-tenancy and regulatory heterogeneity that Multi-Raft only partially addresses, a defensible architectural floor against newer entrants offering "smarter sharding," and a forward-compatible posture against regulatory regimes (EU Data Act, sectoral cyber-physical mandates, sovereign-cloud requirements) that are converging on credentialed-scope governance for distributed state. What the customer gains: differential consensus that matches mutation criticality, cross-scope admissibility that survives tenant boundaries and jurisdictional boundaries, and an audit-grade record of which scope's anchors admitted which mutation under which rule. Honest framing — the primitive does not replace Raft; it gives Raft the namespace-shaped governance layer that single-log consensus has never had and structurally cannot grow on its own.