Caryon · Provable compliance

Provable compliance for the medical device industry.

Determinism, not probability. Ready for audit.

Caryon’s engine doesn’t estimate whether your documentation holds together. It proves it — and the moment a change breaks it, it shows you exactly what broke, and why.

REQREQ-208SUSU-31RCRC-114SOUPSOUPVERVER-77G-9.3G-9.3

The platform

One engine. Three things it does that nothing else can do together.

Cartography

see the whole structure of conformity

A living map of every artefact in your technical documentation and every relationship between them — requirements, risk controls, software units, SOUP, verification records, GSPR justifications, traceability links.

Not a folder of documents. A connected structure — where you can watch a single change propagate to every record it touches.

AI Expert

a domain expert that drafts, never decides

An LLM layer trained on the regulatory corpus — EU MDR, FDA QMSR, ISO 14971, IEC 62304, ISO 13485 — that proposes compliant content, remediation, and rationale at expert speed.

It proposes. The engine disposes. Generated content only stands once the symbolic layer has proven it conforms — so the AI's fluency never becomes your liability.

Agentic Orchestration

the workflow runs itself, under proof

Agents carry a change through its full lifecycle: detect impact, draft updates, route the right artefacts to the right reviewers, and hold everything until conformity is restored.

Automation you can trust precisely because it can't commit anything that isn't proven. Every agent action is gated by the engine.

One foundation · IGKSE

The use case in full · Change management

A single change. Watch what it touches.

A software engineer needs to update a third-party cryptographic library — a piece of SOUP — to a new version in a Class IIb connected device. In most quality systems, the true consequences of that change surface weeks later, in review, by hand, if at all. Here is the same change inside Caryon.

REQREQ-208SUSU-31RCRC-114SOUPSOUPVERVER-77G-9.3G-9.3
TracedSeveredDrafted
01

The change is proposed.

The engineer enters the proposed SOUP version change. Nothing is committed. The engine treats it as a hypothesis to be tested against every invariant.

02

The engine propagates the change across the cartography.

Instantly, the map lights the chain of artefacts the change touches: the software unit that depends on the library, the SOUP records under IEC 62304, the risk controls in the ISO 14971 file that assumed the old version's behaviour, the verification records that tested it, and the GSPR justifications that cite those records.

03

The engine returns counter-examples.

This is the heart of it. The symbolic layer doesn't say “this might be risky.” It returns proofs of violation — each one inspectable, down to the exact dependency that breaks.

RC-114 mitigates a timing side-channel by relying on constant-time comparison in the previous library build. The new version's comparison is not guaranteed constant-time — the mitigation's stated property no longer holds.

VER-77 verified SU-31 against the library's prior cryptographic API. The new version changes that API surface, so VER-77's result no longer covers SU-31 — and REQ-208, which traces through SU-31, loses its verified evidence.

G-9.3 cites VER-77 as the evidence that the requirement is met. With VER-77 stale, the justification rests on a result that no longer applies.

04

The AI Expert proposes remediation.

For each broken invariant, the AI Expert drafts what's needed: an updated risk-analysis entry, a re-verification protocol, revised GSPR rationale. It works at expert speed — but every draft is a proposal, not a fact.

05

The engine proves the remediation before anything commits.

Each proposed fix is run back through the symbolic layer. Only when every invariant holds again — when there are no remaining counter-examples — does the change become committable.

Provable conformity, restored before commit.

06

Agentic orchestration routes and closes the loop.

Agents assemble the updated artefacts, route the re-verification to the right owner, attach the proof trail, and hold the change in a non-committable state until every sign-off and every invariant is satisfied. The audit trail isn't reconstructed afterwards — it's the by-product of the proof.

The change manager’s nightmare — the consequence you didn’t see — cannot happen here. If it would break something, the engine has already proven it, before you commit.

Onboarding

You don't rebuild your documentation. The engine reads what you already have — and reveals its structure.

JiraGitHubSalesforceSage

Scattered sources

Ingest · analyse · connect
REQREQ-208SUSU-31RCRC-114SOUPSOUPVERVER-77G-9.3G-9.3

One connected structure

Deep ingestion

we read your documentation where it lives

Your technical file isn't sitting in a clean repository. It's embedded across shared drives, nested folders, naming conventions only your team understands, years of versions. Caryon ingests it in place — requirements, risk files, software documentation, SOUP records, verification reports, GSPR justifications, design history. No reformatting, no migration project.

Analysis

a global mapping, built automatically

Every ingested document is analysed and placed into a single connected structure: the cartography. The engine infers the relationships your files imply — which requirement traces to which software unit, which risk control depends on which verification — and assembles them into one global map of your conformity. This is the moment the cartography comes into existence: read out of your own documentation.

Connection

your IT tools, centralised into one compliance picture

Compliance information doesn't live only in documents. It lives in the systems your teams work in every day. Caryon connects to Jira, GitHub, Salesforce, and Sage — and pulls those fragments into the same connected structure. Because the connectors stay live, the map stays current as those systems change.

On day one, the engine doesn’t just hold your documentation — it proves the state you’re already in: every gap, every severed trace, every invariant already broken, surfaced before you’ve changed a thing.

Under the hood

The engine underneath. Invariant-Governed Knowledge & Symbolic Engine.

Every AI compliance tool on the market is probabilistic. It predicts what lookscompliant. When it’s wrong, it’s confidently wrong — and in a regulated context, a confident hallucination is a recall waiting to happen.

IGKSE is built the other way around. An LLM layer proposes. A formal symbolic layer holds decision authority. Your regulatory constraints — GSPRs, risk-control relationships, traceability requirements, lifecycle obligations — are encoded as invariants: rules that must always hold. When something violates an invariant, the engine doesn’t guess. It returns a counter-example — a concrete, inspectable proof of exactly what is broken and why.

Proof is the decision authority. Not a score. Not a confidence level. A proof.

Proposal layer

LLM

Proposes content, remediation, rationale.

proposal

Decision layer

Symbolic · invariants

Holds decision authority. Proves or refuses.

↑ counter-example

01

You stop trusting and start verifying.

A probabilistic tool asks you to trust its judgment. IGKSE shows you the proof and lets you check it. The burden of trust moves off your shoulders.

02

The engine is uncopyable by prompt.

Anyone can wire an LLM to a regulatory PDF. No one can make a language model decide with the certainty of a formal proof. The symbolic layer is the moat — and it's structural, not a feature.

03

Wrong is no longer expensive — it's impossible to commit.

Because nothing passes the engine until it's proven, the failure mode that haunts AI tooling — silent, plausible error — simply can't reach your technical file.

Sovereignty & deployment

Your documentation never leaves your perimeter. We ship the engine to your data — not your data to our cloud.

YOUR PERIMETERCaryon engineIGKSELocal modelsLocal inferenceTechnical filesTraceabilityThird-partycloudno data leaves

Local models, local inference.

The AI Expert runs on models deployed inside your environment. Inference happens locally. Your regulatory content — among the most sensitive IP a manufacturer holds — is never sent to a third-party API and never used to train anyone else's model.

On-prem or dedicated VPC.

Caryon is delivered as a local server: installed on-premises behind your firewall, or in a dedicated, single-tenant VPC under your control. No shared multi-tenant cloud. No co-mingling of customer data.

Documentation stays in your IT scope.

Your technical files, your traceability, your proofs — all of it remains under your IT governance, your access policy, your audit. Caryon provides the engine; you keep custody of everything it reasons over.

For manufacturers who can’t — and shouldn’t — put their regulatory file on someone else’s cloud, sovereignty isn’t a feature. It’s a precondition.

Company

Built by people who’ve lived inside the regulation.

Caryon is led by its founders — Loïc (CEO), Fabien Desprez (CTO), and Philippe Triem (CAIO) — backed by an advisory board with deep regulatory, organisational, and clinical experience.

Request a working session

See it prove something.

Bring a change. Watch it propagate.

The fastest way to understand Caryon is to put a real change through the engine and see exactly what it touches.