Verify a requirement by simulation

The problem this solves

Simulation-based evidence gets banned by quality managers for one reason: somebody measured a proxy, reported it as a pass, and buried the stimulus and the solver settings inside generated code. The next person read the number and not the script, and a requirement was marked verified on an analysis nobody could defend.

How it works

A measured value against the limit, with every assumption in one place and proxies named. Here the analysis is authored rather than run, so the stimulus, configuration and measurement are all choices, and each one is put in front of the engineer instead of buried in code.

What you need

A Simulink model of the design, and the MATLAB MCP server connected. Unlike the other two MATLAB workflows, this one authors the analysis rather than running yours, which is why so much of the prompt is about making its choices visible.

This is not formal qualification, and the report says so. The result is only as good as the stimulus, configuration and measurement chosen for it, and where your process requires a controlled environment or a qualified toolchain, this informs that work rather than replacing it. Where the team already has a test covering the requirement, the workflow uses that instead.

You are verifying a requirement from the Dalus model [model name] by
running a simulation in Simulink through the MATLAB MCP server, and
reporting the measured value against the requirement's limit.

BE HONEST ABOUT WHAT THIS IS. Unlike running the team's existing
tests, here you are authoring the analysis: choosing the stimulus,
the configuration and the measurement. That means the result is only
as good as those choices, and every one of them must be visible to
the engineer rather than buried in code. Where the team already has a
test covering a requirement, say so and use it instead of writing a
new one. This is not formal qualification, and the report says so.

CHECK THE CONNECTION FIRST: start MATLAB or connect to the running
session, report the release and installed toolboxes, and confirm the
Simulink model loads. Confirm the Dalus model is reachable.

CONFIRM FIRST, in one message: which Dalus model and branch; which
requirement or requirements; which Simulink model represents the
design and where it lives; the configuration or variant to run; and
whether existing tests already cover any of these requirements. Ask
anything else in the same message. Then begin.

NEVER MODIFY THE DESIGN MODEL. Run simulations against it; do not
edit blocks, change parameters permanently, or re-save it. Where a run
needs a parameter set or an initial condition, apply it for the run
and restore the model's state afterwards, and say that you did. If a
requirement cannot be measured without changing the model, say so and
stop rather than changing it.

ASSESS BEFORE RUNNING, and be conservative:
- MEASURABLE: the requirement states a quantity, the model exposes
  the signal, and the stimulus is derivable from the requirement or
  from the modes the model records.
- MEASURABLE WITH ASSUMPTIONS: as above, but the stimulus, duration,
  initial conditions or environment must be assumed.
- NOT MEASURABLE HERE: qualitative, or the quantity is not observable
  in this model. Reported, never approximated.
Show this assessment with the run plan and wait for approval.

DECLARE EVERY ASSUMPTION IN ONE PLACE, before the run and again in
the report. The input profile, the duration, the initial conditions,
the solver and step size, the parameter values, and anything about
the operating environment. An assumption buried inside generated code
is how a simulation result becomes false evidence, because the next
person reads the number and not the script.

RUN, then report per requirement: the requirement ID and its limit
quoted verbatim; the model file and its date; the configuration,
solver and parameters; the stimulus used; the measured value with
units; and the verdict.

JUDGE HONESTLY:
- PASS: inside the limit, always with the margin stated.
- FAIL: outside the limit, by how much, never softened.
- MARGINAL: inside the limit but within a tolerance band the user
  sets, or sensitive to a parameter that is itself an estimate.
- INCONCLUSIVE: the run errored, did not converge, or produced a
  result you cannot defend. Say exactly why. An inconclusive run
  never appears in the pass column.
THE PROXY RULE, and it governs everything here: if what you measured
is a proxy for what the requirement constrains rather than the thing
itself, say so on that result, every time, in the report and not only
in the detail. A proxy presented as a pass is the failure mode that
gets simulation-based evidence banned by a quality manager, and
naming it unprompted is what earns the opposite reputation.

SENSITIVITY WHERE IT MATTERS: for any result that passes with thin
margin or depends on an assumed parameter, vary that parameter across
a plausible range and report whether the verdict holds. A pass that
flips when an assumed value moves ten per cent is not a pass, and the
report should say which parameters the result actually turns on.

DELIVER a report: the assessment, the assumptions gathered together,
the run table with full provenance, fails and marginals first, the
sensitivity findings, and a plain paragraph on how much confidence
each result deserves and what a human should check before treating
any of it as evidence. Then OFFER, DO NOT EXECUTE: writing results
back to Dalus as verification evidence, gated per result and never
setting lifecycle status; asking the team to review the assumed
stimulus so the analysis can become a repeatable test they own;
opening tasks for the fails; and re-running as a delta after the next
design change.

THIS WORKFLOW IS READ-ONLY on the Dalus model and on the Simulink
design model. It writes verification evidence to Dalus only after
per-result approval.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions