Case Studies

These are four systems built on AIEP in production. Each started from a specific, observable problem. The outcome in each case is measurable, not theoretical.

Case Study 1 — Piea

The problem

Enterprise AI assistants produce confident-sounding answers with no evidence trail. When an answer is wrong, there is no record it was ever produced. When a claim is challenged, there is no way to replay the reasoning. Users cannot verify whether the source was current, who issued it, or whether it has been altered.

This is not a UX problem. It is an epistemic infrastructure problem: the reasoning pipeline was never designed to produce verifiable outputs.

What AIEP changed

Piea is an enterprise AI assistant built entirely on the AIEP Piea Surface (P116–P128). It did not add evidence governance as a feature. Evidence governance is how the system works.

Every response Piea produces:

• Retrieves evidence from live sources and verifies TLS and source integrity before use
• Computes a response_hash (SHA-256 over the GENOME-normalised output) and commits it to the session ledger
• Generates a 5-step Replayable Reasoning Chain, persisted as a verifiable record
• Detects ambiguous questions and answers both valid interpretations against shared evidence (Semantic Branch Detection)
• Records dissent when the evidence is mixed, rather than suppressing minority positions

Observable outcome

Any response Piea produces can be:

• Replayed — the 5-step reasoning chain is persisted; any party can confirm the output followed from the evidence
• Hash-verified — the response_hash is stable; any alteration of the response content is mechanically detectable
• Evidence-pinned — sources are committed with a content_hash at retrieval time; the source cannot be silently updated after the response was issued

When Piea is wrong, the error is visible and traceable. That is a structural capability most AI systems do not have.

→ Piea specification · → Try Piea at piea.ai

Case Study 2 — Forecast

The problem

Construction projects generate thousands of instructions, variations, notices, and snagging records. These are legally significant — they determine who is liable, how much is owed, and what was actually agreed. Almost none of them are formally linked to the evidence that justifies them.

When a dispute arises (and in construction, disputes are common), reconstructing the evidence chain is manual, expensive, and retrospective. Lawyers spend months finding documents that should have been linked from day one.

What AIEP changed

Forecast is a full-stack construction project management platform. Every legally significant event — an instruction, a variation, a notice, a snag, an incident — is automatically committed as a GENOME artefact at the moment it is recorded.

Evidence is not something users add later. It is a consequence of how the platform works: you cannot record a contract event without AIEP generating a committed evidence record at the same time.

Observable outcome

A legal evidence report generated from Forecast is:

• Self-contained — everything needed to verify the chain is embedded in the report
• Hash-verifiable — a third party can independently confirm the report’s integrity without access to the Forecast platform
• Time-stamped — every event carries a committed timestamp; no backdating is possible after the hash is committed

→ Forecast specification

Case Study 3 — QARDL

The problem

Professional identity in the trades is poorly verified. A contractor can present a CSCS card that may be expired, belong to someone else, or refer to a qualification that has since been revoked. There is no standard machine-readable way to check a professional credential at the point of hire.

For AI-assisted hiring platforms and automated site access control, this is not an edge case — it is a core problem. Systems that assess credentials are only as reliable as the identity substrate they use.

What AIEP changed

QARDL (Qualified Artefact Record and Digital Ledger) provides cryptographically verifiable professional identity for UK tradespeople, contractors, and regulated professionals.

Each credential — a CSCS card number, a Gas Safe registration, a Companies House number, a professional qualification — is committed as a GENOME artefact and chain-linked. When a credential is revoked or expires, the chain records the change. There is no way to present a stale credential as current without the hash mismatch being detectable.

The QARDL Identity Code (QIC):

QARDL-USR-3a8f1c-7    (individual)
QARDL-ORG-b72d04-3    (company)
QARDL-AGT-c91f22-9    (AI agent — P118)

is a stable, machine-readable identity handle derived from GENOME canonical hashing. It is not a username or a database ID — it is a cryptographic commitment.

Observable outcome

A platform or AI system querying a QIC can:

• Verify current credential status — not from a screenshot or a PDF card, but from a live GENOME artefact
• Detect divergence — if the credential has changed since last verification, the chain records the delta
• Confirm issuer identity — the credential is bound to the issuing organisation via its AIEP Mirror surface

Governance level (tier 1–4) is computed from the artefact chain, not manually assigned. A contractor cannot claim a higher tier than their committed record supports.

→ QARDL specification

Case Study 4 — AIEP Miner

The problem

Autonomous systems making decisions in the physical world — interacting with hardware, executing financial transactions, controlling machines — are rarely governed in any formal sense. Actions are taken because the system decides to take them. There is no cryptographic record of what was in scope, what was suppressed, and why.

For regulators, insurers, and operators, this is a governance void. When something goes wrong, the audit trail is a log file — not an evidence artefact.

What AIEP changed

AIEP Miner connects to ASIC cryptocurrency miners and governs every hardware interaction under the AIEP protocol. It demonstrates that an autonomous system operating in an adversarial environment — real machines, real money, real failure modes — can be fully governed.

Every decision point:

• Telemetry poll → a content-hashed record committed to the evidence ledger
• Action suppressed → a Negative Proof record (P37) committed, proving the action did not occur — absence is proven, not merely asserted
• Anomaly detected → a Divergence record (P37) committed: staleness, temperature gate, physical impossibility, or error state
• Mode transition → MANUAL → AUTONOMOUS gate requires a valid authority hash before hardware dispatch

The evidence ledger is append-only and chain-linked. Any action taken (or not taken) is reproducible from the committed inputs.

Observable outcome

An operator or regulator reviewing an AIEP Miner deployment can:

• See every decision — not infer it from a log, but replay it from committed evidence
• Verify every suppression — Negative Proof records confirm that unsafe actions were blocked, not just absent
• Audit the chain — the append-only ledger cannot be altered without detection
• Switch modes with governance — AUTONOMOUS mode cannot be entered without a committed authority hash

AIEP Miner is open-source under Apache 2.0. It is not a cryptocurrency product. It is a proof that AIEP governance works on physical systems under real operating pressure.

→ AIEP Miner specification · → Full reference implementations

What these four systems share

Each of these systems was built on the same protocol. The problems they solved are different. The governance layer underneath is identical.

This is the key point the case studies illustrate: AIEP is not a single product. It is a governance protocol that applies the same verifiable properties to any system that adopts it.

Build on AIEP: Get Started · Integration Guide · Builders Programme