Research cards

How it works — A unified memory architecture lets the CPU and GPU share the same 128GB pool, avoiding the classic consumer-GPU ceiling where VRAM (typically 16–24GB) forces model size or precision compromises.

Why Solystopia cares — This is the first machine in the Hearthmind trajectory: the concrete answer to "can a household afford and power meaningful local AI capability" without appeal to hypothetical future hardware.

Practical constraints

• 01Capital cost: £3,999–£4,699 up front, no financing model assumed.
• 02Electricity: continuous idle draw plus load draw, metered against local tariff.
• 03Knowledge: household needs baseline comfort installing and maintaining a local model runner.
• 04Maintenance: no long-run reliability data yet from household (rather than datacentre) use.
• 05Regulation: none currently anticipated for personal-use household compute.

Readiness — TRL 8–9 (commercially available, shipping product) for the hardware; TRL 4–6 for validated household-scale daily-use workflows built on top of it.

What would need to happen next

• 01Independent long-run (6–12 month) household reliability and maintenance data.
• 02Published tokens/kWh benchmarks specific to Spark hardware (not extrapolated from Apple Silicon or RTX 4090 figures).
• 03A published open model-selection guide matched to 128GB unified memory.
• 04Comparative capital-efficiency data against a self-built alternative (e.g. used enterprise GPUs).
• 05Documented solar/battery coupling case studies at household scale.

Related work

• 01Apple Silicon unified-memory local inference (comparable architecture, different ecosystem).
• 02Consumer GPU (RTX 4090-class) local inference (higher power draw, lower unified memory).

Questions worth investigating

• 01What is the actual measured tokens/kWh for common open models on Spark hardware, under household (not benchmark-lab) conditions?
• 02How does capital efficiency (£/petaFLOP) compare to a self-assembled used-hardware alternative?
• 03What is the realistic multi-year maintenance burden for a household without a systems administrator?
• 04At what household size or workload does a Spark stop being sufficient, and a neighbourhood-scale node become justified?

How it works — Two identical NVMe drives are mirrored so every write lands on both; if one fails, the household loses no data and keeps running on the survivor while it is replaced. A separate NAS holds periodic snapshots so a mistake or ransomware event on the live mirror does not propagate into the only backup.

Why Solystopia cares — Hearthvault is what makes "the household owns its intelligence" true at the data layer, not just the compute layer. Without it, the Spark is a fast processor for data that still, in practice, has no guaranteed local home.

Practical constraints

• 01Capital cost: roughly £650 for a mirrored NVMe pair plus an 8TB NAS at current retail prices.
• 02Physical space: a NAS enclosure is a second piece of hardware in the household, not a line in a cloud invoice.
• 03Maintenance: mirrors need monitoring for silent single-drive failure, or the household is one more failure away from data loss without realising it.
• 04Knowledge: household needs baseline comfort with a snapshot/backup schedule, even if it is scripted.

Readiness — TRL 9 (mirrored storage and NAS backup are mature, widely deployed patterns) for the mechanism; TRL 3 (early prototype, not yet built) for Hearthvault’s specific household implementation.

What would need to happen next

• 01Measured figure for actual model-library + household-document storage requirements after 3–6 months of real use.
• 02A tested, scripted nightly snapshot routine specific to the Hearthmind data layout.
• 03A documented recovery drill: simulate a drive failure and time how long restoration actually takes.
• 04A comparison of ZFS mirror vs. simpler rsync-based redundancy once real usage patterns are known.

Related work

• 01The First Machine (HM-001) — Hearthvault exists specifically to protect the model weights and data that machine produces and consumes.
• 02Hearthmind Software and Hearthdata Foundry side quests, both of which depend on Hearthvault as their storage substrate.

Questions worth investigating

• 01Is a ZFS mirror worth its added operational complexity for a single-operator household, versus simpler redundancy?
• 02How much local storage does a genuinely useful model library plus household document set require, once measured rather than estimated?
• 03What is the real, tested time-to-recovery after a simulated drive failure — not the theoretical figure?

How it works — The household network is split into VLANs — one for Hearthvault and compute, one for general household devices, one for energy telemetry — with a firewall enforcing which traffic can cross between them. The Spark’s QSFP ports, when a second unit is added, bypass the household LAN entirely for machine-to-machine model-serving traffic.

Why Solystopia cares — Hearthnet is what stops the Spark and Hearthvault from being isolated appliances that happen to sit in the same room. It is the layer that lets compute, storage, and (eventually) energy telemetry cohere into one household-owned system rather than three unrelated boxes.

Practical constraints

• 01Capital cost: a managed switch with VLAN support and, if scaling to a second Spark, a second unit plus QSFP cabling.
• 02Knowledge: VLAN configuration, firewall rules, and (for remote access) VPN setup require intermediate networking skill.
• 03Physical: a second Spark for clustering is a substantial additional capital outlay, not a casual upgrade.
• 04Maintenance: network hardware (switches, routers) is commodity and locally serviceable, unlike the Spark’s SoC.

Readiness — TRL 9 (VLAN segmentation, firewalling, and 10GbE homelab networking are mature, widely deployed patterns) for the mechanism; TRL 2 (design only, not yet built) for Hearthnet’s specific household implementation.

What would need to happen next

• 01A built and tested VLAN/firewall boundary around Hearthmind’s compute and storage traffic.
• 02A documented, tested WireGuard (or equivalent) remote-access setup for when the household is away.
• 03Measured throughput and latency figures for the household’s actual switch and cabling, not vendor specification sheets.
• 04A decision on whether a second Spark and 200Gbps clustering is ever justified at this household’s scale, versus staying single-node.

Related work

• 01The First Machine (HM-001) and Hearthvault (HM-002) — Hearthnet is the connective layer between the compute and storage nodes those quests establish.
• 02Multi-Spark vLLM clustering guides, which validate that the 200Gbps fabric works in practice, even though Hearthmind has not yet built a two-node cluster.

Questions worth investigating

• 01Is a commercial mesh router acceptable for the household boundary, or does a self-hosted router OS (e.g. OPNsense) better match the sovereignty argument?
• 02How is remote access handled when the household is away — a permanent WireGuard tunnel, or no remote access at all by default?
• 03At what point, if any, does a second Spark and clustered fabric become justified for this specific household’s workload?

How it works — A metered smart plug reports the Spark’s real-time power draw into a time-series store (e.g. Prometheus, via Home Assistant); the same store holds solar generation and battery state of charge. A scheduler can then compare the two and prioritise heavy inference jobs during surplus generation, deferring them when the battery is low or the grid tariff is high.

Why Solystopia cares — Hearthpower is what makes the Spark’s energy footprint a fact rather than an estimate, and what opens the possibility of the household’s AI capability becoming energy-positive rather than purely additive load. It is also the quest that gives every other Hearthmind claim about cost and sustainability a number to stand on.

Practical constraints

• 01Capital cost: a metered smart plug is inexpensive; a household solar array or battery, if not already present, is a substantial separate investment.
• 02Attribution: a shared household solar array complicates cleanly attributing "renewable share" to the Spark specifically without a dedicated sub-meter.
• 03Knowledge: building a scheduler that ties workload timing to energy signals requires basic home-automation and scripting skill.
• 04Data: a full year of metered data is needed before seasonal patterns (and a genuine annual TCO figure) can be trusted.

Readiness — TRL 9 (PUE/ERE metrics and household energy-scheduling tools are mature and proven) for the underlying techniques; TRL 2 (not yet instrumented) for Hearthpower’s specific application to this household’s Spark.

What would need to happen next

• 01Installation of a metered smart plug and at least one full month of logged kWh data, replacing the independent-reviewer estimate with a household-measured figure.
• 02Definition of locally relevant metrics — tokens per kWh, renewable fraction, heat reused — matched to this household’s actual generation mix.
• 03A first working integration between workload scheduling and existing PV/battery telemetry, even in a minimal form.
• 04A full twelve-month dataset to support a genuine, seasonally-aware total-cost-of-ownership report.

Related work

• 01The First Machine (HM-001) — Hearthpower supplies the metered energy data that machine’s TCO report ultimately depends on.
• 02Hearththermal, which depends on Hearthpower’s telemetry to establish whether waste heat is worth capturing at this household’s scale.

Questions worth investigating

• 01Does a shared household solar array need a dedicated sub-meter to keep the "renewable fraction" figure honest, or is a proportional estimate acceptable?
• 02How well, in practice, can AI inference jobs be deferred to periods of surplus generation without degrading day-to-day usefulness?
• 03What is the real payback period, if any, for adding dedicated battery capacity specifically to smooth the Spark’s load?

How it works — Ambient and surface temperature loggers placed near the Spark establish a baseline for how much heat it actually adds to a room under sustained load. If the differential and duration are large enough, a simple passive measure (placement, ducting) or a small supplemental fan could redirect that heat somewhere useful rather than simply venting it.

Why Solystopia cares — Hearththermal is the honesty check on any claim that a household AI node is "efficient" in a fuller sense than electricity cost alone. It also tests, at the smallest possible scale, the same heat-reuse logic that operates at datacentre scale in the peer-reviewed literature this quest draws on.

Practical constraints

• 01Capital cost: temperature loggers are inexpensive; any active heat-reuse equipment (ducting, fans) is a small but real additional cost.
• 02Scale: at roughly 170–240W, the Spark’s heat output is orders of magnitude below the datacentre-scale systems this quest’s evidence base is drawn from — findings may not transfer directly.
• 03Honesty: this quest should be willing to conclude that heat reuse is not worthwhile at this scale, if that is what the data shows.

Readiness — TRL 9 (heat reuse from liquid-cooled data centres is proven at scale) for the underlying physics; TRL 1 (no measurement yet taken) for Hearththermal’s household-scale application.

What would need to happen next

• 01Baseline ambient and surface temperature logging around the Spark during sustained workloads.
• 02A documented placement and airflow recommendation based on that baseline data.
• 03A go/no-go assessment of whether any active heat-reuse experiment is justified at this power scale, made honestly even if the answer is no.

Related work

• 01Hearthpower (HM-004), whose telemetry establishes the load duration and intensity that determines how much heat is actually available to reuse.
• 02NREL’s ESIF and 5GDHC research, the datacentre-scale analogue this household-scale experiment is testing the limits of.

Questions worth investigating

• 01Is any meaningful heat reuse realistic at Spark-level power draw, or is that overreach for a single desktop unit?
• 02Does room placement alone (rather than any active ducting or fan) already solve any practical heat problem this device creates?
• 03What is the minimum measured temperature differential that would make even a passive heat-reuse measure worth the effort?

How it works — A minimal stack layers a container runtime, a model server (such as Ollama or vLLM) serving quantised open-weight models sized to the 128GB unified-memory ceiling, a vector database for retrieval-augmented generation, and an observability layer (Prometheus/Grafana) for monitoring — all defined as versioned configuration so the entire stack can be torn down and rebuilt deterministically.

Why Solystopia cares — This is the layer that makes "the household controls its AI workflows" literally true rather than aspirational. Without it, the Spark is fast hardware running whatever default software ships with it, auditable by no one in the household.

Practical constraints

• 01Platform maturity: GB10’s Blackwell architecture is new enough that some AI tooling requires nightly builds or manual workarounds rather than stable releases.
• 02Knowledge: operating CUDA 13, container orchestration, and infrastructure-as-code requires intermediate-to-advanced technical skill.
• 03Maintenance: keeping pace with a fast-moving toolchain (nightly PyTorch builds, evolving sm_121 support) is an ongoing burden, not a one-time setup cost.

Readiness — TRL 7–8 (the individual open-source components are mature and widely deployed) for the ecosystem; TRL 2 (design and early experimentation) for Hearthmind’s specific integrated stack.

What would need to happen next

• 01Selection and integration of a minimal, rebuildable stack: Linux base, container runtime, model server, vector database, and observability layer.
• 02A finalised model library matched to the 128GB unified-memory ceiling, chosen for real household use rather than benchmark scores.
• 03A decision on whether the household-facing interface should work from any device on Hearthnet or remain a single local web UI.
• 04A documented, periodically-tested recovery procedure for rebuilding the stack from bare metal.

Related work

• 01The First Machine (HM-001), which supplies the hardware this stack runs on, and Hearthvault (HM-002), which supplies its storage substrate.
• 02Hearthdata Foundry (HM-007), which depends on this stack’s vector database and model-serving layer to make household documents queryable.

Questions worth investigating

• 01Should the household interface be a simple local web UI, or does it need to work from any device on Hearthnet?
• 02Which model sizes actually deliver a good day-to-day experience inside the 128GB memory ceiling, once tested rather than assumed?
• 03How much of the stack’s ongoing maintenance burden can realistically be automated away versus requiring continued manual attention?

How it works — Household documents are ingested, embedded with a local embedding model, and indexed for retrieval so the model can answer questions grounded in this household’s actual manuals, records, and notes rather than generic training data. Each dataset carries metadata on source, licence, and allowed use, kept physically inside Hearthvault rather than any external service.

Why Solystopia cares — This is the quest that makes local AI capability specific to the household that owns it, rather than a generic assistant that happens to run locally. It also keeps the most sensitive material — the household’s own documents — inside the sovereignty boundary Hearthvault and Hearthnet establish.

Practical constraints

• 01Tooling maturity: no embedding model or vector index has yet been selected specifically for household scale, as opposed to enterprise deployments.
• 02Evaluation: without a documented methodology, claimed improvements from fine-tuning cannot yet be measured, only assumed from the general literature.
• 03Provenance discipline: keeping a clean separation between public research data, private household data, and licensed third-party corpora requires ongoing metadata hygiene, not a one-time setup step.

Readiness — TRL 6–7 (the underlying techniques — RAG, fine-tuning, dataset versioning — are proven in general AI practice) for the mechanism; TRL 1 (no pipeline built yet) for Hearthdata Foundry’s specific household implementation.

What would need to happen next

• 01An initial household document inventory with provenance and licensing metadata attached to each source.
• 02Selection of a local embedding model and a vector index sized appropriately for household (not enterprise) scale.
• 03An evaluation design capable of actually measuring whether fine-tuning or RAG improves task performance on household-specific queries.
• 04The first household document set fully ingested and queryable end to end.

Related work

• 01Hearthvault (HM-002), whose storage substrate this quest’s datasets and indices depend on.
• 02Hearthmind Software (HM-006), whose model-serving and vector-database layer this quest’s retrieval pipeline runs on top of.

Questions worth investigating

• 01Is a full vector database overkill at household scale, or does simplicity actually argue for one anyway rather than a simpler search index?
• 02What evaluation methodology would actually prove that fine-tuning on household-specific data improves real task performance, rather than just plausibly should?
• 03How should the household draw the line between what it fine-tunes on versus what it only retrieves via RAG?