Requirements & verification
A requirement here is a model element, not a row in a spreadsheet that stopped matching reality in week three. Adam reads every requirement against the whole system model and works out what satisfies it — and tells you plainly what it cannot prove.
Requirements come in two levels, and the distinction is enforced rather than suggested.
As originally given, often contractual language. Never edited, split or rewritten — not by you in passing, and under no circumstance by Adam. It stays the authoritative validation target at delivery, and only formal customer-driven change touches it.
Singular, verifiable, testable statements traced back to their Level 1 parent. They exist to make design, integration and test tractable. They are what engineering works against day to day — not what gets validated against the customer.
The enclosure shall be constructed of aluminum and finished in matte black.
The enclosure shall be constructed of aluminum.
The enclosure shall be finished in matte black.
A compound requirement triggers a decomposition proposal, not a rewrite. Adam explains its reasoning; you accept, edit or decline. The Level 1 statement above is untouched by the operation — it remains the thing validated at the end.
At ingestion, at authoring, and on demand across the whole set, each requirement is evaluated against established quality criteria:
Findings are advisory. Never automatic, never blocking, never applied without your confirmation.
Adam reads the requirement text against the full system model — every block, its explicit and inferred capabilities, its interfaces, its logical flows — and works out which elements satisfy it. This is capability-level reasoning, and it shows its work.
If every Level 2 child is satisfied, the Level 1 parent is architecturally satisfied. If only some are, Adam names precisely which decomposed piece is missing — “the steel requirement is met by the frame assembly, but nothing in the model addresses the finish”.
A requirement with no plausible satisfying element is flagged automatically. That is the whole reason the matrix stays current: nobody has to remember to draw the link that proves it is missing.
Analysis is tied to the model’s sequence number. Change a block that satisfies a requirement and that requirement re-checks itself; change the model materially and the status reads “needs re-analysis” rather than quietly showing you yesterday’s answer.
Select a requirement and the canvas highlights what satisfies it. Blocks carrying requirements wear a badge. The traceability matrix rolls it all up, hierarchy and gaps included, and prints.
The line we do not blur
Prometheus SE models systems. It does not perform verification and validation, and it will not let the distinction blur.
The right components exist and are connected in a way that could satisfy the requirement. This is what satisfaction analysis establishes.
A specific numeric tolerance or behavior is proven. This is what testing establishes — and Prometheus SE is not the thing that does it.
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.
Each requirement carries a verification method — Test, Analysis, Inspection or Demonstration — plus a procedure and the acceptance criteria that would prove it met. Adam can suggest all three, advisory and confirm-to-commit.
These fields document how a requirement would be verified, in the conditional. Filling them in never marks anything verified. Actual sign-off happens against a delivered unit — see Delivery.