Skip to content
← All AppsAPI ยท Web SaaS

VibeVal

IEC 62304 compliance validation, as an API. A Quality Engineer pastes a code diff, picks a risk class, and gets back a CSA-aligned validation assessment in seconds instead of hours — with a SHA-256 attestation ready for the Design History File.

Private beta — contact for access.

Diff in, verdict out

1

Send the change

POST a code diff with its risk class (A / B / C), change type, and a line of clinical context to the /v1/validate endpoint.

2

Rules + rationale

A rule engine checks the IEC 62304 §5.5–5.7 structural requirements for that risk class, and Claude drafts a CSA-style validation rationale in plain language.

3

Attest & file

You get a structural compliance verdict, the rationale, and a SHA-256 attestation of the inputs and result — audit-ready for the Design History File.

One call, in your pipeline

curl -X POST https://vibeval.vercel.app/v1/validate \
  -H "Authorization: Bearer csa_..." \
  -H "Content-Type: application/json" \
  -d '{
    "framework": "iec-62304",
    "risk_class": "B",
    "change_type": "modification",
    "diff": "<your code diff>",
    "context": "Patient monitoring display update per REQ-042"
  }'

Returns a structural compliance verdict, a CSA-style validation rationale, and a SHA-256 attestation of the inputs and result.

Example VibeVal API response: verdict pass, IEC 62304 section 5.5 to 5.7 checks all ok, a CSA rationale, and a SHA-256 attestation hash

An example response — the rule engine owns the verdict, the model writes the rationale.

Making an audit trust a diff

The Problem

Every software change to an FDA-regulated device needs a Computer Software Assurance (CSA) rationale under IEC 62304. Quality teams write these by hand — hours per change — and the result still varies by whoever held the pen that day.

The Architecture

A deterministic rule engine encodes the IEC 62304 §5.5–5.7 structural requirements per risk class, so the pass/fail verdict never depends on the model. Claude Haiku only drafts the human-readable rationale on top of that verdict.

Key Challenges

Regulatory tooling has to be defensible, not just plausible. The attestation hashes the exact inputs and result so a reviewer can prove nothing changed after the fact, and usage is tracked per key for audit and billing.

What I Learned

The winning split was letting rules own the verdict and the LLM own the prose. That keeps the compliance decision reproducible while still turning a raw diff into language a QE can paste straight into the Design History File.

Built with

TypeScriptVercel FunctionsSupabaseClaude HaikuRule EngineStripe

Validating regulated software?

VibeVal is in private beta. Reach out for API access and a look at the full framework coverage.