Draft → Validate → Commit
A flexible system for populating devices and I/O from any source
Manual data entry, spreadsheet wrangling, back-and-forth with site contacts.
Ops stitches together P&IDs, tag exports, PLC code, and tribal knowledge. Different every time.
"What's done? What's missing?" No systematic way to track completeness.
Multiple ingest paths → unified draft → validated commit. Clear picture of gaps at every step.
P&ID scan, tag import, network sniff, operator chat, PLC export, photos, manual entry
I/O Draft, Device Draft — partial, inconsistent, tracks provenance and gaps
Validates against templates → Creates real I/O + Devices in Blueprint
The draft layer is the key insight:
✓ Partial — not all fields populated yet
✓ Inconsistent — conflicts from different sources OK
✓ Explicit gaps — "SuctionPressure: ???"
✓ Provenance — "came from P&ID" vs "operator said"
✓ Mergeable — multiple sources contribute
Not all sources apply to all sites. That's the point.
| Source | What It Gives Us | Limitations |
|---|---|---|
| Tag Import | I/O points, aliases, device hints | No connections, no metadata |
| P&ID Scan | Devices, connections, topology | No I/O mapping, may be outdated |
| Network Sniff | Controllers, IPs, protocols | No semantic meaning |
| PLC Code | Control logic hints, setpoints | Messy, not always available |
| Operator Chat | Fill gaps, validate, metadata | Slow, requires site access |
| Photos | Equipment specs, nameplates | Requires LLM extraction |
The system must handle variability gracefully.
→ PLC export possible
→ P&ID scan valuable
→ Operator chat viable
→ Network sniff possible
No single discovery flow will work everywhere.
The draft layer unifies them all.
Ops sees exactly what's done, what's missing, and where conflicts exist.
Template: FrickCompressor
Populated: 8 / 12 fields
Missing: SlideValvePosition_2, OilPressure, Model, Tonnage
Conflict: SuctionPressure has 2 different aliases
Template: Condenser
Populated: 6 / 8 fields
Missing: FanCount, Location
✓ No conflicts
"Here's a PDF — extract devices, connections, and topology"
"Here's a tag list — infer device types and map to templates"
"Here's a nameplate photo — extract manufacturer, model, specs"
"Ask the operator questions to fill remaining gaps"
"This value looks wrong based on similar devices"
"Based on device type, suggest likely missing values"
LLMs help fill the last gaps — there will always be some manual work.
Device templates capture more than what the control system needs.
I/O for real-time monitoring and control. The core use case.
Setpoints, schedules, operating parameters for optimization apps.
Names, descriptions, locations, relationships — so AURA can reason about the facility.
Manufacturer, model, tonnage, install date — for reporting and maintenance.
DeviceTemplates enforce validation across all these domains.
One source of truth for the entire platform.
What else could we tap that we haven't considered?
What should the intermediate representation actually look like?
When two sources disagree, how do we handle it?
Where can AI add the most value with least risk?
Minimum viable version we could ship and iterate on?
Flexible ingest. Unified representation. Clear visibility.
Let's brainstorm.