Piea — The Architecture in Production

Piea is not a concept. It is a running system.

It is an enterprise AI assistant built from scratch on the AIEP evidence substrate. Every response Piea generates is backed by retrieved evidence, cryptographically committed, and independently replayable. Every source is inspected for integrity, every session is persisted in a tamper-evident ledger, and every operation Piea takes is governed by the same constitutional constraints the protocol defines in the abstract.

Piea proves the architecture works.

Piea is live at piea.ai. Enterprise access, API documentation, and vertical specialist modes are available there.

What Piea is

Piea is what an AI assistant looks like when it is built on AIEP rather than on a prediction engine.

A standard AI assistant retrieves text and predicts a confident-sounding answer. It cannot tell you which sources it used. It cannot show you their provenance. It cannot prove the answer has not changed since it was generated. It cannot archive its uncertainty. It cannot replay its reasoning.

Piea does all of these things — not as added features, but as the consequence of running on an AIEP substrate.

AIEP is not the model — it is the evidence layer around the model

Piea uses a large language model to generate text. That is not AIEP’s claim.

Every capable AI assistant uses a language model. The model produces text. The text can be good or bad, accurate or hallucinated, useful or misleading. Model quality is a real dimension — but it is not what AIEP governs.

AIEP governs what wraps the generation. Before the model sees a question, Piea has already:

• retrieved live sources and committed each one to an evidence chain (P37)
• inspected every source’s network path for integrity flags (P124)
• qualified the evidence window to remove noise (P117)

After the model generates a response, Piea has:

• bound the response to its evidence set with a cryptographic commitment (R8)
• checked whether the evidence was sufficient — and if not, emitted a dissent record (P126)
• stored the full reasoning chain in a form any third party can replay (P127)

The model is the generation engine. AIEP is the governed evidence substrate the model operates on.

When evaluating Piea against other AI assistants, the relevant question is not “which model generates better text?” — it is “which system can prove what sources it used, verify they were not tampered with, and produce a hash any third party can independently check?” No other system answers that question. Piea does — as a structural property of running on an AIEP substrate, not as a claimed feature.

What Piea implements

Piea is a direct production implementation of the AIEP Piea Surface patent cluster (P116–P128). It is the reference implementation of what governed AI inference looks like at the application layer.

Cryptographic spine

Every Piea response is built on GENOME R1–R8 — the eight canonical primitives:

• R1 canonical_json — deterministic serialisation of every artefact
• R2–R3 sha256 — hash binding at every step
• R4 concat_hash — chain construction across evidence items
• R5 evidence_commitment — session evidence set committed before answer generation
• R6 lifecycle_hash — lifecycle event binding
• R7 negative_proof_hash — absence proven, not merely asserted
• R8 response_commitment — the answer itself, hash-bound to its evidence

No response can exist in Piea’s ledger without a valid R8 commitment over its evidence chain.

The Evidence Rail

The Evidence Rail is Piea’s live audit surface — shown as a persistent right panel in the UI. For every response, it displays:

• Source URLs with metadata
• ContentHash (SHA-256) where available — detects alteration since retrieval
• Confidence tier: verified · qualified · unverified · community
• Source integrity flags: VPN · Relay · No TLS · Geo-Restricted · Stale
• Time since retrieval (retrieved_at)

The evidence rail is not a footnote. It is the primary governance surface. Every source that influenced a response is visible, inspectable, and linkable.

Dissent Signal Engine (P126)

When Piea’s retrieved evidence is insufficient to meet the confidence threshold, it does not silently answer with reduced confidence. It generates a DissentSignal — a governed record containing:

• The triggering question
• The number of sources retrieved
• The confidence threshold that was not met
• The specific reason for dissent

The dissent record is persisted to the evidence ledger. It is not a warning message. It is a first-class artefact in the session’s evidence history.

Replayable Reasoning Chain (P127)

Piea streams its reasoning steps to the UI before the final answer — over the same SSE channel. Each step is a structured ReasoningStep:

1. Query classification
2. Source identification
3. Evidence retrieval and qualification
4. Cross-source synthesis
5. Confidence determination and response commitment

The terminal step (step 5) carries the response_hash as its completion signal. The full reasoning chain is stored as a first-class field of the session record — independently replayable from the stored evidence set.

Semantic Branch Detection (P128)

When Piea detects a semantically ambiguous query — one that is valid under two distinct interpretive frameworks — it does not ask for clarification. It answers both interpretations simultaneously, each grounded in the same retrieved evidence set.

Each SemanticBranch carries:

• The interpretive framework it applies
• A complete answer grounded in the shared evidence
• A confidence tier for this specific interpretation
• An is_primary flag preserving the conventional reading

Both answers are persisted in the session record. This is not AI equivocation. It is a governed protocol response to genuine interpretive ambiguity — each branch independently auditable.

The infrastructure

Piea runs entirely on Cloudflare’s edge:

Every component is edge-deployed. No centralised server. No single point of failure. The substrate continuity layer (P116) maintains reasoning state across channel changes without data loss.

Multi-model dispatch

Piea does not route every question to a single model. Every query is classified into one of eight types (factual, procedural, analytical, generative, administrative, domain, conversational, smalltalk) and dispatched accordingly:

• Factual / procedural → Workers AI (Llama-3.3-70B) against retrieved evidence
• Analytical / complex → Multi-model LRM: Workers AI + OpenAI GPT-4o + Claude Sonnet + Ollama run in parallel; a four-dimension consensus weights evidence alignment, source completeness, claim overlap, and model agreement
• Domain / internal → custom sources only; no substrate legislation injected
• Conversational → no sourcing; direct response

The LRM consensus produces a single governed answer synthesised from all model perspectives — not the output of one model but a hash-committed synthesis of their agreement. Dissent zones where models diverge are surfaced to the evidence rail.

Cross-source synthesis engine

Beyond answering individual questions, Piea can run a synthesis operation across the full evidence source graph for any topic. Four modes:

The integration surface scan is particularly useful for compliance and investment teams: it identifies exactly where Piea can provide evidence-grounded answers without approximation — and which regulatory changes are worth adding to a monitoring watchlist.

Vertical specialist modes

Seven domain modes reconfigure the full evidence pipeline — sources, system prompt, and confidence routing — without separate applications:

Enterprise: multi-tenancy, SSO, and data connectors

Piea is a production enterprise system. It runs with full tenant isolation from day one:

Multi-tenancy and RBAC — each tenant has a scoped evidence ledger, five RBAC roles (super_admin → viewer), and an independent subscription lifecycle. White-label UI is available at enterprise tier.

SSO — OIDC and SAML supported: Google, Microsoft (Entra ID), Okta, and Cloudflare Access JWT. Per-tenant SSO provider configuration. Credentials stored in Cloudflare Secrets — never in D1.

Internal data connectors — PostgreSQL, MySQL, REST API, SharePoint, S3/R2, CSV/JSON feeds. Internal query results are committed to the Evidence Ledger with the same artefact schema as web sources. Piea treats internal and external evidence identically — the retrieval pipeline cannot distinguish origin.

Integrations — Slack, Microsoft Teams, and generic webhooks with signed payloads. Five event types: piea.response, piea.source.added, piea.source.drift, piea.export.ready, piea.session.resumed. TypeScript SDK (@piea/integrations) for external developers.

App Expert Helper protocol (PF-009)

Any AIEP application can call Piea as a domain expert helper using the AppContext protocol. The calling app prepares:

• live_context — pre-fetched app data (project summary, snag list, positions, etc.)
• mode — vertical specialist mode to activate
• source_priority — domain-relevant URLs to boost
• expertise_kb — static KB chunks committed to the evidence rail

Piea grounds its answer in the app’s live data along with retrieved external evidence — producing an answer that knows both the current state of the application and the current state of the regulatory environment. AIEP Forecast uses this to give Piea live project and CRM context. Any AIEP-compliant application can do the same with no schema changes.

The critical claim is not that Piea is a good AI assistant. The critical claim is that an AI assistant built on AIEP cannot behave like a hallucinating prediction engine — not because it is instructed not to, but because the architecture prevents it.

A prediction-based AI can always generate a confident answer with no evidence. Piea cannot. Every response requires an evidence commitment before generation. An empty evidence set produces a dissent record, not a fabricated answer.

A prediction-based AI cannot prove its answer has not changed. Piea can. The response_hash is a cryptographic commitment over the answer and its evidence — tamper-evident and independently verifiable.

A prediction-based AI cannot replay its reasoning. Piea can. The full reasoning chain is stored as structured artefacts in the same session store as the response. Any session can be audited — step by step, source by source — from the ledger record.

This is what makes Piea evidence for AIEP, not just an application of AIEP. Piea demonstrates that the protocol is complete enough to build a real production system on — and that building on it produces properties no prediction-based architecture can match.

Try Piea

Piea is live at piea.ai. Enterprise access, API documentation, and vertical specialist modes are available there.

Related

• Architecture — the seven-layer AIEP stack Piea implements
• Evidence Layer — normalisation, stitching, and recall
• GENOME SDK — the cryptographic kernel Piea runs on
• Showcase — the full repository and test coverage record
• Patents — P116–P128: the Piea surface patent cluster