FAQ

What is Kristal Farms, in one sentence?

A modular compute site built around heat reuse: tenants run compute, and the infrastructure captures waste heat to support district heating and greenhouse production, under explicit community governance.

Is this “just a data center”?

No. A conventional data center treats heat as waste and optimizes for compute alone.

Kristal Farms is designed so compute and useful heat are co-products, and so priorities (heat, environment, community benefit) are governed rather than left to operator discretion.

Who is it for?

The host community: heat, infrastructure investment, jobs/training, and long-term resilience.
Tenants: reliable, high-quality compute capacity and network access.
Local institutions: improved connectivity and potentially heat supply for public buildings (phase dependent).

Do tenants’ workloads become visible to the host?

No by design.

Kristal Farms uses a black-box tenancy boundary:

the host provides pad utilities (power, cooling interfaces, fiber) and monitors infrastructure health,
the tenant controls everything inside the module (hardware, software, keys, workloads).

See: Tenancy model →

Does Kristal Farms require the Kristal technology?

No.

Kristal Farms is infrastructure. It can host many kinds of compute tenants.
Kristals are a separate technology (verifiable knowledge artifacts) that can optionally be produced/served using available compute.

See: Kristal (technology) →

What does “heat-first” mean?

Heat-first means the operating model treats useful heat delivery as a priority constraint, not a marketing add-on.

When there is a real tradeoff (seasonal demand, storage limits, maintenance), the system follows an explicit policy for:

which buildings/services are prioritized,
when curtailment happens,
and how decisions are reported.

See: Heat-first design →

How is heat actually reused?

At a high level:

compute pads generate heat,
heat is transferred through controlled interfaces into a community heat loop,
heat is delivered to buildings and/or greenhouse systems,
storage buffers mismatches between supply and demand.

See: How it works →

What about environmental safety (water, discharge, local ecosystems)?

Environmental safeguards are treated as hard constraints:

monitoring and limits,
incident procedures,
and oversight via governance (not only internal operations).

See: Environment & safety →

Who governs the project?

Kristal Farms is governed by named bodies with explicit mandates (steering, heat priorities, environmental limits, and knowledge-council topics if applicable).

The goal is to keep priorities explicit, measurable, and correctable.

See: Governance →

How will the public know if it’s working?

Through a published metrics & dashboard approach: energy and water performance, useful heat delivered, uptime, network reliability, and community benefit indicators.

See: Metrics & dashboard →

What is the rollout plan?

Kristal Farms is intended to scale in phases:

prove the loop (pads + heat delivery + monitoring + governance),
extend heat distribution and greenhouse capacity,
reach steady-state operations and replication.

See: Phasing →

What are the “Go / No-Go” conditions?

Before expansion (or even initial power-on), the project should meet clear gates:

community agreements signed,
infrastructure commissioned and monitored,
safety and environmental procedures proven,
governance seated and functioning,
reporting/dashboards live.

See: Go / No-Go gates →

Can the site be removed or reversed if the project ends?

Reversibility is part of the design intent: modular pads and a restoration plan so the site can be returned without permanent scarring.

See: Reversibility →

Is this “AI infrastructure”?

It can host AI workloads, but it is not defined by AI. The defining features are:

modular compute tenancy,
heat reuse as a first-class outcome,
environmental limits,
explicit governance,
and public accountability.

Where do I start if I’m new?

I want technical details. Where are they?

This site prioritizes what it does and how it is governed. Technical specifics (interfaces, commissioning checklists, etc.) can live in internal documentation or a separate “Reference” area if needed.

Some previously uploaded reference files in this workspace have expired; if you want me to align wording to earlier documents line-by-line, re-upload them.