Reference
Quick reference for assessment statuses, scope features, deliverable formats, and what a model contains.
Assessment status lifecycle
Every assessment moves through the following states, in order:
| Status | Meaning | Next action |
|---|---|---|
| Draft | Assessment created but not yet submitted | Customer submits it |
| Submitted | Assessment queued for processing | Ops confirms and triggers the survey |
| Surveying | Daritas is surveying, condensing, and extracting grounded behaviours | Automated — no action needed |
| Assigned | The model is ready; a reviewer has been assigned to verify it | Reviewer verifies against the evidence |
| In Review | Verification under way; the model is being finalised | Reviewer signs off |
| Delivered | The model is available to explore | Customer reviews and explores |
| Cancelled | Assessment cancelled by customer or ops | Final state |
Scope comparison
| Capability | Orientation | Full model | Verified | Advanced |
|---|---|---|---|---|
| System map & components | ✓ | ✓ | ✓ | ✓ |
| Grounded behaviours (every claim cited) | high-level | ✓ | ✓ | ✓ |
| Dependencies & data flow | — | ✓ | ✓ | ✓ |
| Risk & obsolescence picture | basic | ✓ | ✓ | ✓ |
| Named, accountable reviewer | ✓ | ✓ | ✓ | ✓ |
| Skeptical review pass (coverage, contradictions) | — | — | ✓ | ✓ |
| Interactive model | ✓ | ✓ | ✓ | ✓ |
| Document exports (Markdown / Word / PDF) | ✓ | ✓ | ✓ | ✓ |
| Structured export (you own it) | ✓ | ✓ | ✓ | ✓ |
| Diff / equivalence vs a replacement | — | — | — | ✓ |
| Specification to rebuild from | — | — | — | ✓ |
| Runtime / dynamic corroboration | — | — | — | ✓ |
Supported inputs & platforms
Daritas is vendor-neutral: it reads the control logic itself rather than tying to one manufacturer's tooling. Across controller families, it works from what you can already export.
| Input | Notes |
|---|---|
| PLCopen XML | The preferred, vendor-neutral interchange format — export it from your engineering tool where available. |
| Project / source files | The files your engineering tool produces. Vendor-neutral formats are read first; support for specific vendor formats is added on demand as customers ask for them. |
| IEC 61131-3 logic | Ladder (LD), Structured Text (ST), Function Block (FBD), Sequential Function Chart (SFC), and Instruction List (IL). |
| Supporting documents | Schematics, P&IDs, wiring diagrams, I/O lists, manuals, and functional descriptions — these corroborate and sharpen the model. |
Deliverable formats
Interactive model
A self-contained interactive HTML application: an explorable tree of systems → components → behaviours, with each behaviour expandable to its evidence — the exact source location and the quoted line that supports it. It opens in a browser, works offline, and needs no server or account. This is the primary deliverable.
Document exports
Markdown, Word (.docx), and PDF documents generated from any selection of the model — a function description, an operator summary, a risk register. Clean and formatted, ready to drop into your own documents and meetings.
Structured export
The model in an open, documented, machine-readable format that you own. Each claim carries its source locator and quoted evidence, so the export stays portable and auditable, and integrates with your own systems.
What the model captures
A Daritas model is organised around a few simple kinds of fact, each one carrying the evidence behind it:
| Element | What it is | Evidence-backed |
|---|---|---|
| System / component | A controller, program, function block, or physical unit, and how it fits into the whole. | ✓ |
| Behaviour | Something the system does — a control action, interlock, sequence, calculation, or alarm. | ✓ |
| Dependency | A link between parts — a signal, a shared variable, a call, or a failover relationship. | ✓ |
| Risk | A concern worth flagging — an obsolescence, a single point of failure, an undocumented assumption. | ✓ |
Every element links back to the exact source that supports it. Nothing in the model is asserted without a citation a reviewer has checked.
Getting support
- Customers — submit a support request for billing queries, assessment questions, or technical issues.
- Reviewers — use the support system to flag evidence gaps, ambiguous logic, or inaccessible inputs.
- Response times — Normal priority: 1 business day. High priority: 4 business hours. Urgent: 1 business hour (ops on-call response).