The Daritas Assessment Standard

Version 0.1 — 2026-07-27. Publishable.

This document may be shared. It states what a Daritas assessment asserts and how anyone can check it. The how — pipeline, prompts, orchestration, the engineering that makes it affordable — is a business secret and lives in program-analysis-methodology.md, which must never be quoted publicly. The line is what vs how: a customer cannot buy what they cannot see, and a competitor should not be handed the recipe. Everything here is deliberately on the public side of that line, because a standard that cannot be shown cannot be used to judge anything.

0. Why this document exists

An assessment is an assertion about a machine that people depend on. Anyone can now generate a fluent document about a control system; the question a buyer should ask is not how good does this read but what is being claimed, on what evidence, and who is accountable for it. Those are answerable only against a stated standard.

So this is the standard we hold ourselves to, published so that

• a customer can check any individual claim without asking us,
• an assessment produced by anyone else can be compared against it on equal terms, and
• our own deliverables can be held to it — including where they fall short.

It describes the current, implemented behaviour. Where something is designed but not built, it says so.

---

1. Object of study, and the boundary

A Daritas assessment describes one system: the automation that controls a defined piece of plant, as it exists in a defined set of source artifacts at a defined moment.

An assessment asserts things about the sources it was given. It does not assert that the plant matches those sources. That gap is real — code is edited on a laptop that never reaches the repository, a drive is reconfigured through its keypad — and the standard treats the gap as a finding rather than as an assumption. Where a second channel exists (runtime observation, a measurement, an engineer's testimony) a disagreement between channels is recorded as an open conflict, not silently resolved in favour of either.

Out of scope by construction: whether the system's design is correct, safe, or compliant. We report what the logic does, not what it should do. A claim that an interlock exists is not a claim that the interlock is adequate.

2. The unit of assertion: the claim

Everything in an assessment reduces to claims. A claim is a statement about the system, carrying its own evidence, its own state, and its own confidence. There is no prose in a deliverable that is not either a claim, a declared unknown, or narrative that links them.

A behavioural claim is stated in the shape of a Hoare triple — {pre} ⟨the cited source⟩ {post}: under this precondition, this code, that postcondition. The command is not restated, because the claim already cites it.

3. What counts as evidence

Every claim carries one or more evidence records. An evidence record names its origin, the source location, and a verbatim quote. The implemented origins are:

Origins are not ranked into a single hierarchy, deliberately. A measurement is not automatically truer than the code, and the code is not automatically truer than the engineer who maintains it. What matters is that the origin is stated, so a reader can weigh it.

4. The provenance rule — the one mechanical guarantee

A claim whose quote cannot be found verbatim in the cited source is rejected, by machine, before a human ever sees it.

This is the load-bearing rule of the standard. Extraction proposes; a deterministic guard disposes. For each proposed claim the guard resolves the cited file, searches for the quoted text, and:

• if the file is unknown → the evidence is discarded (reason: unknown-file);
• if the quote does not occur in it → the evidence is discarded (reason: quote-not-found);
• if evidence survives, the guard stamps the located line range and admits the claim.

A claim left with no verifiable evidence does not enter the model. Rejections are recorded and reported, not silently dropped: a run that proposed a great deal and grounded little says so, and that ratio is itself information about the sources.

The consequence worth stating plainly: a fabricated or paraphrased citation is wasted output. It cannot reach a deliverable, because the check is not a review step that might be skipped — it is mechanical and runs on every claim.

5. States: what a claim has earned

A claim's state records how it is known. It is a ladder, not a score:

Only a defined subset may appear in a customer-facing deliverable (CUSTOMER_FACING_STATES): sourceSupported, runtimeObserved, humanReviewed, crossChecked, customerConfirmed, and the three approvedFor… states. A bare aiInferred claim is not customer-facing by default — it is machine output that has passed the guard, and the gate exists precisely so that "the AI said it, and the quote checks out" is not by itself presented as an established fact.

6. Depth: what an assessment is willing to assert

Two depths, chosen per assessment (and recorded in the deliverable):

• Evidential-functional — behaviour is asserted where the evidence supports it.
• Design-interface — structure and interfaces only. Runtime behaviour is not asserted; behavioural claims are downgraded to requiresClarification rather than stated.

The second exists because some systems — highly concurrent, heavily dynamic, or supplied only as partial exports — cannot honestly yield behavioural claims from static sources. Reporting structure and declining to assert behaviour is the correct output for those, and the standard names it rather than letting a thin assessment pass as a full one.

7. Coverage and the unknown

Two numbers accompany every assessment, and both may be unflattering:

• What was read — files actually ingested against files present ("read 6 of 753").
• What was rejected — claims discarded by the guard, with reasons.

Declared unknowns are part of the deliverable, not a gap in it. What the sources cannot establish is listed as an open question with the quoted line that raised it. A question put to a human and left unanswered becomes a labelled assumption — visible as an assumption for as long as the model exists — never a confident sentence with nothing behind it.

8. Grade: who is accountable

Every deliverable carries exactly one of two grades, and the label is never blurred:

• Machine-generated — extraction, guard and rendering, no engineer review. Honest and useful; nobody has vouched for it.
• Engineer-reviewed — a named, qualified automation engineer worked through the claims against their evidence and signed off. Their verdicts (confirmed, corrected, flagged) are part of the record, including corrections and disagreements.

The reviewed grade is what accountability costs, and it is the only thing in an assessment that a machine cannot supply. A review is a record of what a person examined and concluded — not a certificate, and not a proof of the software.

Daritas certifies nothing. We produce the evidence and the trail; a qualified person's signature is theirs, and any regulatory weight it carries comes from them, not from us.

9. Continuity: an assessment has a version, not an expiry

A system changes. Every assessment is a version of a system's model, and later versions are diffed against earlier ones: what changed, which claims still hold, which are invalidated, which need re-review. Claims affected by a change are marked stale until their evidence is renewed.

A deliverable therefore states what it is current to, and staleness is visible rather than assumed.

10. Reproducibility — how to check us

1. Check any single claim yourself. Every claim cites a file, a location and a verbatim quote. Open the file and search for the quote. If it is not there, the claim should not exist; tell us, because that is a defect in the guard and we want it.
2. Re-run the assessment. The engine is a command-line tool; the same sources at the same version produce a comparable model. The deterministic part is deterministic.
3. Compare against a reference. examples/ahu-1 is a public synthetic package shipped with expected outputs — claims, open questions, assets — so the method can be exercised end to end by anyone, without a customer's material.
4. Read the rejections. They ship with the run.

11. Limitations, stated

A standard that lists no limitations is marketing. Ours:

• Sources, not reality. §1. We assert about artifacts; the plant may differ.
• Completeness is not provable. We can show what we found and what we read. We cannot prove that nothing was missed, and no method over an unbounded corpus can.
• A verbatim quote proves attribution, not truth. The guard proves the source says this. It does not prove the source is right — a comment can be stale, a document can be wrong.
• Extraction is model-dependent. Different models, and different runs, surface different amounts. The grade and the model-of-record are recorded for exactly this reason.
• Machine-generated means unreviewed. The fast lane is honest and it is not accountability.
• Design-interface depth asserts no behaviour. By design, and it must not be read as a weak behavioural assessment.
• Not built yet: runtime corroboration exists as a state and a design, and is not part of the standard assessment today. When it ships, this section changes and the version number moves.

12. Versioning of this standard

This document is versioned. Changes that alter what a grade or a state asserts move the version and are dated, so a deliverable can name the standard version it was produced under. Assessments delivered before a change remain governed by the version in force when they were issued.