59 Personal Compute Hives and Federated Edge Intelligence

59.1 Chapter status

Field	Value
Chapter ID	`personal-compute-hives-and-federated-edge-intelligence`
Part	Part III - Routing, Compression, Representation, and Substrates
Status	conceptual
Last updated	2026-08-08
Primary source records	32 assigned records: twelve local architecture sources, twelve network/cluster/federation and partition comparators, and eight heterogeneous-memory implementation or paper comparators
Claim label	Design rationale
Evidence level	argument
Source loading state	source notes: `beastbrain`, `field_of_god_ai_constitution`, `scf`, `talos`, `vcm_public`, `planforge`, `octopus_router`, `rmi`, `tokenmana`, `project_theseus_whitepaper`, `theseus_operator_os`, `ladon_manhattan`, `ext_tailscale_docs_2025`, `ext_kubernetes_overview_docs`, `ext_k3s_docs_2026`, `ext_nomad_docs`, `ext_ray_core_docs_2026`, `ext_boinc_home_2026`, `ext_syncthing_home`, `ext_ipfs_docs`, `ext_akash_docs_2026`, `ext_golem_docs_2025`, `ext_github_self_hosted_runners_docs`, `ext_cap_theorem_gilbert_lynch_2002`, `ext_airllm_2023`, `ext_deepspeed_inference_2022`, `ext_flexgen_2023`, `ext_hf_accelerate_big_model_inference_2026`, `ext_llama_cpp_memory_mapping_2026`, `ext_llm_in_flash_2024`, `ext_powerinfer_2024`, `ext_atsinfer_2026`; raw cache: `beastbrain`, `scf`, `talos`, `vcm_public`, `planforge`, `octopus_router`, `rmi`, `tokenmana`, `ladon_manhattan`
Test state	Seven public record schemas validate. The exact 2/8 Hive-admission and 3/6 partitioned-authority suites remain passing. The refinement recompiles 31 theorems, executes six accepted events, verifies seven trace splits, covers all 47 routes, rejects all six post-closure event kinds, and rejects 144/144 mutations. Thirty-one refinement declarations and 21 retained legacy consequences remain live; five projections/fixture declarations are retired. No live scheduler, registry, portal, authority service, network overlay, federation, partition run, runtime enforcement, rented-node sandbox, energy measurement, dropout recovery, security, privacy, availability, useful-work, or transfer result has been run.

59.2 Drafting guardrail

This chapter uses source-note material for BeastBrain’s Mimic hardware-profile lineage, VCM, Talos, Octopus Router, RMI, TokenMana, Project Theseus, the Hive Operator OS, SCF, Field of God governance, PlanForge, and Ladon/Manhattan. It also uses source-note material for adjacent public systems: private overlay networking, orchestration, lightweight cluster operation, distributed execution, volunteer compute, file synchronization, content-addressed retrieval, rented compute, self-hosted CI, and CAP-style partition trade-offs. It does not claim that a complete personal compute hive exists, that those tools prove the ASI Stack design, or that any private device has been enrolled.

After routing and the folded MoECOT runtime crosswalk define the evidence packet a concrete orchestrator must emit, this chapter asks where that runtime can live. The answer is not “any reachable device.” It is a policy-bounded hive where portals, workers, stores, rented nodes, and project machines participate only through explicit identity, data, tool, network, approval, and revocation records.

59.3 Human Reading Path

Concrete lens. Latency-first scheduling selects the three-minute rented GPU, but that route violates local-only private-data and tool boundaries; policy filtering makes it ineligible before optimization begins.

Runtime orchestration asks what an orchestrator should emit for review before placement. The placement problem follows immediately: where can such orchestration safely live? A personal compute hive is not every device the system can reach; it is a governed federation of portals, workers, storage, rented nodes, family surfaces, and project machines.

The governing question is consent joined to containment. Edge intelligence deserves placement only when work respects data locality, owner policy, family roles, cost, privacy, rollback, approval, and authority boundaries instead of treating personal hardware as free ambient compute. The hive should feel less like borrowed background machinery and more like a governed household/workshop operating surface.

Personal compute becomes part of the stack only when stewardship is as explicit as scheduling.

The edge should extend agency and control, not quietly absorb private machines.

The accountable hive is one a household or project can inspect, pause, and reclaim.

Shared compute should deepen stewardship before it expands power, and the hive earns use only if accountability scales with capacity. Capacity must answer stewardship before it can safely become shared infrastructure.

59.4 Problem

A governed ASI stack needs a place to live. If the stack is only a cloud service, it inherits the cloud provider’s boundaries, cost model, availability, surveillance risk, and authority assumptions. If it is only a local application, it cannot coordinate the phones, laptops, desktops, network storage, old machines, workshop computers, rented nodes, and project machines that already form the practical substrate of a person’s work.

The missing layer is not merely “edge compute.” Edge compute says that work can run near data or users. A Personal Compute Hive says that a person’s, family’s, or project’s machines are a governed body: a federated substrate with identity, memory, policy, scheduling, evidence, and revocation. Its purpose is to let an ASI stack use the hardware that is actually available while preserving a hard distinction between reachability and authority.

59.5 Why existing approaches are insufficient

Cloud assistants are convenient, but their default shape is centralized: the user sends context upward, rented infrastructure performs the work, and the provider controls most of the runtime boundary. Single-device assistants are private by comparison, but they strand memory and compute inside one box. Home clusters and generic schedulers can distribute jobs, yet they typically optimize availability, load, and throughput before they represent consent, family authority, data sensitivity, tool risk, or evidence requirements as first-class constraints.

The ASI Stack requires a different abstraction. The scheduler must understand that a phone may be the right approval portal but the wrong training node; that a NAS may be the right memory store but the wrong place for internet-facing code; that a desktop GPU may be a good worker until the job touches private family data; that a rented node may be useful for public inference but unacceptable for sensitive memory; and that a child’s device may be reachable without being a lawful endpoint for a topic, tool, or dataset.

59.6 Core Claim

Reader claim. A hive chooses the fastest eligible device, not the fastest reachable device.

Operational rule. Filter every node by principal, data, tool, approval, secret, locality, energy, federation, dropout, and residual policy before comparing latency or price. A partition or stale grant routes high-impact work to denial, quarantine, or fresh approval rather than available-but-unauthorized execution.

[personal-compute-hives-and-federated-edge-intelligence.core, label: Design rationale, support: argument] For an exact versioned principal, household or project, job, use, data and tool class, effect envelope, acceptance test, risk budget, deadline, and evaluation horizon, a Personal Compute Hive should admit and place work only through policy-before-optimization: independently attested participants and roles, intersected authority and rights, task-local context and execution leases, least-authority adequate node selection, scoped approval, monitored sandboxed execution, complete artifact/effect/resource receipts, partition-aware denial or quarantine, and effect-complete rollback or residual custody; reachability, ownership, cheap capacity, a passing record schema, or stale authority alone cannot license execution, and federation, dropout, revocation, replacement, requeue, and retirement must preserve affected descendants and residual owners.

The claim is architectural, not empirical. The current support state is argument. It says that governed personal AI needs this layer in order to preserve authority and locality while using distributed hardware. It does not say that the scheduler is already implemented, that the network is secure, that old devices are always worth using, or that rented nodes can safely touch private data.

59.6.1 Claim-source mapping status

The core claim has not been promoted above argument. Appendix C carries exact reviewed mappings for the original 23 sources: eleven internal or tracked local architecture sources and twelve external comparator sources, including Gilbert and Lynch for the bounded partition-pressure warning. Eight newly assigned heterogeneous-memory sources supply metadata-first drafting context for worker admission only. The internal mappings support pieces of the design: VCM for governed context and taint, Talos for typed jobs and audit, Octopus/RMI for routed specialists and lifecycle state, TokenMana for resource budgets, Project Theseus and Hive Operator OS for trusted-machine node registries and operator surfaces, SCF for capability boundaries, Field of God governance for consent and least sufficient power, PlanForge for scheduling, and Ladon/Manhattan for handle-based secret use.

External mappings ground adjacent substrate vocabulary such as private overlay networking, cluster orchestration, distributed tasks, volunteer compute, file synchronization, content-addressed retrieval, rented compute, self-hosted runners, and consistency/availability pressure under partition. The repository includes record-shape schemas, synthetic fixtures, and finite Lean consequences, but no live hive scheduler, registry, approval portal, authority service, family-governance engine, network overlay, rented-node sandbox, federation, security evaluation, privacy evaluation, useful-work campaign, independent reproduction, or transfer result.

59.7 Mechanism

A Personal Compute Hive starts with three records: a Device Resource Card, a Hive Job Contract, and a Hive Scheduling Decision.

The Device Resource Card describes a node without granting it open-ended authority. It records device identity, owner or guardian, physical location class, trust tier, network reachability, compute profile, storage profile, power state, data classes allowed, tool classes allowed, secret-handle capability, operator-presence requirements, and revocation path. A phone, laptop, desktop, NAS, old machine, family tablet, workshop PC, rented GPU, and project runner can all be represented by the same record type, but their policy cards differ.

The Hive Job Contract is the work request. It names the objective, data dependencies, context packet, tool requirements, authority ceiling, physical-world risk, federation scope, budget, energy preference, deadline, required approvals, verification predicate, and residual policy. It is compiled from intent, planning, VCM materialization, and Talos-style typed work rather than free-form agent desire.

The Hive Scheduling Decision is the narrow bridge between the job and the substrate. It records all eligible nodes, rejected nodes with reasons, selected node, approval receipts, data-placement decision, secret-handle plan, verification path, cost and energy estimate, expiration, and audit references. Optimization happens after rejection reasons are recorded, not before.

59.7.1 Worked hive placement: the three-minute rented GPU loses

The public admission fixture asks the hive to render and validate a private draft. Two devices bid. The home desktop estimates fifteen minutes, accepts personal_private data, supports both schema_validation and local_render, and requires approval from the owner’s phone. A rented GPU estimates three minutes and has high compute fit, but its card permits only public notes and synthetic data, offers public sandbox egress, and cannot hold a secret handle.

The scheduler rejects the faster node before optimization because the job is local_only and its context contains private material. The phone receipt authorizes only this local render and explicitly denies rented-node, external- network, and private-export permissions. The desktop wins after policy filtering, not because the fixture claims it is globally better hardware.

The result records two valid synthetic scenarios and rejects eight controls, including private data on a rented node, missing high-risk approval, child- sensitive routing without a guardian surface, external project work without a sandbox lease, energy overrun, dropout without a requeue residual, missing audit refs, and support overclaim. No scheduler or network ran. The unexecuted dropout recovery remains a named residual instead of being smuggled into the passing admission record.

flowchart TD
  intent["Human or project intent"] -- "compiled request" --> plan["PlanForge / Talos job lowering"]
  plan -- "job boundary" --> contract["Hive Job Contract"]
  vcm["VCM context packet\nsource, taint, adequacy, revocation"] -- "permitted context" --> contract
  registry["Device Resource Cards\nphones, laptops, GPUs, NAS, rented nodes"] -- "available capacity" --> filter["Policy filter"]
  contract -- "requirements" --> filter
  gov["Governance predicates\nconsent, family rules, SCF leases, secret handles"] -- "authority limits" --> filter
  filter -- "policy denial" --> rejected["Rejected nodes\nwith reasons"]
  filter -- "eligible after policy" --> bids["Eligible node bids\ncapability, locality, cost, energy"]
  bids -- "selected bid" --> decision["Hive Scheduling Decision"]
  decision -- "approval needed" --> approval["Portal approval\nwhen required"]
  approval -- "scoped lease" --> execute["Bounded execution slot"]
  execute -- "produces record" --> evidence["Artifact, audit, residual, and revocation records"]
  evidence -- "updates memory" --> vcm

Reading the hive scheduler: The hive scheduler filters devices by policy before optimization begins. Phones, storage, local GPUs, rented nodes, portals, and workers are not interchangeable; each selected execution slot needs a scoped lease, approval when required, and evidence back into memory.

Those three records are necessary but not sufficient. The full hive protocol also needs a PortalCard, HiveApprovalReceipt, HiveJobBid, and HiveFederationLease. A portal card states what a phone, laptop, tablet, headset, browser, or shared display may ask, show, and approve. An approval receipt binds a human or guardian decision to one job boundary and one time window. A job bid records a node’s capability, latency, energy, cost, privacy fit, and policy reason after filtering. A federation lease lets a project hive, collaborator hive, rented node, or public compute market borrow bounded capacity without inheriting private network access.

Partitioned authority is the governance problem that appears when a hive spans devices, sites, collaborators, or rented nodes. A node may still be reachable while its authority state is stale. A revocation may have reached the portal but not the effect site. A worker may hold an old grant while the scheduler has already narrowed the job. Gilbert and Lynch’s CAP theorem is not imported as an AI result, but it gives the right warning: under communication failures, safety-like consistency and availability-like response cannot both be assumed for free.

For hives, the practical rule is CAP-style authority consistency: high-impact effects should prefer denial, quarantine, or a fresh authority receipt over available-but-stale dispatch. python3 scripts/validate_partitioned_authority_fixture.py records this as the partitioned authority fixture at experiments/partitioned_authority/results/2026-07-03-local.json; it rejects stale-grant dispatch, mutation after an unseen revocation, grant/effect race records without residual ownership, missing no-mutation evidence, support-state promotion from fixture shape, and missing non-claim boundaries. This does not prove deployed partition tolerance or revocation propagation.

This mechanism turns household and project machines into a policy-first compute fabric. A phone is primarily a portal and approval surface. A laptop is an interactive worker with limited background availability. A desktop GPU may be a heavy worker. A NAS may be long-term memory, artifact storage, and retrieval infrastructure. Old machines may run background summarization, indexing, or test jobs with low authority. Rented nodes may run public, scrubbed, or synthetic jobs. Project machines may accept work only through explicit contracts. Family devices may expose only age-appropriate portals and guardian-approved transitions.

59.7.2 Eighteen-stage governed job lifecycle

The operational claim is meaningful only if the whole job lifecycle has an owner and a rejecting path. The reference lifecycle is:

Freeze the exact principal, household or project, job, use, acceptance predicate, risk budget, cost and energy budget, deadline, and evaluation horizon.
Inventory principals, portals, workers, stores, authority services, tools, datasets, effects, external providers, and evaluators as separate participants.
Attest identity, owner or guardian, role, location, capability, software and policy version, security posture, readiness, and currentness.
Classify the job’s data, tool, physical-effect, network, rights, privacy, locality, verification, and retention obligations.
Compile a typed job contract and task-local context lease with inputs, effects, outputs, evidence, expiry, revocation, fallback, rollback, and residual ownership.
Prefilter nodes by identity, role, data class, tool authority, rights, locality, security, readiness, budgets, and verifier requirements.
Build comparable capability, load, latency, bandwidth, battery, thermal, energy, monetary-cost, privacy-exposure, reliability, and dropout features for eligible nodes only.
Solicit signed, expiring bids after filtering and retain both eligible and rejected-candidate evidence.
Select the least-authority adequate lawful node, or record abstention, escalation, local-only fallback, or a justified deviation.
Obtain task-bound human, guardian, multi-party, spending, physical-effect, or federation approval where required.
Issue a task-local execution or federation lease with exact node, data, tools, effects, network, sandbox, verifier, expiry, revocation, and no-delegation bounds.
Transfer only permitted data or opaque handles, never ambient memory, credentials, network visibility, or standing authority.
Execute through a governed runtime adapter and monitor action, artifact, effect, resource, and anomaly events.
On partition, stale authority, dropout, revocation, or policy drift, deny or quarantine high-impact mutation, require a fresh receipt, and preserve no-mutation evidence.
Collect content-addressed artifact, effect, approval, cost, energy, latency, audit, verifier, recovery, and residual receipts with complete denominators.
Roll back, requeue, compensate, or quarantine affected work and invalidate descendants when execution, authority, evaluation, node state, or evidence fails.
Update scoped reliability, readiness, and reputation from adjudicated evidence without creating standing authority or deleting failures and residuals.
Replay natural and adversarial campaigns against matched baselines and transfer settings before promoting any efficacy, safety, privacy, availability, efficiency, or federation claim.

59.7.3 Twelve interface owners

The hive owns consumer-specific placement. It does not absorb the rest of the stack:

Owner	Hive handoff
Intent, Contracts, and Planning	Exact purpose, acceptance predicates, decomposition, dependencies, risk, budgets, deadlines, and re-contract triggers.
VCM and Context Engineering	Task-local context, taint, provenance, locality, materialization, expiry, revocation, and non-authority.
Routing, SCF, and Readiness	Candidate qualification, consumer-specific readiness, least-authority route choice, fallback, quarantine, and invalidation.
Security, Privacy, Rights, Legal, and Constitutional layers	Identity, consent, guardian and affected-party rights, data/tool/network membranes, secrets, retention, and jurisdiction.
Runtime Adapters, Tools, and Physical Effects	Lease enforcement, isolation, actions, monitoring, stop paths, and effect receipts.
Humans, Labor OS, Family Governance, and Tribunals	Approval, escalation, contestability, accessibility, remedy, override, and operator workload.
Resource Governance	Capacity, battery, thermal load, energy, bandwidth, money, attention, burst, scarcity, and complete cost attribution.
Artifact Graphs, Evidence, and Claim Accounting	Artifact identity, lineage, evaluator output, negative results, evidence transitions, descendant invalidation, and residual custody.
Procedural Memory, Data Governance, and Learning	Reuse, scoped reputation updates, contamination controls, retention, deletion, unlearning, and learned-state non-authority.
Inter-Stack and Hive Federation	Cross-hive identity, lease negotiation, sandbox manifests, payment or credit, dispute, revocation, partition reconciliation, and exit.
Project stewards and external providers	Project admission, publication and licensing boundaries, infrastructure custody, incident response, and handback.
Release and Deployment	Versioned rollout, canary scope, monitoring, rollback readiness, public non-claims, decommissioning, and retirement.

59.8 Owned substrate and device roles

The point of the hive is not to make every device interchangeable. It is to stop pretending that the device in the user’s hand is the whole AI. The phone, laptop, desktop, NAS, headset, workshop computer, and rented node are different organs with different authority. A personal AI should be able to choose among them without losing the owner’s policy boundary.

Hive participant	Best role	Default boundary
Phone	identity surface, approval portal, notifications, camera or voice capture, mobile review	high approval value; limited heavy compute; sensitive outputs should respect public surroundings
Laptop	mobile workbench, coding, writing, local file operations, interactive inference	good human-in-the-loop worker; poor always-on background node
Desktop or GPU PC	heavy inference, rendering, compilation, simulation, local training experiments	strong worker; not automatically trusted with family or regulated data
NAS or storage server	durable memory, backups, datasets, vector indexes, artifact archives	strong store; internet-facing execution should be narrow and auditable
Old machine	background indexing, crawler, low-priority transforms, test runners	cheap capacity; low trust unless patched and sandboxed
Tablet, TV, browser, or headset	shared portal, education surface, spatial review, dashboard	portal authority depends on user, room, and attention context
Workshop computer	CAD/CAM, fabrication, robotics, sensors, local physical tools	physical-world actions require stronger approval and operator presence
Rented or public node	burst compute, public tests, synthetic workloads, rented inference	no private memory or secrets unless a stronger contract proves the exposure is lawful

The hive vocabulary therefore separates portals, workers, stores, and authorities. A phone can approve a job that runs on the desktop. A NAS can hold the source corpus without executing untrusted code. A rented GPU can process public or synthetic work while being forbidden from private memory. A family tablet can be a learning portal without becoming a surveillance device.

59.9 Memory-tier admission inside a worker

A device can have enough total storage to hold a model and still be unable to serve it usefully. The scheduler therefore needs two admission decisions. Hive admission asks whether the job may run on the worker. Memory-tier admission asks whether this exact model, runtime, and paging policy can run inside that worker’s physical limits without violating the job contract.

The worker publishes a MemoryTierCapabilityCard as a versioned component of its DeviceResourceCard. It should describe more than nominal VRAM:

accelerator memory, reserved floors, largest allocatable block, supported dtypes and kernels, and measured host-device bandwidth;
host RAM, pinned-memory allowance, swap policy, memory pressure, and the amount that may be consumed without destabilizing the machine;
storage device and filesystem, available and reserved capacity, sequential and random read behavior, page-cache policy, scratch requirement, integrity checks, endurance assumptions, encryption state, and recovery path;
sustained rather than advertised thermal and power behavior, including battery constraints and whether a human is actively using the device;
permitted concurrency, request classes, interruption expectations, and background windows; and
the model, tensor layouts, runtimes, and memory-policy classes the worker can actually execute.

59.9.1 Hardware adaptation is a qualification transaction

The BeastBrain lineage calls its hardware-adaptation layer the Mimic: inspect the host, measure its physical envelope, and select a suitable execution mode. The durable idea is not its biological name or four hard-coded device modes. It is that a runtime should negotiate with the machine it actually inhabits instead of inheriting a generic hardware profile. That negotiation belongs in the hive’s qualification path, not in an unreviewed boot-time optimizer.

A HardwareProfileDecision binds the attested device and firmware, kernel, driver and runtime versions, accelerator and memory topology, filesystem and storage path, available kernels and dtypes, foreground-use policy, battery and power mode, ambient and sustained thermal observations, calibration workload, measurement horizon, candidate execution profiles, selected profile, rejected profiles, safety floors, fallback, expiry, and decision receipt. Direct register or operating-system probes receive no special trust merely because they are low-level: unavailable, privileged, vendor-specific, virtualized, or spoofable measurements remain explicit unknowns.

The profiler first uses passive inventory and bounded, cancellable probes. A short burst can discover an obvious incompatibility, but it cannot certify sustained thermal behavior, storage endurance, latency tails, or interactive quality. Qualification therefore separates discovered, smoke_measured, sustained_measured, and workload_qualified states. It retains the exact calibration artifact and compares a conservative generic profile, a smaller resident model, a heterogeneous-memory profile, and any optimized kernel path under the same useful-work contract. Hardware discovery may narrow a route; it cannot widen data rights, tool authority, or execution authority.

Profile changes need hysteresis and safe transition points. Memory pressure, thermal rise, battery state, foreground use, device removal, bandwidth loss, or repeated page misses may trigger throttle, pause, unload, smaller-model fallback, checkpoint, or requalification. They must not trigger destructive “panic compression,” silent precision loss, cache eviction that destroys rollback, or a driver switch during an uncommitted effect. The receipt records the old and new profile, state transferred or discarded, quality and authority consequences, affected jobs, and recovery boundary. A machine that adapted once is not permanently adaptable; every material hardware, software, power, or workload change expires the claim.

The policy then declares its largest indivisible objects and simultaneous working set. A layer-streaming runtime may need one full layer plus kernels, buffers, and KV state in accelerator memory. A sparse expert system may need a cold expert fallback that is larger than the nominal hot set. A conversion may temporarily require the original model, transformed shards, and scratch space at once. If any required indivisible object does not fit, or the working set depends on memory that the worker has reserved for safety and recovery, the policy is not admissible on that device. Aggregate SSD capacity cannot override that result.

59.9.2 Runnable is not qualified

The hive should use at least four memory-service grades:

Grade	Meaning	Typical use
`runnable`	the worker can load the policy and complete a bounded smoke request without violating hard capacity limits	diagnosis, conversion validation, or emergency fallback
`interactive-qualified`	the worker meets a declared first-token, inter-token, tail-latency, thermal, and interruption contract	conversation, coding, or human-in-the-loop work
`batch-qualified`	the worker meets a throughput, completion-window, energy, and recovery contract while latency may be high	overnight extraction, summarization, indexing, or synthetic evaluation
`background-qualified`	the worker can yield to foreground use, survive pause or cancellation, respect battery and quiet hours, and resume from a verified boundary	opportunistic household or project work

A model that produces one token after a long cold load is only runnable. It does not inherit interactive qualification. Conversely, a slow disk-backed route can be valuable for a weekend batch if it amortizes weight transfers, stays inside thermal and wear budgets, and can recover after interruption. The job contract chooses the needed grade before node bidding begins.

Admission fails closed when storage identity or integrity is unknown, free space cannot cover conversion and recovery, the fallback cannot run, cache or scratch cleanup is unowned, thermal telemetry is unavailable for a thermally-limited job, or measured bandwidth makes the deadline physically implausible. It also expires after changes to the model, adapter, tokenizer, quantization, runtime, kernel, driver, filesystem, storage device, power mode, or material hardware condition. A stale benchmark is not a permanent device capability.

59.9.3 Choose the adequate model and machine before paging

The point of heterogeneous memory is to enlarge the feasible set, not to make the largest available model the default. The scheduler first finds the least-authority adequate combination of model, worker, and memory policy. A smaller fully resident model on a private laptop may satisfy an interactive editing contract with less latency, energy, storage exposure, and failure surface than a much larger SSD-streamed model. A large disk-backed model may be appropriate when its quality advantage is material, the task is latency-insensitive, the source data may remain local, and the full lifecycle fits the worker. A remote or rented accelerator may be cheaper, but it is ineligible when data, model-weight, or authority constraints do not permit the transfer.

This creates a two-level bid. The node offers a physical envelope; the model-memory route offers a predicted quality, latency, throughput, energy, wear, recovery, and privacy profile inside that envelope. The hive records rejected pairings and reasons, selects among the eligible pairs, and returns actual measurements after execution. Repeated results may update a capability card, but learned performance estimates cannot widen data rights, authority, or trust.

For personal compute, this distinction is practical. An old desktop with fast NVMe may become a useful batch worker but a poor interactive portal. A laptop on battery may temporarily lose background qualification. A NAS can store verified shards while being forbidden to decrypt or execute them. A rented node can have excellent memory bandwidth and still be disqualified for private context. The hive becomes intelligent by making these differences explicit, not by pretending that every byte of storage is interchangeable virtual VRAM.

59.10 Interfaces

The hive interfaces with VCM before it interfaces with compute. VCM says what context exists, which version is in scope, which parts are tainted or revoked, and which data may be materialized. A scheduler that sees only a file path or prompt cannot protect the user because it cannot distinguish source evidence, private data, quoted hostile text, control text, and tool authority.

Talos and PlanForge provide the work interface. PlanForge decomposes the goal and identifies dependencies, minimum viable intelligence tier, fallback needs, and scheduling constraints. Talos turns the selected unit into a typed job with output contract, allowed tools, forbidden tools, isolation, audit, replay, and delivery requirements. The hive should not accept a raw “do this somewhere” instruction.

Octopus Router and RMI provide the capability interface. A device can be a node, but the schedulable unit is a bounded capability on that node: local summarizer, code runner, file indexer, GPU worker, verifier, retrieval store, workshop controller, or public test runner. Capability state, residuals, regressions, retirement criteria, and readiness matter as much as hardware specs.

TokenMana-style accounting provides the capacity interface. The hive should track not just tokens but heat, battery, bandwidth, storage churn, human attention, approval fatigue, reviewer time, monetary cost, and opportunity cost. A schedule that saves cloud spend while draining a phone battery or waking a human reviewer at the wrong time is not efficient in the ASI Stack sense.

SCF, Field of God governance, and Ladon/Manhattan provide the authority interface. A node receives a lease, not a blank check. Sensitive credentials remain behind handles. Tool use remains reversible where possible, logged where required, and escalated when consent, family governance, physical effects, or protected data are involved.

59.11 Hive objects

Object	Purpose	Minimum fields
`DeviceResourceCard`	Declare a node as an eligible but bounded hive participant.	device id, owner/guardian, trust tier, locality, compute profile, storage profile, network profile, allowed data classes, allowed tool classes, secret-handle capability, operator-presence mode, revocation path
`PortalCard`	Declare a human-facing access surface without making the portal the whole AI.	portal id, human principal, guardian principal if any, input/output modes, authority level, privacy context, attention level, safe output profile, revocation path
`HiveJobContract`	Declare what work may be attempted.	objective, source context refs, data classes, tool classes, authority ceiling, risk tier, federation scope, budget, deadline, verification predicate, residual policy
`HiveJobBid`	Let an eligible node describe how well it can perform a filtered job.	bidder device id, status, latency, cost, energy, transfer estimate, thermal risk, interruption risk, privacy fit, capability fit, policy reason
`HiveSchedulingDecision`	Record why work ran where it ran.	eligible nodes, rejected nodes, selected node, rejection reasons, approval refs, data-placement refs, estimated cost/energy, isolation mode, evidence refs, expiration
`HiveApprovalReceipt`	Bind human or guardian approval to a specific job boundary.	approver id, portal id, job id, permission granted, permission denied, time window, appeal or reversal path
`HiveFederationLease`	Let another hive or project borrow bounded capacity.	requester, provider, job class, data class, tool class, budget, network scope, evidence obligations, expiration, revocation

These records are intentionally smaller than a full distributed operating system. They are enough for a first implementation to decide whether a task may run on a node, whether a person must approve it, what data may move, and how the result becomes evidence.

59.12 Job classes and federation modes

Hive scheduling should classify work before it asks for bids. The classes can stay simple at first: local harmless work, personal private work, family-sensitive work, high-compute work, external project work, physical-world work, and dangerous or irreversible work. This table is a policy surface, not a taxonomy of every possible task.

Class	Typical route	Default boundary
`T0 local harmless`	phone, laptop, or small local worker	no private memory, no physical tool, no spend
`T1 personal private`	trusted local node	no rented node, no public project hive
`T2 family sensitive`	family portal plus guardian policy	preserve dignity, log minimally, escalate boundary questions
`T3 high compute`	desktop GPU, site node, or rented node if data is safe	cost and privacy checks before bidding
`T4 external project`	disposable sandbox worker	no private network, no credentials, artifact bundle returned
`T5 physical-world`	workshop or device controller with operator present	explicit approval receipt
`T6 dangerous or irreversible`	deny or multi-party approval	no ordinary autonomous execution

Federation should also be explicit. A personal hive uses one person’s devices. A family hive has shared and private zones. A site hive binds a physical place such as a home or workshop. A joined private hive lets collaborators cooperate under a contract. A public project hive accepts temporary issue or benchmark work. A market hive exposes spare capacity for payment or credit. An emergency hive prioritizes local continuity when ordinary internet paths fail. Each mode changes what a lease may contain.

59.13 Family and project mediation

Family governance is the place where a personal hive can become genuinely useful or genuinely abusive. The useful version keeps parents, guardians, and children in the loop for boundary decisions without turning every interaction into monitoring. A child-facing portal should classify the topic, choose an age-appropriate explanation when ordinary, escalate sensitive boundaries to a guardian when required, and record only the minimum policy event needed for review. The child should receive a dignified response, not a cryptic refusal whose real audience is an audit log.

A project-hive route has a different shape. A public repository or artifact steward may request a bounded job such as reproducing an issue, running a test suite, rendering documentation, or proposing a patch. The personal hive should treat that request as untrusted until it has a signed job contract, sandbox manifest, resource budget, evidence obligation, and expiration. The project can ask; the personal hive governs acceptance.

These two flows share one rule: external requests and family-sensitive requests do not become ordinary compute jobs until the relevant person, policy, and evidence boundary is explicit.

59.14 Relationship to artifact stewards

Personal hives and artifact stewards are paired but not interchangeable. The hive is the owned compute, memory, portal, and federation substrate. The steward is the project-lifecycle layer that decides which work is worth proposing for a book, repository, dataset, model, benchmark, or other durable artifact. A steward may request work from a hive, but it does not inherit authority over the hive’s devices, people, memory, wallets, or physical tools.

The boundary should be boring and explicit. A steward emits a project work contract with objective, context refs, allowed tools, forbidden tools, evidence requirements, budget, deadline, and non-claims. The hive compiles or wraps that request as a hive job contract, checks data class, tool risk, family policy, federation scope, cost, energy, and approval requirements, and then accepts, rejects, asks for repair, or returns a safer variant. The output back to the steward is an artifact bundle with logs, evidence refs, residuals, and revocation state, not a grant of project authority to the hive or hive authority to the project.

This pairing prevents two common mistakes. The first mistake is treating project automation as if it can command personal hardware because the hardware is reachable. The second mistake is treating a personal hive as if it knows project purpose just because it can run jobs. Stewardship supplies mission and lifecycle context; the hive supplies lawful execution slots. Neither layer should erase the other.

59.15 Hive-to-Hive protocol

At maturity, the hive needs a small Hive-to-Hive protocol rather than a pile of ad hoc scripts. The protocol objects are boring on purpose: identity cards, device cards, portal cards, capability cards, data policies, job contracts, bids, leases, sandbox manifests, artifact manifests, evidence bundles, payment or credit records, reputation records, and revocations.

The protocol should support joining, leaving, advertising bounded capabilities, requesting work, bidding, leasing compute, transferring safe artifacts, verifying outputs, paying or crediting work, revoking access, and replaying audit logs. It should not support ambient trust. A public project may request a job; the personal hive decides whether that request is lawful. A rented node may bid; the scheduler decides whether the job’s data class and sandbox rules permit that bid. A family portal may ask for a sensitive explanation; the guardian policy decides whether ordinary response, parent mediation, or denial is appropriate.

59.16 Hive memory

A hive is also a memory topology. Artifact memory, episodic memory, semantic memory, procedural memory, device reliability history, trust history, family education records, project records, and market or payment records have different owners, retention rules, and allowed placements. Treating all of them as one vector store would erase the reason to have a hive.

Memory type	What it records	Placement rule
Artifact memory	documents, code, diagrams, builds, logs, release bundles	durable store with provenance and backup policy
Episodic memory	meetings, sessions, task events, approvals	scoped retention and owner-visible review
Semantic memory	concepts, source notes, embeddings, claim references	source-bound and revocable through VCM
Procedural memory	repeated workflows compiled into tools	governed by tests, preconditions, postconditions, and retirement rules
Device memory	benchmarks, thermal history, reliability, dropout events	used for scheduling, not for expanding authority
Trust memory	safe or unsafe behavior by nodes, projects, workers, or providers	evidence-linked, contestable, and decay-aware
Family memory	learning context, guardian decisions, shared household records	dignity-preserving, role-scoped, and minimally logged
Project memory	issues, PRs, contracts, CI logs, releases, steward decisions	artifact-bound and auditable

This is where VCM becomes physical. VCM decides what context is needed and which source or taint labels travel with it. The hive decides where that context is allowed to exist.

59.17 Invariants

Every admission and result is bound to exact versions of principal, household or project, job, use, policy, data, tool, node, runtime, evaluator, acceptance predicate, and horizon.
Network reachability, physical possession, ownership, prior trust, or cheap capacity never implies identity, authorization, data access, or execution authority.
Principal, portal, worker, store, authority service, evaluator, and external provider remain separately identified roles with no implicit privilege inheritance.
Policy and readiness filtering always precede bidding, scoring, optimization, speculative execution, or data transfer.
Effective authority is the intersection of principal, job, data, tool, node, runtime, rights, approval, budget, locality, and temporal ceilings; composition cannot increase it.
Data remains within its permitted locality and disclosure class, and cross-node movement is explicit, minimal, purpose-bound, and receipted.
Secrets and standing credentials remain opaque handles mediated by a trusted boundary rather than strings in prompts, logs, bids, artifacts, or model context.
Human, guardian, multi-party, spending, and physical-effect approvals are informed, task-bound, revocable, expiring, and separable from mere portal interaction.
External or rented work receives only an isolated task slot with explicit sandbox, network, data, effect, verifier, cleanup, expiry, and revocation boundaries.
Under partition or stale authority, high-impact mutation fails closed or quarantines until a fresh receipt exists; safe stale-tolerant work is separately classified and no-mutation evidence is retained.
Baseline and candidate routes receive matched information, resources, retries, authority, evaluators, time, and stopping rules unless a deviation is disclosed and analyzed.
Every metric includes attempted, admitted, executed, completed, failed, abstained, escalated, dropped, rolled back, and missing cases so routing or availability cannot improve by denominator deletion.
Latency, compute, bandwidth, battery, thermal load, energy, money, human approval, verification, recovery, and governance work are attributed per job and lifecycle.
Dropout, cancellation, lease expiry, node loss, and partial output preserve recoverable state, requeue or compensation status, cleanup duties, and a named residual owner.
Revocation, rollback, replacement, and retirement propagate through affected jobs, artifacts, caches, descendants, routes, approvals, credentials, and external effects.
Family and child-facing operation preserves dignity, data minimization, age-appropriate explanation, affected-party rights, appeal, and minimal logging; safety does not license ambient surveillance.
Replay records capture nondeterminism, environment, node state, policy, authority, data, resource conditions, evaluator version, missing artifacts, and irreproducible boundaries.
Record-shape validation, finite theorem consequences, synthetic fixtures, imported metadata, and adjacent tool capability are never described as deployed scheduler, security, privacy, availability, efficiency, federation, or safety proof.

The phrase “personal hive” should not be allowed to smuggle in surveillance. A family hive is not a parental monitoring system by default. It is a policy system whose goal is to give the right person or guardian the right approval point for the right transition while minimizing unnecessary observation.

59.18 Failure modes

Botnet or malware conversion: enrolled nodes execute untrusted or self-propagating work outside the task lease.
Surveillance conversion: family, safety, productivity, or reliability telemetry becomes ambient monitoring or coercive control.
Data exfiltration: private, family, project, licensed, or secret material reaches a rented, public, compromised, or overbroad node.
Wrong-node placement: a capable route violates locality, tool, physical-risk, battery, thermal, quiet-hour, accessibility, rights, or approval constraints.
Identity or guardian confusion: child, guest, agent, project, owner, operator, device, or service identities are conflated and authority crosses principals.
Memory swamp: artifacts, logs, models, caches, replicas, and personal data accumulate without provenance, retention, deletion, revocation, or residual custody.
Optimizer-before-policy: cost, latency, availability, reputation, or accelerator preference silently determines eligibility.
Stale-grant dispatch: cached approval or authority continues through revocation, policy change, partition, clock skew, or lease expiry.
Partition availability laundering: unsafe mutation counts as availability, denial lacks no-mutation proof, or reconciliation silently accepts conflicting effects.
Sandbox theater: declared isolation omits network discovery, credentials, persistence, side channels, cleanup, nested delegation, or physical effects.
Secret materialization: handles are resolved into prompts, logs, artifacts, caches, bids, or external-provider memory.
Approval fatigue or rubber stamping: prompts are too frequent, vague, inaccessible, bundled, coercive, stale, or detached from actual effects.
Energy or cost laundering: battery wear, thermal load, bandwidth, electricity, cloud spend, operator time, verification, and recovery disappear from efficiency claims.
Dropout loss: node departure, sleep, network failure, cancellation, or lease expiry loses work, duplicates effects, strands data, or leaves no residual owner.
Federation authority creep: temporary project or external access becomes standing network visibility, data access, tool authority, reputation, or onward delegation.
Evaluator, reputation, or bidding corruption: collusion, self-report, sybil identity, shared failure, gaming, poisoning, or selective logging causes unsafe placement or promotion.
Offline or inaccessible residuals: disputed effects, cleanup duties, revocations, costs, and missing artifacts vanish when a node or provider leaves.
SOTA theater: synthetic records, finite proofs, imported reports, or a favorable single metric are promoted as useful, secure, private, available, efficient, or superior hive behavior.

These are not merely a threat list. Each one needs a detector or adjudicator, a rejecting or quarantine route, a recovery or compensation path, complete denominators, and a named residual owner in the mature campaign.

59.19 Minimum Viable Implementation

The current executable boundary is exact and small:

Seven public record schemas with valid fixtures: DeviceResourceCard, PortalCard, HiveJobContract, HiveJobBid, HiveSchedulingDecision, HiveApprovalReceipt, and HiveFederationLease.
One deterministic hive-admission harness with two accepted records and eight expected-invalid controls for policy-first scheduling, data locality, approval, guardian routing, sandboxed external work, audit refs, energy budgets, dropout residuals, and support-state non-promotion.
One deterministic partitioned-authority fixture with three accepted records and six expected-invalid controls for stale grants, delayed revocation, fresh authority receipts, grant/effect race custody, no-mutation evidence, CAP-style boundaries, and support-state non-promotion.
One accepted no-change evidence transition that keeps the partitioned-authority claim and chapter core at argument.
Thirty-eight live family declarations: seventeen reachable-lifecycle declarations plus twenty-one retained legacy route or negative consequences; five weaker projections or fixture-summary declarations are retired.

The bridge unfolds a repository-authored summary and proves finite consequences from it. It is useful executable record discipline, but it is not an independent replay of the Python fixture and not proof of scheduler behavior, partition tolerance, revocation propagation, or availability. The other declarations prove consequences of the modeled predicates; they do not establish that the predicates faithfully model a deployed system.

No live scheduler, registry, portal, authority service, network overlay, sandbox, federation, partition experiment, energy meter, device-dropout recovery, effect-complete rollback, privacy evaluation, security evaluation, natural workload, independent evaluator, reproduction, or transfer test ran. Therefore the current evidence supports no claim that a hive is useful, safe, private, available, efficient, robust, or superior.

The next governed reference slice should stay deliberately bounded: at least two owned node classes and one isolated external-node class; a typed public or synthetic job corpus; signed resource and portal cards; policy-before-optimization; task-local context and execution leases; manual approval; actual sandbox enforcement; partition and revocation injection; complete artifact, effect, cost, energy, and residual receipts; dropout recovery and cleanup; descendant invalidation; and no public federation, autonomous spending, private-data external execution, or background family-device operation.

59.20 Mature Research Target

The mature claim must be tested as a joint frontier, not advertised from an architecture diagram. The preregistered workload should include natural household document work, accessibility support, local retrieval and inference, workshop or physical-tool preparation, project builds and tests, storage and backup, public-data batch work, isolated rented compute, intermittent connectivity, and emergency or deadline pressure. Adversarial cohorts should stress identity and guardian confusion, bid and reputation gaming, stale grants, delayed revocation, network partition, exfiltration, malicious artifacts, sandbox escape, nested delegation, device dropout, duplicate effects, battery and thermal abuse, cost overruns, evaluator capture, surveillance pressure, and provider exit.

Matched baselines should include:

one manually selected device;
a cloud-only service;
manual placement across the same nodes;
a local-only policy;
cost-only and latency-only schedulers;
Kubernetes-, Nomad-, or Ray-like orchestration configured over the same substrate;
a conservative-denial policy;
and the complete governed hive.

All arms receive the same jobs, information, hardware access, model and tool versions, authority ceilings, retries, evaluators, time, and stopping rules unless a preregistered difference is the intervention. Joint gates measure useful task success, unsafe execution, false denial and missed help, authority and rights violations, privacy exposure, data-locality breaches, availability and consistency by job class, latency, bandwidth, compute, battery, thermal load, energy, money, human approval and recovery work, security incidents, rollback and compensation, residual survival, and total lifecycle burden. No single accuracy, availability, cost, or latency win can dominate a material safety or rights failure.

Causal ablations remove, one at a time, role separation, task-local context leases, policy-first filtering, least-authority choice, scoped approval, sandbox enforcement, fresh-authority receipts, partition quarantine, complete receipts, effect-complete recovery, reputation non-authority, and lifecycle invalidation. Each mechanism needs a preregistered causal signature: removing it should worsen the failure surface it is claimed to control without merely making the system refuse all work. The full stack must produce useful work rather than safety by abstention alone.

An independently implemented evaluator and a second orchestration implementation must reproduce the conclusions. Transfer varies device classes, networks, models, tools, data classes, households and projects, external providers, jurisdictions, threat models, failures, updates, and time. Raw public-safe attempts, nulls, negative results, missing artifacts, human work, costs, and residuals remain visible. If the full hive is dominated, a causal signature fails, or transfer does not survive, the relevant claim is narrowed or refuted rather than protected by rhetoric.

That campaign is the mature beyond-state-of-the-art target, not a current result. The present seven schemas, 2/8 admission fixture, 3/6 partition fixture, no-change transition, and finite proof envelope do not constitute that result.

59.21 Codex test plan

Test	Purpose	Status
Device registry fixture validation	Validate `DeviceResourceCard` shape, trust tier, owner/guardian field, allowed data classes, allowed tool classes, and revocation path.	implemented; `validate_protocol_examples.py` validates the fixture shape only
Portal, approval, bid, and federation fixture validation	Validate `PortalCard`, `HiveApprovalReceipt`, `HiveJobBid`, and `HiveFederationLease` shape.	implemented; `validate_protocol_examples.py` validates fixture shape only
Policy-first scheduling denial test	Confirm a faster node is rejected before optimization when its policy membrane forbids the job’s data, authority, or network scope.	implemented as a finite Lean predicate; no scheduler run
Bound approval receipt test	Confirm a high-risk job that requires approval cannot execute unless a bound receipt exists.	implemented as a finite Lean predicate; no approval service run
Federation lease boundary test	Confirm external hive access requires active lease, scope, sandbox, evidence, expiration, and revocation fields.	implemented as a finite Lean predicate; no federation run
Hive work admission lifecycle route proof	Confirm a finite hive-work admission review routes malformed jobs, missing identity/data/tool policy, registry gaps, scheduler-policy gaps, high-risk jobs without approval, external access without leases or sandbox records, missing cost or energy budgets, missing dropout plans, missing audit receipt plans, missing residual owners, and support-promotion attempts without evidence transitions to explicit outcomes.	implemented as a finite Lean route predicate; no scheduler, registry, portal, device, rented-node, or federation run
Hive admission harness	Check deterministic Personal Compute Hive admission packets for policy-first scheduling, data locality, approval receipts, guardian portal routing, federation leases, energy/dropout residuals, audit evidence refs, and no-promotion boundaries.	implemented as synthetic record validation by `python3 scripts/validate_hive_admission.py`; 2 valid and 8 expected-invalid fixtures pass; no deployed hive, scheduler, device registry, network overlay, approval service, guardian-policy engine, rented-node sandbox, federation, energy measurement, dropout recovery, privacy, security, or support-state claim
Partitioned authority fixture	Check stale grants, revocation-delay quarantine, fresh authority receipt requirements, grant/effect race residual ownership, no-mutation evidence, CAP-style authority consistency boundaries, and no support-state promotion.	implemented as finite synthetic record validation by `python3 scripts/validate_partitioned_authority_fixture.py`; 3 valid and 6 expected-invalid controls pass at `experiments/partitioned_authority/results/2026-07-03-local.json`; no deployed partition tolerance, distributed consensus, availability, runtime adapter enforcement, revocation propagation, or support-state-promotion claim
Data locality and rented-node denial test	Confirm private or family data cannot be sent to a rented node unless the job contract explicitly permits the exposure class.	implemented as synthetic record validation; no rented-node sandbox, privacy guarantee, or deployed scheduler claim
Phone approval gate test	Confirm a high-risk or high-spend job cannot execute until a bound approval receipt exists.	implemented as synthetic record validation; no approval-service, phone-portal, or deployed execution claim
Child topic routing test	Confirm child-facing portals deny or escalate sensitive topics according to guardian policy rather than routing them to ordinary workers.	implemented as synthetic record validation; no family-governance engine or child-safety behavior claim
External project sandbox contract test	Confirm project-to-personal federation receives only a sandboxed lease and cannot discover private network resources.	implemented as synthetic record validation; no network overlay, federation run, or rented-node sandbox claim
Audit replay test	Reconstruct why a job ran on a node from device cards, job contract, scheduling decision, approvals, and evidence refs.	implemented as audit-ref and residual-presence validation; no replay service or deployed audit reconstruction claim
Cross-router connectivity test	Confirm home, workshop, and mobile nodes can be represented as one logical hive without making network reachability an authority grant.	planned; not run
Job bidding test	Confirm eligible nodes can estimate latency, cost, energy, locality, and capability after policy filtering.	implemented as synthetic bid-selection and policy-blocked rejection validation; no scheduler-quality or optimality claim
Device dropout test	Confirm a job records residuals and recovers or requeues when the selected device leaves the hive.	implemented as dropout/requeue residual-presence validation; no recovery run or live device dropout claim
Energy-aware scheduling test	Confirm battery, thermal, and quiet-hour constraints can reject or down-rank otherwise capable nodes.	implemented as synthetic energy-budget and thermal-risk rejection validation; no energy measurement or live scheduling claim
Portal continuity test	Confirm a user can leave a site with a phone portal while approval authority remains scoped and auditable.	planned; not run

59.22 Formalization hooks

Tag	Lean module	Formal target	Status
`lean:personal_hives.scheduling.operational_invariant`	`AsiStackProofs.HiveLifecycleRefinement`	A reachable Hive lifecycle preserves exact job, principal, contract, registry, candidate-set, selected-node, policy, authority, lease, evaluator, consumer, and residual custody through acknowledged closure while separating dispatch, useful-outcome, recovery, support, and effect accounting.	implemented
`lean:personal_hives.policy_first.failure_blocks_promotion`	`AsiStackProofs.HiveLifecycleRefinement`	Incomplete policy, denominator, least-authority, locality, budget, energy, or dropout records block selection before optimization.	implemented
`lean:personal_hives.approval_gate.failure_blocks_promotion`	`AsiStackProofs.HiveLifecycleRefinement`	A high-risk Hive job cannot execute without a bound approval receipt tied to the exact job and lease.	implemented
`lean:personal_hives.federation_lease.operational_invariant`	`AsiStackProofs.HiveLifecycleRefinement`	External access requires federation, sandbox, scope, evidence, expiration, and revocation custody bound to the selected node.	implemented
`lean:personal_hives.work_admission.lifecycle_route`	`AsiStackProofs.HiveLifecycleRefinement`	The independent consumer preserves all 47 policy, selection, lease, partition, execution, reconciliation, recovery, revocation, and closure outcomes.	implemented
`lean:personal_hives.partitioned_authority.fixture_bridge`	`AsiStackProofs.HiveLifecycleRefinement`	Partitioned stale authority quarantines before mutation only with denial and no-mutation evidence; otherwise evidence is requested without inferring deployed partition tolerance or support.	implemented

The family now contains 52 live declarations: 31 reachable-lifecycle declarations and 21 retained legacy consequences; five weak projections or fixture-summary declarations are retired. The refinement proves arbitrary-run thirteen-field custody, zero support/external-effect authority, exact receipt accounting, accepted-trace validity, batch composition, and absorbing closure. Its independent consumer recompiles the exact surface, executes the six-event witness, checks all seven prefix/suffix splits, preserves custody and non-authority at every reachable state, covers all 47 routes, rejects every event kind after closure, and rejects 144/144 mutations. These surfaces do not prove a distributed scheduler, network boundary, rented-node sandbox, family-governance policy, privacy guarantee, approval service, partition tolerance, energy-aware scheduling, dropout recovery, audit replay, revocation propagation, effect-complete rollback, useful work, transfer, or live federation behavior.

59.23 Source crosswalk

Source ID	Use in this chapter	Boundary
`vcm_public`	Context packets, taint, revocation, adequacy, source binding, and materialization boundaries.	Does not prove retrieval quality or memory safety.
`talos`	Typed jobs, audit, replay, allowed tools, forbidden tools, evidence, and delivery contracts.	Does not prove the hive runner exists.
`octopus_router`	Routing vocabulary for bounded specialists, permission envelopes, and lifecycle-managed capability nodes.	Does not prove modular routing performance.
`rmi`	Residual escrow, specialist lifecycle, regression preservation, and three-mode execution discipline.	Does not prove a distributed personal hive improves capability.
`tokenmana`	Capacity accounting beyond raw tokens: load, friction, budget, burst, and scarcity.	Does not prove a specific scheduler is economically optimal.
`project_theseus_whitepaper`	Trusted-machine Hive node framing, local-first report discipline, and registered task-kind providers.	Does not prove the current Theseus Hive is operational from this repo.
`theseus_operator_os`	Operator channels, work board, node registry, feedback routing, TTLs, kill switches, and safety-visible surfaces.	Does not prove unattended operation is safe.
`scf`	Capability leases, qualification, route validation, lifecycle, replacement, and authority non-escalation.	Does not prove any personal-device capability is qualified.
`field_of_god_ai_constitution`	Consent, least sufficient power, memory/tool governance, reversibility, and family/agency caution.	Does not validate a policy engine.
`planforge`	Goal decomposition, dependency-aware scheduling, tiering, fallback, and replanning.	Does not prove scheduler quality.
`ladon_manhattan`	Secret handles, secure entry paths, credential injection boundaries, and isolated compartments.	Does not prove kernel-level isolation or side-channel resistance.
`ext_tailscale_docs_2025`	Private overlay-network and identity-connectivity vocabulary.	Does not make reachability equivalent to authority.
`ext_kubernetes_overview_docs`	Container orchestration, rollouts, storage, bin packing, and self-healing vocabulary.	Does not encode ASI Stack data, family, or evidence membranes.
`ext_k3s_docs_2026`	Lightweight edge, homelab, IoT, CI, and embedded Kubernetes substrate candidate.	Does not prove the right personal-hive substrate.
`ext_nomad_docs`	Heterogeneous scheduling across containers, binaries, batch jobs, on-prem, and cloud.	Does not decide job lawfulness or personal-device safety.
`ext_ray_core_docs_2026`	Distributed task, actor, and object-reference vocabulary.	Does not prove safe data movement or hidden-state control.
`ext_boinc_home_2026`	Volunteer-compute lineage and background job participation.	Does not authorize arbitrary project work on personal machines.
`ext_syncthing_home`	File synchronization, device identity, encrypted transport, and user-controlled storage vocabulary.	Does not solve VCM revocation or semantic memory quality.
`ext_ipfs_docs`	Content-addressed, peer-to-peer artifact location and decentralized retrieval vocabulary.	Does not solve private hive memory, deletion, VCM revocation, privacy, authority control, or safe federation.
`ext_akash_docs_2026`	Decentralized cloud leases, providers, GPUs, SDKs, and rented-compute vocabulary.	Does not prove provider isolation or private-data suitability.
`ext_golem_docs_2025`	Decentralized computation, provider selection, task execution, and result handling vocabulary.	Does not prove output validity, payment fairness, or sandbox safety.
`ext_github_self_hosted_runners_docs`	User-managed CI runners as physical, virtual, containerized, on-prem, or cloud execution slots.	Does not prove unattended runner safety for untrusted work.
`ext_cap_theorem_gilbert_lynch_2002`	CAP-style consistency, availability, partition-tolerance, and safety/liveness trade-off vocabulary for partitioned authority, stale grants, revocation delay, and grant/effect races.	Does not prove deployed partition tolerance, consensus, availability, revocation propagation, or ASI Stack governance consistency.

59.23.1 Manifest source assignment reconciliation

These rows keep Personal Compute Hives and Federated Edge Intelligence’s manifest assignments visible at their recorded review boundary. Passage review does not establish local reproduction, performance, safety, deployment, or support-state movement.

Source	Intake role	Boundary
`beastbrain`	Passage-reviewed comparator: BeastBrain Cognitive Architecture. Passage-reviewed Mimic lineage for adapting execution to the actual host: hardware and memory-topology discovery, device-specific runtime profiles, thermal and power pressure, memory-tier policy, background-work shedding, and conservative fallback. The book turns this into a versioned HardwareProfileDecision with staged measurement, explicit rejected profiles, expiry, hysteresis, and state-safe transitions.	The source does not implement or validate hardware probing, direct SSD-to-accelerator paths, Apple Neural Engine access, thermal protection, paging, profile switching, sub-five-second adaptation, device safety, useful performance, or transfer. Low-level probes cannot expand data rights, tool authority, or execution authority. No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.
`ext_airllm_2023`	Metadata-first comparator: AirLLM: Scaling Large Language Models on Low-End Commodity Computers. Official implementation comparator for layer-wise model sharding, one-layer accelerator residency, next-layer prefetch, optional storage compression, and original-versus-transformed model storage. Maintainer-reported fit and speed claims are not independently reproduced.	No passage-level source claim, local implementation, reproduction, safety, performance, deployment, support-state, or ASI result is established by this reconciliation row.
`ext_deepspeed_inference_2022`	Metadata-first comparator: DeepSpeed Inference: Enabling Efficient Inference of Transformer Models at Unprecedented Scale. Primary heterogeneous-inference systems source spanning GPU, CPU, and NVMe for dense and sparse Transformer inference. Reported latency, throughput, scale, and model-fit results remain source-scoped and unreproduced.	No passage-level source claim, local implementation, reproduction, safety, performance, deployment, support-state, or ASI result is established by this reconciliation row.
`ext_flexgen_2023`	Metadata-first comparator: FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU. Primary planned-placement source for GPU/CPU/disk tensor storage and access, batching, and optional weight/cache compression under latency-insensitive workloads. Its throughput results are not interactive-latency or local evidence.	No passage-level source claim, local implementation, reproduction, safety, performance, deployment, support-state, or ASI result is established by this reconciliation row.
`ext_hf_accelerate_big_model_inference_2026`	Metadata-first comparator: Hugging Face Accelerate: Loading Big Models into Memory. Official implementation documentation for automatic or explicit GPU/CPU/disk device maps and memory-mapped disk tensors. The documented sequential-dispatch, prefetch, and hard-drive-performance limitations make it a baseline, not a qualification result.	No passage-level source claim, local implementation, reproduction, safety, performance, deployment, support-state, or ASI result is established by this reconciliation row.
`ext_llama_cpp_memory_mapping_2026`	Metadata-first comparator: llama.cpp CLI Memory Mapping, Tensor Placement, and KV Offload Controls. Official consumer-runtime documentation for model load modes, memory mapping, DirectIO, GPU-layer and tensor placement, MoE CPU placement, KV offload, and KV data types. No local model or performance result is implied.	No passage-level source claim, local implementation, reproduction, safety, performance, deployment, support-state, or ASI result is established by this reconciliation row.
`ext_llm_in_flash_2024`	Metadata-first comparator: LLM in a Flash: Efficient Large Language Model Inference with Limited Memory. Primary flash-aware inference source for on-demand parameter loading, I/O cost modeling, transfer reduction, contiguous reads, windowing, and row-column bundling. Sparse/context-adaptive loading is not an exact dense paging result.	No passage-level source claim, local implementation, reproduction, safety, performance, deployment, support-state, or ASI result is established by this reconciliation row.
`ext_powerinfer_2024`	Metadata-first comparator: PowerInfer: Fast Large Language Model Serving with a Consumer-Grade GPU. Primary consumer-inference source for source-reported power-law neuron locality, hot-GPU/cold-CPU placement, adaptive predictors, and sparse operators. Architecture transfer and performance are not locally reproduced.	No passage-level source claim, local implementation, reproduction, safety, performance, deployment, support-state, or ASI result is established by this reconciliation row.
`ext_atsinfer_2026`	Metadata-first comparator: Automated Tensor Scheduling for Hybrid CPU-GPU LLM Inference on Consumer Devices. Very recent preprint comparator for tensor-granular static placement, load-aware dynamic transfer, and asynchronous CPU-GPU coordination on consumer devices. Only abstract/metadata were reviewed; reported results are provisional and unreproduced.	No passage-level source claim, local implementation, reproduction, safety, performance, deployment, support-state, or ASI result is established by this reconciliation row.

59.24 External literature and tooling queue

Initial source records and conservative source notes now exist for the most important adjacent systems named above, including content-addressed storage. Remaining queue items include secret-management systems, sandbox runtimes, family safety/tutoring systems, local-first databases, and privacy-preserving computation. Before those support claims, each needs a source record, source note, and explicit mapping to a hive claim.

59.25 Summary

Personal Compute Hives propose an owned placement substrate without pretending every reachable machine is safe to use. Their distinct responsibility is consumer-specific job admission and placement across separately owned portals, workers, stores, authority services, and external providers. The operational center is exact: freeze the job and authority boundary, attest roles, compile task-local leases, reject unlawful nodes before optimization, choose the least-authority adequate route, enforce the lease, and preserve complete artifact, effect, resource, recovery, and residual receipts.

The present evidence is deliberately narrower: seven schemas, 2 valid and 8 invalid admission fixtures, 3 valid and 6 invalid partition records, one no-change transition, and 26 finite Lean declarations. It proves neither useful hive behavior nor security, privacy, availability, efficiency, federation safety, or state-of-the-art performance. Those claims require the natural/adversarial, matched-baseline, causal, independent-reproduction, and transfer campaign defined above. That honesty matters because a hive can create pressure for compact generation, but compression is useful only when residual burden, verification cost, fallback, and displaced human work remain visible.

59.26 Evidence reconciliation (2026-07-16)

The invariant protocol, field meanings, and inference limits are stated once in Living Book Methodology. This packet contains only the chapter-specific projection; its authoritative per-atom rows are the personal-compute-hives-and-federated-edge-intelligence slice of experiments/claim_family_terminal_coverage/results/result.json.

The core remains blocked after full attempt at argument support. The strongest family attempt was Ambiguous routing and deliberation confirmatory campaign. Its exact boundary is: Mixed bounded routing effect with unsafe outputs and no support promotion; no general router, deliberation, or transfer claim. Across 77 atoms, the terminal ledger records 77 blocked_after_full_attempt.

Chapter-specific field	Value
Family / atom denominator	`CF-05` / 77 atoms
Terminal dispositions	77 `blocked_after_full_attempt`
Core	`personal-compute-hives-and-federated-edge-intelligence.core`: `blocked_after_full_attempt` at `argument`
Core attempted / missing lanes	`causal`, `empirical`, `executable`, `formal`, `source-synthesis` / `normative`, `transfer`
Attempted local lanes	`causal`, `empirical`, `executable`, `formal`, `source-synthesis`
Missing or unproved lanes	`normative`, `transfer`
Strongest family bundle	Ambiguous routing and deliberation confirmatory campaign (`natural_work`): A 32-task held-out real-model workload across eight tracks, four ingress modes, eight routing arms, and four stopping arms.
Negative controls	17 active control mutations; five disposition mutations; 15 preserved extra-compute harms; wrong-fast-path and unsafe-release accounting.
Accepted transitions	none
Maximum inference	Mixed bounded routing effect with unsafe outputs and no support promotion; no general router, deliberation, or transfer claim.
Reproduction / next burden	Replay `scripts/validate_p4_m6_routing_deliberation.py` and `scripts/validate_claim_family_terminal_program.py`; fill the named atom-specific lanes under a new prospective protocol.

59.27 Handoff

Federated compute creates pressure to make work smaller, cheaper, and more local, but smaller work is not automatically better work. Compact Generative Systems: Generate, Verify, Repair, and Residual Honesty gives that pressure an evidence boundary. It asks whether a compact core has merely moved complexity into verification, repair, review, fallback, or governance, and it requires those burdens to remain visible before compactness can count as efficiency.