The pipeline · v1.1 · Phase R complete · May 12 2026
~10 min read
Build the software. Contain the AI inside it.
Two pipelines, one substrate, one cryptographic chain. Build-time: regulation → typed spec → 49 deterministic generators → 3 target languages → signed audit bundle. Runtime: every LLM call your emitted product makes — bounded by a closed-enum schema, gated by §67 reviewer queue, fallback-safe, signed into L12 with Ed25519, anchored under L1 to Bitcoin. The pattern that v0.1 used at build time is now operational at runtime. Phase R: shipped.
00 — Runtime-AI containment (Phase R, v1.1)
Every LLM call your product makes, cryptographically bounded.
Most "AI inside a regulated product" pitches diagram the constraint. Promethean ships it. The runtime SDK (runConstrainedAI) takes a RuntimeAISpec + an input, validates the input against the spec's schema, calls the LLM, validates the LLM output against a closed-enum schema, routes through §67 reviewer-queue if the spec asks, applies the declared fallback if the model fails, and appends one signed L12 receipt per decision. Product code never sees an unconstrained LLM output.
paysafe
fintechpaysafe-fraud-classifier
L12 entries
12
Reviewer gate
on-low-confidence @ 0.85
Anchors
- PSD3 Art. 13 SCA
- DORA Art. 23
- PCI-DSS 4.0 Req. 10.2
See the chain →
cliniclens
healthcarecliniclens-note-structurer
L12 entries
10
Reviewer gate
always-human
Anchors
- HIPAA §164.312(b)
- EU MDR Art. 5/10
- EU AI Act Annex III §5
See the chain →
civicgate
govtechcivicgate-message-router
L12 entries
10
Reviewer gate
on-low-confidence @ 0.80
Anchors
- eIDAS Reg. 910/2014
- GDPR Art. 22
- AI Act Annex III §5(a)
See the chain →
The architectural commitment
AI as building material, not arbiter. The substrate has had this commitment since v0.1, when build- time AI was caged to a single step (intent → ProductSpec) followed by 49 deterministic generators. Phase R (May 12, 2026) extended the same discipline to runtime: every LLM call a substrate-emitted product makes goes through runConstrainedAI, every output is closed-enum-validated, every decision is signed into L12 under the same Ed25519 trust anchor that covers L1–L11. Multi-tenant L12 isolation (R4). Federated cross-substrate convergence on shared specs (R5).
CI enforcement: three adversarial-autoplay strategies catch attempts to bypass the containment — unconstrained-llm-import, raw-llm-completion-payload, runtime-ai-spec-without-closed-enum-output. A developer who imports @anthropic-ai/sdk outside src/lib/runtime-ai/ fails the autoplay scan before the PR merges.
Verify any L12 chain in one command
# Download a real signed chain — paysafe, cliniclens, or civicgate $ curl -O https://promethean.software/paysafe-runtime-ai-receipts.jsonl # Verify in 30 seconds with Node 18+ stdlib only $ npm run substrate:verify-runtime-ai -- paysafe-runtime-ai-receipts.jsonl Promethean L12 Runtime-AI Receipt Log ===================================== total entries: 12 products observed: paysafe specs observed: paysafe-fraud-classifier schema violations: 2 ← out-of-enum LLM outputs (both fallback-handled) fallback triggered: 2 ← (1 schema-violation, 1 LLM-error) reviewer-gated: 2 ← low-confidence queued + verdict-recorded valid: true fully verified: 12 / 12
01 — From regulation
Regulation is the spec.
Pre-v0.14, the operator wrote a ProductSpec — what entities, what features, what tech stack. That works for prompt-driven builders. It does not work in regulated markets, where the operator usually knows what regulation says and needs software that provably satisfies it. v0.14 introduces a layer above ProductSpec.
RegulatorySpec → ProductSpec derivation
The operator declares regulatory requirements as structured data; the substrate derives a ProductSpec that provably satisfies them via a hand-curated 25-article mapping table across seven frameworks. Per-requirement DerivationProofs explain which derived feature satisfies which article. Hash-anchored. Unmapped requirements surface explicitly as gap-acknowledged for hand-review — the substrate never silently invents.
GDPR
Art. 6, 7, 15, 17, 20, 25, 30, 33, 35
EU AI Act
Art. 9, 10, 12, 13, 14, 15, 50
PCI-DSS 4.0
3.4, 4.1
ISO 27001
A.5.1, A.16
DORA
Art. 17, 18
NIS 2
Art. 23
HIPAA
§164.312, §164.408
// Operator declares:
const regulatorySpec = {
productDomain: "fintech",
requirements: [
{ framework: "gdpr", articleId: "art-30",
obligation: "Records of processing activities",
citationUrl: "https://eur-lex.europa.eu/..." },
{ framework: "pci-dss-4", articleId: "3.4",
obligation: "Render PAN unreadable wherever stored", ... },
{ framework: "eu-ai-act", articleId: "art-14",
obligation: "Human oversight requirements", ... },
],
};
// Substrate derives:
const { productSpec, derivation } = deriveProductSpec({
regulatorySpec, productName: "paysafe", ...
});
// productSpec.features now contains:
// audit-log (derived from gdpr art-30)
// records-of-processing (derived from gdpr art-30)
// pci-vaulted-card-storage (derived from pci-dss-4 §3.4)
// ai-human-oversight (derived from eu-ai-act art-14)
//
// productSpec.tech.payments = "stripe" (PCI requirement triggers it)
// derivation.derivationHash = "<sha-256 of canonical form>"
//
// Every feature traces to an EUR-Lex citation. Mathematical
// derivation chain from regulation to emitted file.02 — Deterministic emission
Three target stacks. One closed-enum dispatch.
v0.15 generalises the substrate beyond TypeScript+Next.js. The TargetStack closed-enum dispatches per target — the same MultiLangSpec emits a Next.js app, a FastAPI service, or an Axum binary. Adding a fourth stack is one ADR + one entry in the closed-enum vocabulary.
TypeScript + Next.js
Reference target (substrate's own stack)
package.json + app/ + src/ + tests/
Python + FastAPI
Regulated finance / scientific computing
pyproject.toml + app/main.py + tests/
Rust + Axum
Defense / high-assurance / low-latency
Cargo.toml + src/main.rs + tests/
v0.15 ships minimum-viable scaffolds per target — the multi-stack architecture works end-to-end (package manifest, HTTP routes, health endpoint, smoke tests, README all emit correctly per target). Feature-parity across stacks (auth, payments, full audit-log, etc.) is v1.x scope — additive on top of the locked architecture, not blocked by it.
Why deterministic at the emission layer
The same ProductSpec produces byte-identical output across runs. Same regulatory inputs → same derived ProductSpec → same emitted file tree → same SHA-256 Merkle root → same L4 build receipt. Two regulators auditing the same product independently get bit-for-bit identical results.
LLM intelligence enters at one bounded edge: the IntentSynthesizer (v0.2) translates a natural-language description into a structured GeneratorIntent if the operator authors via prose rather than code. After that intent is approved (v0.3-1 review gate), the synthesis path is pure-template, deterministic, and auditable. AI proposes; the deterministic core disposes.
03 — Adversarial autoplay
The substrate attacks its own emitted products.
v0.12 turns the substrate's red-team energy outward. After emission, eight closed-enum attacker strategies run against the emitted code. Static analysis, deterministic, CI-safe, no network. Successful attacks generate AntiPatternCandidates for §47.3 admission review; failed attacks credit the relevant generator's strength score. AlphaZero-style self-play applied to software production.
missing-rate-limit-on-mutation
missing-csrf-on-state-mutation
sql-injection-via-template-string
xss-via-dangerous-inner-html
secrets-in-source
missing-input-validation
unbounded-pagination
permissive-cors
Each strategy returns one of three closed-enum outcomes: attack-blocked, attack-succeeded, or inapplicable. The reportHash is deterministic — same emitted product always produces the same autoplay report regardless of when or where the autoplay runs. Adding a ninth strategy is an ADR + a row in the closed-enum vocabulary.
04 — Provenance + runnable bundle
Every emitted product carries its own audit.
Every product the substrate emits carries an L4 build receipt — Ed25519-signed over the canonical form, committing to ProductSpec hash, corpus root, generator versions, file-tree Merkle root, state.json reference, and (since v0.3-4) the full meta-generator lineage of every meta-emitted generator that contributed. The receipt is the customer's bit-for-bit reproducibility contract.
L4 build receipt
{
"schemaVersion": "promethean-build-receipt-1.0",
"productName": "paysafe",
"productSpec": { "hash": "<sha-256>", ... },
"corpus": { "rootHash": "<sha-256>", ... },
"generators": { "versionsHash": "<sha-256>", ... },
"output": {
"treeRoot": "<sha-256 over file tree>",
"totalFiles": 447,
"totalBytes": 1843720
},
"metaGeneratorLineage": {
"lineageHash": "<sha-256>",
"entries": [ /* per-meta-emitted-generator records */ ]
},
"attestation": {
"algorithm": "ed25519",
"publicKey": "HM6MRfGkwyFa1HN+/XG40rGmYwPyaYvhnINJmv4ntME=",
"signature": "<base64>",
...
}
}Runnable audit bundle (v0.16)
Roll up: the substrate produces a single directory containing state.json + every log file + every build receipt + the audit conclusion + an embedded plain-JS verifier (Node 18+ stdlib only, ~500 lines, zero npm install). A regulator runs:
tar xzf substrate-audit-bundle.tgz cd runnable-audit-bundle/ node verify.mjs # → exit 0 (PASS) or exit 2 (FAIL)
No Promethean code at verification time. The substrate produces the bundle; the operator hands it over; the regulator verifies it offline. The substrate's verifiable-disappearance contract: Promethean can vanish, archived bundles still produce green/red verdicts against the published Ed25519 trust anchor.
05 — Reflexive variant
The same pipeline, turned inward.
v0.7 closes the recursion. The same meta-generator that emits product code emits substrate components of itself — modules placed under contrib/jarvis/src/synthesized/ that the rest of the substrate's own code imports at runtime.
First synthesis · v0.7
corpus-trend-analyzer.ts
intentHash: ccc8e5c4… · 133 lines · category: analyzer
Reads the substrate's corpus JSONL, groups entries by topic, classifies per-topic trend (rising / falling / flat / insufficient-data) using §65.1's small-N discipline. Imported by the substrate's own analytics surface.
Second synthesis · v0.8
lineage-chain-summarizer.ts
intentHash: 52bde153… · 150 lines · category: analyzer
Reads the L11 substrate-component log itself and produces aggregate summaries. The deeply reflexive closure: a substrate-emitted module that analyses substrate-emitted modules.
Both modules compile cleanly with the 113 hand-written modules under tsc --noEmit. Both are behaviourally tested against real fixtures with no mocking. Every emission is Ed25519-signed at point of recording and chained into L11 — and the L11 head is anchored into state.json under L1 (which is anchored to Bitcoin under L8). The vision-doc claim "the substrate produces the systems that produce software" is operational at every layer.
06 — See it running
Three product previews. Synthetic data; real architecture.
What a substrate-built product looks like when running. UI is realistic; data is synthetic; click-throughs don't navigate. The framing question per preview: "if your regulator audited this product, what would they verify?"