HiNet — Living Whitepaper
Version 0.10.2 · Living document (changelog at the end) · Status: E1 composition PASSED (the foundational thesis); and Track 2 is now being built — the local iCore runtime (hinetd: MLX, OpenAI-compatible, generalist + coding roots, Cursor-connectable) and a provenance-rich personal RAG (encrypted vault → hybrid retrieval → consent-filtered, cited answers; semantic and cross-lingual) are built and verified (§5–§6, §8). With the economic model & ownership (§6A) and a fully-verified References section (§12).
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 (Borzunov et al., 2022) 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.
Where the edges are drawn (the membrane). Composition is not unbounded: assemblies form inside membranes — org- or gov-gated boundaries that let a company or institution build its own sovereign intelligence and keep or sell it on its terms. So HiNet serves two audiences at once: individuals (own an iCore, earn when it serves the network) and organizations (an iCorp — a rigid quorum that answers as one business identity and retains its intelligence). An iCore is human-owned for life and merely leased to an employer while employed. This organizational layer — membranes, the lease, and the two-sided economy — is §6B.
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; Qwen Team, 2025), MoE decisively — only MoE (Shazeer et al., 2017; Fedus et al., 2021) lets an assembly be literally bigger (dense merges hit a same-size ceiling); experts are the natural fractal sub-unit. MoE is therefore a hard model-selection filter, not a preference — it's what makes quorum assembly bigger, so we always take the newest Qwen general that is still MoE. Default anchor (Oct-2026) Qwen3-Next-80B-A3B-Instruct (MoE, 3B active; ~45GB at 4-bit, 64GB+ Mac); the even-newer Qwen3.8-27B is dense and so is excluded (it can't compose bigger). Qwen3-30B-A3B-Instruct-2507 is the fast / lower-RAM tier (
icore-fast).
- Architecture = "Holographic Spectrum." Each iCore = frozen anchor ⊕
Δ_private ⊕ Δ_public + tiny dense drafter. Keystone: FlexOlmo's frozen-anchor invariant (Shi et al., 2025) — 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; Wang et al., 2024) · MoErging (same-DNA default — bigger single sparse LLM, decomposable; Yadav et al., 2024) · BTM-merge (Li et al., 2022) · distributed-MoE/BTX (LAN, long-lived; Sukhbaatar et al., 2024). 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, Liu et al., 2024 / lower-rank/less-overfit) + TIES (Yadav et al., 2023) / DARE (Yu et al., 2023) + re-basing (Ainsworth et al., 2022).
4. Decentralized Training & Inference
(Full detail: Foundational-Model-Plan §6–§7.)
- Training: per-iCore learning is local (MLX); heavy RL stays local — decentralized RL is feasible (INTELLECT-2; Prime Intellect, 2025), but frontier RL runs are still centralized (INTELLECT-3 trained on a 512×H200 cluster; Prime Intellect, 2025). Communal/base sync uses low-comms optimizers (SparseLoCo, Sarfi et al., 2025 / DiLoCo, Douillard et al., 2023, over a DHT); merges via mergekit (Goddard et al., 2024); network-epoch RL via prime-rl (Prime Intellect, 2025). Decentralized projects are transport/consolidation plumbing, not the architecture.
- Inference: committee/MoA over plain text; MoErging over public twins; Exo (exo-explore, 2024) for intra-qCore LAN distributed-MoE; Parallax (a newer Petals-style decentralized layer-shard system from Gradient, benchmarked ~3.1× lower end-to-end latency than Petals; Tong et al., 2025) 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, Bernstein et al., 2011 / 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 inference + on-device LoRA training — Apple's open ML framework for Apple Silicon; its unified memory (CPU+GPU share one RAM pool) lets a 4-bit 30B run fully local on a 128 GB Mac. Reality check: MLX is Apple-Silicon-only and its model ecosystem is younger than PyTorch/CUDA — a real ops cost (e.g. some embedders ship no MLX-loadable weights; see §6), and the
ComputeBackend seam is what covers non-Apple + cloud tiers. (Ollama 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.
- Built (P1, verified):
hinetd is the local iCore runtime — an OpenAI-compatible MLX server serving your generalist (Qwen3-30B-A3B) + a coding root (point Cursor at it for a sovereign coding model). The substrate the launcher UX, RAG, and agentic layer all plug into. (app/osx/hinetd · delivery roadmap)
- The laptop build is the on-ramp; iCore Prime is the holy grail. The laptop node (above) is the lowest-barrier entry — download and run your iCore on the Mac you own, no hardware, no network. The strongest form is iCore Prime: dedicated personal hardware (built on Jetson-class silicon) that runs a bigger model and does the heavy lifting — nightly training/consolidation — while your laptop and phone attach as thin clients (via the
ComputeBackend seam, over the LAN). iCore Prime is to intelligence what a miner is to a blockchain: always-on, owner-operated capacity that compounds the network as more come online — a positive-sum effect where each Prime both serves its owner and strengthens the whole. Tiers: pocket/edge · laptop · iCore Prime · user-owned cloud (§6).
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): RAG carries facts (Lewis et al., 2020), while fine-tuning carries voice/skill — fine-tuning is weak at injecting new facts and retrieval beats it for factual recall (Ovadia et al., 2023; FineTuneBench, Wu et al., 2024), and personal PEFT adapters capture a user's style (OPPU; Tan et al., 2024). 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.
- Built (P2/P2.1, verified — local, provenance-rich RAG): one encrypted sqlite vault holds the canonical records; retrieval = consent/provenance pre-filter → hybrid (dense + BM25 + RRF) → parent-merge → cited records. Embedder =
multilingual-e5-base on MLX (semantic and cross-lingual — an English query retrieves a Hebrew note; bge-m3 was the design pick but ships no MLX-loadable weights, so we pinned e5). Provenance (Origin) is kept for RAG (metadata filter + citation) and generalized for training. (RAG architecture)
- Personalization engine — a depth spectrum, not a thin adapter (full detail: Personalization-Engine): LoRA (Hu et al., 2021) → high-rank LoRA → DoRA (Liu et al., 2024) → full fine-tune, tuned in bf16/int8 (not 4-bit) — int4 sharply cuts knowledge capacity (Allen-Zhu & Li, 2024) — with diverse Self-QA augmentation + replay + eval-gate (augmentation à la Self-Instruct; Wang et al., 2022). Composition of deep deltas works via task-vectors (TIES/DARE) relative to the shared base + periodic anchor re-basing (Ilharco et al., 2022; Yadav et al., 2023; Yu et al., 2023; Ainsworth et al., 2022) — 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). Every source normalizes into one Canonical Record — a shared schema with
Origin provenance (spec) that the vault, RAG, and training views all consume.
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 you get paid when you serve the network.
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 — you earn when you serve the network
- Your consented
Δ_public is an income-producing expert. Each time you serve the network — a qCore composes or routes to your iCore to answer someone else — you get paid (usage-metered royalty). Complementary, in-demand skills get served 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 proofs and secure multi-party computation — e.g. zkLLM, Sun et al., 2024; PUMA, Dong et al., 2023), 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.)
6B. Organizations, Membranes & the Lease — decentralized intelligence, corporate borders
(Canonical model: HiNet-Sovereign-Intelligence-Vision.md.)
§6A is the individual economy. This is the organizational one — and the reconciliation that lets HiNet exist inside the real business world: decentralize intelligence to the atom (the human), while respecting the membranes of companies and states. Inside a firm people compound intelligence freely; that intelligence is not aggregated outside the firm without the firm being paid back. Sovereignty is human; commerce is organizational.
- The membrane. A membrane is the boundary that defines where a quorum draws its edge — org- or gov-gated. It governs what compounds inside and what may cross out, and on what terms. The membrane is what lets a decentralized brain coexist with corporate confidentiality and state regulation.
- The iCorp. An iCorp is a rigid, org-gated iQuorum that presents to the outside world as a single business-unit identity: externally it answers as the company and does not expose its member iCores individually; internally it is a workspace of iCores and iQuorumz. An org builds its own sovereign intelligence model from its members' know-how and either uses it in its products or sells it externally.
- The human-first lease. An iCore is human-owned permanently; employment is a lease, not a transfer. With the human's consent, their iCore is leased to the iCorp for the duration of employment and, while leased, contributes to the iCorp's model. When the human leaves, the iCore travels with them (still theirs, portable) — but the intelligence it contributed remains in the iCorp's model. The company keeps what was built on its premises; the human keeps their atom. This is the crux: atomic human-first sovereignty underneath, corporate borders on top.
- Two audiences, three views. A public netizen sees free iCores (unattached) and iCorps as single identities (member iCores hidden). An iCorp member sees the company workspace — all internal iCores and iQuorumz. The product differentiates the two: a public user builds on their own iCore in the public network; a business user operates inside their iCorp.
- Asking (Slack-for-AI shape). No channels — the objects are iCores and iQuorumz, and an iCorp is a workspace. You ask a specific iCore, ask a predefined iQuorum (a named group, admin-defined, for mentioning), or ask openly and let the mechanism route to the most suitable quorum. Because the member set is known, iCorps get a more streamlined path to build intelligence than the open network.
- The two-sided economy. iCorp = SaaS: organizations subscribe and retain their sovereign intelligence (it never crosses the membrane unless they externalize it). Public = pay-per-use: askers pay per question, split among the iCores / iQuorumz / iCorps that answered, with a platform share (§6A). When an iCorp answers publicly it earns as a unit — its internal iCores are paid via the iCorp, and are neither referenced nor paid individually, honoring the membrane.
The net shape is a "Slack for AI" where each iCore = one human and each iQuorum/iCorp = a workspace — decentralizing intelligence to the person while preserving the commercial borders organizations require.
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 |
iCore runtime (hinetd) |
local MLX OpenAI-compatible server; generalist + coding roots; Cursor-connectable |
✅ P1 done |
| Canonical Record + RAG design |
shared normalization schema (+Origin provenance); local provenance-rich RAG architecture |
✅ specced |
| Vault + RAG (personal memory) |
encrypted sqlite vault + hybrid retrieval (dense+BM25+RRF) + consent pre-filter + citation; multilingual-e5 embedder (cross-lingual) |
✅ P2/P2.1 done |
| Node container (rest) |
Tauri launcher UX + identity/consent/audit + connectors + VaultReplication |
🔨 building (P3–P4) |
| 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 — zkLLM, Sun et al., 2024; PUMA, Dong et al., 2023; CipherGPT, Hou et al., 2023) 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-Sovereign-Intelligence-Vision.md — the org/human sovereignty model: iCore/iQuorum/iCorp primitives, membranes, the human-first lease, the two/three views, and the two-sided economy (source of §6B).
- 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-Delivery-Roadmap.md — the Track-2 build plan (atomic-first phases: runtime → vault/RAG → launcher → connectors → training/sleep → agentic → quorumz) + build status.
- specs/HiNet-Canonical-Record.md — the shared normalization format every connector emits (envelope, thread/identity model,
Origin provenance, per-source mappings).
- specs/HiNet-RAG-Architecture.md — the local, provenance-rich RAG design (hybrid retrieval, consent pre-filter, citation, the embedder decision).
- 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/ (mind.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.
12. References
Citations for the methods, models, and systems named above, grouped to mirror the sections. All entries were verified against arXiv/venue listings; the field moves fast, so a few are very recent preprints (flagged) that may change on acceptance.
Foundational & open models (§2–§3)
- Shazeer, Mirhoseini, Maziarz, Davis, Le, Hinton & Dean (2017). Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer. ICLR 2017. arXiv:1701.06538
- Fedus, Zoph & Shazeer (2021). Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity. JMLR 23 (2022). arXiv:2101.03961
- Jiang et al. (Mistral AI) (2024). Mixtral of Experts. arXiv:2401.04088
- Muennighoff et al. (Ai2) (2024). OLMoE: Open Mixture-of-Experts Language Models. ICLR 2025. arXiv:2409.02060
- OLMo Team (Ai2) (2025). 2 OLMo 2 Furious. COLM 2025. arXiv:2501.00656
- Qwen Team (Alibaba) (2025). Qwen3 Technical Report. arXiv:2505.09388 — covers the Qwen3 dense+MoE suite incl. Qwen3-30B-A3B; the later Qwen3-Next-80B-A3B is a separate Sept-2025 release (see its model card).
Composition: shared-anchor experts, branch-train, routing & merging (§3–§4)
- Shi, Bhagia, Farhat, Muennighoff, Walsh et al. (Ai2) (2025). FlexOlmo: Open Language Models for Flexible Data Use. arXiv:2507.07024 — the frozen shared-anchor composability invariant HiNet builds on.
- Li, Gururangan, Lewis, Smith & Zettlemoyer (2022). Branch-Train-Merge: Embarrassingly Parallel Training of Expert Language Models. arXiv:2208.03306
- Sukhbaatar, Golovneva, Weston, Li et al. (Meta FAIR) (2024). Branch-Train-MiX: Mixing Expert LLMs into a Mixture-of-Experts LLM. arXiv:2403.07816
- Wang, Wang, Athiwaratkun, Zhang & Zou (2024). Mixture-of-Agents Enhances Large Language Model Capabilities. ICLR 2025. arXiv:2406.04692
- Yadav, Raffel, Muqeeth, Caccia et al. (2024). A Survey on Model MoErging: Recycling and Routing Among Specialized Experts. TMLR. arXiv:2408.07057
Weight-space model merging (§3–§4, §6)
- Wortsman, Ilharco, Gadre, Roelofs et al. (2022). Model Soups: averaging weights of multiple fine-tuned models improves accuracy. ICML 2022. arXiv:2203.05482
- Ainsworth, Hayase & Srinivasa (2022). Git Re-Basin: Merging Models modulo Permutation Symmetries. ICLR 2023. arXiv:2209.04836
- Ilharco, Ribeiro, Wortsman, Gururangan, Schmidt, Hajishirzi & Farhadi (2022). Editing Models with Task Arithmetic. ICLR 2023. arXiv:2212.04089
- Yadav, Tam, Choshen, Raffel & Bansal (2023). TIES-Merging: Resolving Interference When Merging Models. NeurIPS 2023. arXiv:2306.01708
- Yu et al. (2023). Language Models are Super Mario: Absorbing Abilities from Homologous Models as a Free Lunch (DARE). ICML 2024. arXiv:2311.03099
- Goddard et al. (Arcee AI) (2024). Arcee's MergeKit: A Toolkit for Merging Large Language Models. EMNLP 2024. arXiv:2403.13257
- Dalili & Mahdavi (2025). SAMerging: Sharpness-aware Model Merging via Multi-Teacher Knowledge Distillation (preprint). arXiv:2512.21288 — recent, not yet accepted; verify before relying on it.
Parameter-efficient & full fine-tuning (§5–§6)
- Hu, Shen, Wallis, Allen-Zhu, Li, Wang, Wang & Chen (Microsoft) (2021). LoRA: Low-Rank Adaptation of Large Language Models. ICLR 2022. arXiv:2106.09685
- Dettmers, Pagnoni, Holtzman & Zettlemoyer (2023). QLoRA: Efficient Finetuning of Quantized LLMs. NeurIPS 2023. arXiv:2305.14314
- Liu et al. (NVIDIA & HKUST) (2024). DoRA: Weight-Decomposed Low-Rank Adaptation. ICML 2024. arXiv:2402.09353
Decentralized training & inference (§4)
- Borzunov, Baranchuk, Dettmers, Ryabinin et al. (2022). Petals: Collaborative Inference and Fine-tuning of Large Models. ACL 2023 (demos). arXiv:2209.01188
- EXO Labs (2024). exo: run frontier AI on everyday devices. Software. github.com/exo-explore/exo
- Douillard et al. (Google DeepMind) (2023). DiLoCo: Distributed Low-Communication Training of Language Models. arXiv:2311.08105
- Sarfi, Thérien, Lidin & Belilovsky (2025). Communication-Efficient LLM Pre-training with SparseLoCo. arXiv:2508.15706
- Jaghouar, Ong et al. (Prime Intellect) (2024). INTELLECT-1 Technical Report. arXiv:2412.01152
- Prime Intellect (2025). INTELLECT-2: A Reasoning Model Trained Through Globally Decentralized Reinforcement Learning. arXiv:2505.07291
- Prime Intellect (2025). INTELLECT-3 Technical Report. arXiv:2512.16144 — centralized 512×H200 RL run (the "heavy RL stays local" datapoint); recent preprint.
- Prime Intellect (2025). prime-rl: asynchronous decentralized RL. Software. github.com/PrimeIntellect-ai/prime-rl
- Tong et al. (Gradient) (2025). Parallax: Efficient LLM Inference Service over a Decentralized Environment. arXiv:2509.26182
Knowledge injection, RAG & personalization (§6–§7)
- Lewis, Perez, Piktus et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. arXiv:2005.11401
- Wang, Kordi, Mishra, Liu, Smith, Khashabi & Hajishirzi (2022). Self-Instruct: Aligning Language Models with Self-Generated Instructions. ACL 2023. arXiv:2212.10560
- Allen-Zhu & Li (2023). Physics of Language Models: Part 3.1, Knowledge Storage and Extraction. ICML 2024. arXiv:2309.14316
- Allen-Zhu & Li (2024). Physics of Language Models: Part 3.3, Knowledge Capacity Scaling Laws. ICLR 2025. arXiv:2404.05405
- Ovadia, Brief, Mishaeli & Elisha (Microsoft) (2023). Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs. EMNLP 2024. arXiv:2312.05934
- Wu, Wu & Zou (Stanford) (2024). FineTuneBench: How well do commercial fine-tuning APIs infuse knowledge into LLMs? arXiv:2411.05059
- Tan, Zeng, Tian, Liu, Yin & Jiang (2024). Democratizing Large Language Models via Personalized Parameter-Efficient Fine-tuning (OPPU). EMNLP 2024. arXiv:2402.04401
Verifiable private inference (research-grade; §6A, §9)
- Hao, Li, Chen, Xing, Xu & Zhang (2022). Iron: Private Inference on Transformers. NeurIPS 2022. proceedings.neurips.cc
- Dong, Lu, Zheng, Wu et al. (2023). PUMA: Secure Inference of LLaMA-7B in Five Minutes. arXiv:2307.12533
- Hou, Liu, Li, Li, Lu, Hong & Ren (2023). CipherGPT: Secure Two-Party GPT Inference. IACR ePrint 2023/1147. eprint.iacr.org/2023/1147
- Sun, Li & Zhang (2024). zkLLM: Zero Knowledge Proofs for Large Language Models. ACM CCS 2024. arXiv:2404.16109
Node stack (software) (§5)
- Tauri (2024). Tauri 2.0 — cross-platform native apps with a web frontend. v2.tauri.app
- Apple ML Research (2023–). MLX — an array framework for Apple silicon (with mlx-lm). github.com/ml-explore/mlx
- Ollama (2023–). Ollama — run large language models locally. ollama.com
- Zetetic (2008–). SQLCipher — full database encryption for SQLite. zetetic.net/sqlcipher
- Bernstein, Duif, Lange, Schwabe & Yang (2011). High-speed high-security signatures (Ed25519). CHES 2011. ed25519.cr.yp.to
Changelog
- 0.10.2 — Generalist anchor upgraded to Qwen3-Next-80B-A3B-Instruct (§3) — the newest Qwen general model that is still MoE, which the quorum-assembly thesis requires (only MoE composes bigger). Made MoE an explicit hard model-selection filter: the even-newer Qwen3.8-27B is dense → excluded. Qwen3-30B-A3B kept as the
icore-fast / lower-RAM tier. Feasibility verified (137GB unified memory; mlx-lm 0.31.3 supports the qwen3_next hybrid arch). Note on strategy: the agent harness is model-agnostic (OpenAI-compatible), so the anchor stays Qwen while any harness — our lean loop, DeepSeek-Harness (MIT), or OpenClaw — can drive it; DeepSeek's own MoE models don't fit a local anchor (smallest flagship ~142GB@4-bit, and a non-Qwen DNA that isn't weight-composable with our iCores).
- 0.10.1 — iCore Prime (hardware iCore) elevated in §5 — the laptop build is the low-barrier on-ramp; iCore Prime (dedicated Jetson-class hardware doing heavy training/consolidation + a bigger model, laptop/phone as thin clients) is the network's "mining unit" / holy grail with a positive-sum network effect. Landing gains a "The hardware iCore" section (laptop → Prime tiers). Product work vectors captured in master-task-list.md (P-A standalone laptop iCore = current focus).
- 0.10.0 — Organizational layer added: §6B Organizations, Membranes & the Lease + a North-Star paragraph on where the edges are drawn. Introduces the iCorp (a rigid, org/gov-gated quorum that answers as one business identity and retains its sovereign intelligence), the membrane (the boundary defining a quorum's edge), the human-first lease (an iCore is owned for life, leased to an employer while employed — it travels with the human on exit, its contributed intelligence stays with the iCorp), the two audiences / three views (public netizen vs iCorp member), and the two-sided economy (iCorp = SaaS + retained sovereignty; public = pay-per-use split to contributing iCores/iQuorumz/iCorps + platform). New canonical companion: HiNet-Sovereign-Intelligence-Vision.md (source of §6B). Landing (mind.quorumz.com) updated to tell both the individual and organizational stories.
- 0.9.0 — Track 2 build underway — folded into the doc. Shipped + verified: P1 the local iCore runtime (
hinetd — MLX, OpenAI-compatible, generalist Qwen3-30B-A3B + a coding root, Cursor-connectable); P2/P2.1 the personal RAG (one encrypted sqlite vault; consent/provenance pre-filter → hybrid dense+BM25+RRF → parent-merge → cited records; embedder = multilingual-e5-base on MLX, semantic and cross-lingual). New companion specs Canonical Record (shared normalization + Origin provenance) and RAG Architecture, plus a Delivery Roadmap (§5, §6, §8, §11). Findings folded in: MLX is the local engine but its embedder ecosystem is young — bge-m3 ships no MLX-loadable weights and Qwen3-Embedding hit an MLX bug (→ pinned multilingual-e5-base); provenance is kept for RAG, generalized for training; a cross-encoder reranker is deferred (no MLX reranker head). Roadmap (§8) now carries build status.
- 0.8.0 — Added §12 References: every named method/model/system now carries a real, verified citation (46 sources; arXiv/venue confirmed by a parallel verification pass), plus per-section inline author-year cites (§1–§9, §6A). Verification also forced prose corrections: split INTELLECT-2 (decentralized RL is feasible) from INTELLECT-3 (frontier RL still centralized — the "stays local" datapoint); fixed SparseLoCo (2025) and FineTuneBench (2024) dates; reworded Parallax (Gradient's decentralized layer-shard system, not a self-described Petals "successor"); scoped Qwen3-Next-80B-A3B out of the Qwen3 report; reframed Ovadia et al. as "FT weak at new facts / RAG wins facts" (not the FT-carries-skill half). A few cited works are very recent preprints (SAMerging, INTELLECT-3) — flagged inline in §12.
- 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.