The platform
One model, the whole SE lifecycle.
Gather requirements, design the system, verify requirements, sell off to the customer — the sequence any SE program already runs, on one event-sourced model that stays formally correct the whole way through. Then it keeps going, because sustainment runs on the same model instead of a handoff to something else.
Gather Requirements
Author them, or hand Adam almost any document and let it extract them.
Requirements are first-class model elements from the moment they exist — author them directly, or upload the document you already have and let Adam pull them out. Customer-sourced text is never rewritten, only decomposed into engineering-level children with your approval, and every requirement is checked against SE-standard quality criteria before it ever reaches the model.
Requirements and verification in depth →- Extracts requirements from almost any format you hand it — PDF, DOCX, or a photograph of a printed page — not just a requirements-tool export
- Applies quality criteria automatically: singular, verifiable, testable, unambiguous — catching a vague or compound requirement before it becomes a program problem
- Proposes Level 2 decomposition for a compound requirement, but never rewrites your Level 1 customer text — you accept, edit or decline every proposal
Design the System
Draw it, describe it, or hand Adam a datasheet and let it build the block.
The canvas is where the system takes shape — blocks, ports, parts and connections, drawn by hand or described in plain language and built by Adam. For a system you are inheriting rather than designing from scratch, document ingestion turns whatever documentation exists — a datasheet, a manual, even a photograph of a nameplate — into a populated block ready for review.
- Builds the canvas from a plain-language description, asking a clarifying question rather than silently guessing when something is ambiguous
- Reads a spec sheet, datasheet, manual or photograph and hands back a structured block — properties, interfaces, flows — every element confidence-rated
- Lets you take just the fields you trust from an extraction and discard the rest, instead of forcing an all-or-nothing overwrite of a block you already built
Verify Requirements
Adam works out what satisfies each requirement. You draw no links by hand.
Adam reads every requirement against the whole model — every block, capability, interface and flow — and reasons about what satisfies it. This is capability-level reasoning, not keyword matching, and it draws a hard line between what is architecturally addressed and what has actually been proven: Prometheus SE models systems, it does not perform verification and validation, and it says so rather than overclaiming.
Requirements and verification in depth →- Builds and maintains the traceability matrix automatically — no manual satisfy-links, and no matrix that goes stale the moment the model changes
- Names precisely which piece is missing when a requirement is only partly satisfied, instead of a blanket "not satisfied"
- Can propose the verification method, procedure and acceptance criteria for each requirement — held explicitly as a plan, since proving it is a step that happens off the tool
Customer Sell-off
A frozen delivery record, a two-action sign-off, a report you can print and hand over.
At delivery, the model freezes into an immutable As-Built snapshot; what actually shipped — serial numbers, firmware, real part identities — gets recorded separately as the answers come in. This sign-off step is deliberately human, not an AI one — the verification plan Adam helped build earlier becomes the checklist a verifier and an engineer actually sign, captured as a two-action mark-then-accept with a printable report. Acceptance is also the moment those as-delivered identities seal, write-once from then on. A conditional closeout is never edited away; it freezes as the honest record of that event, and a follow-on round re-verifies only what is still open.
How a delivered unit is tracked →- The verification plan built in the requirements stage becomes the literal checklist signed against here — nothing has to be re-derived for sell-off
- The As-Built snapshot freezes automatically at the moment of delivery, so there is nothing to remember to archive by hand
- A conditional sign-off is preserved as its own honest record rather than quietly overwritten — a follow-on round re-verifies only what is still open, with prior passes carried forward
Sustain the System
Most tooling stops at sell-off. Prometheus SE keeps the model alive after delivery.
A traditional SE process — and most MBSE tooling — ends at sell-off. Prometheus SE does not: every delivered unit keeps a living Deployed configuration, the frozen As-Built folded together with every field change since, and a diagnostic mode that reasons over the machine actually standing in front of you rather than the pristine design.
How a delivered unit is tracked →- When a field replacement is not in any model, Adam can search the web for that exact part’s datasheet and populate the installed structure — labeled honestly as web-sourced-but-unverified or as inference, never presented as more certain than it is
- In diagnostic mode, Adam grounds every session on the unit’s actual deployed configuration, walks the fault path with you step by step, and the outcome becomes a permanent maintenance record
- Fault history aggregates across every unit of a model, so a repeat failure gets noticed instead of looking like a one-off
No overclaiming
Where the product stands
Prometheus SE is in private beta with hand-selected engineers. Every stage of the lifecycle above is built and usable end to end. Subscriptions are the last piece before public launch.
- Built Requirements, modeling, verification and diagnostic capability
- Built Adam, document extraction, and requirements satisfaction
- Built Accounts, sign-in with Google or GitHub, model persistence
- Built Named versions and a personal component library
- Built Deployed-unit tracking, verification sign-off, maintenance history
- At launch Subscriptions and billing
- Roadmap XMI export for interoperability with existing MBSE tooling
- Roadmap Shared model libraries and real-time collaboration