HiNet — Living Whitepaper
Version 0.7.0 · Living document (changelog at the end) · Status: E1 composition PASSED; bf16 full-FT injects personal data; composition inherits the fact/skill hybrid — facts compose by retrieval-union, skills by weight-merge+distill. Now with the economic model & ownership (§6A).
HiNet ("Human Intelligence Network") is a network where every human owns an iCore — a complete, standalone, continually-personalized LLM — and where any consenting assembly of iCores composes into a single, larger LLM, recursively from pair → team → domain → network. This document is the canonical narrative; the deep-dive specs are listed in §11 and are the source of truth for implementation detail.
This whitepaper consolidates and supersedes the planning narrative previously split across the foundational-model plan, packaging addendum, and experiment design. It builds on the founding conceptual paper, HiNet-Fractal-Intelligence-Whitepaper.md (the quorum-sensing / fractal-intelligence motivation), which remains the origin document.
1. North Star
Every human owns an iCore that is, by itself, a useful LLM — booted from a shared open-weight base ("shared DNA") and hyper-tuned to its owner for life — and any consenting assembly of iCores composes into a single, more capable LLM, at every scale a usable model. This must hold for both decentralized training and decentralized inference.
The success predicate (two parts, held simultaneously and honestly):
(A) the part is a whole — an iCore generates coherent tokens standalone, owned, offline; and (B) the whole is bigger — assembling iCores yields a single model with more capability (and, in the weight-composed modes, more parameters), not merely an output vote — and composition is decomposable, so an owner can leave and the assembly re-forms without them.
Beyond Petals: Petals slices one monolith into layer-blocks served across volunteers — a block is not a usable LLM, and the owner holds a slice. HiNet's atomic owned unit is a whole mind, and composition yields a bigger whole. The owned unit coincides with a model, not a layer range.
2. The Ownership & Learning Model — one brain, one filter, a coupled twin
(Canonical; full version in Foundational-Model-Plan §2A.)
- One brain. The owner has a single mind — frozen anchor + personal adaptation + private memory. Talking to oneself = no filter.
- One filter (mind ↔ tongue). "Public mode" is not a second mind; it's the same brain through a context-conditioned disclosure filter (who's asking, private vs public). It runs at two timescales:
- Conversing (runtime): answer this asker; the filter shapes the output text; only filtered text leaves → output-level / committee composition.
- Teaching (consolidation): the filter governs what's allowed into a generalized, de-identified projection others can learn from → weight-level composition.
- The coupled twin. The contributable artifact is not a second mind:
Δ_private (raw, never leaves; the folded standalone W = B + Δ_private is made of this) and Δ_public (anchor-locked projection distilled from Δ_private each sleep cycle, under the filter + a leakage gate). They co-evolve; Δ_public is a running privacy-filtered re-projection of Δ_private.
- Right-sizing — more is not better. The network assembles the minimal sufficient qCore for the contextual generality of the input (narrow → own iCore; broad → a few experts; general → escalate). "Bigger" is available capacity, never an obligation; over-assembling should lose.
3. The Foundational Model
(Full detail: Foundational-Model-Plan §2–§3.)
- Base = Qwen3-MoE family (Apache-2.0), MoE decisively — only MoE lets an assembly be literally bigger (dense merges hit a same-size ceiling); experts are the natural fractal sub-unit. Default iCore Qwen3-30B-A3B-Instruct-2507; power tier Qwen3-Next-80B-A3B on a 128 GB Mac.
- Architecture = "Holographic Spectrum." Each iCore = frozen anchor ⊕
Δ_private ⊕ Δ_public + tiny dense drafter. Keystone: FlexOlmo's frozen-anchor invariant — all deltas trained against the same frozen anchor stay mutually composable, so anchor ⊕ {any subset of deltas} is always a runnable LLM (→ fractality, opt-out = drop a delta, associative composition).
- Spectrum router picks composition fidelity by scope/bandwidth and labels it honestly: committee/MoA (cross-DNA — bigger system) · MoErging (same-DNA default — bigger single sparse LLM, decomposable) · BTM-merge (WAN) · distributed-MoE/BTX (LAN, long-lived). Mode-0 right-sizes first (§2).
- Fidelity ↔ singularity trade-off (E1-grounded; full mechanism: Plan §3.3.1–3.3.2). Two ways to combine N iCores: weight-merge → one bigger single model (cheap, persistent, but an interference tax that grows with delta depth + member count — E1 lost ~28%/pack), vs routing/committee → a system (no interference, ~ceiling, but N models + needs an accurate router). E1 numbers: best-single 0.556 · merge-all 0.667 · oracle-routing 0.934 → routing the right specialist beats merging all ("more isn't better," confirmed). Dynamic per-prompt selection: competence-signature routing → right-size to the minimal sufficient set (narrow→own iCore; cross-domain→few; general→escalate) → pick mode by fidelity-need × latency budget → hierarchical router-of-routers at scale → frequently co-activated sets pre-merged into standing qCores during consolidation. Knobs to cut the merge tax: bounded/lighter deltas (DoRA/lower-rank/less-overfit) + TIES/DARE + re-basing.
4. Decentralized Training & Inference
(Full detail: Foundational-Model-Plan §6–§7.)
- Training: per-iCore learning is local (MLX); heavy RL stays local (the INTELLECT-3 lesson). Communal/base sync uses low-comms optimizers (SparseLoCo / DiLoCo over a DHT); merges via mergekit; network-epoch RL via prime-rl. Decentralized projects are transport/consolidation plumbing, not the architecture.
- Inference: committee/MoA over plain text; MoErging over public twins; Exo for intra-qCore LAN distributed-MoE; Parallax (the live Petals successor) only if a WAN layer-shard path is ever needed.
5. The Node — a sovereign, native app
(Full detail: Node-Packaging-Addendum.)
- Native macOS app: Tauri v2 (Rust core + web UI) wrapping a
127.0.0.1 Python sidecar (hinetd). Rust core owns identity (Ed25519/Keychain), the encrypted vault (SQLCipher), the consent decision, and the signed audit hash-chain; Python owns MLX inference + LoRA training + eval. SwiftUI is a later view swap.
- Engine: MLX / mlx-lm for both inference and on-device LoRA training (Ollama as fallback).
ComputeBackend seam: every model call crosses as a node-signed WorkOrder and returns a verified BackendReceipt — the seam moves computation, never authority. LocalBackend now; a user-owned attested-TEE cloud sandbox later, as a drop-in.
6. Personal Data & Sovereignty (the differentiation)
(Full detail: Personal-Data-and-Sovereignty.)
An iCore's value is the data its owner opens to it. The anchor is identical for everyone; personalization is the moat.
- Hybrid by design (research-grounded): fine-tuning carries voice/skill/behavior; RAG carries facts (Ovadia, OPPU, FineTuneBench). So an iCore = vault + RAG (the owner's facts/memory) + tuned weights (the owner's voice/skill). Pure weight-injection of facts is capacity-limited and fragile —
memory/RAG is now load-bearing, not optional.
- Personalization engine — a depth spectrum, not a thin adapter (full detail: Personalization-Engine): LoRA → high-rank LoRA → DoRA → full fine-tune, tuned in bf16/int8 (not 4-bit) with diverse Self-QA augmentation + replay + eval-gate. Composition of deep deltas works via task-vectors (TIES/DARE) relative to the shared base + periodic anchor re-basing — re-basing is how "a new network model is built from the personally-tailored iCores." Depth↔composability is navigated by the multi-timescale clocks.
- Hardware tiers — one human, several coherent iCore builds: pocket/edge (Jetson-class — self-custody), laptop (full-FT a 7–8B or DoRA/high-rank on the 30B), and a user-owned cloud iCore (full-FT the full 30B+ overnight). Kept coherent by one identity + the shared vault; heavier tiers distill into lighter ones.
- What's proprietary: the encrypted deltas (
Δ_private/Δ_public, up to full-FT task-vectors) + vault data, on the shared public anchor — not a private base (which would break composition).
- Ingestion (consent-gated, local-first): a source-agnostic framework + connectors — easy tier (local files incl. iCloud Drive folder, Gmail/Drive/Calendar OAuth, platform export dumps for socials' own-content) in the POC; live social API / feed-slice capture deferred (ToS-fragile, per-platform).
VaultReplication (sovereign redundancy): encrypt locally, replicate ciphertext to N owner-owned targets (local + owner's cloud + a decentralized FS). Only ciphertext leaves; the owner holds the keys; restore-on-new-machine. Distinct axis from the compute sandbox. Key loss = data loss (backup enforced at onboarding).
- Security-first sequencing: the consent/audit/encryption container must exist before any connector touches real data — so Track 2 capabilities are features of the node container.
6A. Economic Model, Value & Ownership
Your iCore is not a subscription — it is owned intelligence capital that serves you and earns from the network. Three things make it an asset: you hold the only keys to your weights, it appreciates as it learns you, and the network pays you when it uses you.
What you open up → what you get (for yourself, and for the network)
You decide what your iCore ingests. Each kind of data becomes a capability — privately for you, and (only with consent, only as a generalized projection) as something the network can compose with.
| You open up… |
Capability for you (private) |
Contributable to the network (consented, generalized) |
| Messages (Telegram/WhatsApp/Slack/email) |
an agent that knows your relationships, threads, and context; drafts and replies in your voice |
communication/coordination skill (de-identified), social-EQ patterns |
| Documents / Drive / notes |
recall + reasoning over your knowledge and projects |
domain-knowledge skills (de-identified) |
| Code (repos, editor sessions) |
a coding agent that knows your codebase, stack, and style |
a coding skill expert |
| Feedback (edits, accept/reject) |
taste & style alignment — it sounds and decides like you |
(stays private; rarely shared) |
| Persona / goals / identity |
an agent aligned to your objectives across life |
(stays private) |
The pattern: facts & memory → your private retrieval (and, optionally, de-identified knowledge to the network); skills & voice → your private weight-delta Δ (and a generalized, consented Δ_public the network can route to). The more you open, the stronger your personal agent; the more you consent to share (as generalized skills), the more you can earn.
Value to you — a foundational model + an agent that grows with you
- A model you own, for all of life — a private assistant + memory + advisor that compounds as it learns you; runs offline.
- A sovereign work agent. Point your own tools at it — e.g. use your iCore as the model behind Cursor / your IDE via a local OpenAI-compatible endpoint, a sovereign backup so you aren't wholly dependent on a model you don't own. As developers grow reliant on rented frontier models, owning a capable coding model that knows your code is leverage and insurance.
Choose your root — and still compose
You pick a starting root for your iCore — e.g. developer-focused (coding-tuned skills) or general-use (assistant-tuned), with more roots over time (research, writing, finance…). Roots that share a compatibility class (same anchor DNA / model passport) stay weight-composable; different roots still compose at the output/routing level (route conflicting, distill across classes). So you can start specialized and combine with the network when it helps — your root shapes which network skills you most complement (and earn from).
How you get paid — the network pays you when it uses you
- Your consented
Δ_public is an income-producing expert. Each time a qCore composes or routes to your iCore to serve someone else, you get paid (usage-metered royalty). Complementary, in-demand skills get routed to more → earn more.
- Privacy-preserving: only your generalized, consented projection is ever used; raw data and private weights never leave; you can revoke (drop the delta) at any time.
- Net economics: you pay (or self-host) for your own compute; you earn from network usage. A well-contributing iCore can be net-positive — an asset that pays for itself.
- (Settlement mechanism — metering + micropayments — is deferred; out of scope for the POC.)
Sovereignty & snapshots — sole access, with redundancy
- You hold the only keys to your weights. Backups (
VaultReplication) are encrypted under your key and replicated only to owner-owned targets — HiNet is never in the trust path.
- Two snapshots, your choice: a local snapshot for true off-grid security and ownership, and an optional cloud snapshot (your attested tenant) with higher capability for heavier work. Same identity; the cloud is rented muscle, not a new owner.
Verifiable participation & the network economy
Composition stays trustless because of programmable cryptography: an iCore can prove it genuinely contributed to a qCore's inference without revealing its private weights (zero-knowledge / secure-computation techniques), so anyone can build on anyone else's intelligence and every contribution is metered and attributable — the basis for fair revenue-share and for paying a fee to use the network without any party owning the whole. Think a blockchain for intelligence: a decentralized brain nobody owns and everyone contributes to. (This verifiable-private-inference layer is research-grade — §9.)
7. The POC — two tracks
- Track 1 — composition science (E1): do same-anchor sub-models synthesize into a bigger model? Public datasets, single Mac. The cheap falsifiable gate. Full pre-registration: E1-Experiment-Design.
- E1 flagship test: frozen Qwen3-30B-A3B anchor → 3 persona experts → committee vs MoErging vs BTX (+ an all-experts-always control) on a 600-item mixed MCQ eval. Success = a weight-level mode beats the best single iCore by ≥ 8 pp macro-avg, smart routing beats all-experts-always, and opt-out is exact. If neither weight-mode wins, the assembly thesis is falsified at the smallest scale and we stop before networking.
- Track 2 — personal intelligence + sovereignty: does an iCore become measurably you from your data, with proprietary redundantly-owned weights? Lives in the node container. Proven by E2-on-real-data (sleep cycle + leakage gate, piloted on the developer's own Mac).
8. Roadmap
| Phase |
What |
Status |
| Toolchain |
MLX 0.31 on M4 Max; QLoRA-on-MoE; download/grader validated |
✅ done |
| E1 data harness |
persona SFT views + 600-item mixed MCQ eval + grader (anchor 80% medicine smoke) |
✅ done |
| E1 composition |
synthetic packs → 3 bf16 full-FT specialists → task-vector merge |
✅ PASS — merged single model 0.667 > best-single 0.556 (+11pp), knows all 3 packs; routing ceiling 0.934. (E1 §6) |
| Reduce merge interference (M5-009) |
sweep done: merge-algo buys single digits (best full-FT+DARE 0.678/73%); LoRA/DoRA under-inject facts; axes can't close the gap. Conclusion: facts compose by RETRIEVAL-union (lossless), skills by weight-merge+distill — composition inherits the fact/skill hybrid. Detail: Personalization-Engine §5b–§5c |
✅ done |
| Skill-composition validation (optional) |
show weight-merge + distill-into-merge ≈ ceiling on a SKILL testbed (LoRA's strength), not facts |
⏳ optional |
| Node container |
Tauri + hinetd + identity/vault/consent/audit + connector framework + VaultReplication |
⏳ Track 2 |
| E2-on-real-data |
sleep cycle (coupled twin) on the dev's own files/mail + leakage gate |
⏳ Track 2 |
| Networking |
qCore over real peers; communal consolidation; receipts |
later |
9. Open Research Questions & Risks
- Does the assembly beat the best single iCore? (E1 — the make-or-break gate.)
- FlexOlmo → Qwen3-MoE retarget for BTX (verified on OLMo-2; OLMoE is the fallback base).
- Router quality / saturation past large N (hierarchical router-of-routers).
Δ_public privacy — leakage even after the gate; DP-noise vs mergeability (measured in E2).
- Decomposability after BTX promotion (kept rare/opt-in; live qCores are decomposable).
- Decentralized frontier RL is unsolved → heavy RL stays local.
- Anchor drift across base upgrades (compatibility-class migration).
- Sovereign key recovery — HiNet cannot recover lost keys; backup UX must be unavoidable.
- Live social ingestion — ToS/legal + brittleness of the per-account feed-slice.
- Depth ↔ composability — how deeply can an iCore be fine-tuned (DoRA/full-FT) before its task-vector stops merging cleanly? Sets the re-basing cadence. (See Personalization-Engine §3, §5.)
- Personalization method bake-off — full-FT a 7–8B base vs DoRA/high-rank on the 30B: which gives better deep personalization on quality × depth × composability? (To test.)
- Verifiable private participation — proving an iCore contributed to inference without revealing its weights (ZK / MPC / FHE for LLM inference) is research-grade and a hard performance problem; it's what makes trustless composition + metered, fair payouts possible (§6A).
10. Out of scope (for now)
aCore agentic layer · token economics / on-chain settlement · live social scraping · multi-OS packaging. Hooks (audit chain, consent grants, receipts, ComputeBackend/VaultReplication seams) are placed so these attach later without re-architecting.
11. Companion documents
- HiNet-Foundational-Model-Plan.md — base model, holographic-spectrum architecture, ownership model §2A, training, consolidation, decentralized stacks.
- HiNet-Node-Packaging-Addendum.md — native macOS app + on-device runtime +
ComputeBackend seam.
- HiNet-Personal-Data-and-Sovereignty.md — Track 2: ingestion connectors,
VaultReplication, proprietary-delta redundancy, E2-on-real-data.
- HiNet-Personalization-Engine.md — training-method spectrum (LoRA→DoRA→full-FT), depth↔composability + task-vector merging + re-basing, and the hardware tiers (pocket/laptop/cloud).
- HiNet-E1-Experiment-Design.md — the pre-registered composition experiment + results.
- HiNet-Sim-to-Real-Gap.md — honest assessment of how far the (clean, small, one-shot) sims are from real user data; what they do/don't validate; the gaps + closing experiments.
- specs/HiNet-Track2-Functional-Spec.md — the product: macOS app, personal-data connectors (Telegram/WhatsApp/Slack/Gmail/Drive incl. multi-account), the agentic (Hermes-style) layer, ingestion→vault→training-views, consent/audit/kill-switch, app UX.
- gtm/investor-cold-email.md — investor cold email. Landing site:
website/ (icore.quorumz.com).
- HiNet-Fractal-Intelligence-Whitepaper.md — founding conceptual paper (quorum sensing, fractal intelligence, hypotheses).
- specs/ · project-management/master-task-list.md — functional/technical specs and milestones.
Changelog
- 0.7.0 — Added §6A Economic Model, Value & Ownership: the data→capability mapping (what you open up → what you get, for self + network), value-to-you (a model you own + a sovereign work agent, e.g. your iCore behind Cursor), choose-your-root (developer vs general, still composable via compatibility class), how you get paid (the network pays you when it routes to your iCore), and sovereignty/snapshots (sole keys; local off-grid + optional cloud tier). Site whitepaper now serves gated behind an email-code and renders in-page as HTML.
- 0.6.0 — M5-011 skill-composition test refined the conclusion: mergeability is governed by delta CONFLICT/orthogonality, not fact-vs-skill. 3 conflicting cipher skills merged at ~7% (≪ facts' 73%) but routed at the 0.61 ceiling (~15×). New rule: merge complementary deltas (lit. ~98% on different tasks) · ROUTE conflicting ones · RETRIEVAL-union for facts — the §3.3 selector picks by conflict. Also added the Sim-to-Real-Gap assessment (sims validate mechanisms, not real-data eval/continual/privacy).
- 0.5.0 — M5-009 interference sweep done: merge-algo buys single digits (best full-FT+DARE 0.678/73%), LoRA/DoRA under-inject facts, the delta×algo axes can't close the gap to 0.934. Key conclusion: weight-merging independent FACTS is structurally lossy (erased facts don't recover from distill) → composition inherits the storage hybrid: facts compose by RETRIEVAL-union (lossless), skills by weight-merge + distill-into-merge (~ceiling). Also documented the SOTA merge/re-basing methods + per-tier recipe (Personalization-Engine §5b–§5c).
- 0.4.0 — E1 composition PASSED on a synthetic testbed: 3 bf16 full-FT specialists (each ~0.9 on its pack) task-vector-merged into one model scoring 0.667 macro > 0.556 best-single (+11pp), knowing all 3 packs (routing ceiling 0.934). En route, proved bf16 full-FT injects personal data (helix 0.27→0.97, 8/8 recall) — retracting the earlier "FT can't inject facts" (that was 4-bit + recipe). Quantified the depth↔composability interference tax (~28%/pack for heavily-overfit deltas). Full arc in E1 §6. Next: DoRA/bounded deltas + re-basing to reduce interference; scale to 30B/tiers.
- 0.3.0 — Research-grounded correction: iCore personalization is hybrid (RAG=facts, fine-tuning=voice/skill; per Ovadia/OPPU/FineTuneBench/Physics-of-LMs). Added the Personalization-Engine companion: the method spectrum (LoRA→high-rank→DoRA→full-FT), the depth↔composability trade-off with task-vector merging + anchor re-basing, and hardware tiers (pocket/Jetson · laptop · user-owned cloud iCore). Recorded that the earlier fact-injection failure was a setup flaw (4-bit + uniform augmentation + format + overtraining), not a wall. Open questions +2 (depth↔composability; method bake-off).
- 0.2.0 — Consolidated the planning narrative into this living whitepaper. Added Track 2 (personal data + sovereignty): ingestion connector framework,
VaultReplication, proprietary-delta model, E2-on-real-data. Added the two-track POC framing and the right-sizing / coupled-twin ownership model (§2). E1 data harness complete; E1 train/verdict next.
- 0.1.0 — (pre-consolidation) Foundational-model plan, packaging addendum, and E1 pre-registration authored as separate docs.