Verify Performance
verify_performanceProve or fail performance requirements against measured uncertainty bands, returning pass, fail, or indeterminate verdicts with provenance. Escalate indeterminate results instead of guessing.
Instructions
Prove (or fail to prove) every requirement declared with declare_performance — the step that turns "a solver printed 0.29" into a claim with a band and a provenance.
A verdict has THREE states. pass and fail each require the measurement's whole
uncertainty band to sit on one side of the limit; a band that straddles it is
indeterminate, meaning "escalate", not "probably fine". A correlation reading
Cd = 0.28 ± 10 % against a limit of 0.30 spans 0.252–0.308 and has NOT shown the
part passes — collapsing that to a pass is how a spec silently goes unmet.
tier picks the evidence:
'screen'— each requirement's cheap estimator only. Milliseconds, no solver.'solver'— the real solve for every requirement.'auto'(default) — screen first, escalate only what the screen could not decide or what declaresfidelity_floor: 'solver'. This is the ladder that keeps a design loop cheap: cheap measurements eliminate candidates, solves confirm survivors.
Trust is part of the measurement, not a footnote: trust: {converged: true} or a
band_max_pct cap makes an unconverged (or insufficiently mesh-converged) solve
come back indeterminate with the reason, never pass.
Solver-tier measurements are asynchronous, so this returns EITHER the finished verdict (screen-only, or everything already decided) or {job_id, status, pending, results} — poll job_result for the completed verdict. Never raises on a failing requirement; a failure is a row.
Every verdict is also RECORDED on the part, stamped with a geometry signature of
the shape it measured (#261). That record is what merge_assembly,
substitutability_check and component_contract_check consult, since a gate has to
answer synchronously and this may not have: an in-flight solve records rows the
gates read as unverified, and editing the part invalidates the signature so they
read stale — never a pass on either path.
Returns {handle, tier, ok, n_requirements, passed, failed, indeterminate, escalate, results: [{name, tier, metric, state, measured, limit, band_pct, worst_case, best_case, margin, margin_pct, detail, trust_reasons?, screen?, job_id?}]}.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | auto | |
| handle | Yes |