Ask your project. Dirac answers from the real numbers.

Overview

Dirac is the chat panel built into the canvas. It reads your project's live data — assets, wiring, commissioning progress, issues, schedule — and answers questions, reports status, and, with your confirmation, makes changes on your behalf. Dirac uses the same calculations as the rest of the app — the same scheduler, the same gate and exposure numbers Management View shows — so an answer from Dirac always matches what you see elsewhere in the app.

Opening Dirac

Dirac AI panel

12345

About the Commands browser

The list you browse is a faithful reference for the full range of commissioning-industry phrasing Dirac is meant to eventually understand end-to-end. It is not a list of what works today — clicking an entry fills the input and sends it exactly like typing it yourself, and if that phrase isn't backed by one of the capabilities below, you'll get the same "command not recognized" response as typing something Dirac doesn't know. The 4 "Import & Data" commands are the one exception — see below.

How Dirac reads a command

Every message is routed through a tier ladder, cheapest and most predictable first. You don't pick a tier — this happens automatically:

Talking to Dirac

Direct commands

Short, exact phrasings resolve at T0/Tier 1 with no LLM call — e.g. "set UPS-A duration to 5 days", "assign CX to L2 on Generator-1", "what's blocking handover", "management summary" (the whole management picture in one answer; add "as a page" to save it as a printable page).

Open-ended questions and requests

With Neural Mode on, anything else falls through to Tier 3 (parses your intent) or T0.5 (reasons and can act). Ask naturally — "why is Generator-1's exposure so high?", "are we ready for handover?", "what should I do next?".

Ask Dirac instead of reading the manual

You don't have to come here to look something up. Ask Dirac directly — "how do I sign off a stage", "what does L4 mean", "how do parallel capacity windows work", "how does the cable library work", "what does the fault level calculation assume" — and it searches the application's manuals (the Application Overview, Dirac, Scenario Testing, Engineering Calculations, Commissioning Tracker, VR Walkthrough, Management View, Scheduling, Permissions & Sharing, Cx Logic Diagrams and the FAQ)' real, current text live and answers with the actual matching section, not a memorized guess. This means an answer is only ever as stale as this manual itself: edit a manual and the very next question reads the update, with nothing else to keep in sync. (Yes, this paragraph is technically describing a feature that can read this same paragraph back to you — that's the point.)

What Dirac can do — the 50 capabilities

mutates capabilities change project data and are always staged for your confirmation first, on every tier that can reach them. Everything else only reads and reports.

Plan this with me — the guided planning interview

For people who are not commissioning or electrical specialists — or for any project in Project Management Only mode — the canvas can be built by answering questions instead of by placing blocks and drawing wires. Type plan this with me (also: "help me plan the project", "let's plan the work", "guide me through the plan", "interview me"). Dirac then asks, one question at a time:

1. Work items. "List the work items" — comma-separated or one per line, over as many messages as you like; say done when the list is complete. If the canvas already has items, name one to reuse it, or say use existing to start from all of them.
2. Order of work. For each item: "What must be finished before X can start?" Answer with item names (comma-separated) or nothing. Each answer becomes a wire on the Field layer (the PM-Only name; "Operational" in the engineering modes). Naming something that isn't on the list yet simply adds it — and Dirac will ask about it too — so you never need a perfect list up front.
3. Decisions and approvals. For each item: "Which decision, approval or release must be in place before X can proceed?" e.g. "Budget approved", "Permit to work", "Design sign-off" — or none. Each becomes a small decision block wired to the item on the Office layer ("Control" in the engineering modes). Naming an existing work item instead makes that item the gate.
4. Review. Dirac summarises items, Field order and Office gates. Say apply to draw it, or cancel to discard. Nothing is written to the project before "apply".

On "apply" Dirac creates the missing blocks (laid out left-to-right by dependency depth, decision blocks in a row above), sizes their ports to the wires, marks them in scope (the canvas "Available" tick), and draws every wire on distinct ports. Existing assets named in the interview are reused, never duplicated. Then open the Schedule and press ⚡ Reschedule: the sequence, the critical chain, Gates and the Management View all derive from those wires exactly as they do for an electrical topology — the office/site logic is the same graph with different words (see the Commissioning Tracker manual's "Layers in Project Management mode").

Full Semantic Memory

Every asset now has a History & Rationale panel — a running, timestamped log of why it's configured the way it is. An entry is added whenever: you add one manually ("+ Add Rationale"), an import brings one in, or Dirac itself makes a mutating change on your behalf. Each entry records who/what made the change, when, and (when available) a plain-language reason.

Ask Dirac why is Bioreactor-1 configured this way? (or "why is X wired/connected/set up this way") and Dirac reads that real recorded history back to you, newest first — not a guess reconstructed from the asset's current position and connections. If nothing has been recorded yet, Dirac says so plainly and points you at "+ Add Rationale" rather than inventing an explanation.

Cross-Project Cascade

For projects that belong to a Group (see the Management View / Permissions manuals for Groups), a Group Combined View lets you draw boundary connections — the real electrical/control links between one project's assets and another's, e.g. a WFI Generation Room feeding a Sterile Filling Suite. Once at least one boundary connection exists, "Run Cross-Project Scenario" in that panel simulates turning a feed on or off and shows what changes in every project the group touches, not just the one you're looking at.

Dirac exposes the same functionality as a chat command — it only appears (and only ever will respond) once the open project is in a Group of 2+ projects; in an ungrouped project this phrasing correctly falls through to "not sure what you mean" rather than offering a capability with nothing to bridge. Ask with generic wording for the other side — "what happens elsewhere if WFI-System goes down", "what happens to the other project if X fails" — since only that generic phrasing is recognized by the fast-matching tiers today; naming the target project explicitly by name currently isn't matched by a fast-path rule and falls through to slower tiers (still answered, just via a different tier).

Standby feeds, open points and paralleling

A connection on the operational layer can be marked Standby feed (normally open) in its connection panel on the canvas (the "Primary" column of the Connections XLSX does the same in bulk: Yes or blank = primary, No = standby). A standby feed is drawn dotted. It is the breaker that sits open under normal conditions — the second utility incomer of a main-main board, the normally-open point of a ring main — and the cascade engine treats it exactly like a Not Available cable: it carries nothing, so an asset whose only feeds are standby cannot have mains on. Every connection you already had, and every new one you draw, is primary.

Three things follow, and nothing else changes:

• Preferred source is simply the primary feed; preferred open point of a ring is the one standby connection in it. Moving the open point is two flag flips.
• Transfer. When a scenario loses a source ("simulate loss of Utility-A", "turn off mains in Utility-A and reevaluate"), the restoration may close a standby feed to bring a load back. The answer lists every standby feed it closed under "Transfers", and the flip is saved with the scenario result, so a later cascade update does not undo the restore. A loss is always break before make — the incomer that lost the voltage opens first, then the alternate closes — whatever the feed's transfer scheme says, because the loss may be a false signal.
• Paralleling. Two live primary feeds into one asset from different root sources is paralleling. An operator cannot create it by accident: "close feed" onto a bus that is already live from another live source is interlocked and refused — unless the feed carries the closed-transition scheme, when the close is accepted as the first step of a closed transition and the answer tells you which feed to open within the window (see "Transfer schemes" below). "parallel feeds" reports what the drawing itself contains or a timing race produced, and every restoration ends with the same check. The same source arriving twice over a ring with no open point is reported as a loop, on the bus where it happens. Several generator sets on one generator bus are what a paralleling switchgear is for — that is shown as an information line, not as a warning.

Switching per asset. The state lives per connection, but you operate it per asset. Select an asset on the canvas: its panel lists its Feeds — every operational input with its source and a Primary / Standby toggle, plus a "manual transfer" tick on a standby feed. In chat: switch Switchgear-A to Utility-B (or prefer Utility-B on Switchgear-A) makes that feed primary and opens the others; open feed from RMU-2 to RMU-3 / close feed from RMU-2 to RMU-3 work one breaker by name; open points lists the switching state. Opening a breaker by hand is a loss of voltage for everything behind it, and the relays downstream cannot tell an operator's open from a trip, so the automatic scheme answers exactly as after a trip — on the clock, Manual-mode feeds left for the operator, the opened breaker itself left open; the answer carries the restoration and the timeline. To switch by hand without the scheme reacting, put the relay in Manual first, as on site. The Feeds list and open points mark such a feed "opened by hand or trip": its normal state is closed, and a transfer that closes it again restores the normal state without remembering anything. When a by-hand sequence ends with the drawing's own open point open, tell the model so — mark feed from RMU-2 to RMU-3 as normally open (or the Standby tick): that is the design statement, and it clears the marker. Every switch is followed by the same re-evaluation: what lost its only carrying feed is turned off, what the new feed reaches is re-energised through the normal validation with the final-stage gate, and the paralleling check runs — the answer lists all of it.

Manual transfer. A standby feed can be marked "manual transfer" (the relay's Manual mode). A loss-of-source scenario will then not close it on its own; the answer lists it under "Available for MANUAL transfer" and you close it yourself. Generators are the last source: a load that an operator could restore by closing such a manual feed from a live utility is never put on generators by the scenario — it waits for you. Without the mark the scenario transfers automatically. This is the only transfer policy modelled; timers, sync-check and dead-bus rules wait for the design sequence of operation.

Rings: a link that carries power both ways. A connection is drawn in one direction, and for scheduling that is the right one: the ring main unit upstream is commissioned first. For energisation a ring cable works in either direction — once the open point closes after a feeder is lost, power comes back through the ring from the far end, against the drawn arrow. Mark such a link Carries power both ways (ring link / tie) in its connection panel (the "Both Ways" column of the Connections XLSX does it in bulk; Yes = both ways). It shows a ⇄ at its midpoint on the canvas, both of its ends list it under Feeds, and the engine lets either end feed the other. Two neighbours cannot hold each other up this way — the circular-dependency guard insists on a real live source behind them — so a ring with a dead feeder goes dark until the open point closes, then comes back from the other side. Closing a ring's open point with both feeders live is reported as paralleling. The drawn direction, ports, scheduling and sign-off are not affected.

Memory of the preferred open point. The standby feed is the preferred open point. When an automatic transfer closes it — a loss-of-source scenario, or a generator paralleling onto its bus — the breaker is closed but the app remembers that this was the normal open point: the asset's Feeds list shows "closed by a transfer — preferred open point", and open points lists it under "Preferred open points currently CLOSED". The transfer also OPENED the incomer that lost its source (break before make — the Feeds list shows "opened by a transfer — normally closed", open points lists it under "Normally closed feeds currently OPEN"), so a returning source never meets a closed breaker. return to normal undoes both as an open transition: step 1 re-opens every transfer feed whose load will be live again once its incomer is back, generator-fed ties first; step 2 re-closes the incomers whose source is live and whose bus has no other live feed at that moment; then the running generator sets are stopped together and their breakers re-opened, because the utility takes priority over the generators (load decides: switchgear, transformers, boards and busbars are distribution, not load; turn on mains in <utility> does the same automatically in the Automatic scheme) — but only if no load that is on would lose its mains without them (otherwise the sets stay running and the answer says what depends on them). Everything that was running through the transfer feeds is without power for the switching instant — the answer counts it — and nothing is ever closed onto a live bus. It reports what it had to leave as it was and why — close the missing source first (e.g. "switch Switchgear-A to Utility-A" once the utility is back), then say it again. What you do by hand is a preference, not a transfer, and is never remembered: "switch", "close feed", "open feed", the Standby tick, the Feeds list toggles and an imported Primary value. So a breaker you closed yourself in Manual mode you also open yourself ("open feed from Utility-B to Switchgear-A", or "switch Switchgear-A to Utility-A"); a feeder you opened for a test and closed again leaves no trace; and opening a breaker by hand also drops any remembered open point on the same asset's other feeds, because you have just chosen where the open point is. Whether the return is automatic, and whether it is an open or a closed transition, is the feed's transfer scheme — the next paragraph.

Transfer schemes. The relay's programme is data on the drawing, not an assumption of the model. A loss of a source is always break before make — the loss may be a false signal (a VT fuse, a stuck contact) while the bus is in fact live, so the incomer that lost the voltage opens before the alternate closes, under every scheme. What the scheme governs is every transfer made while both sources are live: the retransfer when the preferred source has returned, an operator's "switch", a "close feed" onto a live bus. Each standby feed can carry its own scheme (its connection panel under Transfer scheme, or the Connections XLSX columns "Transition", "Parallel Window (s)", "Auto Retransfer (s)", "Priority"), and the project has a default every other feed inherits (set default transition to closed with 2 s window / set default transition to open, set default retransfer to automatic after 30 s / set default retransfer to manual). Nothing set means open transition and manual retransfer — how every project behaved before the scheme existed. Transition: open = break before make, a switching-instant outage (counted); closed = make before break — the preferred feed closes onto the live bus, the two sources are paralleled for the parallel window, then the transfer feed opens: no outage, which presupposes the design verified synchronism (a 25 sync-check, or the same grid on both sides). "return to normal", "switch" and the interlock all read it; while the two feeds are closed, "parallel feeds" reports a ℹ️ closed transition in progress with the window, not a fault (the Feeds list shows "closed transition in progress" on the feed until the other one is opened) — a parallel on a feed without the scheme, or on a bus whose two incomers are normally closed by design, stays a fault. Auto retransfer: with a value, the transfer feed returns to normal by itself, that many seconds after the preferred source has come back ("simulate … on" / "turn on mains in Utility-A" reports "Automatic retransfer"), in the order the transition says; blank = manual, the operator says "return to normal". Priority: among several standby feeds into one bus, the lowest number closes first on a loss; blank = the engine's order (fewest breakers, shortest delay, shortest path). switching model prints the scheme the project actually uses — the default and every feed with its own — before the legend, so the legend never pretends a scheme the drawing does not carry; the Feeds list tags a feed's own scheme, and open points states the default.

Generators and load. A rating means two different things depending on what carries it: on a declared power source (utility feed, generator) the asset panel's Generator Power Rating is generating capacity; on anything else — transformer, switchgear, a row — the panel offers Load (MW) instead, and that is demand. The BIM rated power can be copied into whichever applies with one button ("Use as Generator Power Rating →" / "Use as Load (MW) →"); the Assets XLSX carries both as "Generator MW" and "Load MW". When a loss scenario has to fall back on generators and the command states no load, the start is sized from the sum of Load (MW) over the de-energised assets: enough sets to cover it plus one spare — the running number is always N+1, and the answer warns when the spare is not available; when that sum is zero — no load data — every available generator is started, because generators are the last possible source. In every case the generator bus takes load when the whole started set is ready. The answer says which of the three applied.

Time. A loss-of-source scenario runs on a clock. Three optional delays, all in seconds and all blank (instantaneous) until you set them: on a source that can be lost (a utility feed, a tie), loss confirmed after — how long the loss must persist before transfers start (the relay's 27 pickup); on a standby feed, transfer delay — from confirmation to that breaker closing (in the feed's connection panel, or the asset's Feeds list, or the "Transfer Delay (s)" column of the Connections XLSX); on a generator, start → ready — from the start command to the set being able to take load (asset panel next to the power rating, or the "Start Delay (s)" column of the Assets XLSX). With a stated load ("simulate loss of Utility-A and Utility-B with 20 MW load") the generator bus takes load only once enough started units are ready, and every further unit parallels onto the running generator bus as it becomes ready. The answer then ends with a Timeline — one line per instant: lost, confirmed, generators started, ready, breakers closed, assets back — and an outage summary (how many assets were dark for how long, and the longest). When nothing has a delay the answer is the same as before, with a note that every transfer was instantaneous. The clock models switching and starting only: no synchronising, inrush or protection timing — those stay in the power-system study.

What the switching model assumes — and what it does not pretend to know

Temporary sources, target dates & circular dependencies

Any asset can be flagged Temporary in its Properties panel — a small orange "TEMP" badge marks it on the canvas everywhere it appears. This is purely a label (it doesn't change power-path resolution or auto-expire anything); it exists so a bridge asset like a temporary generator is understood as such, not mistaken for a permanent source. Any asset can also carry a Target Date — a plain per-asset deadline, also set in the Properties panel and not auto-computed from anything.

Target date risk

The Scheduler compares each target-date-carrying asset's currently projected completion against its target. If the plan runs later, a banner appears — and leads with the real verdict up front: ⛔ if the date is NOT achievable even in the best case (the critical path itself needs more working days than are available), or 📅 if it's late but theoretically achievable (a scheduling/capacity artifact — look at Parallel Capacity Windows or task ordering instead). Ask Dirac explain the target date risk for the same breakdown, including the specific longest-duration tasks worth shortening if the date genuinely isn't reachable.

Circular dependency detection & temp-generator placement

A pre-emptive structural check runs before every schedule computation: if the predecessor graph (built from your canvas wiring) contains a genuine unresolvable loop — accounting for redundant/OR feeds, so a bus-tie pair with a real alternate path never false-positives — a "🔁 circular dependency detected" banner appears in the Scheduler. "Explain (Dirac)" names the actual loop.

Two related but distinct Dirac capabilities cover the fix, depending on WHY the loop can't resolve:

• Out-of-scope source (an asset/joint-group depends entirely on a feed that will never be signed off in this project): ask Dirac where a temporary generator would need to go — it's read-only, it only names the fix, it doesn't apply it.
• Genuine raw cycle (no real source anywhere in the loop, even discounting out-of-scope sources): ask Dirac to "place a temp generator to break this cycle" and it doesn't just describe the fix, it applies it (after your confirmation): mints a new temporary generator, already flagged Temporary and force-signed-off on all four stages (so it never needs its own checklists/issues worked through), and wires it directly into the loop.

Import & Data commands

The 4 "Import & Data" commands — import assets from xlsx, export assets to xlsx, import connections from xlsx, import mapping — live under Dirac rather than in a separate sidebar menu, and each opens a real file picker/download instead of routing through the capability registry above.

Confirmation — how mutations stay safe

Dirac never silently changes your project, on either reasoning path:

Multi-step (compound) commands

Without any AI tier you can put several commands in one line, separated by "then", ";" or "and": "turn on mains in Utility-A then return to normal", "project status; help". Dirac runs them in order, each one confirmed as usual. The split is only accepted when every part is a command on its own — "then" and ";" are tried first, so an "and" inside a command stays whole: "force turn off mains on all assets then energize downstream from Utility-A and Utility-B" is two commands, the second keeping both utilities. If a part is not recognised, the whole line is read as one command.

T0.5 can chain several capability calls together to resolve one compound request in a single exchange — for example, "what's blocking handover, and set UPS-A's duration to 5 days" reads the blocking-issue data, reasons over it, then stages the duration change for your confirmation, all in one turn. Chaining is capped at 5 rounds so a confused reasoning loop can't run away unbounded.

Proactive suggestions

With the panel's "Proactive Suggestions" toggle on (default), Dirac watches project state and unprompted surfaces its top recommendation whenever something changes — the same priority order as asking "what should I do next" yourself:

1. An open critical-severity issue outranks everything else.
2. Then an open high-severity issue.
3. Then the deepest unresolved prerequisite chain blocking an unreleased gate.
4. If every gate is released with nothing open, a "ready for handover" note.
5. If the canvas is empty, a nudge to add assets or try a build command.

Dirac's own questions

With the same toggle on, Dirac also asks its own equipment questions when an asset's 3D model needs a fact only you know — for example "How many sections/cubicles does this switchgear or UPS lineup have?" — one asset at a time, marked (proactive question). Answer it plainly: 6, 6 sections, or it has about 6 sections all work. Anything else you type — a command, a question of your own, anything with more in it than the answer — is treated as a normal message, not as the answer, and the question simply stays open until you answer it or switch the toggle off. A command from the library is never read as an answer, even if it contains a number ("tick L1 on all assets" does not set anything to 1). Switching Proactive Suggestions off silences these questions too and withdraws any that is open.

Neural Mode and the AI Tiers tab

Two separate switches gate the LLM-backed tiers (Tier 3, T0.5):

Native Dirac Model (experimental)

The AI Tiers tab (above) has a sixth toggle below Tier 3: Native Dirac Model (experimental) — off by default for every project. It's a genuinely different kind of tier from the other five: not another call to a general-purpose model, but a small, standalone model fine-tuned specifically on this app's own domain knowledge (commissioning terminology, the app's own command library, business/EE fundamentals). It's aimed squarely at "what does X mean"/"what is DQ" style domain-knowledge recall, not at anything that needs live project state or tool use — that stays with T0.5/Tier 3 exactly as before.

Where it sits in the tier ladder

When a command comes back "unrecognized" from T0/Tier 1/Tier 2, and this project's toggle is on, Dirac tries the native model FIRST — before Tier 3 or T0.5 — since it's cheaper (no per-call API cost, no round trip through a third-party API) and its proven strength is exactly this kind of domain question. Unlike Tier 3/T0.5, it does not require the Dirac panel's own per-browser "Neural Mode" footer toggle to be on — it has its own project-level gate and no per-browser gate of its own.

If the native model errors, times out (8 seconds), or has no endpoint configured at all, Dirac silently falls through to Tier 3/T0.5 (if those are enabled) or the ordinary "command not recognized" message — exactly the behavior you'd see with this feature switched off entirely. That means switching this toggle on is safe even before a real endpoint is hosted anywhere persistent — it simply has no effect until one is.

How to try it

👁 Teach Dirac Vision (admin-only)

A separate, global admin screen — reachable from a "👁 Teach Dirac Vision" button on the Project Manager screen's header, never from inside a project's canvas, since the corpus it builds isn't scoped to any one project. It uses the same permission as the existing "🎓 Certificates" button, which is a distinct admin flag from the general project owner/admin role — see the Permissions manual for why those are two different permissions. Anyone without that permission simply never sees the button, and the underlying data is protected independently of the UI, the same as every other admin-gated feature in this app.

Capturing a training example

Every saved example appears in the gallery below the form, newest first, with its thumbnail(s), caption, tags, and capture date. Delete removes an example permanently, behind a confirmation step. Photos are resized to a 1280px-max JPEG before upload and stored under a random filename, never your original filename.

Exporting for training

⇩ Export Vision Training Data downloads every captured example as a single zip file, structured and ready to feed into the vision model's next training run with no reformatting needed. An example is marked "exported" only after the zip has finished building successfully, so a failed download never silently loses track of what still needs exporting.

Growing the corpus straight from your issues

Most projects already have exactly what a training example needs sitting on their issues: a photo, and a title/description an inspector wrote while looking at it. The 🔍 Scan issues for photos + narrative button on this screen finds every issue like that across every project you can see — whether it was raised by hand in the app or came in through a BCF/ACC import — and shows how many qualify. Click + Add N examples from issues to capture all of them in one pass: each becomes a training example using the issue's own title and description as the caption (nothing to confirm or correct here — a human already wrote it looking at the exact same photo), tagged bcf-import or hand-logged so the gallery below can tell them apart, and photographs are copied into this corpus's own storage so a later change to the source issue (or its photo) never affects the training example. Scanning again only ever adds issues it hasn't captured yet — nothing is ever duplicated.

👁 Teach Dirac Through Discussion (any user, in-project)

A second, lighter-weight way to grow the vision training corpus above — not an admin screen, just an ordinary chat exchange with Dirac inside a project, usable by anyone who can open the Dirac panel. Where "Teach Dirac Vision" (above) is for deliberately curated, "good example" photos sourced from anywhere, this is for turning an issue you already raised — with its own photo already attached — into a real, human-verified training example in a few chat turns.

The loop

Describing any photo, not just an issue's

The loop above assumed an issue already existed with a photo attached to it. There are two more ways to reach that exact same confirm/correct/"write it down" loop, for a photo that isn't reached through an issue number at all:

By asset name

Ask Dirac something like "describe the photo for XFMR P1" or "what's in the picture on CRAC_1". There's no separate photo store per asset — the only photos ever attached to an asset live on that asset's own logged issues — so Dirac resolves this to that asset's most recently logged issue that has a photo attached, and describes it exactly like the issue-number path above, including the same grounding in the issue's title and description.

By attaching a photo directly in chat

A new 📷 button sits next to the Send button on the Dirac chat input. Click it, pick any photo from your device, and Dirac describes it immediately — no issue or asset needs to exist first. The photo is read straight to the vision model with no storage upload at all; it's only actually uploaded, lazily, if you go on to say "write it down". Since there's no logged issue to ground this photo against, Dirac uses a plain, generic prompt here instead ("What do you see in this photo? Describe it plainly and flag anything that looks like an installation or maintenance issue.") — there's simply nothing else to anchor it to.

Requires the Native Dirac Model tier to be enabled

Requires a hosted vision model

Beyond the tier toggle above, this feature is also a true no-op until a real endpoint is configured — the same as the text model above. That endpoint is already configured today, so this feature works with no extra setup once the tier toggle above is on, for all three entry points above. If the endpoint ever needs to move, an administrator can update it at any time with no app update required.

Known limitations

FAQ

Massive Dynamic · Dirac AI Manual