A build number is not a release record.

Author: IT Modality editorial team
Reviewed: July 14, 2026

The failure usually lives between records

A software ticket can close while a controller revision remains ambiguous. A bench test can pass against a configuration that never reaches the line. A supplier can deliver a corrected package without a shared record of what changed. A plant can accept a workaround that product engineering never sees.

None of those is primarily a documentation-volume problem. It is a custody problem: the identity of the tested system, the evidence behind the decision, and the next accountable owner separate as work crosses organizational seams.

NHTSA describes vehicles as cyber-physical systems and its current best-practices document treats cybersecurity as relevant to organizations designing and manufacturing electronic systems and software. The guidance is voluntary, but the framing is useful: software risk cannot be separated from the physical system and the organizations that produce it. (NHTSA Cybersecurity Best Practices for the Safety of Modern Vehicles, accessed July 14, 2026.)

Establish one release baseline

Before testing begins, create a baseline that can answer these questions without reconstruction:

• Which software, firmware, hardware, calibration, model, configuration, interface, and supplier package are in scope?

• Which plant, line, station, controller, vehicle, environment, or operating mode does the evidence represent?

• Which physical assumptions constrain the software behavior?

• Which requirements and failure modes are assigned to each boundary?

• Which versions were tested together, and which permitted differences exist in production?

• Who owns product, safety, cybersecurity, quality, plant, supplier, and final release decisions?

The baseline is a controlled relationship among records, not a spreadsheet copied into every team. Each source can remain in its operating system if stable identifiers and ownership make the full configuration reproducible.

Make the evidence cross the same seams as the system

Use four linked evidence views.

1. Boundary evidence

Record the expected behavior at every software-to-hardware, supplier-to-integrator, station-to-line, and plant-to-enterprise seam. Include signal or message identity, direction, timing, units, tolerances, state transitions, error behavior, fallback, and owner.

2. Configuration evidence

Connect every result to the exact tested configuration. A result without the hardware revision, calibration, environment, fixture, data set, dependency versions, and known deviations is a story about a test—not reusable release evidence.

3. Failure and recovery evidence

Test the intended behavior and the credible degraded states: missing input, stale value, timeout, partial connectivity, power transition, invalid configuration, unavailable supplier service, and recovery after interruption. Record what the operator sees, what the system does, and who can stop or restore operation.

4. Decision evidence

The decision record names the requirement, result, unresolved exception, consequence, compensating control, decision owner, expiry or review trigger, and the configuration for which the decision applies. A waiver is bounded permission, not a permanent deletion of the defect.

NIST's Secure Software Development Framework is deliberately adaptable to different development lifecycles and supplies common language for producers and purchasers. That makes it useful at the supplier seam, while leaving automotive safety, product, quality, and release authority with the organizations and qualified owners that hold it. (NIST SP 800-218, accessed July 14, 2026.)

Use gates that change the state of the work

Within Frame → Assemble → Govern → Transfer, a release evidence stream should make six decisions visible:

What the acceptance packet should contain

Keep it concise enough for a decision and deep enough for an audit:

• exact release and configuration identity;

• requirements and failure modes in scope;

• test environments, fixtures, data, tools, and limitations;

• result summary linked to detailed evidence;

• defects, deviations, waivers, and their current disposition;

• cybersecurity, safety, quality, supplier, and operating reviews assigned by authority;

• rollback, degraded-mode, support, and monitoring readiness;

• named acceptance owner, decision, date, conditions, and change triggers.

At Verge Mobility Systems, the engagement record for four plants used this pattern to join supplier decisions, controller baselines, plant validation, and enterprise quality evidence. The result was a release record that survived the handoff instead of a larger archive of disconnected artifacts.

Read the Verge Mobility case

Start with one contested release

Choose a release where teams already disagree about version, evidence, exception, or ownership. Trace one decision from change request through the physical configuration, supplier inputs, tests, defect disposition, plant acceptance, and recovery plan. The broken seam will become visible quickly.

Start a conversation.

Supporting links: Explore automotive and industrial work · Review systems integration · Review quality assurance