Agree what a successful native assembly must prove

Freeze the scope and the expected result

This is a buyer-owned acceptance instrument. Before testing, select the relevant criteria, state the inputs and setup, identify each evidence source and mark required checks. Confirm with the vendor which checks are supported in the chosen version and deployment. A row is a question to verify, not a claim that the software already performs it.

For every row record: criterion ID, required status, input/revision, setup, expected result, evidence reference, actual result, verdict, exception owner and reviewer sign-off. The downloadable CSV leaves actual results and approvals blank. Preserve the completed version privately with the permitted evaluation evidence.

Do not average a missing requirement into a pass

• PASS: the agreed check was performed and its recorded actual result meets the expected result.
• FAIL: the check was performed and the expected result was not met.
• CANNOT_VERIFY: the check, evidence or necessary capability was unavailable or insufficient. A blank actual result is unresolved, not PASS.
• N/A: the criterion was explicitly excluded before the run with a reason and owner approval. A required check cannot be N/A.
• Aggregate accepted: all required checks are PASS, no required result is blank/FAIL/CANNOT_VERIFY/N/A, and the designated reviewer signs off. This technical outcome is not manufacturing release.
• If the required set is empty or not agreed, no aggregate acceptance may be issued. Optional exceptions remain visible and are not silently deleted.

Include a negative control and repeat-use test

Use permitted synthetic or expressly authorized inputs to exercise an unsupported interface or missing prerequisite. The expected result should be an explicit stop or review outcome, not an invented successful assembly. Do not use a live hazardous process as a test environment.

For repeatability, change a bounded input while retaining the agreed library and rules. Keep first-time qualification work outside the repeated-run clock but report it separately. Compare like-for-like accepted deliverables, including engineer review and correction effort.

Evaluation criteria

Use this blank checklist to agree the required set before running, then record actual results and evidence in the downloadable worksheet.

AUTH-01 Input authority

Expected: The input subset, purpose and processing permissions are approved by the responsible owner.

Evidence: Scope approval and permitted input inventory.

INPUT-01 Input identity

Expected: P&ID, BOM, model and rule revisions are unambiguously recorded for this run.

Evidence: Versioned inventory and run record; hashes where agreed.

PID-01 Process interpretation

Expected: Required equipment tags and connections match the independently reviewed interpretation.

Evidence: Source references, expected list, actual interpretation and review decisions.

BOM-01 Selection

Expected: Selected part identities, configurations, revisions and quantities match the approved selection basis.

Evidence: Selection reconciliation and exception list.

LIB-01 Library readiness

Expected: Required component references are available and approved for the chosen assembly relationships.

Evidence: Library subset and family/interface readiness record.

IFACE-01 Interface qualification

Expected: Required connection interfaces and permitted relationships are identified without unresolved ambiguity.

Evidence: Qualified interface definitions and affected-occurrence review.

LAYOUT-01 Physical layout

Expected: The output meets the declared envelope, orientation and other supported hard constraints.

Evidence: Active constraint list, coordinate/unit convention and measured result.

ROUTE-01 Connections

Expected: Required connections and supported routing rules match the approved scope; omissions remain visible.

Evidence: Expected connection list, realized connections and exception report.

OPT-01 Optimization

Expected: If optimization is required, the active objective, constraints, stopping reason and measured value are reported.

Evidence: Solver result and agreed baseline; no inferred global-optimum claim.

NATIVE-01 Native deliverable

Expected: The saved deliverable is the agreed editable native assembly, not only a mesh or rendered image.

Evidence: Native document identity, location, revision and reviewer inspection.

REF-01 Reference resolution

Expected: The saved assembly reopens in the agreed environment with the intended component references.

Evidence: Reopen result, resolved reference inventory and failures if any.

MATE-01 Assembly relationships

Expected: Required mates and constraints meet the declared acceptance state; skipped or rejected items are reported.

Evidence: Expected mate list and actual native read-back results.

REBUILD-01 CAD rebuild

Expected: The agreed rebuild check completes with an inspected status and no undisclosed relevant errors.

Evidence: Rebuild result and classified warnings/errors.

POSE-01 Preview consistency

Expected: If required, saved native poses match the preview/handoff within agreed units, frames and tolerances.

Evidence: Occurrence-matched pose comparison from the actual saved native result.

STOP-01 Negative control

Expected: A deliberately unsupported or missing prerequisite produces the agreed stop/review outcome, not a silent PASS.

Evidence: Authorized negative input and visible/logged refusal or review record.

RECOVER-01 Operational recovery

Expected: The agreed interruption scenario recovers or stops without confusing old artifacts with the current run.

Evidence: Job identity, operator recovery steps and inspected output state.

DATA-01 Data boundary

Expected: Actual processing, storage and support access match the approved data-flow schedule.

Evidence: Deployment configuration review and owner confirmation.

REPEAT-01 Repeat use

Expected: A bounded variation is evaluated using the agreed qualified library, with interventions and exceptions recorded.

Evidence: Variation definition, actual result and human-work log.

VALUE-01 Commercial evaluation

Expected: Reported savings use a like-for-like baseline and include setup, review, correction and accepted output scope.

Evidence: Time/effort worksheet, baseline definition and reviewed calculation.

SIGN-01 Engineering authority

Expected: The designated reviewer records the technical acceptance decision and the separate production-release boundary.

Evidence: Signed acceptance record and unresolved exception register.

Sources and revision

Edition 1.0. Reviewed 2026-09-05. Publisher: MST Engineering Intelligence.

• MST evidence method and limits
• MST benchmark method

Cite this edition: MST Engineering Intelligence. “Agree what a successful native assembly must prove.” Version 1.0, 2026-09-05. Canonical online edition.