Your documents
Point Adam at a spec sheet, a manual, or a photograph of a nameplate. It comes back with a structured block — properties, interfaces, flows, inferred capabilities — each element carrying a confidence rating.
AI-native systems modeling
The model builds itself while you think.
Upload a datasheet and get a populated block back. Write a requirement and watch Adam work out what satisfies it. Describe a subsystem and see it appear on the canvas. Your AI co-modeler does the tedious half — and nothing reaches your model until you say so.
Available at launch
- Added an Enable link from the Controller Unit to the Process Unit
- Added a Status link from the Process Unit to the Sensor Unit
Over the whole model
Adam reads each requirement against every block, capability, interface and flow, and works out what satisfies it. Capability-level reasoning, not keyword matching, with the gaps named.
Units in the field
Describe a symptom and Adam grounds itself on that unit’s actual deployed configuration, then walks the fault path with you step by step.
The gap
The tooling was never built for you
Traditional MBSE tools are extraordinarily capable and almost impossible to reach. They arrive through enterprise procurement, need a license server and an IT ticket, and expect you to learn a specification before you can draw a box. Most engineers who would benefit from a formal model never get one.
So the knowledge lives in a slide deck, a spreadsheet, and one person’s head. When that person leaves, the system becomes undocumented — and the next engineer inherits a machine nobody can explain.
35windows
Meet Adam
An AI co-modeler, not an autocomplete
Adam works alongside you across the whole lifecycle — co-modeling on the canvas, reading your documents, reasoning about requirements, and diagnosing faults in the field.
Asks before assuming
When a description is ambiguous, Adam asks a clarifying question rather than silently inventing structure. When it does assume, it says so.
Shows its confidence
Extracted and inferred elements carry a confidence rating. You see how sure Adam is before anything is committed to your model.
Nothing lands without review
Adam proposes; you dispose. Extraction, inference and merge all pass through a review step you control.
Honest about its sources
Adam distinguishes what it read in your documents from what it inferred from general engineering knowledge — and it will not present the second as the first.
This is not a cut-down version of the incumbent tools, and not a SysML wrapper with a chatbot bolted on. It is a new category — an AI-native platform where you work on a rich graphical canvas in plain language, and Adam maintains a formally correct model underneath without the formalism ever being pushed in your face.
The lifecycle
One model, from the first requirement to a unit in the field
Gather, design, verify, sell off — the sequence any SE program already runs. Most tooling, and most process, stops at sell-off. This does not, because sustainment runs on the same model rather than a handoff to something else.
- 01
Gather Requirements
BuiltAuthor them, or hand Adam almost any document and let it extract them.
Adam Extracts requirements from almost any format you hand it — PDF, DOCX, or a photograph of a printed page — not just a requirements-tool export
Requirements and verification in depth → - 02
Design the System
BuiltDraw it, describe it, or hand Adam a datasheet and let it build the block.
Adam Builds the canvas from a plain-language description, asking a clarifying question rather than silently guessing when something is ambiguous
- 03
Verify Requirements
BuiltAdam works out what satisfies each requirement. You draw no links by hand.
Adam Builds and maintains the traceability matrix automatically — no manual satisfy-links, and no matrix that goes stale the moment the model changes
Requirements and verification in depth → - 04
Customer Sell-off
BuiltA frozen delivery record, a two-action sign-off, a report you can print and hand over.
Adam The verification plan built in the requirements stage becomes the literal checklist signed against here — nothing has to be re-derived for sell-off
How a delivered unit is tracked → - Beyond the standard lifecycle 05
Sustain the System
BuiltMost tooling stops at sell-off. Prometheus SE keeps the model alive after delivery.
Adam 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
How a delivered unit is tracked →
Requirements & verification
Traceability that does not go stale
Customer-sourced requirements are never rewritten. Adam reasons satisfaction over the whole model, names the gaps, and draws a hard line between what is architecturally addressed and what is provably verified.
Adam will tell you a control loop exists that could hold a target value. It will not tell you a specific ±2% tolerance is met, because that depends on tuning parameters the model does not capture. Being told the difference is more useful than being told what you want to hear.
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.
- Freeze The As-Built snapshot
- Record What actually shipped
- Verify Sign-off against the delivered unit — and the seal
- Re-verify Rounds, when it is not all clean
- Log Field changes, append-only
- Fold Deployed vs As-Built
Principles
What we refuse to rebuild
Friction eliminated, not rigor
The model underneath is formally correct and designed to map cleanly onto standard interchange formats. What we removed is the dialog maze, not the engineering.
No IT, no procurement, no license server
It runs in the browser. There is nothing to install, nothing to approve, and no seat to be allocated to you by somebody else.
Every capability earns its place
A feature existing in a traditional MBSE tool is explicitly not a reason to build it here. If it does not serve the practicing engineer, it does not ship.
Domain agnostic
Industrial machinery, building systems, consumer products, medical devices, energy infrastructure — any engineered system you need to formally document.
Straight answer
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
Fire, for the people who need it
Prometheus SE is in private beta with a small group of engineers. Put your name down and we will be in touch.