Documentation  /  Fractal Intelligence (origin paper)

HiNet Fractal Intelligence Whitepaper

Origin paper (2026-05, first draft). Superseded where it conflicts with the current Whitepaper (v0.13.0); kept for the founding concept. Model/training specifics below are origin-era.

Status: First Draft

Scope: This draft concentrates only on HiNet's first research point: holographic fractal training and inference. It does not cover the aCore agent execution layer, SSV-like verification, token economics, or full governance design except where they touch iCore and qCore training/inference.

Abstract

HiNet proposes a human-owned intelligence network built from atomic intelligence cores, or iCores. Each iCore is controlled by a human owner, learns from that owner's consented data, and can operate independently as a local intelligence nucleus. The network's long-term research goal is fractal intelligence: an iCore should remain useful alone, while dynamic collections of iCores should assemble into quorum intelligence cores, or qCores, without collapsing into a centralized model that owns the humans' data, weights, or learned preferences.

This whitepaper frames fractal intelligence as a concrete research and engineering program. The central technical question is not merely whether many agents can vote on answers. It is whether humans can start from open models, separate egoistic local learning from communal network learning, standardize consented data into reusable iCore learning objects, perform recurring sleep-cycle consolidation, and then entrain many separately evolving iCores into larger qCore intelligence through shared base models, compatible adapters, federated learning, model merging, distillation, retrieval, routing, and network-level consolidation phases.

The first practical target is not a fully decentralized foundation model. It is a basic user node that makes the future research testable: local identity, user-owned memory, consented data ingestion, standardized learning records, PEFT-style adapters, nightly consolidation, local inference, evaluation gates, audit logs, and simulated qCore participation.

1. Problem Statement

Modern AI has concentrated intelligence in large models trained and served by centralized institutions. These systems can be powerful, but they invert the relationship between humans and intelligence infrastructure:

1. Human data is gathered into external systems.
2. Learned model weights are owned by centralized operators.
3. User preferences become product signals rather than user-owned intelligence.
4. Inference access is rented back to users through remote APIs.
5. Collective intelligence emerges inside institutions, not among the people who generated the underlying data.

HiNet starts from the opposite claim: not your weights, not your intelligence.

The network should treat each human as the owner of an atomic intelligence nucleus. That nucleus should learn locally, preserve attribution to the human owner, and participate in larger intelligence structures only by consent.

The central research problem is:

Can a decentralized network of human-owned iCores train and infer in a way that preserves local ownership while allowing dynamic, useful, larger-scale intelligence to emerge?

2. Definitions

iCore

An iCore is the atomic intelligence core owned by one human or explicitly defined human quorum. In early implementations, an iCore may be a local node composed of:

1. Persistent identity.
2. Consent policy.
3. Local data vault.
4. Memory records and embeddings.
5. Preference state.
6. Local summaries and learned artifacts.
7. Model adapters or fine-tuned modules.
8. Local inference and consolidation runtime.
9. Training and evaluation history.

The iCore is not required to begin as a full standalone foundation model. It must, however, be useful and attributable on its own.

qCore

A qCore is a quorum intelligence core. It is a composition of multiple consenting iCores acting as a larger reasoning system, model committee, routed expert set, federated retrieval network, adapter federation, or distributed model path.

Fractal Intelligence

Fractal intelligence means useful intelligence exists at multiple scales:

1. One iCore can operate alone.
2. A small qCore can act as a larger intelligence.
3. A community qCore can coordinate smaller qCores.
4. A network-level qCore can emerge from many compatible substructures.

This is a design target, not a solved claim.

Holographic Inference

Holographic inference means that when a qCore is decomposed, its parts are still meaningful intelligence units. The network should not be a pile of passive shards that only work when a central operator assembles them. Each iCore should remain a useful local mind-fragment owned by a human.

Fractal Training

Fractal training means learning processes repeat across scales:

1. An iCore learns from its owner's local data and feedback.
2. A qCore learns from the behavior and contributions of participating iCores.
3. Communities form higher-order qCores whose learning is built from smaller qCore histories.
4. Each level preserves provenance, consent, attribution, and reversibility where possible.

3. Core Thesis

Atomic ownership without composition produces private assistants that cannot become a network. Composition without atomic ownership recreates centralized AI under a decentralized aesthetic. HiNet requires both:

1. Every iCore must be owned and controlled at the edge.
2. Every qCore must be assembled from consented iCore participation.
3. Every training and inference contribution must be attributable.
4. The network must define protocols for data standardization, local training, sleep-cycle consolidation, routing, aggregation, and network-level entrainment.
5. The whole must become more capable without consuming the parts.

Biological Design Lesson: Shared DNA, Local Phenotype, Collective Activation

The stronger biological analogy suggests a more precise architecture than a loose network of arbitrary personal models.

In bacterial quorum sensing, cells do not appear to run a mutual training session every time they coordinate. A quorum response emerges because cells share a species-level genetic substrate and communication circuit: they produce signals, sense signal concentration, cross activation thresholds, and alter gene expression through regulatory pathways. Individual cells still differ. They live in different local microenvironments, express genes heterogeneously, and may contribute unequally to autoinducer production or target behavior. But the communal behavior is possible because each cell carries compatible "communal DNA" for sensing, signaling, and responding.

For HiNet, the equivalent is:

1. Shared DNA: a base model, tokenizer, chat template, adapter contract, data schema, consent vocabulary, qCore signaling protocol, and evaluation suite.
2. Communal genotype: shared or network-evolved weights, adapters, routers, and protocols that belong to a compatibility class or qCore lineage.
3. Local phenotype: each iCore's private memory, preferences, local adapters, replay buffer, owner feedback, and environment-specific learning.
4. Autoinducers: qCore requests, task embeddings, capability announcements, contribution receipts, router scores, and threshold signals.
5. Gene regulation: policy-gated activation of local tools, memories, adapters, communal adapters, and qCore participation modes.
6. Quorum behavior: temporary activation of compatible iCores into a larger qCore when task conditions cross a threshold.

This implies that a HiNet compatibility class should begin from shared DNA. That does not mean every human must use the same model forever. It means that every iCore participating in a weight-compatible qCore lineage should start from the same base substrate, then evolve locally. Different species can exist, but cross-species composition should happen through output-level protocols, distillation, translation, or committee inference rather than direct weight merging.

The octopus analogy points in the same direction but at a different scale. Octopus arms are semi-autonomous; much of the nervous system is in the arms, each arm has local sensory-motor processing, suckers and arm segments can act locally, and arms communicate through peripheral pathways such as the interbrachial commissure as well as through hierarchical brain control. The octopus does not need a new communal training session every time two or three arms coordinate. Coordination is enabled by a shared evolved body plan, repeated local control modules, arm-to-arm communication pathways, central modulation, and lifetime learning.

For HiNet, the octopus suggests:

1. Each iCore should be locally competent, like an arm with its own nervous system.
2. qCore coordination should use low-bandwidth shared commands and local autonomy, not micromanagement by a central brain.
3. Multiple iCores can combine for a task through compatible interfaces and routing, not necessarily through immediate shared retraining.
4. Larger network consolidation is still useful, but it is more like evolution, development, or long-term learning of the communal substrate than the mechanism needed for every coordinated action.

The design conclusion is that HiNet needs two learning clocks:

1. Fast local clock: each iCore evolves continuously through owner-specific sleep cycles.
2. Slow communal clock: compatibility classes periodically update their shared DNA through network epochs, benchmarks, protocol changes, distilled public datasets, router improvements, and carefully promoted base/adaptor releases.

Immediate qCore intelligence should come from shared DNA plus local phenotype plus communication. Network consolidation should improve the species over time; it should not be required every time the hive mind forms.

The key HiNet addition is that each iCore must contain both egoistic and communal learning systems. The egoistic system is the owner's proprietary local intelligence: private data, private memory, private preferences, and private adapters. The communal system is the part of the iCore that remains compatible with the larger network: shared base model lineage, communal adapters, qCore routers, protocol skills, public or permissioned distilled knowledge, and evaluation behavior. These are not two sealed boxes. They form a spectrum, because some knowledge is purely personal, some is broadly communal, and much of intelligence sits between them: family, company, city, country, language, profession, research field, or temporary task quorum.

4. The Base Model Question

The first concrete question is whether all humans need to start from the same open model.

The answer depends on the kind of composition the network wants.

4.1 Heterogeneous Inference Can Start Immediately

For committee inference, federated retrieval, debate, ranking, and judgment, iCores do not need the same base model. One iCore can use Qwen, another Llama-family weights, another Mistral, another Gemma, another local embedding model, and another remote model allowed by policy.

This works because the qCore composes outputs, not weights.

Heterogeneous inference is the best first qCore path because:

1. It respects different hardware.
2. It allows users to choose models by license, language, domain, or performance.
3. It does not require every node to share architecture or tokenizer.
4. It can start with local memory, retrieval, and answer synthesis.

4.2 Weight-Level Entrainment Requires Compatibility

If HiNet wants iCore training updates to combine directly, then compatibility matters.

Direct adapter aggregation or model merging usually requires the same:

1. Base model identity.
2. Architecture.
3. Tokenizer or chat template.
4. Adapter type.
5. Adapter target modules.
6. Rank or a defined heterogeneous-rank aggregation method.
7. Training objective.
8. Data schema.
9. Evaluation protocol.

Without these, updates can be translated only indirectly through distillation, routing, or output-level learning.

4.3 Recommended Model Strategy

HiNet should not force every human to use one universal model forever. It should define compatibility classes that behave like species or lineages.

A compatibility class is a model lineage that can share or merge learning artifacts.

Example:

compatibility_class:
  base_model_id: "Qwen/Qwen2.5-3B-Instruct"
  base_model_hash: "..."
  tokenizer_hash: "..."
  chat_template_hash: "..."
  adapter_type: "LoRA"
  adapter_target_modules: ["q_proj", "v_proj"]
  adapter_rank_policy: "rank_16_default"
  training_objectives: ["SFT", "DPO", "replay_consolidation"]
  evaluation_suite: "hinet_icore_eval_v0"

[SUPERSEDED — origin-era example.] The current anchor is Qwen3-Next-80B-A3B (MoE), and MoE is now a hard compatibility filter (only MoE composes into a bigger single model; a dense base is excluded from the mergeable spine), so this dense Qwen2.5-3B example no longer reflects the chosen base. See Whitepaper §2 and Foundational-Model-Plan §2.

The network can then support:

1. Same-class iCores: eligible for adapter aggregation and direct qCore consolidation.
2. Related-class iCores: eligible for distillation or translated adapter experiments.
3. Different-class iCores: eligible for committee inference, federated retrieval, and output-level entrainment.

The default recommendation is:

1. For personal/local iCore usage, allow heterogeneous model choice.
2. For qCore committee inference, allow heterogeneous model choice.
3. For qCore weight entrainment, require a shared model passport.
4. For a true fractal intelligence lineage, start participants from the same base model DNA and let each iCore evolve locally through adapters and memory.
5. For cross-lineage learning, use distillation, router learning, and output-level protocols rather than direct weight aggregation.

4.4 Practical Open Model Starting Points

The first experiments should use small-to-medium open-weight models available through Hugging Face. Selection criteria:

1. Runs on consumer hardware, ideally 3B to 8B for early work. [SUPERSEDED — origin-era: the current anchor is Qwen3-Next-80B-A3B MoE, and MoE is a hard selection filter, so a dense 3B–8B base is a starting example only, not the chosen composable base.]
2. Has a stable instruct/chat template.
3. Supports PEFT/LoRA/QLoRA workflows.
4. Has a license compatible with HiNet's intended usage.
5. Has strong multilingual and reasoning baselines where possible.
6. Has active ecosystem support in Transformers, PEFT, TRL, Axolotl, Unsloth, llama.cpp, Ollama, or vLLM.

Possible early model families to evaluate:

1. Qwen instruct models.
2. Llama-family instruct models, subject to license review.
3. Mistral-family instruct models, subject to license review.
4. Gemma-family instruct models, subject to license review.
5. Phi-family small models, subject to license and capability review.

The whitepaper should not bless one model until benchmarks are run. The technical requirement is a model passport, not one sacred base model.

5. iCore Data Standardization

The second concrete question is how to standardize data that the human decides to share into their own iCore.

HiNet should separate raw data from learning objects.

Raw user data is messy, private, and source-specific. iCore learning objects are normalized, consent-scoped, auditable records derived from raw data.

5.1 Data Pipeline

flowchart TD
    RawSource[Raw User Source] --> Consent[Consent Grant]
    Consent --> Extract[Extract And Normalize]
    Extract --> Memory[Memory Record]
    Extract --> Fact[Fact Record]
    Extract --> Conversation[Conversation Record]
    Extract --> Preference[Preference Record]
    Memory --> TrainingSet[Training View]
    Fact --> TrainingSet
    Conversation --> TrainingSet
    Preference --> TrainingSet
    TrainingSet --> SleepCycle[Sleep-Cycle Training]
    SleepCycle --> Adapter[iCore Adapter]
    SleepCycle --> Eval[Evaluation Gate]

5.2 Core Record Types

HiNet should define an iCore Data Standard with at least these record types.

SourceRecord

Represents the origin of data.

source_id: "src_..."
owner_node_id: "icore_..."
source_type: "file | chat | email | browser | drive | manual_note | app_event"
source_uri: "local-or-redacted"
source_hash: "..."
consent_grant_id: "grant_..."
created_at: "..."

MemoryRecord

Represents searchable memory.

memory_id: "mem_..."
source_id: "src_..."
content: "normalized text"
summary: "optional"
sensitivity: "private_local | private_share_summary | public"
embedding_ref: "vec_..."
provenance:
  extractor: "..."
  consent_grant_id: "grant_..."

FactRecord

Represents a candidate stable fact about the user, world, project, relationship, or preference.

fact_id: "fact_..."
claim: "The user prefers concise engineering updates."
subject: "owner | project | contact | domain | world"
confidence: 0.82
evidence_memory_ids: ["mem_..."]
valid_from: "..."
valid_until: null
contradicts: []

ConversationRecord

Represents interaction data in chat/instruction format.

{
  "messages": [
    {"role": "system", "content": "You are the owner's local iCore."},
    {"role": "user", "content": "Summarize my notes on HiNet."},
    {"role": "assistant", "content": "The notes describe..."}
  ],
  "metadata": {
    "source_id": "src_...",
    "consent_grant_id": "grant_...",
    "sensitivity": "private_local"
  }
}

This aligns with common SFT chat data formats used in modern fine-tuning tooling.

PreferenceRecord

Represents a human preference for DPO-style alignment.

{
  "prompt": [{"role": "user", "content": "Explain qCore entrainment."}],
  "chosen": [{"role": "assistant", "content": "A qCore entrains by..."}],
  "rejected": [{"role": "assistant", "content": "It is just a blockchain..."}],
  "metadata": {
    "preference_source": "explicit_user_choice",
    "consent_grant_id": "grant_..."
  }
}

ReplayRecord

Represents data selected for memory replay during sleep cycles.

replay_id: "replay_..."
record_ref: "fact_... | conversation_... | preference_..."
priority: 0.91
selection_reason: "surprising | important | frequently_used | recently_changed | weak_recall"
last_replayed_at: "..."
replay_count: 3

5.3 Training Views

The iCore should not train directly on the raw vault. It should train on generated views:

1. SFT view: instruction-response or chat messages.
2. DPO view: prompt, chosen, rejected.
3. Fact recall view: question-answer pairs derived from stable facts.
4. Style view: examples of preferred tone and response structure.
5. Reflection view: summaries of the owner's projects, values, and recurring decisions.
6. Replay view: selected prior examples to prevent forgetting.

Each training view must preserve:

1. Consent grant ID.
2. Source provenance.
3. Sensitivity class.
4. Expiration or revocation behavior.
5. Whether the view can leave the node.

5A. Literature Review And Scientific Grounding

The HiNet fractal intelligence proposal is speculative as a complete system, but its core pieces map to existing scientific and engineering literatures. The novelty is not that any one component is invented from zero; it is the attempt to combine these components into a human-owned, multi-scale intelligence architecture.

5A.1 Personalized Federated Learning: Global And Local Parameters

The dual egoistic/communal weight model is strongly related to personalized federated learning. Classic federated learning tries to train one global model over distributed clients without moving raw data. Personalized federated learning emerged because one global model is often suboptimal when client data is non-IID, user-specific, or locally contextual.

Several personalized FL families are relevant:

1. Shared representation plus local head: FedRep learns a shared representation across clients while keeping personalized local heads. This maps naturally to HiNet's communal substrate plus egoistic local adaptation.
2. Global model plus local personalization: methods such as FedPer, FedBABU, and related approaches split shared and personalized components so clients benefit from common structure while adapting to local data.
3. Local memorization over shared representations: personalized FL through local kNN/memorization combines a collectively trained representation with local memory, which resembles HiNet's retrieval-first local memory over a shared model passport.
4. Personalized aggregation: methods such as FedFomo/FedALA-style approaches combine global and local information differently per client, matching the idea that each iCore may weight communal and local layers differently.

Design implication for HiNet:

1. The egoistic/communal split is not only philosophical; it matches an established ML response to non-IID client data.
2. iCores should not collapse into one global model.
3. The default architecture should be shared substrate + local adapters/memory + personalized routing.
4. Direct aggregation should be treated carefully because client heterogeneity is the norm, not an edge case.

5A.2 Federated Multi-Task Learning: Related But Distinct Local Minds

Federated multi-task learning frames distributed clients as separate but related tasks rather than replicas of one global task. MOCHA and later federated MTL work argue that learning separate related models can outperform both fully local and fully global training under heterogeneous data.

This is close to HiNet's iCore premise: each user is not merely a data shard of one task. Each user is a distinct local learning problem with its own environment, values, habits, domain, and goals. qCores then become multi-task compositions across related iCores.

Design implication for HiNet:

1. Treat iCores as related tasks, not interchangeable workers.
2. Country qCores, domain qCores, and team qCores can be modeled as task clusters.
3. The right qCore may be the one whose participants are related enough to share signal but diverse enough to add value.
4. Spectrum routing can be interpreted as selecting the relevant task cluster for the question.

5A.3 Hierarchical Federated Learning: Multi-Scale Aggregation

Hierarchical federated learning studies device-edge-cloud and multi-tier aggregation. Instead of every device aggregating directly into one global server, clients first aggregate at intermediate tiers such as edge nodes, regions, organizations, or clusters. Surveys of FL for edge AI describe this as matching the learning architecture to the physical and statistical hierarchy of real networks.

This supports the HiNet claim that intelligence should exist at many scales:

1. Device/iCore level.
2. Pair/team/company qCore level.
3. City/country/language/domain qCore level.
4. Global compatibility-class level.
5. Grand-network level.

Design implication for HiNet:

1. qCore hierarchy is not arbitrary; it mirrors hierarchical FL and edge AI aggregation patterns.
2. Country qCore or domain qCore consolidation can happen faster than global consolidation.
3. Network epochs should be multi-timescale: local sleeps often, qCore epochs periodically, global epochs rarely.
4. The architecture should support tree, DAG, and overlapping-cluster qCores rather than one star topology.

5A.4 Federated LoRA And PEFT: Efficient Shared/Personal Adaptation

Recent federated fine-tuning and FedLoRA work studies how LoRA/PEFT methods can adapt foundation models across distributed clients. The literature highlights both promise and pitfalls:

1. LoRA reduces communication and computation by training low-rank adapter matrices rather than all model weights.
2. Personalized LoRA and dual-adapter methods explicitly separate shared/global adaptation from client-specific adaptation.
3. Naive FedAvg over LoRA can be mathematically or empirically suboptimal because LoRA factorization creates aggregation mismatch.
4. Heterogeneous ranks and heterogeneous client hardware require special aggregation or adapter design.

Design implication for HiNet:

1. Local iCore sleep cycles should prefer PEFT/LoRA/QLoRA over full fine-tuning.
2. Same-class qCore weight entrainment should use model passports and adapter contracts.
3. Dual adapters are a strong candidate: one personal adapter and one communal adapter.
4. Aggregation must be evaluation-gated and may require FedLoRA-specific methods rather than naive averaging.

5A.5 Mixture-of-Experts, Modular Learning, And MoErging

Mixture-of-Experts literature shows how large models can route inputs to sparse expert subsets, increasing capacity without activating every parameter. Surveys emphasize gating/routing, load balancing, expert specialization, hierarchical MoE, and continual-learning benefits from modularity.

MoErging and model-merging literature is especially relevant because it studies independently trained expert models or adapters that are later routed, merged, or combined. This is closer to HiNet than classic MoE, because HiNet experts are independently trained iCores, not centrally trained FFN experts inside one model.

Design implication for HiNet:

1. qCore routing is a decentralized MoE-like router over human-owned experts.
2. The router may be more important than weight merging in early versions.
3. Adapter ensemble and adapter merging can create communal qCore artifacts, but interference is a serious risk.
4. Hierarchical MoE maps naturally to qCore-of-qCores: personal experts, country/domain experts, and global experts.

5A.6 Complementary Learning Systems And Replay: Sleep-Cycle Consolidation

Complementary Learning Systems theory argues that mammalian learning uses complementary fast and slow systems: hippocampal-like rapid episodic learning and neocortical-like gradual structured learning. Replay during sleep/rest supports gradual integration of new experiences while reducing catastrophic forgetting. Continual-learning literature similarly uses replay, generative replay, hidden-state replay, slow/fast weights, and regularization to balance plasticity and stability.

This grounds the iCore sleep cycle:

1. Wake phase records recent experience and feedback.
2. Sleep phase curates replay and training views.
3. Fast local memory captures new information immediately.
4. Slow adapters consolidate stable preferences and behavior.
5. Evaluation gates prevent catastrophic forgetting.

Design implication for HiNet:

1. The iCore should not train continuously during active use.
2. It should maintain fast memory and slower weight/adaptor consolidation.
3. Replay buffers are central, not optional.
4. Sleep cycles should interleave new owner data with prior important examples.

5A.7 Bacterial Quorum Sensing: Shared Protocol With Heterogeneous Expression

Quorum sensing literature describes cell-cell communication through autoinducers, receptors, regulatory networks, and threshold-triggered gene expression. Bacteria can coordinate group behavior without a fresh communal training phase at every action. However, modern work also emphasizes that quorum sensing is not always perfectly homogeneous: isogenic cells can differ in signal production and response, and environmental factors modulate the fraction of contributing cells.

This maps closely to HiNet:

1. Shared DNA: base model, protocol, signal grammar.
2. Local heterogeneity: local environment, local memory, local adapters.
3. Autoinducers: qCore task signals and capability signals.
4. Threshold response: qCore activation when task scope, density, relevance, and confidence cross a threshold.
5. Heterogeneous contribution: not every iCore contributes equally to every qCore.

Design implication for HiNet:

1. qCore formation should be an activation event, not always a training event.
2. Shared compatibility-class DNA matters for coherent activation.
3. Heterogeneous local behavior is a feature, not a bug.
4. The router should expect partial participation and division of labor.

5A.8 Octopus Distributed Control: Local Autonomy Plus Shared Coordination

Octopus neuroscience shows a highly distributed nervous system. A large fraction of neurons are in the arms; axial nerve cords, sucker ganglia, intramuscular nerve cords, and segmented arm structures support local sensory-motor processing. Arms communicate with the brain and with each other through structures such as the interbrachial commissure. Reviews describe a hierarchical arrangement: lower motor centers in the arms, intermediate centers in suboesophageal regions, and higher centers in the supraesophageal brain.

This supports a HiNet architecture where:

1. Each iCore is locally competent.
2. qCore coordination uses local autonomy rather than central micromanagement.
3. Higher-level qCores can set goals or route tasks without controlling every local computation.
4. Multiple iCores can form task-specific coalitions like multiple arms coordinating for locomotion or manipulation.

Design implication for HiNet:

1. The qCore router should issue compact task signals, not full execution scripts.
2. Local iCores should decide how to use their private memory and tools.
3. qCore aggregation should respect local autonomy.
4. A distributed nervous system can have hierarchy without becoming fully centralized.

5A.9 Collective Intelligence Across Biological Scales

Recent collective-intelligence biology argues that there is no sharp boundary between centralized brains and collective minds. Biology uses multi-scale architectures from molecular networks to cells, tissues, organs, organisms, and swarms. Each level can solve problems in its own state space while participating in higher-order problem solving.

This is the strongest scientific analogy for HiNet's spectrum model:

1. Personal iCore: one local agent.
2. Team/company/country/domain qCore: intermediate collective.
3. Grand network: upper-scale collective.
4. No absolute line between individual and communal intelligence.

Design implication for HiNet:

1. Fractal intelligence should be measured by whether each scale can solve useful problems in its own scope.
2. The network should support many overlapping collectives, not one global mind.
3. Higher-order intelligence should emerge through interaction dynamics, not by erasing lower-order agents.

6. What Actually Gets Trained

[OVERTURNED by E1 — see Whitepaper §7–§8 and HiNet-E1-Experiment-Design.] The "LoRA-first / defer full fine-tuning" premise of this section is origin-era. E1 showed bf16 full fine-tuning DOES inject facts (recall 0.27 → 0.97) and that a full-FT task-vector merge beats the best single member (0.667 > 0.556). The current engine uses a depth spectrum up to full fine-tuning (see Personalization-Engine), not LoRA only; facts compose by retrieval-union and weight-injection, and are no longer kept out of weights by rule.

The first iCore should not full-fine-tune a large model on every user's laptop. That is expensive, risky, and hard to compose.

The practical first training target is parameter-efficient adaptation.

6.0 The Dual Weight System

Each iCore should contain two distinct but interoperable learning systems.

Egoistic Local Weights

Egoistic local weights are the proprietary user model. They encode the user's private environment.

Examples:

1. Private memory-derived adapters.
2. Owner-specific preference adapters.
3. Personal writing style and workflow habits.
4. Private facts and project context that should not become communal.
5. Local retrieval index and summaries.
6. User-specific router preferences.

Properties:

1. Owned by the user.
2. Stored locally by default.
3. Trained during personal sleep cycles.
4. Revocable, exportable, and deletable by the owner.
5. Not directly aggregated into communal weights unless the owner explicitly consents and privacy checks pass.

Communal Weights

Communal weights are the part of the iCore that stays aligned with the network's shared intelligence substrate.

Examples:

1. Base model weights for a compatibility class.
2. Community or domain LoRA adapters.
3. Country qCore adapters.
4. Language qCore adapters.
5. Profession or research-domain adapters.
6. qCore routers and capability embeddings.
7. Public distilled examples and benchmark traces.

Properties:

1. Evolved by qCore or network epochs.
2. Shared by a compatibility class, domain, or community.
3. Promoted only after evaluation.
4. Versioned and attributable.
5. Loaded by an iCore as part of its communal substrate.

The Spectrum Between Egoistic And Communal

The fractal part is that there is no absolute line between local and communal intelligence. There is a spectrum:

1. Personal: only this user.
2. Pairwise: two users or iCores.
3. Household/team/company: a small trusted group.
4. City/region/country: a geopolitical or cultural qCore.
5. Language/profession/domain: a functional qCore.
6. Global compatibility class: all iCores sharing a base model lineage.
7. Grand network: all reachable and consenting iCores.

Each point on the spectrum can have its own qCore, router, memory policy, adapter set, evaluation suite, and consent boundary.

This means an iCore is not one model. It is a stack of model layers and retrieval layers:

icore_model_stack:
  base_dna:
    model: "shared compatibility-class base model"
    tokenizer: "shared"
    chat_template: "shared"
  communal_layers:
    global_adapter: "optional"
    language_adapter: "optional"
    country_adapter: "optional"
    domain_adapter: "optional"
    qcore_router: "shared or community-specific"
  local_layers:
    private_memory_index: "local"
    private_preference_adapter: "local"
    private_style_adapter: "local"
    private_project_adapters: "local"
  policy:
    consent_grants: "decide which layers activate for which task"

The inference engine should dynamically choose where on this spectrum a question belongs.

6.1 Recommended Local Training Artifacts

An iCore should maintain multiple artifacts rather than one monolithic set of weights:

1. Retrieval memory: vector index and source-grounded summaries.
2. Preference profile: explicit settings and learned response preferences.
3. Prompt profile: system prompt fragments and routing instructions.
4. LoRA or QLoRA adapter: trainable low-rank weights over a frozen base model.
5. Evaluation suite: owner-specific and network-standard tests.
6. Replay buffer: examples retained for future consolidation.
7. Model passport: base model, tokenizer, adapter, data schema, and training metadata.

6.2 Why LoRA/QLoRA First

PEFT methods such as LoRA and QLoRA are the best first fit because:

1. They train a small number of parameters.
2. They can run on smaller hardware than full fine-tuning.
3. They are supported by Hugging Face PEFT and common training frameworks.
4. Adapters are portable and versionable.
5. Adapters can sometimes be merged, stacked, routed, or federated.
6. The base model can remain frozen, reducing catastrophic drift.

6.3 Training Objectives

The iCore should use different objectives for different kinds of learning.

Retrieval First

[OVERTURNED by E1.] "Facts should not be trained into weights at all" is origin-era. E1 showed bf16 full fine-tuning injects facts (recall 0.27 → 0.97); the current model is a hybrid — facts compose by retrieval-union and can be injected into weights — not retrieval-only.

Many user-specific facts should not be trained into weights at all. They should remain in memory and be retrieved at inference time.

Use retrieval when:

1. The fact changes often.
2. The content is sensitive.
3. The user may revoke it.
4. Exact source grounding matters.

SFT For Stable Behavior

Supervised fine-tuning should be used for stable response patterns:

1. How the owner likes summaries.
2. How the owner writes.
3. How the owner structures project analysis.
4. Repeated workflows.
5. Domain-specific instruction following.

DPO For Preferences

Direct Preference Optimization or similar preference tuning should be used when the owner chooses one answer over another.

Use preference training for:

1. Tone.
2. Brevity.
3. Risk tolerance.
4. Formatting.
5. Decision style.
6. Values and trade-offs, with caution.

Replay For Retention

Replay prevents new sleep-cycle training from overwriting old behavior. Replay examples should be selected by importance, surprise, recency, weak recall, and owner pinning.

7. The iCore Sleep Cycle

The user's intuition is right: the iCore should have a sleep cycle. It should not constantly retrain while the human is actively using the machine.

7.1 Wake Phase

During wake phase, the iCore:

1. Answers queries.
2. Searches memory.
3. Logs interactions.
4. Collects explicit feedback.
5. Detects candidate facts and preferences.
6. Adds records to the replay buffer.
7. Avoids heavy training.

7.2 Sleep Trigger

Sleep can be triggered when:

1. The computer is idle.
2. The laptop is charging.
3. Thermal and battery conditions are acceptable.
4. The owner-defined time window is active.
5. A minimum amount of new learning material exists.
6. The user triggers it manually.

7.3 Sleep Cycle Stages

flowchart TD
    Start[Sleep Trigger] --> Snapshot[Snapshot Current iCore]
    Snapshot --> Curate[Curate Training Views]
    Curate --> Replay[Select Replay Buffer]
    Replay --> Train[Train Adapter Or Memory Artifact]
    Train --> Eval[Run Evaluation Gate]
    Eval --> Pass{Pass?}
    Pass -->|Yes| Promote[Promote New iCore Version]
    Pass -->|No| Rollback[Rollback And Keep Diagnostics]
    Promote --> Audit[Write Audit Event]
    Rollback --> Audit

7.4 Evaluation Gate

Every sleep cycle must pass evaluation before promotion.

Evaluation should include:

1. Owner-specific recall.
2. General instruction following.
3. Safety and refusal behavior.
4. Regression tests from prior sleep cycles.
5. Privacy leakage checks.
6. Format compliance.
7. Small qCore compatibility tests, if enabled.

If the adapter fails, it is not promoted. The iCore keeps the previous version and records diagnostics.

7.5 Fast And Slow Learning

The iCore should distinguish fast memory from slow weight updates.

Fast memory:

1. New facts.
2. Recent conversations.
3. Project notes.
4. Searchable records.

Slow learning:

1. Stable preferences.
2. Repeated workflows.
3. Durable style.
4. Domain expertise.

This mirrors continual learning findings: replay and slow consolidation reduce catastrophic forgetting. A practical design is dual adapters:

1. Fast adapter: trained often, easy to roll back.
2. Slow adapter: updated less often through validated consolidation.

The slow adapter can be an exponential moving average or periodic merge of validated fast adapters.

8. Entrainment Between iCores

The hardest question is whether independently trained iCores automatically create a larger mind as a network effect.

The answer is: not automatically.

Multiple iCores can create useful qCore behavior through inference-time composition immediately, but durable network-level intelligence requires explicit entrainment protocols.

The biological analogy sharpens this point: bacteria and octopus arms do not coordinate because they freshly co-train at the moment of action. They coordinate because they share enough substrate and signaling architecture before the moment of action. HiNet should therefore treat entrainment as substrate compatibility plus repeated interaction, not only as periodic weight aggregation.

8.1 Three Kinds Of Entrainment

Interface Entrainment

iCores share schemas, message formats, consent classes, capability profiles, and evaluation protocols.

This is mandatory and should happen first.

This is the analogue of shared receptor/signal grammar. Without it, iCores cannot reliably know what another iCore is asking, offering, refusing, or promising.

Behavioral Entrainment

iCores learn to cooperate through qCore inference sessions, feedback, routing, and response synthesis.

This can happen without merging weights.

This is the analogue of coordinated gene expression or arm-to-arm coordination. The iCores activate compatible behaviors in response to shared signals and local state.

Weight Entrainment

iCores share or aggregate trainable artifacts such as LoRA adapters, prompt vectors, router updates, or distilled synthetic datasets.

This requires compatibility classes and stronger privacy controls.

This is the analogue of slower species-level adaptation. It should happen through network epochs, not as a prerequisite for every qCore session.

8.2 Does Local iCore Training Automatically Create qCore Intelligence?

Local iCore training creates better atoms. Better atoms improve qCore potential, but they do not by themselves create a larger mind.

For larger intelligence, HiNet also needs:

1. Discovery: find relevant iCores.
2. Routing: choose the right contributors.
3. Protocols: define what each iCore contributes.
4. Aggregation: combine contributions into outputs.
5. Feedback: score outputs and update routing.
6. Consolidation: preserve successful qCore patterns.
7. Evaluation: verify qCore improvement.

Without these, the network is a collection of personalized assistants. With them, it can become a learning network.

The important nuance is that a qCore can form without a new communal training phase if the participating iCores already share compatible DNA and signaling. In that case, qCore formation is an activation and routing event. Communal training is needed later to improve the shared DNA, router, and qCore patterns.

8.3 Network Consolidation Phases

HiNet should have larger consolidation phases beyond individual sleep.

Recommended phases:

1. Personal sleep: one iCore consolidates its own learning.
2. Pairwise entrainment: two iCores compare outputs or exchange safe summaries for a shared task.
3. qCore session consolidation: a temporary qCore records what worked after an inference session.
4. qCore epoch consolidation: a stable qCore periodically updates its router, shared evaluation set, adapter set, or distilled public artifact.
5. Network epoch consolidation: compatibility-class participants aggregate or benchmark shared artifacts.

Network consolidation should never require raw private data. It should work through:

1. Adapter updates.
2. Safe summaries.
3. Evaluation results.
4. Distilled examples.
5. Router metrics.
6. Contribution receipts.
7. Secure aggregation where possible.

This means qCore intelligence has two modes:

1. Runtime quorum activation: no new training required; compatible iCores coordinate through shared protocols.
2. Evolutionary consolidation: slower network learning updates the shared substrate, routers, adapters, benchmarks, and protocols.

The first makes the network useful now. The second makes the network improve across generations.

9. qCore Training Mechanisms

9.1 Output-Level Distillation

The safest first method is output-level distillation.

Flow:

1. Multiple iCores answer a task.
2. qCore synthesizes or selects a strong answer.
3. The answer becomes a training example for a qCore artifact if policy allows.
4. Individual iCores may optionally learn from the distilled answer during sleep.

This works across different base models because it trains from text outputs, not weight deltas.

9.2 Federated LoRA

For compatible iCores, LoRA updates can be aggregated.

Problems:

1. Naive FedAvg over LoRA can be suboptimal.
2. Non-IID human data creates drift.
3. Different hardware may need different LoRA ranks.
4. Updates can leak information.
5. Malicious updates can poison the qCore.

Possible mitigations:

1. Dual-LoRA: one global adapter and one personal adapter.
2. Personalized LoRA: keep client-specific parameters local.
3. Selective aggregation: aggregate only compatible matrices or subspaces.
4. Secure aggregation and differential privacy.
5. Contribution filtering and robust aggregation.
6. Evaluation-gated promotion.

9.3 Adapter Merging

Adapters can sometimes be merged using methods such as linear merging, TIES, DARE, or task arithmetic.

Use cases:

1. Merge several domain adapters into a qCore adapter.
2. Merge a fast adapter into a slow adapter.
3. Create community adapters from consenting iCores.

Risk:

Adapter merging can cause interference. The qCore should treat merges as experimental artifacts that must pass evaluation before promotion.

9.4 Router Learning

The qCore does not always need to merge model weights. It can learn a router.

Router inputs:

1. Task embedding.
2. Domain label.
3. Privacy class.
4. iCore capability profile.
5. Prior contribution quality.
6. Latency and cost.
7. Owner consent.

Router output:

1. Which iCores to ask.
2. Which inference mode to use.
3. How to weight answers.
4. Whether human approval is needed.

Router learning may be the most important first qCore training target because it respects heterogeneity and avoids raw data movement.

10. Holographic Inference Modes

The inference layer should choose a point on the egoistic-to-communal spectrum. A question about the owner's private notes should stay local. A question about a company may assemble that company's qCore. A question about a country may assemble a country qCore. A question about a general scientific topic may use a domain qCore or a broader network qCore.

Mode 0: Spectrum Routing

Before inference, the node classifies the task by scope:

inference_scope:
  privacy_class: "private | group | public"
  locality: "personal | pair | team | city | country | language | domain | global"
  required_knowledge:
    - "private_memory"
    - "country_context"
    - "domain_expertise"
  allowed_layers:
    - "local_private"
    - "country_qcore"
    - "domain_qcore"
  disallowed_layers:
    - "global_public_if_private_data_needed"

The router then decides which layers to activate:

1. Local-only for private questions.
2. Local plus group qCore for trusted group context.
3. Local plus country qCore for country-specific questions.
4. Local plus domain qCore for technical or professional questions.
5. Broad qCore or GQ-like routing for general network intelligence.

Mode 1: Local iCore Inference

One iCore answers from local memory and local model adapter.

Mode 2: Federated Retrieval

Multiple iCores search private memory and return policy-approved summaries or judgments.

Mode 3: Committee Inference

Multiple iCores answer independently. The qCore synthesizes, ranks, or debates outputs.

Mode 4: Routed Expert Inference

The qCore router selects specialist iCores or qCores for subparts of a task.

Mode 5: Adapter Ensemble

Compatible adapters are loaded, merged, or selected at inference time. This can include a stack such as global adapter plus country adapter plus domain adapter plus private adapter, subject to policy and evaluation.

Mode 6: Distributed Model Path

Advanced nodes host model layers or modules in a Petals-like distributed path.

This should be deferred until networking and model compatibility are mature.

Mode 7: Grand Quorum Inference

The theoretical Grand Quorum, or GQ, is not a single always-on brain. It is the upper end of the spectrum: a dynamically assembled network-wide qCore for tasks that are broad enough, public enough, and valuable enough to justify using many iCores or many qCores.

The same mechanism should work at every scale:

1. Identify the relevant scope.
2. Activate the matching qCore.
3. Use local autonomy inside each iCore.
4. Aggregate outputs or adapter contributions.
5. Record provenance and contribution receipts.

11. Fractal Training Protocol

11.1 Local iCoreTrainingRound

training_round:
  type: "local_icore_sleep"
  base_model_passport: "model_passport_..."
  input_views:
    - "sft_view"
    - "preference_view"
    - "replay_view"
  trainable_artifact: "lora_adapter"
  privacy: "local_only"
  eval_gate: "hinet_icore_eval_v0"
  promotion: "only_if_eval_passes"

11.2 qCoreConsolidationRound

training_round:
  type: "qcore_consolidation"
  qcore_id: "qcore_..."
  compatibility_class: "optional"
  contribution_types:
    - "distilled_answer"
    - "router_metric"
    - "adapter_update"
    - "evaluation_result"
  aggregation:
    mode: "router_update | distillation | secure_lora_aggregation | adapter_merge"
  privacy:
    raw_data_allowed: false
    secure_aggregation_required: true
  promotion:
    eval_suite: "hinet_qcore_eval_v0"

11.3 NetworkEpoch

network_epoch:
  epoch_id: "epoch_..."
  scope: "compatibility_class | domain | community"
  accepted_inputs:
    - "qcore_artifact"
    - "adapter_commitment"
    - "public_eval_result"
    - "distilled_dataset"
  outputs:
    - "updated_router"
    - "community_adapter"
    - "benchmark_report"
    - "protocol_parameter_update"

11.4 SpectrumQCoreActivation

qcore_activation:
  task_id: "task_..."
  selected_scope: "country | domain | company | global | custom"
  base_compatibility_class: "model_passport_..."
  active_communal_layers:
    - "global_adapter_v12"
    - "country_adapter_IL_v3"
    - "domain_adapter_ai_research_v5"
  active_local_layers:
    - "owner_private_memory"
    - "owner_private_preference_adapter"
  consent:
    private_data_leaves_node: false
    local_summaries_allowed: true
    adapter_updates_allowed: false
  aggregation:
    mode: "federated_retrieval | committee | routed_expert | adapter_ensemble"

The important property is compositional scale. A country qCore, a language qCore, and a domain qCore should all use the same activation grammar. The difference is membership, adapter stack, router policy, and evaluation suite.

12. Scientific Hypotheses

Hypothesis 0: Shared DNA Enables Runtime Quorum Behavior

The bacterial and octopus analogies predict that compatible iCores should be able to coordinate at runtime without a new mutual training phase, provided they share enough base substrate, signaling grammar, and activation policy.

In HiNet terms, a qCore session should be possible as an activation event when the iCores share:

1. A protocol vocabulary.
2. Compatible data and consent schemas.
3. Capability advertisement semantics.
4. A task signaling mechanism.
5. A router or quorum activation rule.
6. A common evaluation and receipt format.

The qCore may still improve through later consolidation, but its immediate formation should not depend on synchronous retraining.

Hypothesis 1: Same Base Is Not Required For Useful qCore Inference

Heterogeneous iCores should improve qCore answers through retrieval, debate, and synthesis even when they use different base models.

Hypothesis 2: Same Compatibility Class Is Required For Safe Weight Aggregation

Direct adapter aggregation should require a shared model passport or a defined translation/distillation path.

Hypothesis 3: Personal Sleep Improves Atomic Intelligence

Sleep-cycle consolidation should improve owner-specific recall, style, and workflow performance without degrading general capability.

Hypothesis 4: qCore Consolidation Improves Routing Before It Improves Weights

The earliest durable network intelligence will likely come from better routing and aggregation, not merged weights.

Hypothesis 5: Fractal Intelligence Requires Explicit Network Epochs

Local iCore learning creates better atoms, but higher-order qCore intelligence requires periodic consolidation at qCore and network levels.

This hypothesis should be interpreted carefully: network epochs are required for the lineage to improve, not for every instance of quorum behavior to occur.

Hypothesis 6: Intelligence Exists On A Local-Communal Spectrum

The strongest HiNet behavior will not come from choosing between private local inference and global inference. It will come from routing each task to the right point on the spectrum: personal, pairwise, group, country, language, domain, global, or custom qCore.

Hypothesis 7: Communal Layers Improve General Inference Without Erasing Local Identity

If the architecture separates egoistic local layers from communal layers, an iCore should be able to benefit from network-evolved intelligence while retaining owner-specific identity, memory, and preferences.

13. Near-Term Experiments

Experiment 1: Base Model Bakeoff

Compare candidate Hugging Face models for iCore use.

Measure:

1. Local inference speed.
2. Memory requirements.
3. PEFT compatibility.
4. Chat template stability.
5. License fit.
6. Baseline quality.
7. Quantized performance.

Experiment 1B: Shared DNA Versus Heterogeneous qCore

Compare qCore behavior under three conditions:

1. Same base model, different local memories.
2. Same base model, different local LoRA adapters.
3. Different base models, same qCore protocol.

Measure:

1. Output quality.
2. Coordination cost.
3. Agreement stability.
4. Router accuracy.
5. Whether same-DNA qCores show stronger compositional behavior than heterogeneous qCores.

Experiment 2: iCore Data Standard

Convert real local documents and chat interactions into SourceRecord, MemoryRecord, FactRecord, ConversationRecord, PreferenceRecord, and ReplayRecord.

Measure:

1. Conversion quality.
2. Provenance integrity.
3. Revocation behavior.
4. Training view quality.

Experiment 3: Sleep-Cycle LoRA

Train a local adapter during idle time using SFT and replay.

Measure:

1. Owner-specific recall.
2. Style alignment.
3. Catastrophic forgetting.
4. Rollback behavior.
5. Thermal/runtime cost.

Experiment 4: DPO Preference Sleep

Use owner preference pairs to tune response behavior.

Measure:

1. Preference win rate.
2. Overfitting.
3. General instruction retention.
4. Whether DPO should be frequent or rare.

Experiment 5: Heterogeneous qCore Committee

Run qCore inference with iCores using different base models.

Measure:

1. Output quality versus best individual node.
2. Diversity benefit.
3. Aggregation reliability.
4. Cost and latency.

Experiment 6: Same-Class Adapter Aggregation

Train multiple iCores using the same base model passport and test federated LoRA or adapter merging.

Measure:

1. Whether aggregation improves shared evals.
2. Whether personal performance degrades.
3. Whether dual adapters preserve individuality.
4. Whether secure aggregation is needed immediately.

Experiment 7: qCore Router Learning

Train a router over iCore capability profiles and past contribution receipts.

Measure:

1. Whether fewer selected iCores match all-node performance.
2. Whether routing is explainable.
3. Whether routing respects consent.
4. Whether routing improves over qCore sessions.

Experiment 8: Spectrum Inference

Ask the same family of questions at different scopes:

1. Personal question.
2. Team question.
3. Country question.
4. Domain question.
5. Global question.

Measure:

1. Whether the router selects the correct scope.
2. Whether adding the relevant qCore improves answer quality.
3. Whether irrelevant broader qCores add noise.
4. Whether private local identity remains preserved when communal layers activate.

14. Proposed First Implementation Boundary

Build first:

1. Model passport schema.
2. iCore Data Standard records.
3. Local data ingestion into training views.
4. Local memory and retrieval.
5. PEFT LoRA/QLoRA training pipeline.
6. Sleep-cycle scheduler triggered by idle/charging/manual state.
7. Evaluation gate and rollback.
8. Fast adapter and slow adapter versioning.
9. Simulated qCore committee inference.
10. qCore contribution receipt schema.
11. Router metrics from simulated sessions.
12. Egoistic and communal layer registry.
13. Spectrum router for personal, group, country, domain, and global inference scopes.

Defer:

1. Full model fine-tuning. [OVERTURNED by E1 — full fine-tuning is no longer deferred: bf16 full-FT injects facts (recall 0.27 → 0.97) and is part of the current depth spectrum; see Whitepaper §8.]
2. Real decentralized training.
3. Production token economics.
4. Production peer network.
5. Petals-style distributed model execution.
6. Secure aggregation beyond toy prototypes.
7. On-chain coordination.

15. Open Problems

Model Compatibility

How many compatibility classes can the network support before fragmentation prevents entrainment?

Shared DNA Versus Diversity

How much common substrate is needed for qCore coherence, and how much local divergence is beneficial before iCores stop being weight-compatible?

Data Quality

How does the iCore distinguish facts, preferences, temporary context, and noise?

Revocation

If user data influenced an adapter, what does consent revocation mean technically? Delete future use, roll back adapter, retrain without data, or mark derived artifacts as restricted?

Privacy Leakage

Which training artifacts leak private data, and how can the node test for leakage before any contribution leaves the device?

Continual Learning

How does an iCore learn every night without forgetting older capabilities or overfitting to recent user interactions?

qCore Emergence

What measurable threshold proves that a qCore is more than a committee wrapper?

Network Consolidation

How often should qCores consolidate? Who triggers network epochs? What artifacts are eligible?

Runtime Coordination Versus Training

Which qCore capabilities require only shared signaling and routing, and which require actual communal training or adapter consolidation?

Boundary Between Egoistic And Communal Weights

How should the system decide whether a learned artifact remains private, becomes group-shared, becomes country/domain communal, or becomes part of the global compatibility-class substrate?

Interference Between Layers

When local, country, domain, and global adapters are all active, how does the iCore prevent contradictory behavior, privacy leakage, or loss of owner-specific identity?

16. Conclusion

Fractal intelligence is not produced automatically by putting many personal models on a network. Local iCore training creates better atomic intelligence, but qCore intelligence requires explicit protocols for shared schemas, routing, aggregation, evaluation, and consolidation.

The most realistic path is staged:

1. Let each iCore start from an open model compatibility class for weight-compatible lineages, while allowing heterogeneous models for output-level qCore inference.
2. Standardize consented human data into auditable learning records.
3. Separate egoistic local layers from communal network layers while allowing controlled interaction between them.
4. Train local adapters through sleep-cycle consolidation.
5. Use shared qCore signaling so compatible iCores can coordinate at runtime without synchronous retraining.
6. Route each task to the right point on the spectrum: personal, group, country, domain, global, or custom.
7. Use retrieval and committee inference for early qCores.
8. Learn routers from qCore sessions.
9. Test compatible adapter aggregation only after local training and evaluation are stable.
10. Add qCore and network consolidation phases when there is evidence that collective artifacts improve over individual iCores.

The research program succeeds only if both halves remain true:

1. The human keeps ownership of the atomic intelligence nucleus.
2. The network can assemble larger intelligence from those nuclei without erasing that ownership.

References

1. Hugging Face PEFT: https://github.com/huggingface/peft
2. Hugging Face Transformers PEFT guide: https://huggingface.co/docs/transformers/v5.3.0/peft
3. Petals: Collaborative Inference and Fine-tuning of Large Models: https://arxiv.org/abs/2209.01188
4. Hivemind decentralized deep learning: https://github.com/learning-at-home/hivemind
5. Swarm Learning for decentralized and confidential clinical machine learning: https://www.nature.com/articles/s41586-021-03583-3
6. Flower federated learning framework: https://flower.ai/
7. Federated Low-Rank Adaptation for Foundation Models survey: https://arxiv.org/pdf/2505.13502
8. A Survey on Federated Fine-Tuning of Large Language Models: https://arxiv.org/pdf/2503.12016
9. A Survey on Mixture of Experts in Large Language Models: https://arxiv.org/abs/2407.06204
10. Modular Deep Learning: https://arxiv.org/abs/2302.11529
11. Quorum sensing as a mechanism to harness the wisdom of the crowds: https://www.nature.com/articles/s41467-023-37950-7
12. Synthetic neural-like computing in microbial consortia for pattern recognition: https://www.nature.com/articles/s41467-021-23336-0
13. Bacterial quorum sensing in complex and dynamically changing environments: https://www.nature.com/articles/s41579-019-0186-5
14. Bacterial quorum-sensing network architectures: https://pmc.ncbi.nlm.nih.gov/articles/PMC4313539/
15. Phenotypic heterogeneity in bacterial quorum sensing systems: https://pmc.ncbi.nlm.nih.gov/articles/PMC4510197/
16. Toward an understanding of octopus arm motor control: https://pmc.ncbi.nlm.nih.gov/articles/PMC10755184/
17. Neuronal segmentation in cephalopod arms: https://www.nature.com/articles/s41467-024-55475-5
18. Lessons for robotics from the control architecture of the octopus: https://www.frontiersin.org/journals/robotics-and-ai/articles/10.3389/frobt.2022.862391/full
19. Hugging Face PEFT model merging guide: https://huggingface.co/docs/peft/developer_guides/model_merging
20. Sleeping LLM sleep-wake consolidation concept: https://github.com/vbario/sleeping-llm/blob/main/paper.md
21. Automerge local-first state and sync: https://automerge.org/
22. libp2p peer-to-peer networking: https://libp2p.io/
23. Federated Learning with Model Personalization survey: https://www.researchsquare.com/article/rs-6272058/latest
24. Personalized Federated Learning through Local Memorization: https://arxiv.org/abs/2111.09360
25. FedRep shared representations for personalized federated learning baseline: https://flower.ai/docs/baselines/fedrep.html
26. Federated Multi-Task Learning / MOCHA: http://papers.neurips.cc/paper/7029-federated-multi-task-learning.pdf
27. Hierarchical federated learning and edge topologies survey: https://export.arxiv.org/pdf/2302.02573v1.pdf
28. Federated Learning Survey: A Multi-Level Taxonomy of Aggregation: https://arxiv.org/pdf/2511.22616
29. Federated multi-task learning with shared representation / FedMuscle: https://openreview.net/pdf/d32b2c120a50c3249d25241792874d33a1400f6c.pdf
30. Personalized FL as mixtures of shared component models / FedEM: https://openreview.net/pdf?id=YCqx6zhEzRp
31. A survey on Model MoErging: https://openreview.net/pdf?id=u0azVc9Y0y
32. Complementary learning systems review: https://arxiv.org/pdf/1802.07569
33. Complementary learning systems theory update: https://ni.cmu.edu/~tai/nc19journalclubs/KumaranHassabisMcC16CLSUpdate.pdf
34. McClelland, McNaughton, and O'Reilly on complementary learning systems: https://stanford.edu/~jlmcc/papers/McCMcNaughtonOReilly95.pdf
35. Brain-inspired replay for continual learning: https://www.nature.com/articles/s41467-020-17866-2
36. Collective intelligence across scales and substrates: https://pmc.ncbi.nlm.nih.gov/articles/PMC10978875/

Next: Network integration note →  ·  All documentation →