Verify it yourself

How Vera, the verification engine inside Celina, produces evidence your QA team can check without us in the room.

For quality leadership, data integrity owners and computer system validation teams.

Every AI system in clinical research asks to be trusted. This one is built so that it does not have to ask.

Vera is the part of Celina that checks the record. Not the model's reasoning, and not its output. The signed ledger the platform produces as work happens: every event hashed, linked to its predecessor, and content addressed. Vera walks that chain mechanically and issues a certificate that says exactly what she checked and exactly what she could not.

Her verdict is one sentence, and it never changes.

No break detected under the following checks.

Not valid. Not clean. Not verified as a bare word. What held, under which checks, with the exclusions named. Anyone with the public key can re-run the math.

What Vera is, and what she is not

Vera contains no language model anywhere in her verification path. No probabilistic reasoning, no confidence scores, no inference. Same input, same verdict, every time. That property is not a design preference. It is the one a validation team actually tests for, and it is the reason her output can be treated as evidence rather than opinion.

She is not the thing that produces Celina's answers. She is the thing that checks whether the record of those answers is intact. The model proposes. The proof disposes. Vera is the proof.

Why Vera is not a formal proof

Vera's first design was built around Lean, the theorem prover. The plan was to prove the verification logic correct and let a small, machine-checked kernel carry the guarantee. We moved away from that, and the reason belongs in the open.

A proof in Lean attaches to a model of the chain. Input and output, the database, the network and the extraction layer all sit outside the proof. You prove the model, then hope the gap between the model and production is small. Vera walks the production event stream itself: real bytes, real database, the full chain. A rule change is a pull request with tests rather than a proof-engineering project, and a third party checks her work by fetching a public key rather than re-running a prover.

What that trade gave up is real, and we do not pretend otherwise: a machine-checked guarantee that the verification logic itself is sound. That assurance now rests on the simplicity of the checks, a test suite bound to a real database, and the fact that anyone can recompute the result and catch us. A proof says our reasoning is correct. A published key says prove us wrong. Validation teams trust the second sentence more, because it is the shape of their own job.

The walk

Vera checks the record at three levels.

Level zero, the cryptographic chain. Event hashes, predecessor linkage, document integrity. Does each event hash to what it claims, and does each link to what came before it.

Level one, structure. Schema validity, ordering, bitemporal consistency, supersession chains. Are valid time and transaction time both recorded and coherent. When something was superseded, does the chain from original to successor hold.

Level two, the provenance graph. Does every artifact trace to what produced it.

Nothing is sampled. The walk covers the full chain, and anything it cannot cover is named rather than skipped.

The certificate

Every certificate enumerates the checks that ran. It also carries a pre-registered exclusion register that names any check that could not run and why. Nothing is silently omitted, which is the difference between a certificate and a reassurance.

Certificates are signed with Ed25519 by a named verifier identity, vera-audit-v1. They are then appended to the same ledger they describe, as signed events. The act of verification is itself on the audit trail.

Verify it yourself

This is the part that matters most to a validation team, so it is stated plainly.

Re-verifying a certificate requires the public key and nothing else. No vendor access, no database, no secret, no call with us.

The algorithm, the key identifier, the public key in PEM format, the signature encoding and the payload canonicalization contract are published at an open endpoint:

GET /vera/v1/keys

A certificate is re-verified against that key at:

GET /vera/v1/certificates/verify

The verification contract is complete and public. A security or QA function can fetch the key, verify certificates independently, and reach its own conclusion before any commercial conversation begins. That is the intended order of operations.

The ledger underneath

Insert only. The record cannot be edited, only appended to. Correction is supersession: the prior version stays, linked to its successor, with both timestamps intact. There is no path that rewrites history, including for us.

Content addressed. Artifacts are identified by SHA-256 hash. The record is the original by construction, not by policy.

Bitemporal. Valid time and transaction time are both recorded at the moment of the event, not reconstructed afterwards.

Jurisdiction keyed. Signing uses a per-namespace key ring, with separate keys for United States and Brazil records, versioned, with staged rotation. Historical rows verify unchanged under the ring, because the cutover was byte identical by construction. A United States record and a Brazil record are cryptographically separable.

The perimeter

Two independent walls stand in front of the record. Platform-level identity refuses an unauthenticated request before it reaches application code, and that refusal is tested. Behind it, application-level principal checks fail closed: a misconfigured dependency refuses rather than defaulting open.

Lineage export is available per artifact and per jurisdiction, gated to the owner of record or an auditor role. An empty result returns a row count of zero rather than a distinguishable not found, so the interface cannot be used to probe what exists.

Writes and emissions are rate limited. Deployed image digests are pinned in infrastructure as code as the deploy record, and drift fails the build. Vera's strict test suite runs against a real database on every change. Her code does not ship unverified.

What this looks like against ALCOA+

We make no compliance claim. The table describes what the substrate does. The conclusion is yours to draw.

FAQ

Is this 21 CFR Part 11 compliant?

We do not make that claim. Compliance is an assessment your organization performs against your own framework. What we can state is the capability: an insert-only, hash-chained, bitemporal record with named human attestation and independently verifiable certificates. The article above is written so your validation team can assess it directly.

Why does the certificate say "no break detected under the following checks" and not "verified"?

Because "verified" would be a claim about checks that did not run. The certificate names the checks that executed and the ones excluded. Its wording is scoped to exactly that. Anything broader would be a reassurance rather than a finding.

What is in the exclusion register?

Any check that could not run on a given walk, named explicitly, with the reason. The register is pre-registered, meaning the set of possible exclusions is declared in advance rather than discovered afterwards. Nothing is silently skipped.

Can my team verify a certificate without any access to NexTrial systems?

Yes. Verification requires only the public key, which is published with the full contract at the open keys endpoint. No account, no database access, no support call.

Does Vera check whether Celina's answers are correct?

No. Vera checks whether the record of those answers is intact: the cryptography, the structure and the provenance. Correctness of a determination is established by the deterministic verdict engine over an attested corpus, and finalized by a named human. Vera proves the record has not been altered since.

What happens if the verification endpoint is unavailable?

Certificates already issued remain verifiable with the public key regardless of service availability, because verification does not depend on the service. The service itself fails closed: an unavailable dependency produces an explicit refusal, never a silent pass.

If keys are rotated, do older certificates still verify?

Yes. The key ring is versioned and rotation is staged. Historical rows verify unchanged under the ring by construction.

Can we export the record into our own systems?

Yes. Signed lineage export is available per artifact and per jurisdiction to the owner of record or an auditor role. It travels as data. The recipient needs nothing from NexTrial to check it.

What happens when a record is wrong?

It is superseded, never edited. The original remains, linked to its successor, with both timestamps preserved. The chain from original to correction is itself part of the verified record.

Is Vera a language model?

No. There is no model in her verification path. She does not reason. She checks.

How is Vera herself tested?

Her test suite runs against a real database on every code change, and a failing suite blocks the merge. Deployed image digests are pinned as the deploy record, and any drift between the pinned digest and what is running fails the build.

Can we try it before any commercial conversation?

That is the intended order. Fetch the key, verify a certificate, form your own view. Bring one artifact and watch it leave with a certificate.

Was Vera originally built on Lean?

Yes. Vera's first design was built around Lean, the theorem prover, with the verification logic to be proven correct and checked by a small trusted kernel. We moved the assurance to determinism, full transparency and independent recomputation over the production chain, because a proof about a model does not check your data. The article above sets out what that trade gave up and what it bought.

Does dropping the formal proof make Vera less trustworthy?

It changes what the trust rests on. A Lean proof guarantees the verification logic within the model's assumptions and says nothing about the deployed database, network or extraction layer. Vera's checks are small enough to read, her test suite runs against a real database on every change, and any third party can recompute her verdict from the public key. If we ever add formal depth back, it will be by proving the small specification kernels, canonicalization, linkage and supersession, while still executing against reality.

Engineered for environments where data integrity is audited, not asserted.

NexTrial.ai · Celina · Trial Activation Intelligence