AI gateway · Engineers (contract-as-SDK) + AI-governance/compliance owners (read-only console)
CuRE Clarion
Audited AI gateway — spec-typed AI mediation with a hash-chained audit stream.
What it does
Audited AI gateway — spec-typed AI mediation with a hash-chained audit stream. Every AI call in a regulated app routes through one audited, provider-agnostic gateway — one validation story, not an AI audit per app.
Key capabilities
- Spec-typed AI mediation (AIExecutionSpec)
- Hash-chained audit stream
- Provider-agnostic routing + provider-key custody
- Provider-egress PHI de-identification for text prompts and tool-use turns
- Native prompt-injection, jailbreak, tool-observation, and groundedness guardrails at the gateway chokepoint
- Phantom-token proxy + per-tenant cost / rate caps
- Gateway prompt caching + per-tenant cache-savings visibility (cost optimization)
- External-tenant validation-envelope attestation — a vendor-verifiable, tamper-evident SHA-256 attestation bound to the tenant's own audit-chain head
What sets it apart
- Every AI call in a regulated app routes through one audited, provider-agnostic gateway — one validation story, not an AI audit per app.
- The sellable surface is customer governance: usage controls, vendor transparency, audit review, and cost governance that actively minimizes AI spend (gateway prompt caching) and proves the per-tenant savings — and an entitled external (non-CuRE) tenant reads only its own scoped audit chain plus a vendor-verifiable, tamper-evident validation-envelope attestation of it.
- Hash-chained audit of every prompt, response, and spend — AI features are inspectable, not a black box.
- Internal apps and external vendors consume the same spec-typed contract (the SDK is the product) — AI feature logic stays in the calling app; Clarion owns mediation, PHI-scrubbed provider egress, semantic guardrails, key custody, and the audit trail.
Tamper with a sealed audit event, and watch the chain break
Clarion is the platform's single AI gateway — every mediated model call is sealed into a per-tenant, SHA-256 hash-chained audit stream. Edit any sealed event's recorded value and the chain breaks from that row forward, because each row's hash folds in the one before it. Then re-forge the downstream hashes and see why a trusted, immutable seal is what actually catches the forgery.
7 sealed AI-execution events across the CuRE apps, each hash-chained to the one before. Pick a row and edit it to tamper with the record.
Drag to alter row #4's recorded value. Its SHA-256 no longer matches the sealed hash, so the chain breaks at that row and every row after it.
Recompute every hash after the edit so the chain internally re-links. The naïve walk passes — but the trusted seal held in the store still exposes the forgery.
Hash chain · oldest → newest
| # | Event | prevHash | recordHash | Status |
|---|---|---|---|---|
| 1 | Capturecapture:ecrf-field-validateconf 0.97 · 09:00:00 | ∅ (genesis) | 94f256d55d…150819 | Sealed |
| 2 | Conductconduct:dq-rule-draftconf 0.91 · 09:00:47 | 94f256d55d…150819 | ff03fad121…6e291c | Sealed |
| 3 | Calibercaliber:narrative-draftconf 0.88 · 09:02:13 | ff03fad121…6e291c | 8f7c8de00b…a5b47c | Sealed |
| 4 | Compendcompend:tmf-grounded-qaconf 0.94 · 09:03:28 | 8f7c8de00b…a5b47c | 770336f348…2b2f43 | Sealed |
| 5 | Canarycanary:case-narrativeconf 0.86 · 09:04:51 | 770336f348…2b2f43 | ca8498fd56…d01db7 | Sealed |
| 6 | Calculatecalculate:cohort-explainconf 0.90 · 09:06:00 | ca8498fd56…d01db7 | 73b25be87e…462c78 | Sealed |
| 7 | Compasscompass:epro-summarizeconf 0.83 · 09:06:59 | 73b25be87e…462c78 | 7abd669f2c…8b0c78 | Sealed |
Each recordHash is SHA-256(auditTrailId | user | action | table | recordId | value | timestamp | previousHash | …AI metadata) — the previous row's hash is one of the inputs, so editing any field re-derives a different hash and severs every link after it. This is the exact chaining primitive Clarion's gateway seals its AI-execution audit rows with (@cure-platform/audit-chain, consumed by apps/clarion/…/audit/store.ts), running entirely in your browser on synthetic events. No backend, no real data.
Why this is more than a toy
The record-hash and chain-verify here are a byte-for-byte port of the real platform primitive @cure-platform/audit-chain — the same field ordering, |-join, null-coercion, ISO-8601 timestamp, and the AI-metadata append gated on aiAssisted — so a given audit row produces the exact same SHA-256 digest as the in-product gateway (a property the product validates as golden-vector byte-identity under ADR-PLT-045). SHA-256 is implemented from the FIPS 180-4 spec so the whole thing runs with no crypto dependency and no network. In the product, CuRE Clarion's gateway seals exactly one hash-chained row per mediated AI call in apps/clarion/…/server/audit/store.ts, making the AI-execution log tamper-evident for 21 CFR Part 11 / GxP inspection — this is that same seal-and-verify loop, running client-side on synthetic events. No backend, no real data.
See CuRE Clarion in action
Every research ecosystem is unique. Let's discuss how CuRE can be configured for your needs.