Promethean · Solution Brief — Runtime-AI in Regulated Products

Document type Solution brief · VP Product · Head of Platform · Head of AI · Staff Engineer with budget Length ~7 pages Last revised 2026-05-18 (v1.3 — post-launch hardening) Reading time 12–15 min Companion docs PRODUCT_DATASHEET · TECHNICAL_ARCHITECTURE · COMMERCIAL_DATASHEET · PROMETHEAN_THEORY_AND_FINDINGS (canonical theory paper)

1. The problem you came here with

Your engineering team built an AI feature. The model works. The product team wants to ship. Then it hits the compliance review.

The objection is rarely "the model is wrong." The objection is structural:

• "We have no way to prove what the model decided in production."
• "There's no bounded liability surface — the model could output anything."
• "GDPR Article 22 says the citizen has the right to know about automated decisions. We can't answer that question."
• "Our PSD3 / HIPAA / DORA / MDR auditor wants per-call evidence. We have logs, not evidence."
• "The model is a black box. We can't defend it to a regulator."

Two quarters later: the feature is still not shipped. Your engineering team has a tested, working AI feature in a feature/runtime-ai branch that won't merge to production.

The pattern is universal. Every Fortune-500 board has the same mandate (ship more AI) and the same stuck pilot (compliance won't approve). Every regulated industry — fintech, healthcare, govtech, insurance, utilities — has the same shape.

2. Why the existing vendor stack doesn't close this

You have probably tried, or are evaluating, vendors in adjacent categories. Each closes part of the gap:

None of them, individually or in combination, produces what a regulator actually asks for: a chain of signed evidence per AI decision, bounded by a declared schema, with falsifiable claims about what the model can output.

This is the architectural gap the substrate closes.

3. What the substrate does

A RuntimeAISpec is the contract for one type of LLM call your product makes. Five closed-enum fields plus a substrate-defined schema:

{
  specId:           'fraud-classifier',          // kebab-case identifier
  category:         'classifier' | 'extractor' | 'drafter' | 'router' | 'summariser',
  modelIdentity:    { provider, model, version },
  outputSchema:     { /* closed-enum vocabularies enforced */ },
  reviewerGate:     'always' | 'on-low-confidence' | 'never',
  fallbackBehavior: 'deterministic-default' | 'rethrow' | 'silent-pass-through',
  deterministicDefault: <safe default>,          // used when fallbackBehavior = 'deterministic-default'
}

(Full spec is 13 fields — displayName, description, inputSchema, promptTemplate, maxLatencyMs, etc. See TECHNICAL_ARCHITECTURE §3.)

Your product calls one function: runConstrainedAI(spec, input, options). Behind that call:

1. The model is invoked. Latency tracked.
2. Output is validated against outputSchema. Schema failure → fallback executes.
3. reviewerGate is checked. If it fires, the call routes through your reviewer queue.
4. One L12 entry is written: signed under your Ed25519 key, hash-chained to the previous entry, with inputHash (PII-safe), outputCanonicalHash, modelIdentity, latencyMs, schemaValid, reviewerVerdict, fallbackTriggered.
5. The L12 HEAD is anchored into Bitcoin via OpenTimestamps every 5 minutes.

That's it for your code. Your engineers wire ~10 lines of integration. Everything from canonical form to Bitcoin anchoring is downstream of one function call.

4. Three reference deployments, three regulator rails

Each ships a real signed chain. Each verifies under the same Ed25519 trust anchor since v0.1. Each survives every Phase R release (R0 → R5 → v1.1.7 → v1.2 → v1.3 hardening) without signature break — backward compatibility empirically demonstrated, not just claimed. Each chain verifies in <250 ms; benchmarks at 1K/5K/10K entries are at PROMETHEAN_THEORY_AND_FINDINGS §5.2.

Run node verify.mjs against any of these. 30 seconds. No installation. The verifier is plain JavaScript with zero dependencies (~500 lines; live LoC + sha256 at /api/facts/verifier-loc). The three chains are also available as a copy-pasteable workflow at /examples.

Regulatory coverage today

Manifest at /api/facts/regulatory-coverage lists nine regulations with primer pages — EU AI Act, GDPR (including Art. 22), DORA, NIS 2, MDR, HIPAA, PSD3/PSR, IDD, CCPA — and which of them ship handoff templates today (seven do; CCPA and IDD do not yet).

Pattern-match your domain to one of these three. If your AI feature lives in fintech / healthcare / govtech with similar regulatory rails, the pilot conversion is largely about adapting the existing spec patterns. If your domain is elsewhere (e.g., insurance underwriting, utilities load balancing, education credentialing), the pilot week-1 spec phase is where we co-design from scratch.

5. The 90-day pilot

A fixed-scope path from "stalled compliance review" to "production deployment with regulator-readable evidence packet." Six gated phases:

€185,000 fixed for the 90 days. Sized to fit a Q1 platform capex envelope. Two substrate engineers on-call. One product, one regulator rail.

Pre-registered falsification clauses: success looks like (a) feature ships with audit sign-off, (b) audit-cycle time reduced ≥50% vs prior LLM-feature reviews, (c) regulator conversation moves from "show us the model" to "show us the chain," (d) zero spec-bypass paths in production. Failure looks like the spec can't express the decision surface, reviewer-gate latency overwhelms SLA, or compounding-coefficient falls below 1.0. We tell you in advance what would falsify the pilot — and record honestly when it does.

6. Operator outcomes (what changes after the pilot)

If the pilot succeeds, your organisation gains four operational properties:

A. Compliance reviews accelerate

Audit / legal / GRC stop asking "is the model safe" and start asking "show me the chain." Per-decision evidence answers what model-card claims and observability logs cannot. Typical pilot outcome: AI-feature compliance review time drops from quarters to weeks.

B. Regulatory conversations shift in shape

Pre-substrate: "Tell us about your AI." (Open-ended; vendor scrutiny; high uncertainty.) Post-substrate: "Here's the chain. Here's the verifier. Here's the mandate mapping." (Closed-form; verifiable; low uncertainty.)

Regulators we have spoken to consistently prefer the post-substrate framing — it's the conversation they have been asking for.

C. Engineering velocity recovers

The reviewer-gate predicate becomes the integration contract between your product team and your compliance / legal team. When compliance disagrees with the spec, the conversation is about the predicate (a typed function), not about "the model in general." Iteration cycles compress.

D. Liability surface bounds

GC has a concrete answer to "what can the model output?" — the union of (a) outputSchema valid values + (b) the declared fallback. PLD-defensible. Auditable. No "the model could say anything in principle."

7. Evaluation framework (how to decide)

Five questions to ask of any vendor in this category. The substrate's answers in brackets.

Q1: Per-call evidence? Substrate: Yes — one signed L12 entry per LLM call. Hash-chained, Bitcoin-anchored. [Reference: ADR (tt)]

Q2: Closed-enum output surface? Substrate: Yes — outputSchema enforced at request time; fallback executes on schema failure. [Reference: TECHNICAL_ARCHITECTURE.md §3]

Q3: Cryptographically verifiable without vendor trust? Substrate: Yes — plain-JS verifier (~500 lines, exact LoC at /api/facts/verifier-loc), runs offline against any Bitcoin full node. Zero Promethean code required on the verifier's side. [Reference: SECURITY_BRIEF.md §1; paper §2.2]

Q4: PII-safe by construction? Substrate: Yes — only inputHash (SHA-256) recorded; raw input never enters chain. [Reference: SECURITY_BRIEF.md §2 row 5]

Q5: Empirically demonstrated, not just claimed? Substrate: Yes — 243 Phase R tests across 16 suites (0 failed); 7,400+ total tests; mutation-tested with 75% break threshold; 8 cross-language byte-identity tests; 3 live reference deployments verifying across every release back to v0.1; six post-launch adversarial stress-test rounds closing 31 findings, all closed (paper §5; /release-notes for commit references); verifier benchmarks linear at 0.09 ms / entry to 10M entries (paper §5.2).

If a vendor cannot answer all five with "yes" plus evidence, they sit in an adjacent category, not in this one.

8. Procurement timeline

Total elapsed time from first read to pilot start: ~4 weeks for an organisation that already has the AI feature stalled in compliance review. The bottleneck is your internal review, not ours. We aim to keep our side under 5 business days at each step.

9. Common misconceptions

"This is just another GRC tool." No — GRC tools (Vanta, Drata, OneTrust) audit the software around the LLM. The substrate audits the LLM call itself. Different layer, different artefact, different reader (regulator vs auditor).

"This is just LangChain + signing." No — LangChain orchestrates; the substrate bounds. The substrate's value is the closed-enum schema enforcement + reviewer-gate + signed receipt, not the prompt routing. You can use LangChain or any other orchestrator alongside the substrate.

"Bitcoin anchoring is overkill." The OpenTimestamps anchor adds one Bitcoin transaction per ~hour of substrate operation (cost: negligible) and gives regulators an attestation that is independent of Promethean's continued existence. If we disappear, the regulator can still verify the chain existed at the anchored block height. This property is hard to overstate for high-stakes regulated deployments.

"Open-source verifier means competitors can fork." Forks of the verifier do not fork: the operator's signed reference deployments, the regulator citations, the corpus, the continuous chain history, the team, or the brand. See LICENSING page for the seven operational moats that don't live in the code.

"We can build this ourselves." You can. The architecture is publicly documented in 50 ADRs and 7,400+ tests. Most operators we have talked to estimate 18–24 months of engineering investment to reach equivalent reliability, plus the Ed25519 trust anchor reputation problem (yours starts with zero history). The pilot is an alternative to the build-vs-buy decision; pilot to verify the substrate before committing either way.

10. The next step

The lowest-cost path forward is a 30-minute operator-fit interview. Two questions:

1. What's the AI feature?
2. What's the compliance objection?

We come back within a week with a pilot-fit assessment or a clean "we're not the right substrate for this." If we're not a fit, we say so; the substrate is not for every workload, and an honest no is worth more than a pilot that falsifies on week 12.

Operator-fit interview: operators@promethean.software · subject: "Runtime-AI pilot interest"

11. Reading order if you have more time

This solution brief targets the buyer's decision framework, not just the buyer's curiosity. Every claim has a falsifiable source — ADR, test file, live chain, or /api/facts/* endpoint. If you find an inaccuracy, file it via feedback@promethean.software and we'll record it in the L9 self-evaluation chain. Last revised 2026-05-18.