How Daritas works
From your control-system code to an evidence-backed model — graded machine-generated or engineer-reviewed, coverage and unknowns disclosed — a clear, documented process at every step.
Submit your system
Upload your control program — a PLCopen XML export or the project source — plus any schematics, manuals, or notes. One controller or a whole multi-unit system: a system assessment composes several units into one model, each at the depth it needs. A guided form walks you through scope and what you most need to get out of it.
Daritas surveys & condenses
We survey the whole codebase, map its structure, and condense it to its logic essence — stripping the tool-noise (graphics, layout, regenerated wrappers) while keeping the behaviour and the exact source locations.
Grounded extraction
Daritas extracts every behaviour it can identify and ties each one to the evidence that supports it — source-derived claims down to their source locations. A claim whose quote does not occur at its cited location is rejected automatically — a provenance check the machine can make; whether the evidence truly supports each claim is what expert review adds. What the code establishes and what is design-level structure — interfaces, intent — are reported as separate tiers, never blended, and coverage is disclosed: what was read, what was out of reach, what stayed unknown. Whatever the sources cannot settle becomes an open question put to you and your team, never a guess.
Expert review & sign-off
A qualified automation engineer verifies the model against the evidence, resolves ambiguities, and signs off within a stated scope. The reviewer is named and accountable — an attestation of specific claims, not a blanket guarantee.
Delivery & revisions
You receive an interactive model to explore and a report structured the way your installation is — system, unit, source file, function — with per-unit dependency diagrams and every finding linked to its evidence. Multi-unit systems get an Interface Catalog (ICD) covering the connections inside the system and out. Plus document exports (Markdown, Word, PDF) and a structured export you own. Revisions are included — send your comments and we turn them around fast.
What every assessment includes
What you receive, concretely
Four structures every assessment ships — shown from the AHU-01 sample, a synthetic demo air-handling unit run through the real engine. Abbreviated, not mocked: the hashes, counts, and the claim are the sample's actual output.
“FZ-01 has a safety-relevant alarm: freeze stat trip — heating coil frost protection.”
What was not read is listed, never assumed.
Ships with reviewed grades. It binds, at minimum:
- reviewer — name & qualifications
- scope — claims covered, exclusions, unknowns
- review depth — exhaustive / risk-based / sampled
- artifact hashes the review was performed against
- date & supersession conditions
- obfuscation status
No attestation is shown for AHU-01 — the sample is machine-grade, and we do not fake signatures.
What a re-ingest reports when FB_FreezeProtection.st changes:
Illustrative flow — the version diff ships with every re-ingest.
A model you can use, not just read
The report is the first thing you get, not the last. The model behind it stays yours, stays current, and answers questions.
Ask about an alarm, an interlock, a mode you don’t recognise. Answers are drawn from your assessed system and cite the model behind them — so you can check the reasoning instead of trusting a chat window. Scoped to one system: the same alarm code means different things on different machines.
For whoever is standing in front of the machine.
Each assessment is kept as a baseline. Re-ingest after a change and you get a diff: which findings still hold, which were invalidated, and the review needed — scoped to what actually moved, not the whole system again.
For the person who has to sign off after a modification.
The verified model is available over an authenticated read API, and to AI copilots over MCP — read-only, scoped to your organisation by your own key, so your assistant reasons over evidence-backed facts instead of guessing. Every assessment also exports in portable form: it is your model, usable in your systems, and it leaves with you.
For your engineering and IT teams — and whatever AI they already use.
In the expert lane an automation engineer reviews the claims and attests to them within a stated scope, and the attestation records who and when. In the machine lane nothing is signed and the deliverable says so. You always know which you are holding.
For whoever carries the risk of acting on it.
It asks you and your team — and their knowledge stays
Some things aren't in the code: why a setpoint is what it is, which alarm everyone ignores, the workaround that never got written down. We ground what the sources can prove and ask your people the rest — the controls engineer, the operator, the integrator who built it, the vendor's support desk. Each question is written to be forwarded: what is asked, the line that prompted it, and what we currently believe, so whoever receives it can answer or pass it to the person who can. Open questions stay visible in the portal against the behaviour that raised them, and every answer is recorded against the claim it explains, with who said it and when — kept as testimony, a separate tier from what the code proves, so the knowledge outlives whoever happens to know it today.
Bring the people who know the system, including the ones you'd forget to ask.
Three ways to run it
Security claims are only honest per mode — this is the table.
| Mode | What can leave your site | Human review path |
|---|---|---|
| Fully air-gapped | Nothing — a local model, or the deterministic engine alone with the reduced depth honestly marked | Your engineers, or a reviewer working inside your network |
| Local engine + your AI API | The configured payload — source excerpts and prompts to the provider you chose, under your provider contract, including its training terms | Local, or controlled remote review |
| Hosted collaboration | The evidence model and the artifacts you approve for upload | Daritas reviewers or your own, in the portal |
Obfuscation reduces what any mode exposes — proprietary names replaced before review, restored on delivery, with your approval of the diff before anything goes. Structure and logic remain your IP in every mode: you decide what leaves.
The intelligence layer
Most engineering knowledge walks out the door when a person does. Daritas is built the other way — every assessment, and every reviewer correction, makes the next one faster and more accurate.
The AI proposes, the engineer disposes
When the model is proposed, the reviewer sees every claim beside the exact evidence. If something is off, they see precisely why — file, line, and a suggested correction. The work gets sharper as it is done.
Reviewers sharpen the model
Every correction a reviewer makes is captured. The next time a similar pattern appears, those corrections inform it. Assessment #50 benefits from everything learned in #1–49.
Every assessment starts with context
Before anyone reviews a behaviour, the system builds an overview — the systems, their structure, the risks. Human and AI start from the same shared context, not a blank page.
Knowledge outlasts any individual
Customer-confirmed history accumulates. When a great engineer moves on, their confirmed judgements stay. The platform accumulates expertise; it does not leak it.
Assessment #100 will be faster, cheaper, and more accurate than #1 — not because we hire more people, but because the system retains everything it learns, customer-confirmed.
Don't take our word for it — see it run
The best proof of a process is its output — and the rule it was held to. Three things to inspect, no signup and no customer data.
The Assessment Standard
What we assert, on what evidence, what each grade means — and what this method cannot establish. Published so you can hold us to it, and hold anyone else to it.
Read the standard →🌓The Apollo 11 demo
Ask about the 1202 program alarm and check every citation against the public-domain Luminary 099 source — the lines that actually flew. The evidence standard, verifiable by you.
Try it →🗺️Sample answers, sector by sector
What the delivered model answers for a batch plant, an air-handling portfolio, or a fifteen-year-old machine — from synthetic systems, labelled as such.
Read the stories →