The Model & Evidence
Your deliverable is an interactive, evidence-backed model of your control system. Here is how it is structured and how to read it.
What the model is
A Daritas model is a structured, plain-language account of what a control system does — not a summary of the code, but a map of its behaviours, the equipment they act on, how they depend on each other, and where the risks are. Every statement in it is tied to the exact source that supports it, and the whole model is reviewed and signed off by a qualified reviewer.
The model is the primary deliverable. Everything else — the documents you export, the Advisor you can ask, the audit pack, the governed context an AI reads — is a view over this one verified model.
Anatomy of a behaviour
The model is built from behaviours — discrete, checkable statements about what the system does. Each behaviour carries:
| Field | What it means |
|---|---|
| Statement | A plain-language description of one behaviour — e.g. "the outside-air damper closes on a freeze trip". |
| Subjects | The equipment, signals or alarms the behaviour is about, linked to the model’s structure. |
| Evidence | One or more verbatim quotes from the source that support the statement, each with its exact file and location. |
| Confidence | How strongly the source supports the statement, as read. |
| Review status | Whether a qualified reviewer has signed it off, flagged it, or not yet reviewed it. |
| Safety-relevant | Whether the behaviour bears on a safety function — these are prioritised in review. |
Evidence & grounding
Nothing in the model is asserted without a source. Open any behaviour and you see the verbatim line(s) it rests on, with the file and location. This is enforced, not sampled: a proposed statement whose quote cannot be found in the source is rejected before it ever reaches the model.
Claim states
A behaviour moves through states as it is verified:
| State | Meaning |
|---|---|
| Source-supported | Grounded in a verbatim source quote; not yet human-reviewed. |
| Human-reviewed / signed off | A qualified reviewer confirmed (or corrected) it against the evidence. |
| Flagged | A reviewer raised a question or a discrepancy to resolve. |
| Needs clarification | An open question — something the source cannot settle on its own. |
Structure & function groups
Behaviours are organised by the equipment and functions they belong to, so a large system stays navigable. Related behaviours are grouped by purpose — for example smoke/fire safety, freeze protection, or scheduling — so you can read the system by what it is for, not by scrolling raw logic.
Exploring the model
- Model viewer — browse behaviours grouped by function, open any one to see its evidence, subjects, confidence and review status.
- Ask the Advisor — put a plain question to the model and get an answer built only from its verified behaviours, with citations. See The Advisor.
- What changed — when a system is re-assessed, a drift view shows exactly what was added, removed or changed since the last baseline. See The Continuity Loop.
- Portfolio — across all your assessments, a rolled-up view of every system by status (sound, needs attention, or action needed), so leadership sees the whole estate at a glance — each system derived from its own verified model.
Documents & exports
- Document export — select any part of the model and generate clean Markdown/Word/PDF for internal discussion, audits, or handover.
- Structured export — your model in an open, documented format you own, so the knowledge stays portable and does not depend on us to remain readable.
- Audit pack — an evidence-first verification report: coverage, and for each behaviour, who signed it off and against which source line. See Verification & Sign-off.