Intelligence with no single off-switch.

1. Frozen substrate + additive specialization. The base model is obtained or trained once and frozen. All specialization is adapters (LoRA/DoRA) plus RAG. N topics = 1 base + N tiny adapters, not N full models.
2. Data, not weights, individuates. Personalization and memory live in data stores (RAG), not in model parameters. Live dialogue never writes to weights.
3. Verification at the core. Any output that affects a decision passes a deterministic memory check and/or a behavioral check anchored on objective tasks.
4. There are no neutral weights — provenance by trust tier. A base's origin is chosen for the topic's sensitivity.
5. Open core. True decentralization needs open provenance (ideally data + code + weights), not just open weights.
6. Security through isolation. Shared weights are immutable at runtime → no single participant can poison the shared model; client data is isolated.

Philosophical map

Base = universal impersonal substrate (one for all); memory/RAG = the individuating layer (in the Vedic tradition, Smriti, "that which is remembered"); adapter = specialization. One substrate, many memories — like "one Atman, many selves, distinguished only by conditioning."

Rule: a model with potentially "baked-in" foreign vectors (political censorship, bias) is allowed in T1, because an algorithmic checker verifies the answer rather than trusting the model; in T3 such a model is disqualified — there the output can't be checked by an algorithm, and the bias is embedded in the weights.

"Learning from user dialogues" is really four distinct mechanisms; only the last touches weights.

1. In-context — adaptation within the current dialogue's context window; ephemeral, no weight change.
2. Per-user memory/RAG — durable personalization in a personal namespace (facts, preferences, past decisions). The primary mechanism. This is data, not parameters.
3. Per-user adapter — a tiny per-user LoRA when behavioral customization is needed, not just facts. An additive delta on the frozen base.
4. Offline consolidation — the only real weight learning: a batch of dialogues (with consent) → fine-tune → acceptance → new version.

1. Topic definition — scope, a set of control tasks ("canaries" of classes A/B/C), a known-bias probe (vector-audit), trust tier.
2. Data assembly — real JJ queries on the topic + synthetic coverage + teacher generation.
3. Checker cleaning — keep only teacher outputs that pass the objective class-A check. The dataset cleans itself.
4. Training — QLoRA/DoRA on the frozen base → topic adapter, on whatever tier the topic demands.
5. Acceptance — canary battery + vector-audit; admitted only above thresholds.
6. Registration — signed and written to the registry-ledger; published to the adapter catalog.

Teacher: open licenses only (MIT/Apache permit distillation; closed APIs forbid training a competitor on their outputs). Distillation needs the teacher's outputs, not ownership — you can rent the teacher and own the student.

Key property: across topics this is embarrassingly parallel — no synchronization over the internet, unlike jointly training one model. That is what makes heterogeneous hardware tiers natural.

Shared replicated registries (tiny, because we share catalogs and adapters, not weights and gradients): adapter catalog; canary/anchor registry; base registry.

Heavy path (optional): for a topic that outgrows an adapter, a subset of H200+ nodes runs decentralized training from the shared base via DiLoCo/PRIME (local steps, infrequent sync → communication drops by hundreds of times; demonstrated in practice on 10–32B models across continents).

Plane H — memory integrity (deterministic). Every knowledge fragment is content-hashed; the index is a Merkle tree whose root commits the entire knowledge state. Retrieval verification = fragment IDs + short inclusion proofs, with no re-running of the model. Writes are signed by the contributor's identity; write access is governed by policy.

Plane B — reasoning consensus (probabilistic). Control tasks ("canaries") + a scoring aggregator → a per-topic trust score for the node + a drift map (clustering by output similarity).

Reputation is earned on class A, spent on class C. Attestation slot (swappable): verification accepts {behavioral score | TEE hardware attestation | zk-proof} interchangeably — today inference is covered by TEE and optimistic checking; as zkML matures, the slot swaps to a crypto-proof without redesigning the architecture.

Canary lifecycle (against teaching to the test)

A fixed test set is doomed to Goodhart's law: models learn to pass the tests without getting smarter. So canaries are a living process, not a static benchmark:

• Rotation & expiry: each canary has a lifespan; after a few reveals in scored evaluation it retires (difficulty weight → 0), since it may have leaked into training. The set is a river, not a pond.
• Secret reserve (Goodhart detector): a fraction of canaries is never used for reward-bearing scoring — only for blind audits. Good on public, poor on secret → overfit to the test → penalty.
• Sourcing from reality: the least gameable source is real, novel queries with an outcome verified after the fact (class A: code that passed CI; a calculation that held up in the field). Canaries regenerate from reality, which can't be pre-optimized — it hasn't happened yet.
• Adversarial bounty: nodes are rewarded for canaries the incumbent specialists fail — an open hunt for blind spots that keeps the test ahead of the models.
• Difficulty re-weighting: once models master a canary class, its weight decays — reward shifts to newer/harder ones, and the eval tracks the frontier.

All under commit-reveal with unpredictable sampling. Honestly: Goodhart is never "won," only stayed ahead of — an ongoing cost (red-team incentives, fresh sourcing), not a one-off fix.

Router = the gating of a "MoE-of-specialists": it classifies a query → topic(s) + trust tier, and dispatches to the right specialist. The router is also a policy gate: provenance is enforced per topic (geopolitics never routes to a model with foreign vectors).

Routing policy — shared and replicated across all local routers: a single versioned policy is replicated to nodes so routers don't diverge; updates flow through the signed registry.

Economics: one frozen base is loaded into the inference engine (vLLM/SGLang) once, and LoRA adapters are hot-swapped per request — no need for N model instances. Across nodes, the router dispatches to the node holding the right base+adapter pair with free capacity.

Live verification gate: before an answer is used — memory check (Plane H) + reasoning check (Plane B: class-A checker for objective / trust score for subjective) + human in the loop for T3. The tuple (query, specialists, answer, memory root, verification result) is written to the immutable ledger.

The router as a power center — and how to diffuse it

If the router decides who is asked, who answers, and who is in the consensus, it becomes a new control point — an analog of Google ranking, the Twitter feed, or App Store gatekeeping. To be precise about the risk: the router shifts attention and earnings (who gets work), but on objective topics it cannot shift truth — the answer still passes a class-A checker. So the capture is economic, not epistemic. We diffuse it like this:

• The router is mechanism, not discretion: a deterministic, reproducible function with no hidden knobs; anyone can run the same policy on the same query and get the same routing.
• Auditable after the fact: misrouting (work to cronies) is detected and slashed by the same fraud-proof.
• Requester's choice: a client need not accept the default routing — they can request several specialists, a specified provenance mix, or their own policy variant. The default is a Schelling point, not an App Store monopoly.
• Diversity mandate: for consensus queries the router must assemble a provenance-diverse panel, not "top-k by reputation" (which might share one base).
• Power-bearing knobs = class 3: who may answer/judge, provenance constraints, and the reputation→influence mapping change only via class-3 DIIP (70%+, quorum, time-lock, rationale, public diff). The mechanical parts (topic classification, capacity balancing) are class 1–2.

The network is hardware-heterogeneous: a node participates at the tier it can sustain. Below is a guide; detailed requirements will follow in a separate document.

Capex (guide)

8×H200: ~$370k (HGX), $350–500k (DGX). Rental ~$2.5–3.5/hr per GPU. Cost-smart: rent the teacher for a distillation campaign, own a student node; buy an 8×GPU node for sovereign frontier inference or sustained load.

The object the network validates — an inference output — is expensive to produce, non-deterministic bit-for-bit, and often subjective. So classic blockchain consensus doesn't transfer here; the network is built in layers.

9.1 Identity & Sybil resistance

Three layers: proof-of-capability (entry — prove real inference of a real model on real hardware; cost to fake = cost of GPUs); bonded collateral (a stake, burned on cheating); earned competence weight (vote weight = earned, non-transferable competence). The fix for the Monero/Qubic lesson: influence is proportional not to raw compute (which can be rented and herded into a pool) but to earned reputation — which can't be bought and can't be accumulated quickly.

9.2 Work protocol by class

• A (objective): one node answers, a cheap checker verifies; no consensus needed — the checker is the oracle, anyone can re-run it. Optimistic, with a fraud proof.
• B (reference): match against a signed knowledge snapshot.
• C (subjective): redundant query to k independent nodes → compare by meaning; a judge panel weighted by competence; escalate on low agreement.

Limit of C: consensus on judgment ≠ consensus on truth. Guardrails: competence weighting (judges proven on A), vector-audit, and provenance diversity — a panel of models from different countries doesn't share one blind spot.

9.3 Verifier's dilemma & non-determinism

Random audit: verify a random fraction of outputs; set the audit rate so cheating is economically negative. Challenge game: a disputed computation is re-executed by a neutral auditor; the loser is slashed. Non-determinism: not bit-exact — the checker catches correctness (A), a similarity threshold catches C; the attestation slot removes re-execution entirely.

9.4 Consensus object & ledger

The network does NOT reach consensus on every inference. Consensus runs over a small deterministic state: the registries (adapters, canaries, bases, reputation, slashing). Heavy inference stays off-ledger; only a short verifiable state, disputes, and reputation updates hit the ledger. The "chain" here is the reputation-and-audit ledger, not the inferences themselves.

9.5 Incentives & anti-attack

• Reward = task-routing priority for verified-correct outputs and honest audits.
• Slashing for failing A, losing a challenge, collusion, drift.
• Anti-collusion: influence clipping; a cartel that agrees internally but fails objective class A is caught by the anchor.
• Anti-herding (Qubic): influence = non-transferable competence + bounded stake, not rentable compute.

9.6 Topology & permissions

Start as a permissioned consortium (JJ and partner nodes across jurisdictions: Korea, Ukraine, EU) with a protocol ready to open later. An honest correction to the slogan "so no one can switch it off": the goal is "no single off-switch" (resistance to coercion), not "impossible to switch off"; a consortium keeps a hook to revoke a compromised node.

9.7 Synthesis

Each node = a full federation instance (base + adapters + RAG + router with the shared policy). The network = nodes cross-verifying each other. Query path: router → topic+tier → dispatch → class-based verification → optimistic trust + random audit → disputes/reputation → consensus ledger. Anchored on class A, weighted by earned competence.

9.8 Closing the Monero arc

The network achieves Monero's goal (no single off-switch, distributed across jurisdictions), fixes its flaw (influence can't be economically herded — it's weighted by competence, not compute), and adds what was missing (semantic verification, since the object is a fuzzy output, not a hash).

9.9 Reputation math

Reputation is a per-topic vector (competence is domain-specific). For node i, topic t, time τ.

Decaying evidence mass (volume discounted by age and difficulty)

N_{i,t} = Σ_a  d_a · e^(−λ(τ − t_a))        d_a ∈ (0,1],  half-life T½ = ln2/λ

Decaying weighted pass-rate (quality)

C_{i,t} = ( Σ_a d_a · e^(−λ(τ−t_a)) · o_a ) / N_{i,t}      o_a ∈ [0,1]

Shrunk competence (conservative on little evidence)

Ĉ_{i,t} = ( N_{i,t}·C_{i,t} + κ·C_0 ) / ( N_{i,t} + κ )

Raw reputation

R_{i,t} = Ĉ_{i,t} · N_{i,t}^γ · S_{i,t} · g(stake_i)

• N^γ, γ∈(0,1) — sub-linear in volume: no farming unbounded weight.
• S ∈ [0,1] — slashing factor: 1 normally, drops sharply on cheating/collusion (×0.1), recovers slowly → trust leaves faster than it arrives.
• g(stake) = min(1 + β·ln(1+stake/stake₀), g_max) — concave, capped (×2): skin in the game, not bought dominance.

Vote weight (normalization with share clipping)

w_{i,t} = min(R_{i,t}, θ_t) / Σ_j min(R_{j,t}, θ_t)

θ_t is set so no node exceeds w_max (10–20%) of a topic's vote — a structural anti-51%.

The anchor of the whole construction: weight comes from the objective class A, so a cartel that agrees internally but fails A-checkers loses weight. Reputation can't be bought (non-transferable, bound to the node's key), accumulated quickly (it builds over epochs), or coasted on (it decays).

Against reputation ossification

Decay + sub-linear volume (N^γ) + the w_max clip already prevent an old player from ossifying: "10 years" don't grant 10 years of advantage — only the last few half-lives count. But a newcomer's cold start remains, and we close it explicitly, two ways:

• Guaranteed exploration budget: the protocol reserves a share of routing/audits for challengers regardless of reputation (like ε-greedy in bandit problems) — a newcomer is guaranteed slots to build a track record, otherwise rich-get-richer denies it the chance to prove itself.
• DIIP / class A as a meritocratic bypass: a new but objectively better node need not catch up in reputation — it files a DIIP, and if it beats the incumbent on the blind holdout it is adopted by the gauntlet regardless of reputation. Reputation governs influence in subjective consensus; objective superiority routes around it.

Half-life λ is the main anti-ossification knob: shorter = more responsive to newcomers but noisier; calibrated per topic. Honestly: the exploration/exploitation balance is a real trade-off (too much exploration wastes work on weak nodes, too little entrenches incumbents).

Consensus ≠ truth. 100 models trained on a similar internet, similar datasets, and similar architectures share the same blind spots and can be confidently wrong in the same way. Consensus is meaningful only if the voters are INDEPENDENT; correlated votes = an effective sample of one, dressed up as N. So independence must be measured and enforced, not assumed.

10.1 Provenance is multi-axis

"Different origin" is not just country. Axes of independence: base-model lineage, training-data sources, architecture, operator/jurisdiction, methodology. Each specialist carries a signed provenance manifest along these axes, making diversity auditable rather than declarative.

10.2 Independence-weighted consensus

Correlation is measured, not assumed: we track, across the canary history, how often models agree/disagree. Those who always agree are not independent — their joint vote is down-weighted (counted as nearly one). A consensus's confidence grows with the measured independence of the agreeing voters, not their count. 100 models with a shared error pattern count as far fewer than 100 independent ones.

10.3 Diversity-constrained routing

For consensus queries the router assembles not "top-k by reputation" (which may share one base) but "top-k under a diversity constraint" — maximum provenance independence subject to sufficient competence. This ties to §7 (the router's diversity mandate).

10.4 The honest epistemic ceiling & three external oracles

If ALL available models share a blind spot (the whole field trained on the same flawed internet), no consensus among them finds the truth. Only external, non-model oracles break it:

• The objective anchor (class A): the checker is ground immune to models' shared bias. That's why it's the anchor — maximize the share of what's objectively checkable.
• A human expert in the loop for high-stakes T3 — an independent, non-model source.
• Reality feedback: a consensus answer refuted by the outcome (the deal failed, the calculation didn't hold up in the field) → a retroactive penalty to the consensus and the case harvested into canaries. Reality is the final independent voter.

DIIP (Decentralized Intellect Improvement Proposal) is how a node that has trained a better specialist on a topic proposes a network update. It is at once the self-improvement engine and the highest-value attack surface, so the DIIP path is the most defended part of the system.

10.1 Three classes by blast radius

Principle: threshold, soak length, and regression breadth all scale with the class.

10.2 Verification gauntlet (instead of a fixed "6 months")

Time alone is both too slow for a clear win and too weak — a backdoor can sleep quietly for six months. The primary gate is evidence, not the calendar:

• Champion–challenger in the shadows: the candidate sees live traffic; its answers are scored but not used in decisions.
• Objective head-to-head on a blind holdout (commit-reveal): on class-A tasks the candidate must beat the incumbent with statistical significance. Where applicable, the checker decides, not a vote.
• Statistical significance, not calendar: the gate is volume of evaluations × effect size, not months.
• Regression guardrails, tiered by class: class 1 — the topic + neighboring topics + a safety/vector-audit battery + a "no bleed" sanity check; class 2 — global regression; class 3 — plus independent audits.
• Adversarial gauntlet: jailbreaks, the "trigger → insecure code" test, sleeper/backdoor scanning, poisoning detection.
• Reproducibility & provenance: the recipe (base + dataset hash + config) so auditors can reproduce the weights.

A minimum soak remains — as a defense against slow and rare failures and drift, scaled by class (adapter ~2–4 weeks, base ~3–6 months, constitution longer + audits).

10.3 Attack surface

DIIP is a privileged path to inject weights into the shared network, so it is the most defended link: a bond posted with the proposal (burned on a backdoor or misrepresentation), mandatory provenance, adversarial scanning, and — the safety net — scoped + reversible. Without these, DIIP turns from an improvement mechanism into a poisoning vector.

10.4 Voting: facts apart from values

• Objectively measurable improvement is settled by the gauntlet, not a vote — especially class 1 (scoped + reversible): passes head-to-head + no regression + adversarial → auto-adopt with a warm rollback.
• Voting is reserved for what measurement can't settle: subjective/value-laden topics, risk acceptance, class-3 changes.
• Vote weight = per-domain earned competence (not stake or compute), dominated by competence in the proposal's topic; with influence clipping and a quorum. Conflict of interest: the proposer's vote is reduced/disclosed; auditors who correctly predict the outcome are rewarded.
• Thresholds: class 1 — auto/low via gauntlet; class 2 — ≥51% + quorum; class 3 — ≥70% + quorum + time-lock.

10.5 Reversibility & circuit-breaker

Every adoption is reversible: the incumbent is kept warm, post-activation monitoring runs (canaries + drift), and a post-deploy regression triggers auto-rollback. This lets you be liberal on the reversible (class 1) and strict on the irreversible (class 2–3).

10.6 Lifecycle

Draft → Submission (bond + recipe + provenance) → Automated gauntlet → Shadow soak
  → Auto-adopt (class 1) OR Vote (competence-weighted, quorum, class threshold)
  → Time-lock → Activation (champion warm) → Post-monitoring + circuit-breaker → Finalization

Close analogs: the EIP/BIP process (stages), Tezos on-chain self-amendment, champion-challenger from MLOps. Bittensor/Yuma runs a "continuous implicit DIIP"; DIIP formalizes discrete, governed upgrades on top of it.

1. Now (2 nodes, Xeon + RTX 6000): memory integrity (Plane H), base + RAG + prompting + tools, no fine-tuning. The auditor interface is stubbed.
2. LoRA when needed: a topic adapter only once RAG and prompting fall short and a clean dataset exists.
3. H200 expansion (≥3–4 nodes): behavioral consensus and the §9 network activate (consensus needs peers to disagree with), cross-node routing, distillation campaigns, reputation accrual begins.
4. 8×H200 / 8×MI300X: sovereign frontier inference and the teacher role, heavy topics; open the consortium once the protocol matures.

Decided: frozen substrate + additive adapters; personalization in RAG, not weights; verification by two planes with an objective anchor; provenance by trust tier; shared replicated routing policy; multi-LoRA serving on one base; rent the teacher, own the student; the network starts as a permissioned consortium; reputation = decaying class-A competence with influence clipping; upgrades flow through DIIP — three classes by blast radius, the primary gate is the gauntlet (head-to-head + tiered regression + adversarial + provenance + bond), voting only for subjective/constitutional changes (51/70 + quorum), all reversible with a circuit-breaker. The router is a deterministic mechanism with requester choice, and its power-bearing knobs are class 3; against ossification — an exploration budget for newcomers and a bypass via DIIP/class A; canaries are a living process (rotation, secret reserve, sourcing from reality, adversarial bounty); consensus is independence-weighted with provenance manifests and three external oracles (class A, human, reality).

Open: base choice for the first 2–3 topics; T3 provenance policy; challenge-game design for cheap arbitration; calibration of reputation knobs (λ, w_max, slashing thresholds) on real data; the moment to switch the attestation slot to zkML; whether an internal-credit tokenomics is even needed in a consortium; calibration of DIIP thresholds, soak length, and bonds on real data; detailed hardware requirements (separate document).