Documentation  /  Whitepaper

HiNet — Living Whitepaper

Version 0.14.1 · Last release: 2026-08-22 · Living document (changelog at the end)

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.

Where we are today. The foundational thesis is validated: in a controlled composition experiment, independent iCores merged into one model more capable than the best single member (§7). On that footing, the local iCore is built and running — hinetd, an on-device runtime (Apple-Silicon MLX, OpenAI-compatible, so you can even point Cursor at your own model) with a generalist + a coding root, a provenance-rich personal RAG over your own data (encrypted vault → cited, cross-lingual answers), a standalone dev-agent, and a first-run setup that downloads your model and creates your node identity (§5–§6, §6C). The economic and organizational model — own your intelligence, earn when it serves the network, compose within corporate or national membranes — is §6A–§6C; the network layer (identity, registry, routing, the shared monorepo) is specified and entering its build (§6C). Everything cited is verified (§12).

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.

Where to update each thing. This whitepaper is the overview/index; every topic has exactly one canonical home in the companion docs (§11) — deep detail is updated there, not here.

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.
• Not a YAML trainer. Kitchen-sink fine-tune CLIs (e.g. Soup — unrelated to Wortsman Model Soups weight-averaging, already cited below) wrap PEFT/TRL behind one config. Evaluated 2026-08-24 and rejected as the nightly stack: CUDA/PyTorch-first, defaults to 4-bit (our knowledge stage is bf16/int8), and does not emit FlexOlmo-composable Δs. Keep MLX + the Personalization-Engine recipe; steal only the discipline (eval-gated ship, provenance-bound evidence, refuse silent wrong-training). Detail: Personalization-Engine §6.
• 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; build phases in §8.)

The experience (north star). A sovereign-AI UX that feels like the OpenAI desktop app but is owned and local: a global-hotkey quick-launch box for one-shot asks that expands into a full app (chat, history, connectors, consent/training dashboards); two models you own — a generalist for daily life + a coding root you point Cursor/your IDE at; it knows you (consent-gated RAG for facts + nightly training for voice/skill), acts for you (a local, consent-gated agentic runtime), and stays sovereign (your keys, local-first, an optional owner-owned cloud snapshot). It composes later — once the atom is excellent, iCores synthesize into quorums (§6C). Everything hangs off hinetd (the runtime), so that is built first.

• 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 (RAM-adaptive: Qwen3-Next-80B default, Qwen3-30B on lower-RAM Macs) + 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; build phases in §8.)
• The laptop build is the on-ramp; iCore Prime is the holy grail. The laptop node is the lowest-barrier entry — download and run your iCore on the Mac you own (an M4 Max / 128 GB does full training and inference), no extra hardware, no network. The strongest form is iCore Prime: a dedicated, always-on desk appliance — DGX-Spark-class (e.g. GB10 / 128 GB, QLoRA ≤ 70B), not a pocket Jetson (an Orin Nano is inference-only, too small to train) — that runs a bigger model and does the heavy nightly training/consolidation, while your phone / edge box (inference-only) and laptop 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 — positive-sum. Tiers (each true at its class): pocket/edge (inference) · laptop (train + infer) · iCore Prime (nightly training) · user-owned cloud (deepest) (§6). (Detail: Personalization-Engine §4.)

6. Personal Data & Sovereignty (the differentiation)

(Full detail: Track 2 — Functional Spec.)

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 (phone or Jetson-Orin-class — inference-only, self-custody), laptop (M4 Max — full-FT a 7–8B or DoRA/high-rank on the 30B), iCore Prime (DGX-Spark-class desk appliance — heavy nightly training), and a user-owned cloud iCore (deepest). Kept coherent by one identity + the shared vault; heavier tiers distill into lighter ones. (Detail: Personalization-Engine §4.)
• 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.

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 of it as a decentralized intelligence network: a 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.

6C. The Network Layer — identity, registry, routing, the grand monorepo

(Companion specs: Node Identity & Registry · Routing & Quorum Aggregation · Decentralized Monorepo · Onboarding & Harness; the integration note has the build roadmap + open decisions.)

How iCores actually find, verify, route to, and pay each other — the substrate beneath §6A/§6B.

Not an agent-mesh. Agent-mesh projects (e.g. Google's SAM — Sovereign Agent Mesh) route tool calls between agents over a P2P fabric (libp2p + crypto identity + MCP). HiNet's network layer sits a floor above: it composes minds into a bigger model (Quorum Memory, committee/MoErging) and carries ownership + economy (competence attestation, membranes, pay-per-use). Such a mesh is a candidate transport HiNet could ride — not a substitute for the composition layer, which is the moat.

• Identity — one owner-held key. Every iCore carries one Ed25519 keypair the owner holds (never leaves the device except as ciphertext); the node_id is self-certifying — derived from the public key, so anyone can verify a node's key from its id, no PKI, no issuer. This one key signs the audit chain, registration, quorum receipts, and monorepo commits. (Built: node_identity.py.)
• One human behind each iCore. The device's node key is certified by a portable owner key you unlock with Face ID / Touch ID — the biometric only unlocks a key (you can't derive a key from a face), and the template never leaves the device. We reuse Quorumz's passkey identity core so the same owner key follows you across devices, and keep proof-of-personhood (one-human-one-iCore — the Sybil gate for earning) as an external credential (e.g. World ID) bound to the owner key, so biometrics never enter the network. Honest split: owner-binding is buildable today; global uniqueness imports outside trust. (Spec: Owner Identity & Proof-of-Personhood.)
• Registry — a shared index, never an authority. A central hinet-registry (its own resources on the Quorumz GCP footprint) keeps the global node pool: node_id → pubkey → capabilities → endpoint → membrane → liveness, each record owner-signed. Because records are signed and ids self-certify, the registry can withhold or reorder but cannot forge — which is what makes a later DHT migration tractable. A node's speciality is a competence signature derived from its consented Δ_public (never raw data), so it is routable without leaking.
• Routing — sovereign, per query. The router runs on the asker's node: it right-sizes to the minimal-sufficient quorum (§2), selects nodes by competence (membrane-aware — iCorp nodes stay hidden from the public pool), and picks the aggregation mode. The platform indexes; it never re-routes or reads answers. Three ask-modes: ask your own iCore, ask the network, or auto (decide own-vs-combined + how to combine).
• Competence is proven, not claimed. Routing is only as good as the network's knowledge of who is actually good at what — so a node can't simply declare its specialities. Each iCore discovers its own expertise while it sleeps: the consolidation clock watches which subjects genuinely densify in your private vault over time — the topics you keep writing about, gathering material on, and getting better at — and distinguishes systematic accumulation from a one-off mention (a topic must build across many months, from many sources, on a rising curve — a single forwarded article never qualifies). When a speciality passes, the iCore mints a verifiable attestation: it cryptographically commits to the corpus (a fingerprint, never the content), timestamps every night's growth so the history can't be backdated, signs it with the owner's key, and stamps it with an expiry so it decays if you stop — a speciality you abandon quietly falls out of routing on its own, and one you keep feeding strengthens. Only the coarse domain label and the cryptographic proofs ever leave the machine — never your data, never your weights. We are deliberately honest about how far today's proofs reach: the buildable-now layer makes a claim tamper-evident, non-backdatable, and disputable — it stops naked lying and self-expires stale claims — but on its own it is accountability, not proof of skill, so the router treats it as a ranking hint and never routes real money on it alone. Genuine trust is earned by stronger, staged proofs — cryptographic provenance that a body of work is really your received correspondence and authored output (not bulk-downloaded text), challenge-response evaluation that your model can actually answer in the field, hardware-attested measurement that binds those answers to your weights, and a one-human-one-iCore gate — layered on as the technology matures. Competence you can verify, decaying on the same clock that grows it. (Detail: Routing & Aggregation §2.5.)
• Aggregation — privacy-first default. MVP is committee/MoA + retrieval-union: works across different anchor DNAs, moves no weights or raw data, ~ceiling quality. MoErging (same frozen-anchor weight-merge into a bigger single model) is deferred to an attested qCore host. Contributions are metered by signed receipts on the audit chain → the §6A pay-per-use split.
• Quorum Memory — the standing-quorum cache (this is what makes it scale). Re-discovering and re-assembling a fresh quorum for every query, across the whole network, is the thing that would not scale. So the network remembers: groups of iCores that have answered a kind of question well are kept as standing quorums — a learned, persistent cache keyed by the query's competence signature. It behaves like a KV cache for composition, in three tiers:
• Cold (miss) — a genuinely novel question routes from scratch over the competence index; the resulting assembly is recorded.
• Warm (membership hit) — a matching standing quorum is reused: skip discovery, fan out to its known-good members, committee-aggregate.
• Hot (pre-merged) — a frequently-recurring same-anchor quorum is pre-merged (MoErging) into one served model during consolidation; the answer is a single forward pass — the cheapest, most scalable tier (the "keys/values" of the assembly are cached, so the composition isn't recomputed).

Standing quorums are not fixed: they grow and shrink dynamically (add a specialist when a query shows a new facet, drop members who stop contributing) and decay when unused, so the cache tracks the network's live question distribution instead of rebuilding from scratch each time. The curation happens during consolidation ("sleep") by mining the signed attribution receipts for co-activation patterns — the same clock that trains each iCore also learns which iCores belong together. This turns per-query cost from "route the whole network + run N models" into "look up the right standing quorum + a small delta + one merged pass" for the common case — the heart of working at scale. (Detail: Routing & Aggregation §2.4; the query→topic-set→quorum cache keying — same set of topics, any order, maps to the same quorum — is specified in Query Classification & Quorum Cache.) - The grand monorepo. Developer iCores contribute code to a single git-like, content-addressed monorepo on a decentralized FS (IPFS/IPLD), every commit signed by the node identity and attributable; the same economy + membrane/lease rules apply (a leased iCore's code stays with the iCorp on exit). - See the network — the intelligence map. The node pool surfaces as a layer on the Quorumz map: iCores shown geographically and grouped by domain / expertise, each badged by proof-tier so a verified specialist reads differently from a self-declared one. Location is opt-in and coarse (region/city — never your home). It reuses Quorumz's existing map + layer machinery. (Spec: Quorumz Map Integration.)

Build order (integration note): P0 local — onboarding funnel + identity + harness + dev-CLI (shipping now) → P1 registry + ask-network (committee) → P2 real signed-HTTP transport + monorepo MVP + auto routing → P3 libp2p/DHT + attested MoErging + settlement. The layer is designed so the atom — your iCore — delivers standalone value with zero network dependency, and the network is purely additive.

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

The single living build roadmap (the former Delivery-Roadmap is merged here). Atomic-first: every phase is judged by whether it makes the one iCore more capable, more yours, and more sovereign; quorumz (the network) is the horizon, not the starting line.

9. Open Research Questions & Risks

1. Does the assembly beat the best single iCore? (E1 — the make-or-break gate.)
2. FlexOlmo → Qwen3-MoE retarget for BTX (verified on OLMo-2; OLMoE is the fallback base).
3. Router quality / saturation past large N (hierarchical router-of-routers).
4. Δ_public privacy — leakage even after the gate; DP-noise vs mergeability (measured in E2).
5. Decomposability after BTX promotion (kept rare/opt-in; live qCores are decomposable).
6. Decentralized frontier RL is unsolved → heavy RL stays local.
7. Anchor drift across base upgrades (compatibility-class migration).
8. Sovereign key recovery — HiNet cannot recover lost keys; backup UX must be unavoidable.
9. Live social ingestion — ToS/legal + brittleness of the per-account feed-slice.
10. 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.)
11. 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.)
12. 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).
• Network layer (source of §6C): specs/HiNet-Node-Identity-and-Registry.md (owner-held Ed25519 identity + the central node registry + capability indexing) · specs/HiNet-Network-Routing-and-Aggregation.md (the three ask-modes + dynamic router + committee/MoErging aggregation + P2P) · specs/HiNet-Decentralized-Monorepo.md (git-like monorepo on IPFS/IPLD) · specs/HiNet-Onboarding-and-Harness.md (first-run funnel + harness + dev-tool integration) · specs/HiNet-Owner-Identity-and-Proof-of-Personhood.md (biometric-gated owner key + proof-of-personhood) · specs/HiNet-Query-Classification-and-Quorum-Cache.md (query→topic-set→quorum cache keying) · specs/HiNet-Quorumz-Map-Integration.md (the node pool as a Quorumz-map layer) · HiNet-Decentralized-Network-Integration.md (build roadmap + open decisions).
• 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.
• 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-Personalization-Engine.md — training-method spectrum (LoRA→DoRA→full-FT), depth↔composability + task-vector merging + re-basing, hardware tiers (pocket/laptop/cloud), and §6a (Soup trainer evaluated, not adopted).
• 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 (canonical Track-2 home): macOS app, the full personal-data connector inventory (local files/iCloud · Telegram/WhatsApp/Slack · Gmail/Drive/Calendar · export-dumps, incl. multi-account), the agentic (Hermes-style) layer, ingestion→vault→training-views, consent/audit/kill-switch, VaultReplication + the proprietary Δ split (Track2 §10), 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.14.2 (2026-08-24) — Evaluated Soup (Makazhan, 2026; not Wortsman Model Soups) as a nightly-training candidate: rejected as runtime, kept as inspiration for eval-gated promote/rollback + provenance-bound ship evidence. §4 + Personalization-Engine §6 + Technical Spec findings.
• 0.14.1 (2026-08-22) — Situated HiNet against agent-mesh projects (Google's SAM — Sovereign Agent Mesh): §6C gains a "not an agent-mesh" note (a mesh routes tool calls; HiNet composes minds into a bigger model + carries the economy). Routing §4.2 + the integration note add SAM as an adopt-vs-build P2P-transport candidate (ride it for transport; keep our self-certifying identity + the composition layer on top). Onboarding §B8 adds MCP interop (iCore as a first-class mesh node). Task followups (g) SAM-transport eval, (h) MCP-in-harness.
• 0.14.0 (2026-08-21) — Docs consolidation (23→20). Cut the superseded Functional-Spec; merged Personal-Data-and-Sovereignty → Track 2 (§10 VaultReplication + the proprietary split + one unified connector inventory) and Delivery-Roadmap → this whitepaper (§8 is now the single living roadmap; §5 gains the north-star UX). Resolved ~19 staleness/contradiction items (default anchor Qwen3-Next-80B / 30B = fast tier, phantom "Qwen3.6-35B" deleted, E1 PASSED, full-FT injects facts, RAG embedder e5-base + reranker deferred, one 6-tier proof enum, /v1/ endpoints, one node_id formula, did:key). Hardware tiers reconciled (tiered): pocket/edge = inference · laptop = train+infer · iCore Prime = DGX-Spark-class desk appliance* = nightly training · cloud = deepest. Whitepaper is now a pure overview/index; every topic has one canonical home (§11).
• 0.13.0 (2026-08-18) — Owner identity, the map, and the query→quorum cache — three new companion specs (grounded via parallel Quorumz-codebase + biometric-library research). Owner Identity & Proof-of-Personhood: a portable, biometric-gated owner key (reusing Quorumz's passkey/PRF core) that certifies each device node; proof-of-personhood as an external credential (World ID / BrightID) bound to the owner key — biometrics never enter the network. Owner-binding is buildable now; global one-human-one-iCore imports outside trust. Quorumz Map Integration: the node pool as a layer on the Quorumz map (geographic + by-domain/expertise), with an opt-in coarse-location privacy gate. Query Classification & Quorum Cache: the routing hot path — query → classify → order-invariant topic-set → cache → quorum (the same set of topics, any order, resolves to the same quorum), deepening §2.4.
• 0.12.0 (2026-08-18) — Competence is proven, not claimed. Replaced the self-estimated speciality strength with Verifiable Competence Attestation (§6C + Routing §2.5, new §2.1): the iCore auto-detects systematically densifying specialities during consolidation (systematic-vs-occasional test), commits + RFC3161-timestamps + signs them (an accountability base that is tamper-evident, non-backdatable, self-expiring — auditable, not yet trusted), and layers real trust via ZK provenance / decentralized eval / TEE-attested measurement + proof-of-personhood. The router consumes a derived, decaying effective_strength and pins unproven claims to ~0 payout-weight. Registry side specified in Node Identity & Registry §4.5. Designed via a 6-agent adversarial workflow (honest about buildable-now vs research).
• 0.11.1 (2026-08-18) — Quorum Memory added to §6C — the standing-quorum cache that makes routing scale: a KV cache for composition (cold/warm/hot tiers) that remembers which iCores compose well for which kinds of question, warm-starting from a learned, decaying, grow/shrink cache instead of re-routing the whole network per query; curated during consolidation from signed attribution receipts. Formally specified in Routing & Aggregation §2.4.
• 0.11.0 (2026-08-18) — §6C The Network Layer added — how iCores find/verify/route/pay each other: owner-held Ed25519 identity (self-certifying node_id, built as node_identity.py), a central hinet-registry (own GCP resources) as a signed index (not an authority), a sovereign per-query router (three ask-modes; membrane-aware right-sizing), committee/MoA + retrieval-union as the privacy-first aggregation default (MoErging deferred), and a decentralized grand monorepo (IPFS/IPLD, signed contributions). Four new companion specs + an integration note (phased P0→P3 roadmap + open decisions) added to §11. Also shipped this release: the first-run onboarding funnel (RAM-adaptive model + progress/retry + node naming + identity), RAM-adaptive model selection, download-at-first-run prefetch, the standalone dev-agent (P-A v1), and a landing design pass. Added a Last release date to the header.
• 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.

Next: The vision — iCore · iQuorum · iCorp →  ·  All documentation →