Verification & review records

A model is only as trustworthy as its review — and an honest review says what it could not settle. Here is what a reviewer can record, who carries authority, and how you can verify with your own engineers.

Why verification matters

Reading control code and proposing behaviours is the first step; checking them against the evidence is what makes the model trustworthy. Every reviewed model is read by a qualified engineer who works through each behaviour against its cited source. The reviewer is identified and accountable — this is the difference between a reviewed, evidence-backed model and an unaccountable AI summary.

ℹ️

What a reviewer leaves is a record, not a signature. Software has no proofs. An engineer reading recovered logic is doing what every engineer does — checking carefully and forming a judgement — and asking them to sign implies a warranty nobody can honestly give. The engineers who would refuse to give it are exactly the ones whose review is worth having. So what you receive is a review record: who looked, at what depth, on what date, what they excluded, and what they could not determine.

What a review record can say

Every behaviour carries one of these, and only the first two count as verified:

Status	What the reviewer is telling you
Confirmed	A reviewer with authority checked it against its evidence and confirmed it.
Corrected	A reviewer rewrote the statement and stands behind the correction.
Reviewed — not certain	They believe it, and recorded that they could not be certain. Reviewed, not verified.
Reviewed — could not tell	They read it and the sources could not settle it either way. Not a fault in your plant — a limit of the material.
Flagged	A reviewer raised a concern: something here looks wrong.
Not yet reviewed	No reviewer with authority has recorded anything.

The middle two are the ones most systems in this field do not have, and they are the reason a review is worth reading. An engineer who cannot determine something from the code has, until now, had three bad options — flag it (which reads as something is wrong and cries wolf about a system that may be fine), confirm it anyway, or say nothing at all, which looks identical to never having opened the assessment. Recording it plainly is both more honest and more useful: those entries are exactly the list of questions to put to the people who run the plant, and Daritas drafts them as Known-Unknown documents for you.

Neither is folded into “verified” (which would overstate them) or into “not reviewed” (which would throw away that a qualified person read it and left a judgement). Coverage counts only what a reviewer stands behind, so the percentage never flatters itself. Safety-relevant behaviours are tracked separately, so the safety-critical part of the system is never lost in the total.

Two tiers of authority

Review is two-tier so volume and authority are separated. A junior reviewer’s confirm is a proposed review; it does not by itself mark a behaviour verified. An authoritative record comes from a senior reviewer (or a Daritas reviewer). Only that counts as verified in coverage, the audit pack, and everything downstream.

ℹ️

A junior confirming a behaviour moves it to “awaiting review”. A senior then adjudicates — confirming, correcting, or recording that it cannot be settled. This lets a team of juniors do the volume while a senior stands behind the result.

Bring your own reviewers

For critical systems, you can verify the model with your own engineers instead of Daritas’s reviewers — so a sensitive system is reviewed with no external eyes. Your reviewers work on the same rails: every claim is checked against its cited source, safety-first, with the same recording discipline.

A reviewer is one of:

Employee — your own staff.
Trusted contractor — an external engineer you trust, who may review across several of your sites.
Daritas reviewer — our qualified reviewer, when you use our workforce.

The reviewer roster

The org owner manages reviewers under Reviewer roster: invite an engineer by email, set them junior or senior, and mark them employee or contractor. They get review access on their next login. A reviewer who works across several of your organizations can switch between them. Reviewers who are already part of the Daritas network are recognised, so a trusted contractor keeps a single identity.

Attribution: who stands behind a claim

Every review records not just that a behaviour was checked but who stands behind it — a Daritas reviewer, one of your employees, or a trusted contractor — and at what tier (junior/senior). The audit pack carries this attribution, so “who verified this” stays honest and auditable.

The audit pack

The audit pack is the evidence-first verification report for an assessment. It shows overall coverage, the safety-critical picture, and for each behaviour: its status, the source line it rests on, and — where a reviewer recorded a verdict — who, when, and what they could not settle. It downloads as a clean document and can be white-labelled as your own team’s work.