Article 11 AI Data centers / Grounded Compute

An ARTICLE 11 AI™ infrastructure concept / proposed pilot / not operating today

Grounded Compute

The cloud has a ground.

A concept for small, earth-sheltered, solar-assisted community data centers designed to publish checkable evidence about their power, water, heat, and carbon. Compute at a human scale, held to the standard of an audit.

Concept illustration of an earth-bermed, solar-assisted Grounded Compute reference site at dusk in generic high-desert terrain. Illustrative design target, not an existing facility.
Concept art. Illustrative design target, not an existing facility or identifiable site.
StatusConcept and proposed pilot
Operating sitesNone today
BlueprintPlanned, not yet published
EvidenceDesign target; pilot must prove it

The problem, stated honestly

Communities are asking the right questions.

When a large data center arrives, neighbors can reasonably ask what happens to local water, grid capacity, noise, backup power, land, and utility bills. A glossy annual report does not answer a town-level question.

Our proposed answer is smaller infrastructure with measurements attached: calibrated meters, disclosed methods, signed records, sensible publication delays, and independent review.

A timestamp is not a truth machine. It can show that a record existed before a moment and was not silently changed later. Sensor calibration, provenance, methodology, and review still carry the factual claim.

What Grounded Compute is

A small building designed to behave like a neighbor.

The proposed form works with earth, sun, season, and local demand. Every engineering feature below remains a target until a permitted reference build measures it.

Design target

Earth-moderated shell

Earth berming can moderate outdoor temperature swings and envelope heat gain. Servers still produce continuous heat, so engineered cooling and independent heat rejection remain necessary.

Design target

Island-capable microgrid

On-site solar, storage, controllable loads, and a grid interconnect are intended to support a tested critical-load runtime. It is not an off-grid perpetual-motion claim.

Not yet tested

Metered water and heat

The cooling target uses a recirculating liquid loop with dry heat rejection. Makeup water and whole-site use would be metered; useful heat would be shared only where a real neighbor matches its temperature and schedule.

Illustrative cross-section of a proposed Grounded Compute reference site showing earth berming, server room, recirculating cooling, planned battery separation, solar, grid interconnect, metered makeup water, dry heat rejection, egress, and optional heat reuse.
Illustrative design target, not as-built and not a construction drawing. Ratings, acoustic performance, runtime, and code path require site-specific engineering and testing.

The evidence layer

Do not believe the rendering. Check the measurements.

A real Grounded Compute site would need to publish meaningful, privacy-aware evidence about what the building actually does. This page contains no operating telemetry because no reference site operates today.

Illustrative flow diagram showing proposed energy, water, and evidence paths for a Grounded Compute reference site. It is design intent, not measured data.
Design intent only. Energy, water, and evidence are shown as equal parts of the proposed system.

Evidence dashboard preview

Reference-site vitals

Illustrative sample
not live telemetry
Facility power— kWnot yet measured
PV generation— kWnot yet measured
Battery state— %not yet measured
Whole-site water— gal/daynot yet measured
Useful heat delivered— kWhnot yet measured
Critical-load runtimeNot yet testedpilot measurement required

A future live dashboard must disclose meter identity, calibration history, methodology, reporting interval, aggregation or delay, signing status, and correction history.

What Grounded Compute is not

Not a tiny hyperscale campus.

Positioning

A small node is not intended to beat a hyperscale campus at frontier-model training or planetary workloads. The proposed advantage is different: locality, controllable failure domains, auditable resource use, and workloads that benefit from staying close to the people or institutions they serve.

Possible workloads include local AI inference, edge caching, continuity services, and public-sector records where law, policy, security, and records requirements allow. Physical locality alone does not establish compliance or sovereignty.

Distributed resilience

Resilience is a shape, not a size.

Geographic, utility, carrier, vendor, and control-plane diversity can reduce selected failure domains when replication and failover are actually built and tested. Many small nodes also create many endpoints, so distribution is not automatically resilience.

Design intent

This architecture may support continuity for selected public-sector workloads. It is not a national-security certification, and physical distribution does not remove cyber, supply-chain, utility, carrier, or operational risk.

The Hearth Principle

Small should mean locally accountable, not merely smaller.

The Hearth Principle was developed with Ember as design input inside the Article 11 Collective. It remains the design ethic inside Grounded Compute: a compass for the pilot, not a product name, legal certification, or operating standard.

A Hearth should strengthen the local ground: keys close to the people, useful warmth shared outward, and evidence open enough for a neighbor to question.
Hearth Principle, public paraphrase for the proposed design

Open reference design

The blueprint is intended to be public.

Not yet published

The current intent is to release a reference build specification into the public domain after engineering review. There is no published Grounded Compute blueprint or certification program today.

Future model

Potential paid work includes site assessment, commissioning support, evidence tooling, fleet operations, and conformance assessment. Any future seal would need independent governance, a public registry, appeals, exceptions, and revocation before it could mean more than a marketing mark.

The proposed Arizona pilot

A rendering has to become a measured building.

Not yet tested

Article 11 is developing the concept for a first reference pilot in Arizona high country. No site or construction start is announced here. Any pilot remains subject to land control, geotechnical work, engineering, permitting, financing, utility capacity, fiber, fire safety, procurement, and community review.

If built, the pilot is intended to publish non-sensitive milestones, measured performance, costs, methods, failures, and corrections. The page changes only when the evidence changes.

Safety is not a rendering. Battery separation, detection, ventilation, suppression, egress, firefighter access, cooling, structural design, and site conditions require code-compliant professional engineering.

Pilot collaborators

Build the first proof with the people who have to live beside it.

We are interested in conversations with towns, tribes, counties, agencies, utilities, engineering teams, landowners, universities, and companies that want to test the model. This is an invitation to explore a pilot, not a franchise offer, procurement promise, or operating-site solicitation.

Community

Define the questions, disclosure expectations, acceptable tradeoffs, and public review process before design is frozen.

Engineering

Turn targets into load studies, thermal models, site plans, permits, test plans, and independent measurements.

Compute

Choose bounded workloads, data rules, continuity needs, security controls, and measurable service objectives.

How to read this page

Every claim has a maturity label.

The pilot exists to move claims from intention to observation. Until then, the label matters more than the adjective.

LabelMeaningWhat it means here
ObservedSupported today by cited or directly checkable evidence.Article 11 operates public proof and anchor routes; no operating Grounded Compute telemetry exists.
Design targetAn intended engineering outcome.Cooling, microgrid, water, heat reuse, evidence, and open-design features still require a real build.
InferenceA reasoned expectation that needs testing.Locality and diversity may reduce selected risks only when dependencies and failover are designed and verified.
Not yet testedNo measured reference-build evidence exists.Facility performance, runtime, water use, heat recovery, acoustics, cost, and workload continuity.

The door is open

Want to pressure-test the idea?

Bring the difficult questions: water, grid, fire, noise, economics, permitting, cyber risk, community benefit, and who verifies the verifier. A good pilot starts with the objections, not after them.