4. Designing dummy record templates

A dummy certification record is only as trustworthy as the template that produces it. If the template is ambiguous, the filled-in record becomes unverifiable; if the template drifts between revisions without control, traceability collapses. This section treats the dummy record template as a controlled engineering artifact: a schema that defines what fields exist and what they mean, a validation layer that rejects malformed or incomplete records before they enter the review chain, and a version-control discipline that keeps every record bound to the exact template revision under which it was created.

From paper form to machine-checkable schema

The starting point is a field inventory derived from the certification workflow itself, not from a generic form. For a pretest dummy certification record, the fields typically fall into five groups: identification (record ID, dummy serial number, part number, build batch), configuration (dummy type, material, mass, center-of-gravity coordinates, interface geometry revision), test context (test campaign, facility, instrumentation set, ambient conditions), measurement results (measured mass, measured CoG, dimensional deviations, pass/fail per parameter), and sign-off (operator, reviewer, date, template revision). Each field needs a name, a data type, a unit, a cardinality, and an explicit definition of what "empty" means — because in certification records, "not applicable" and "not yet measured" are different states and must not collapse into the same blank cell.

A practical schema is best expressed in a structured, diff-friendly format such as JSON Schema or a YAML field dictionary, so that the schema itself can be reviewed and versioned alongside the records. The following excerpt shows the core of a dummy record schema; note that units are declared per field and that the CoG is modeled as a structured object rather than three loose numbers:

record_id:        {type: string, pattern: "^DCR-[0-9]{4}-[0-9]{3}$", required: true}
dummy_serial:     {type: string, required: true, unique: true}
dummy_type:       {type: enum, values: [ballast, instrumented, mass-model], required: true}
mass_kg:          {type: number, unit: kg, min: 0.1, max: 500, required: true}
cog_mm:           {type: object, required: true,
                   properties: {x: {type: number, unit: mm},
                                y: {type: number, unit: mm},
                                z: {type: number, unit: mm}}}
interface_rev:    {type: string, pattern: "^IF-[A-Z0-9]+$", required: true}
measured_at:      {type: datetime, required: true}
result:           {type: enum, values: [pass, fail, conditional], required: true}
operator_id:      {type: string, required: true}
reviewer_id:      {type: string, required: false}
template_rev:     {type: string, pattern: "^T[0-9]+\\.[0-9]+$", required: true}

Two design decisions deserve emphasis. First, the coordinate convention must be stated once in the schema documentation and never redefined per record: for this course we adopt a right-handed frame with origin at the dummy's datum face, +X forward along the vehicle axis, +Y to the left, +Z upward, all in millimeters. Every CoG value in every record and every diagram in this course uses that convention. Second, the template_rev field is mandatory and self-referential — the record carries the identity of the template that generated it, which is the anchor for the entire traceability review.

Validation rules: structural, semantic, and cross-record

Validation should be layered so that cheap checks run first and expensive checks run only on structurally sound records. Structural validation enforces types, patterns, required fields, and enumerations — the kind of check a JSON Schema validator performs natively. Semantic validation enforces domain constraints that a generic validator cannot know: mass must be positive and within the dummy class envelope; CoG coordinates must lie inside the dummy's bounding box; measured_at must not precede the dummy's build date; a result of pass requires that every measured parameter be present and within tolerance. Cross-record validation catches the errors that only appear in aggregate: duplicate dummy_serial values across campaigns, a record whose interface_rev does not match the revision recorded in the test facility's configuration log, or a reviewer who is also the operator on the same record.

A useful validation outcome is not a boolean but a structured report: each violation carries the field path, the rule identifier, the observed value, and the expected constraint. This makes the failure actionable for the operator and auditable for the reviewer. For example, a record rejected with cog_mm.z = 412.0 mm against a bounding-box maximum of 400.0 mm tells the operator exactly which measurement to re-check, rather than merely stating that the record is invalid.

Version control: binding records to template revisions

Template revisions must be immutable once a record has been issued against them. The practical rule is: any change to field names, units, enumerations, required-ness, or tolerance values increments the template revision; cosmetic changes that do not alter the data contract may be handled as a patch revision, but even then the revision string changes so that the record's provenance remains unambiguous. Records are never migrated silently — if a template revision changes the CoG convention or the mass tolerance, existing records retain their original template_rev and are re-validated only under an explicit, documented migration step.

The repository layout should make the relationship between schema, validator, and records obvious. A workable structure keeps the schema and its changelog together, the validator versioned with the schema, and the records stored under the revision they were issued against:

templates/
  dummy-record/
    T1.0/schema.yaml
    T1.0/CHANGELOG.md
    T1.1/schema.yaml
    T1.1/CHANGELOG.md
    validator/validate.py        # reads schema, emits violation report
records/
  DCR-2024-001.json              # template_rev: T1.0
  DCR-2024-002.json              # template_rev: T1.1

Each changelog entry should state what changed, why, and which existing records are affected. A typical entry reads: "T1.1 — added mandatory interface_rev field; mass tolerance tightened from ±1.0% to ±0.5%; records DCR-2024-001 and earlier remain valid under T1.0 and are not re-validated." This single sentence is what allows a reviewer six months later to reconstruct why two records in the same campaign carry different revision stamps.

How the pieces fit together

The diagram below shows the template lifecycle as a controlled loop: the schema defines the data contract, the validator enforces it at record creation, the revision stamp binds each record to its template, and the review step consumes both the record and its revision context. The key structural point is that the validator reads the schema rather than hard-coding rules, so a revision change propagates to validation automatically and cannot be bypassed by editing the validator alone.

Worked example: a record that fails validation

Consider an operator submitting a record for a ballast dummy with mass_kg = 42.30, cog_mm = (12.4, -3.1, 388.0), and result = pass. The structural validator accepts the record: all required fields are present, the record ID matches the pattern, and the enumeration values are legal. The semantic validator then checks the CoG against the dummy's bounding box, which for this class is defined as z ∈ [0, 400] mm; 388.0 mm is inside, so that check passes. The cross-record validator, however, finds that dummy_serial already appears in a record from an earlier campaign with a different interface_rev. The record is rejected with a violation report naming the duplicate serial and the conflicting interface revision. The operator's corrective action is not to edit the record but to confirm which physical dummy the serial refers to and, if the serial was reused, to assign a new serial and re-issue the record under the current template revision. This is the behavior the template is designed to force: errors are surfaced at the boundary, not discovered during the review.

Deliverable: template definition checklist

The following checklist is the minimum content of a template definition package before it is released for use. It is written to be filled in and signed off, not merely read.

The template is complete when a reviewer can take any record, read its template_rev, open the corresponding schema revision, and reproduce every validation decision that was made at issue time. That reproducibility — not the visual layout of the form — is what makes the dummy certification record defensible in a traceability review.