Audio System Release Record

The release record is the reproducible identity of the approved system.

It prevents final-final-v2 files, undocumented gain changes, mismatched hardware, and orphaned measurements from becoming the only history of the build.

What Belongs In The Release

Category	Examples
Vehicle and physical build	vehicle configuration, speaker and amplifier models, serials, locations, adapters, enclosure, trim, wiring, labels, service access
Electrical	batteries, charging, protection, conductor paths, grounds, remote sequence, measured voltage drop, approved load state
Source and software	phone or source, app settings, head-unit state, device software, DSP editor project, exported settings, source clean limits
Processing and presets	routing, coefficients, filters, delays, polarity, EQ, dynamics, limiters, mute, user controls, preset and transition matrix
Evidence and documents	raw measurements, acceptance matrix, diagrams, photos, calibration records, user guide, known limitations, service notes

Release States

draft
→ protected bench test
→ candidate release
→ formal acceptance
→ approved release
→ superseded release retained for history and comparison

Do not silently edit an approved release. A meaningful change creates a new identifier, reason, affected requirements, regression scope, evidence, and approval.

Naming

The naming scheme may be simple, but it must be consistent and unambiguous. One practical pattern is:

PROJECT-SYSTEM-MAJOR.MINOR.PATCH-STATE-DATE

For example:

WONDOM-DEMO-1.0.0-RELEASE-20260731

major: architecture or compatibility change
minor: added compatible function or preset
patch: corrected setting or documentation without changing intended operation

This is a project convention inspired by semantic versioning, not a claim that every audio-system change behaves like a software API.

Manifest And Stable Identifiers

The release manifest lists each artifact and a stable identifier such as a file hash, export date plus file size, repository commit, equipment serial, measurement record identifier, or signed revision. The goal is to detect accidental substitution—not to create paperwork for its own sake.

Physical And Functional Comparison

Before approval, compare the installed system with the record:

every physical component, connection, label, fuse, load, and service point
every source, DSP route, preset, user control, amplifier gain, limiter, mute, and restore state
every acceptance result and evidence file
the project file versus the settings actually running in the device

Reload Test

A known-good release is not proven until it can be reloaded into the intended equipment and pass a defined smoke-test set. For the Wondom demonstration, that test includes channel identity, unity paths, center and ambience coefficients, mute, limiter, source limit, output level, and power-cycle restore behavior.