Describe it by hand
The port table is seeded with what was delivered, so you edit it down rather than typing it from scratch.
Delivery & sustainment
You always know what you delivered
The design keeps evolving. The unit you shipped eighteen months ago does not. Prometheus SE keeps both records, keeps them distinct, and can always tell you which one it is talking about.
The record
From frozen snapshot to the machine in front of you
Six steps. What actually shipped stays editable while it is still being figured out — then acceptance seals it, write-once from that moment on. Nothing here quietly overwrites a record once it is meant to be final.
- 01 Freeze
The As-Built snapshot
A deployed unit is a customer, an optional order and an immutable snapshot of the model taken at delivery. The design carries on changing. The As-Built does not — it is a self-contained record, not a pointer at a model that will look different next quarter.
- 02 Record
What actually shipped
The frozen snapshot is the design as specified — but which exact part shipped, which firmware revision, which serial number, is rarely known at that instant. Those actuals live in their own mutable field, separate from the frozen snapshot, filled in and revisited as the real answers come in, right up until the unit is sealed.
- 03 Verify
Sign-off against the delivered unit — and the seal
Level 1 verification runs against the unit, with the method carried through from the frozen procedure. Deliberate two-action sign-off — mark, then accept — captured with verifier and engineer signatures and a printable report. Acceptance is also the moment the as-delivered actuals seal: write-once from then on, enforced in the database rather than hidden in the UI. Before that you can still correct what shipped; after it you log a field change instead, which is the honest way round.
- 04 Re-verify
Rounds, when it is not all clean
A conditional closeout freezes as the permanent record of that event rather than being edited away. Open a follow-on round and only the open items are re-verified, with passes carried forward and a follow-up due date that surfaces on the unit list.
- 05 Log
Field changes, append-only
Swap a part and it is recorded, never overwritten. If the replacement is physically different — different ports, not just a different make and model — the installed structure is captured port by port, and you see the before-and-after before anything is recorded.
- 06 Fold
Deployed vs As-Built
The Deployed configuration is the frozen As-Built with that unit’s change log folded on top: the machine actually standing in front of you. As-Built stays available as the immutable baseline. Toggle between them; a changed block is flagged in both.
Two records, never confused
As-Built is the baseline. Deployed is the truth on the ground.
As-Built
The immutable snapshot taken at delivery.
- Frozen at the moment of delivery
- Serials sealed at acceptance, write-once
- Never edited — not by you, not by Adam
- Always available for “what did it ship with?”
Deployed
The As-Built with that unit’s field changes folded on.
- Reflects every recorded part swap
- Structural swaps redraw the actual ports
- Changed blocks flagged in both views
- What diagnostics reason over
When the replacement part is in no model at all
A distributor’s equivalent, a newer revision, whatever was actually available that week. Three ways to capture it, all landing in the same port-by-port record:
Read a datasheet
The same extraction that ingests documents, except it lands in the port table rather than creating a block — the substitute is on one unit, not in your design.
Ask Adam
Adam searches the web for that exact part’s datasheet. A deliberate, scoped click — not a standing setting — and the result is labeled by what Adam actually did: web-sourced but unverified, or inference when no source was found. That provenance rides into the unit’s permanent record.
When something breaks
Diagnosis reasons over the real machine
When a fault comes in, Adam grounds the session on the Deployed configuration — not the design model, and not the pristine As-Built. A substituted part has different ports; reasoning over the as-delivered structure would walk connections the unit no longer has.
- “What did it ship with?” stays answerable — the as-delivered side of every change is carried into the diagnostic context.
- Guided isolation steps with Adam-authored outcomes: cleared, confirmed, or branch.
- Every session appends a maintenance record to the unit — symptom, cause, what was done, technician, outcome.
- Fault history aggregates across every unit of a model, so a repeat failure stops looking like bad luck.
Boundaries
Adam is walled off from your customer data
The co-modeler cannot see customers or deployments. There are exactly two deliberate, read-only crossings: diagnostic sessions on a single unit, and fleet-failure analysis over recorded fault history. Neither writes anything, and neither feeds back into the co-modeler. Writing sustainment data by AI is not a feature we have quietly enabled.