AIEP Miner — Verifiable Control of Autonomous Systems

AIEP Miner is a reference implementation of the AIEP protocol applied to a real-world autonomous system.

It connects to ASIC cryptocurrency miners and monitors their operation, makes governed decisions — run, stop, restart — records every action and every input, and produces a complete, immutable audit trail. Every cycle. Without exception.

This is not a cryptocurrency product. It is a controlled demonstration that autonomous systems can be governed.

The problem with autonomous systems today

Most autonomous systems act on live data, make decisions automatically, and cannot explain or prove those decisions afterwards.

The system took an action. Or it did not. Either way, the record is incomplete — a log of what happened, not a proof of why. When something goes wrong, the reconstruction begins: hours of log correlation, disputed timestamps, contested inputs. Evidence assembled after the fact, under adversarial conditions, is not evidence. It is argument.

This is a problem in finance, energy, infrastructure, and AI. It becomes a regulatory problem when the system causes harm. It becomes a legal problem when the harm is disputed. It becomes a systemic problem when the pattern repeats across thousands of independent systems, none of which can demonstrate that their behaviour was governed.

AIEP Miner demonstrates the alternative.

An autonomous system whose behaviour is fully verifiable, auditable, and replayable — not as a claimed feature, but as a structural property of how it works.

What it demonstrates

Six properties. Each one proven end-to-end on physical hardware.

Autonomous systems can be governed

No action is dispatched unless the evidence required to justify it is valid. If the telemetry is stale, the decision cycle records a Negative Proof and halts. If the operator mode is MANUAL, the decision cycle records a Negative Proof and halts. The hardware never moves without a valid evidence chain behind the command.

Decisions can be audited

Every decision has a complete evidence trail: the telemetry record that entered the cycle, the price feed at time of evaluation, the profit calculation, the divergence check result, the governance gate check, and the action taken or suppressed. A regulator can inspect any decision in the ledger and reconstruct the full reasoning cycle from the committed inputs.

Systems can prove non-action

When an action is blocked — by a governance rule, an operator mode, a failed safety check — this is not recorded as silence. A Negative Proof is written to the ledger: a structured record stating what was considered, what gate blocked it, and why. Absence is proven, not merely asserted.

Behaviour is deterministic

Same inputs produce the same decision every time. The decision logic contains no hidden state. Given any committed telemetry record and price record, any party can re-run the cycle and confirm the system made the correct decision under the rules in force at that moment.

Real-world systems can be regulated

This is not a simulation. AIEP Miner runs against physical ASIC hardware on a live network. The financial stakes are real. The adversarial conditions — temperature spikes, pool outages, comms failures — are real. The governance holds under all of them.

Failures are first-class evidence

Comms failures, data anomalies, impossible sensor values — these are not swallowed and ignored. They are detected by the divergence layer and committed to the ledger as structured records. A system that fails silently cannot be audited. A system that records its failures as governed artefacts can.

Cycle architecture

Each monitoring cycle follows a fixed seven-step sequence. Nothing is skipped. Nothing is reordered.

POLL → DIVERGENCE CHECK → COMMS HEALTH → PRICE CHECK → PROFIT → DECIDE → EXECUTE

The ledger receives a record at every step where something materially happened. By the end of any cycle, the full chain of evidence — inputs, evaluations, decisions, outcomes — is committed and immutable.

The evidence ledger

Every record type is written to a separate append-only log:

All records are:

• Append-only — nothing is ever modified or deleted
• Content-hashed — each record carries a SHA-256 hash of its canonical form
• Chain-linked — each record’s hash is derived from its content and the hash of the prior record in the same stream

Any modification to any past record breaks the chain. The ledger cannot be silently edited.

Divergence detection

Divergence detection is not error handling. It is a governed safety gate that runs before every decision, every time.

The gate checks:

• Telemetry staleness — data older than two polling intervals is not acted on
• Hardware error state — an ERROR pool state blocks the cycle
• Physical impossibility — temperature below absolute zero, negative hashrate, negative power draw — values that cannot exist are not silently discarded, they fail the gate explicitly
• Over-temperature — configurable threshold, default 85°C
• Warning temperature — configurable threshold, default 75°C
• Price feed validity — null price, stale price, non-positive price all fail the gate

The divergence layer also tracks consecutive comms failures per miner. When the failure count exceeds the configured threshold, it outputs a structured commsFailure check result that the orchestrator escalates to a RESTART decision.

The entire divergence check result is available to the decision cycle and preserved in the evidence chain. A decision record always reflects whether the divergence check passed cleanly or was overridden.

aiep-divergence-proof (P37) is the next integration here. Where the current divergence-detector package writes a NegativeProofRecord into the internal ledger, aiep-divergence-proof generates a standalone cryptographically-bound proof document — a self-contained artefact suitable for submission to a regulator or legal panel. The NegativeProof already exists in the ledger. The proof document makes it independently presentable without access to the running system.

Execution governance

The execution surface is the final gate before hardware is touched. Its job is to enforce the governance rules regardless of what the decision layer produced.

Two modes:

MANUAL — The operator has declared that no automated actions are permitted. Every decision — including RUN and RESTART — is suppressed. A Negative Proof is written with reason operator_mode_manual. The hardware is not touched.

AUTONOMOUS — Decisions are dispatched. STOP calls stopMiner. RESTART calls restartMiner. RUN uses restartMiner to bring the unit back to an active state. THROTTLE is not yet hardware-implemented and produces a Negative Proof with reason throttle_not_supported.

Every path through the execution surface produces a written record. There is no execution path that consumes a decision and produces no evidence.

aiep-hardware-agent (P09R) sits one layer below this. The current execution surface dispatches stopMiner() and restartMiner() as software commands over the CGMiner TCP API. The aiep-hardware-agent implements a governance-chip kill-switch signal — a hardware-layer enforcement mechanism that operates independently of the software stack. A compromised or malfunctioning controller cannot override it. This is the enforcement floor that a regulated autonomous system requires: software governance for normal operations, hardware governance as the unconditional backstop.

Architecture

AIEP Miner is a pnpm monorepo targeting Node 20. Nine packages, two applications.

Controller API — Fastify on port 3001, exposes fleet status, the evidence ledger, and the control loop over REST.

Dashboard — React + Vite SPA deploying to Cloudflare Pages. Reads VITE_API_URL for the API address; the controller stays on the local mining network.

Multi-operator deployment

A single AIEP Miner deployment can govern fleets belonging to multiple independent principals — operators — from one controller process. Each operator is an independent governance identity: their own miners, their own ledger partition, their own API credentials, their own operator mode.

This is not a pooling architecture. Evidence is not shared. One operator’s telemetry does not flow into another operator’s ledger. The governance boundary between operators is structural, not policy-enforced.

Why multiple operators matter

The single-operator architecture demonstrates that one autonomous system can be governed. Multi-operator demonstrates that governed systems can be deployed at scale — an infrastructure provider managing fleets on behalf of multiple clients, a data centre operating units under different regulatory regimes, a managed service running operators in separate jurisdictions — all under one governance stack, with clean evidence isolation between them.

This begins the path to federation (P264, P265, P269): the property that independently governed systems can share evidence without sharing control.

Operator identity

Each operator is defined by:

Every DecisionRecord and NegativeProofRecord written to the ledger carries the operatorId of the operator whose cycle produced it. The evidence chain is operator-scoped at the record level.

Ledger isolation

In a multi-operator deployment, the evidence ledger is partitioned:

./ledger/operator-alpha/decisions.jsonl
./ledger/operator-alpha/telemetry.jsonl
./ledger/operator-beta/decisions.jsonl
./ledger/operator-beta/telemetry.jsonl

Operator Alpha cannot read or write Operator Beta’s ledger. The partition boundary is enforced at the path level, not by access control alone.

In a single-operator deployment the partitioning collapses back to ./ledger/ — no migration required.

API routes

Multi-operator routes follow a consistent pattern:

GET  /operators/:operatorId/miners
GET  /operators/:operatorId/miners/:id
POST /operators/:operatorId/miners/:id/start
POST /operators/:operatorId/miners/:id/stop
POST /operators/:operatorId/miners/:id/restart
GET  /operators/:operatorId/ledger/:type
POST /operators/:operatorId/loop/run-once
POST /operators/:operatorId/loop/run-once/:minerId

Single-operator convenience routes (/miners, /ledger/*, /loop/run-once) remain fully available and backwards-compatible. A single-operator deployment does not need to change anything.

Authentication

Every route requires an Authorization header:

Authorization: Bearer <operatorId>:<hmac>

The HMAC is computed with the operator’s apiSecret over the message <operatorId>:<METHOD>:<URL>. A valid token for GET /operators/alpha/miners cannot be used for POST /operators/alpha/miners/001/stop — the method and URL are embedded in the signed message, preventing replay across routes.

AUTH_DISABLED=true bypasses authentication in local development only.

Configuration

Three configuration modes, in order of precedence:

OPERATORS_JSON — a full JSON array of OperatorConfig objects. Suitable for secrets managers and container environments that inject structured config.

OPERATOR_N_* indexed env vars — one variable group per operator:

OPERATOR_0_ID=operator-alpha
OPERATOR_0_LABEL=Alpha Mining Ltd
OPERATOR_0_MODE=AUTO
OPERATOR_0_SECRET=secret-for-alpha
OPERATOR_0_MINER_0_IP=192.168.1.101
OPERATOR_0_MINER_0_ID=antminer-001
...
OPERATOR_1_ID=operator-beta
OPERATOR_1_SECRET=secret-for-beta
...

Legacy single-operator vars (MINER_0_*, OPERATOR_ID, API_SECRET) — unchanged from v1.0. Existing deployments require no config changes.

Federation path

Multi-operator is Phase 5 of the AIEP Miner roadmap. It sets the foundation for Phase 6+ federation:

• P264 — Inter-operator evidence sharing: a governed mechanism for operators to share ledger artefacts across trust boundaries without sharing their controllers
• P265 — Federated governance reconciliation: cross-operator governance decisions whose evidence chain spans multiple independent ledgers
• P269 — Multi-party execution gate: a compound execution surface that requires attestation from more than one operator before dispatching a hardware action

These specs are not yet implemented. Multi-operator is the structural prerequisite that makes them buildable.

Why Bitcoin mining was chosen

Bitcoin mining provides the ideal conditions for demonstrating governed autonomous control:

• Deterministic rules — profitability calculus is a closed formula; the correct decision is objectively computable from the inputs
• Measurable outputs — hash rate, power, temperature and revenue are continuous, quantifiable signals
• Adversarial environment — hardware varies, pools go offline, difficulty adjusts, prices move; robustness is tested by the environment itself
• Real financial consequences — wrong decisions cost money; the system cannot be validated against a toy dataset

The goal is not mining performance. The goal is proving that a system operating under adversarial conditions — real money, real hardware, real-time data — can make every decision in a way that is fully explainable, auditable, and governed.

The same protocol across three domains

AIEP Miner shares its core specs with Piea and QARDL. None of these implementations know about the others. They were built independently on the same protocol. That is what a protocol means.

Three completely different domains. Same architecture. Same guarantee: every action is traceable, every suppression is proven, every cycle is replayable.

AIEP stack integration

AIEP Miner is designed to integrate with the broader AIEP stack as the reference implementation matures.

aiep-node — hardware attestation layer

The controller-API runs on a physical machine. That machine can be registered as an AIEP Trusted Node (P09R, P37). When it is, every decision record in the evidence ledger carries a node attestation signature — the commit is not just hash-linked but origin-attested. The chain of evidence extends from the sensor data all the way back to the attested hardware identity of the system that processed it.

The aiep-node emulator is published as open-source developer tooling. Wiring Miner’s controller to a node attestation endpoint is a planned Phase 6 integration.

ledger-v2 — canonical ledger substrate (P80)

Miner currently uses JSONL as its ledger backend. The dual-ledger architecture (P80) formalises the separation that Miner already implements architecturally: mutable working state (the in-memory comms failure counter) stays separate from the immutable evidence record (the JSONL append log). The ledger-v2 substrate makes that separation explicit, adds multi-participant write governance, and ties Miner to the canonical ledger spec. Migration is a Phase 4 item.

Piea — reasoning layer above the control loop (Phase 7)

The evidence ledger is already the correct substrate for PIEA-layer reasoning. Once Miner’s ledger is populated with real telemetry cycles, Piea can be wired above the control loop to produce meta-governance analysis:

• trending comms failures across the fleet
• systematic divergence between predicted and actual profitability
• anomalous decision patterns — cycles where the evidence was valid but the outcome deviated from baseline

Piea reads the evidence ledger as its source corpus. It writes its analysis as governed artefacts back into the same ledger. Nothing in the Miner architecture needs to change to support this. The ledger is already structured for it.

aiep-governance-engine — formal policy layer (P38, P82)

Miner’s current governance logic is hardcoded: MANUAL or AUTONOMOUS, two states, checked inline. The aiep-governance-engine (P38, P82) is the declarative policy layer that replaces this. Governance rules are expressed as formal policies — evaluated at runtime against the current evidence state — rather than compiled into the control loop. This enables:

• operators defining custom governance rules without code changes (e.g. “halt all miners if BTC price falls below $X”)
• policy versioning — each rule set is a versioned, hash-pinned artefact in the evidence ledger
• policy audit — every governance decision traces to the exact policy version in force at the time

The current MANUAL/AUTONOMOUS check is a degenerate case of a single two-state policy. The governance engine generalises it without breaking the existing architecture.

aiep-compliance — regulatory certification (P92, P93)

The page makes the regulatory case for AIEP Miner at length. The aiep-compliance package closes that loop structurally. Given a completed decision cycle in the evidence ledger, aiep-compliance produces a signed compliance artefact — a cryptographically committed record asserting that the system operated within a defined regulatory envelope for a given jurisdiction and time window.

The compliance artefact contains:

• the evidence ledger hash range it covers
• the governance policy version in force
• the jurisdiction scope
• a cryptographic signature from the complying node

This is not a self-reported compliance claim. It is a provable statement derived from the evidence chain. A regulator does not need to trust the operator’s word. They verify the artefact against the ledger.

For Miner, this means: every operating period can produce a compliance certificate. Every certificate is independently verifiable. The audit burden moves from retrospective reconstruction to prospective verification.

piea-execution-surface — P121

Miner’s execution-surface package and the piea-execution-surface repo implement the same governed-dispatch pattern under P121. The difference is domain: Piea’s execution surface governs AI agent computer-use actions (browser operations, file writes, API calls). Miner’s execution surface governs hardware commands (stop, restart, throttle). The gate logic — check governance rules, dispatch or suppress, write receipt or Negative Proof — is structurally identical. This is the clearest demonstration that P121 describes a general execution governance mechanism, not an AI-specific one.

Generalisation

The same architectural pattern — telemetry ingestion, divergence gating, utility evaluation, governed decision, evidence-bound execution, append-only ledger — applies directly to:

• Energy grid control — automated load balancing with auditable dispatch records
• Industrial automation — machine command governance with Negative Proof on safety gate failures
• Financial trading systems — position decisions bound to the market data that triggered them
• AI agent execution — every computer-use action preceded by a governed authorisation record (P121)
• Construction site management — Forecast already implements the evidence substrate for contract administration

AIEP Miner is the simplest possible form of this pattern, made concrete on physical hardware. The same packages — divergence detector, evidence ledger, execution surface — wire into any domain that requires governed autonomous operation.

Licensing

AIEP Miner is open source under Apache 2.0. The source is available for inspection, forking, and non-commercial use without restriction.

Commercial deployment of the core governance packages — kernel, evidence-ledger, divergence-detector, execution-surface — requires an AIEP patent licence from Phatfella Ltd. This is the mechanism that ensures the AIEP architecture is adopted with structural fidelity rather than reverse-engineered in name only.

The architecture is open. The obligation is to use it properly.

Status

AIEP Miner is under active development as an AIEP reference implementation.

• Source: repos/public/aiep-miner
• Stack: Node 20 · pnpm monorepo · Fastify · React + Vite · Cloudflare Pages
• @aiep/[email protected] substrate: ✓ Active
• Evidence ledger: ✓ Active (JSONL, content-hashed, operator-partitioned)
• Divergence detection: ✓ Active — 18/18 tests passing
• Execution governance: ✓ Active — MANUAL / AUTONOMOUS mode enforcement
• Multi-operator: ✓ Active — per-operator ledger isolation, HMAC auth, dual routing
• Dashboard: ✓ Cloudflare Pages ready

AIEP Miner and the protocol

Traditional systems log what happened. AIEP systems prove:

• what happened
• why it happened
• why the alternatives were rejected
• and whether the system was permitted to act at all

AIEP Miner is not about mining. It is the first open-source demonstration that an autonomous system operating on physical hardware, under real financial pressure, in an adversarial environment, can be fully governed — with every decision, every suppression, and every failure committed as tamper-evident evidence.

No competitor can show this cleanly. Because no competitor has built it.