Designing a Tread-Depth Measurement Pipeline: Units, Probe Location, Uncertainty, Calibration, and Evidence

Design-exercise notice: The software and workflow described here are a conceptual engineering exercise, not live KMJ Tire production infrastructure. Operational tire constraints are real; every dataset, identifier, threshold, calculation, event, and result below is illustrative. Nothing here claims a deployed internal tool, customer-facing system, incident, migration, adoption rate, or production measurement history.

Measuring tread depth sounds like a single-number problem. Place a gauge in a groove, read the display, and save the value. A developer asked to model the process quickly discovers a different reality: a reading is meaningful only when its unit, wheel, groove, axial position, instrument, operator method, time, and uncertainty remain attached. Strip away that provenance and 6 could mean 6/32 inch, 6 mm, the sixth wheel, or an unreviewed string copied from a display.

This article treats tread inspection as a measurement-system design problem. The purpose is not to automate a safety verdict or substitute code for a qualified tire inspection. It is to show how a technically credible pipeline can preserve evidence, reject malformed input, express uncertainty, support recalculation, and expose gaps instead of hiding them. Calgary supplies useful stress cases: a chinook changes pressure and surface conditions quickly, gravel can sit in grooves, road salt obscures markings, and a Highway 1 drive west creates a different context than short urban travel.

Readers who want the driver-facing foundation can begin with KMJ Tire's plain-language tire awareness guide. The sections below stay in the developer and operations lane: schemas, invariants, validation, tests, calibration records, and audit-friendly evidence.

Begin With a Measurement Contract, Not a Database Table

A useful contract answers what the value represents before it specifies storage. Define the measurand as the vertical distance from the tread surface to the base of a selected principal groove at a recorded wheel and probe position. That sentence excludes several tempting substitutions. A wear-bar comparison is useful evidence, but it is not automatically the same observation as a gauge reading. A photograph can support location and condition, yet pixels alone do not produce traceable depth without a calibrated scale and controlled geometry.

The contract should declare a canonical unit. Millimetres work well internally because SI arithmetic is familiar and decimals avoid implicit fractions. Display layers may render thirty-seconds of an inch for readers accustomed to that convention. Conversion belongs at a boundary, with the original observation preserved. The exact factor is:

1 inch = 25.4 mm, therefore 1/32 inch = 0.79375 mm.

Do not round before calculations finish. A displayed 7/32 in can remain a presentation label derived from a stored millimetre value; it should not overwrite the raw gauge output. If the instrument reports 5.6 mm, retain 5.6, the instrument unit, and its stated resolution. A formatter may additionally show an approximate imperial equivalent, clearly marked as converted.

The contract also distinguishes observation from interpretation. “Probe displayed 5.6 mm” is an observation. “This tire is suitable for a planned winter trip” is a contextual judgment requiring more evidence than tread depth. Tire type, damage, inflation, age, weather, loading, and route all matter. Software should make that boundary visible.

Represent Wheel Identity Without Guessing the Vehicle Layout

Hard-coding four corners creates silent errors for dual rear wheels, trailers, spares, commercial configurations, or rotated sets stored off the vehicle. A wheel-position model needs a stable identifier plus optional semantic coordinates. front_left is convenient, but it should not be the primary key because the same casing can move during seasonal service.

One conceptual TypeScript model looks like this:

type DistanceUnit = "mm" | "inch_32";
type AxleRole = "steer" | "drive" | "trailer" | "unknown";

interface WheelLocation {
  assemblyId: string;       // stable within the inspection scope
  axleIndex?: number;       // counted from the front when known
  side?: "left" | "right" | "centre";
  dualPosition?: "inner" | "outer" | "single";
  axleRole?: AxleRole;
  humanLabel: string;
}

The optional fields are intentional. Missing data is not the same as false data. An intake workflow might know “loose wheel B” without knowing which axle it previously occupied. Inventing a corner would create confident fiction. The label helps an operator distinguish items locally, while assemblyId prevents a later rename from changing identity.

Tire identifiers deserve the same caution. A sidewall photo, manufacturer code, size string, and technician-applied set label can coexist as evidence. Parsing should never mutate the original text. The guide to tire sidewall information illustrates why several markings may be relevant, while the load-index explanation reinforces that tread depth alone does not describe capability.

Locate the Probe in Two Dimensions

“Inner, centre, outer” is better than one number per tire, but it is still ambiguous. Inner relative to what: the vehicle centreline, the photographed image, or the person standing at the wheel? Define a reference frame. For an installed tire, axial position can run from the inboard shoulder (x = 0) to the outboard shoulder (x = 1). Circumferential position can run from a documented datum around one rotation (theta = 0 through values below 1).

A structured location might contain both semantic and numeric information:

{
  "groove_role": "principal_2",
  "axial_fraction": 0.62,
  "circumference_fraction": 0.25,
  "reference_frame": "vehicle_inboard_to_outboard",
  "location_method": "marked_tread_and_index_photo",
  "location_uncertainty": {
    "axial_fraction_plus_minus": 0.03,
    "circumference_fraction_plus_minus": 0.02
  }
}

Fractions keep the representation independent of section width and circumference, but they are not magic precision. If a person estimates a quarter turn by eye, the record should not pretend the position was 0.250000. Location uncertainty matters because moving the probe a few millimetres can reach a different groove contour, a stone, a wear indicator, or a localized feature.

A minimal passenger-tire protocol might sample three principal grooves across the tread at three circumferential stations, producing nine observations per casing. That count is illustrative, not a universal service rule. A policy layer must define which locations apply to the tire pattern and the decision being supported. Directional, asymmetric, ribbed, and block patterns need different mapping instructions. The data model should accept an explicit not_applicable reason when a requested groove does not exist.

Separate Raw Observations From Derived Summaries

Mutable “current depth” fields destroy evidence. Store append-only observations, then derive summaries with a versioned algorithm. The raw record should capture what was seen, including failed or questionable attempts. A rejected reading can explain why a valid replacement was taken moments later.

{
  "observation_id": "obs_demo_01J6TREAD001",
  "inspection_id": "insp_demo_20260901",
  "wheel_assembly_id": "wheel_demo_FL",
  "captured_at": "2026-09-01T16:18:42Z",
  "raw_value": "7.0",
  "raw_unit": "mm",
  "normalized_value_mm": 7.0,
  "instrument_id": "gauge_demo_A",
  "instrument_resolution_mm": 0.1,
  "probe_location": {
    "groove_role": "principal_1",
    "axial_fraction": 0.31,
    "circumference_fraction": 0.25
  },
  "surface_state": ["dry", "debris_checked"],
  "quality_flags": [],
  "evidence_refs": ["photo_demo_018", "cal_demo_20260831"],
  "recorded_by": "operator_demo_7"
}

In a real implementation, names containing demo would not be necessary, but they emphasize the truth frame here. The raw value is a string because it mirrors an input or device payload exactly. The normalized number is a parsed derivative. If conversion logic changes, an audit can reproduce the earlier result from the untouched source.

Summaries belong in records such as DerivedTreadAssessment, with fields for algorithm version, included observation IDs, exclusions, calculation time, and output. Never summarize nine readings into a minimum without listing which nine were considered. “Minimum 5.4 mm” is much stronger when a reviewer can discover that one location was excluded because a lodged stone prevented a sound probe placement.

Build a Unit Boundary That Refuses Ambiguity

Accepting a bare numeric field is convenient and unsafe. A parser should require a unit, forbid mixed notation, apply reasonable magnitude checks, and retain conversion metadata. Consider a value reported in thirty-seconds of an inch:

type NormalizedDepth = {
  valueMm: number;
  sourceValue: string;
  sourceUnit: DistanceUnit;
  conversion: "identity" | "inch_32_to_mm_exact";
};

function normalizeDepth(raw: string, unit: DistanceUnit): NormalizedDepth {
  if (!/^(0|[1-9]\d*)(\.\d+)?$/.test(raw)) {
    throw new Error("depth must be a non-negative decimal string");
  }
  const n = Number(raw);
  if (!Number.isFinite(n)) throw new Error("depth must be finite");

  const valueMm = unit === "mm" ? n : n * 0.79375;
  if (valueMm > 30) throw new Error("depth exceeds configured review bound");

  return {
    valueMm,
    sourceValue: raw,
    sourceUnit: unit,
    conversion: unit === "mm" ? "identity" : "inch_32_to_mm_exact"
  };
}

The 30 mm ceiling is an illustrative review bound, not a statement about all tire products. Its role is to catch likely unit mistakes such as entering 32 while meaning 32/32 inch. Domain bounds should generate review events rather than silently clamp data. Negative values, NaN, infinity, locale commas, and strings such as about 6 must fail structured ingestion.

Decimal arithmetic may be preferable to binary floating point if exact reproducibility across languages is required. Another option stores integer micrometres after a validated conversion. Whatever representation is chosen, record rounding mode and scale. Banker's rounding, half-up rounding, and truncation can disagree at display boundaries.

Treat Calibration as Time-Bounded Evidence

An instrument identifier without calibration history is merely a label. A calibration event should state the device, reference used, environmental conditions when relevant, method, observed error, acceptance rule, performer, timestamp, and evidence attachment. The system must determine whether that event was valid at observation time, not merely whether the gauge has ever been checked.

create table calibration_event (
  calibration_id text primary key,
  instrument_id text not null,
  performed_at timestamptz not null,
  valid_until timestamptz,
  reference_id text not null,
  reference_nominal_mm numeric(8,4) not null,
  indicated_mm numeric(8,4) not null,
  observed_error_mm numeric(8,4) not null,
  acceptance_limit_mm numeric(8,4) not null,
  verdict text not null check (verdict in ('accepted','rejected','indeterminate')),
  method_version text not null,
  evidence_uri text not null
);

Suppose an illustrative 5.000 mm reference produces indications of 5.1, 5.0, and 5.1 mm. The mean indication is 5.0667 mm before presentation rounding, so the estimated bias is +0.0667 mm. A design has choices: preserve that bias as uncertainty, apply a documented correction, or reject the instrument under a policy. It must not subtract 0.1 casually because the display resolution is 0.1 mm. Resolution, repeatability, and bias describe different effects.

Calibration lineage includes the reference artifact. If its certificate expires or is later invalidated, dependent measurements may need review. A relational foreign key provides identity; an event graph makes impact analysis easier. Either way, the evidence must be immutable enough that replacing a PDF does not rewrite history. Store a content hash along with the object URI.

Quantify Repeatability Without Manufacturing Certainty

Repeated readings reveal variation from probe seating, groove texture, hand pressure, display quantization, and location recovery. They do not automatically reveal every systematic error. Take repetitions without rounding their individual values, then calculate summary statistics appropriate to the instrument resolution and protocol.

For three illustrative readings at one marked location—5.6, 5.5, and 5.7 mm—the arithmetic mean is:

(5.6 + 5.5 + 5.7) / 3 = 5.6 mm.

The sample standard deviation is 0.1 mm. The standard uncertainty of the mean from repeatability alone is 0.1 / sqrt(3), approximately 0.0577 mm. That smaller number does not prove the true tread depth lies within 0.0577 mm. Calibration bias, resolution, location reproducibility, debris, surface shape, and method effects remain.

Assume, solely for a worked design example, these independent standard-uncertainty components:

• repeatability of the mean: 0.058 mm;
• display resolution contribution: 0.029 mm, using 0.1 / sqrt(12) for a rectangular distribution;
• calibration contribution: 0.050 mm;
• location recovery contribution: 0.080 mm.

The combined standard uncertainty is the root sum of squares:

u_c = sqrt(0.058² + 0.029² + 0.050² + 0.080²) = 0.115 mm approximately.

Using an illustrative coverage factor k = 2 yields expanded uncertainty near 0.23 mm. A record might therefore present 5.60 mm ± 0.23 mm (k=2, illustrative model). The label matters. Coverage factor two is often used as an approximation, but software should not translate it into a guaranteed probability without a justified distribution and degrees-of-freedom analysis.

Preserve Every Exclusion and Retake

Clean datasets can be suspicious. Field measurement involves invalid attempts. A groove may contain compacted gravel, the probe foot may bridge a tread block, the instrument may be tilted, or a photo may not show the marked station. Deleting those events removes the reason for a retake and makes training problems invisible.

Model an attempt state:

attempt_id: attempt_demo_44
status: rejected
reason_code: PROBE_NOT_SEATED
operator_note: "base plate crossed raised block edge"
superseded_by: attempt_demo_45
raw_display: "5.9"
unit: mm
persist_as_measurement: false

The rejected value should not flow into the depth summary, yet it remains in the evidence trail. Reason codes permit analysis, while a short note provides context. Avoid a single bad_data bucket. Useful controlled reasons include DEBRIS_PRESENT, LOCATION_UNCERTAIN, DISPLAY_UNSTABLE, WRONG_UNIT_SELECTED, INSTRUMENT_OUT_OF_VALIDITY, and DUPLICATE_ENTRY.

Retakes should link rather than overwrite. A reviewer can then verify that a changed value resulted from a better attempt, not arbitrary editing. If an accepted observation needs correction, append a correction event identifying the original, authority, rationale, and replacement. Auditability comes from temporal facts, not a mutable updated_at column alone.

Make Environmental Context Descriptive, Not Excusatory

Calgary conditions create relevant metadata without changing the definition of depth. A chinook can raise ambient temperature rapidly. A vehicle moving from a cold driveway into a warm bay may carry meltwater and packed snow. Spring gravel can lodge in grooves. Road salt residue can reduce photographic clarity. Large day-night swings complicate comparisons if methods and conditions are undocumented.

Record conditions that can affect acquisition: tire surface state, approximate tire temperature if measured, indoor or outdoor setting, visible moisture, debris removal method, and elapsed stabilization time when the protocol requires one. Never fabricate weather from a postal code. If weather is imported, store the source, observation station, timestamp, and distance; label it as contextual rather than measured at the tire.

Route labels also need restraint. “Deerfoot commute,” “Stoney Trail loop,” or “Highway 1 west” can describe intended use supplied by a driver, but software cannot infer wear causation from the label. It would be overreach to conclude that one road produced a depth pattern without controlled supporting evidence.

Drivers comparing seasonal choices can consult the separate pages for all-season tires in Calgary, all-weather options, and winter tire guidance. Those categories are contextual inputs; a measurement pipeline should not classify a product from tread depth.

Design an Evidence Bundle That Survives Review

Evidence needs more than a database row. A defensible bundle can include the observation payload, calibration reference, photos, instrument metadata, protocol version, validation output, derivation manifest, and integrity hashes. Store the bundle manifest separately from bulky media so services can verify completeness without downloading every image.

{
  "bundle_id": "bundle_demo_902",
  "schema_version": "tread-evidence/1.0",
  "created_at": "2026-09-01T16:25:00Z",
  "artifacts": [
    {"role":"observation","uri":"obj://demo/obs.json","sha256":"demo_hash_a"},
    {"role":"location_photo","uri":"obj://demo/photo.jpg","sha256":"demo_hash_b"},
    {"role":"calibration","uri":"obj://demo/cal.json","sha256":"demo_hash_c"}
  ],
  "derivation": {
    "algorithm":"depth-summary/2.1",
    "inputs":["obs_demo_01J6TREAD001"],
    "code_revision":"illustrative_revision"
  }
}

The hashes are placeholders, visibly not real evidence. In an implementation, use actual cryptographic digests and define canonical serialization for structured documents. Hashing arbitrary JSON bytes without stable key ordering makes semantically identical files appear different. Content-addressed objects help detect replacement, but access control, retention, backup, and privacy still need separate policies.

Photographs require a capture contract. One overview establishes wheel identity and orientation; a close image shows the gauge at the marked groove; another may show the display. Preserve original files and EXIF carefully, recognizing that timestamps and location metadata can be absent or altered. A photo supports the record but should not be presented as independent calibration.

Validate in Layers, From Syntax to Measurement Logic

Validation works best as several explicit stages. A single boolean valid cannot explain what passed.

1. Envelope validation checks schema version, required keys, types, encodings, and identifier syntax.
2. Unit validation parses the raw representation and confirms an allowed unit.
3. Range review flags implausible magnitudes without rewriting them.
4. Referential validation verifies the wheel, instrument, calibration, protocol, and evidence objects exist.
5. Temporal validation checks calibration validity at capture time and rejects impossible event ordering.
6. Spatial validation confirms fractions are within [0,1], reference frames match, and requested grooves exist.
7. Statistical validation checks repetition count, spread, exclusions, and uncertainty inputs.
8. Policy evaluation applies a versioned decision rule only after the measurement record is complete.

Each stage should emit machine-readable findings with severity, field path, code, and explanation. For example:

{
  "severity": "error",
  "code": "CALIBRATION_NOT_VALID_AT_CAPTURE",
  "path": "/instrument_id",
  "message": "No accepted calibration interval covers captured_at",
  "related_ids": ["gauge_demo_A", "cal_demo_expired"]
}

A warning can allow processing while demanding review; an error blocks derivation. Define that distinction centrally. If downstream services reinterpret severities independently, the same observation may be accepted in one dashboard and rejected in another.

Use State Machines to Stop Half-Finished Records Escaping

A measurement moves through meaningful states. draft allows capture to continue. submitted freezes ordinary edits. validated means structural and measurement checks passed. review_required exposes warnings or conflicts. accepted authorizes inclusion in a specified summary. superseded retains history after correction. voided records a deliberate invalidation.

Transitions need guards. A draft cannot become accepted without a calibration link. A submitted record cannot return to draft by direct mutation; an authorized reopening event records why. A superseded observation cannot silently re-enter a new summary. Those rules can be expressed in application code, database constraints, or event-processing logic, but they should also be tested as a formal transition table.

Idempotency protects ingest endpoints. A mobile client may retry after losing connectivity in an underground parkade. Require a client-generated idempotency key scoped to the inspection, and return the original result when the same payload arrives again. If the key repeats with different bytes, produce a conflict rather than inventing a second observation.

Offline capture introduces clock uncertainty. Store device time and server receipt time, plus a declared clock-quality status. Ordering should rely on causal links when wall clocks disagree. An operator can measure several wheels without service, then synchronize later; the pipeline should preserve that reality rather than forging server-time capture stamps.

Model Aggregation as a Reproducible Function

An aggregation function should accept observations and policy configuration, then return a value plus a complete explanation. The minimum is often important because a low local reading can disappear inside an average. Yet a minimum alone is sensitive to a bad probe attempt. The function therefore needs inclusion rules and evidence status.

interface DepthSummary {
  minimumMm: number;
  maximumMm: number;
  medianMm: number;
  includedObservationIds: string[];
  excluded: Array<{ id: string; reason: string }>;
  axialSpreadMm?: number;
  uncertaintyModelId: string;
  policyVersion: string;
}

Consider nine illustrative normalized means in millimetres:

[6.2, 6.1, 6.0, 5.9, 5.8, 5.9, 5.5, 5.6, 5.4].

The minimum is 5.4, maximum 6.2, and median 5.9. If positions one through three are inboard, four through six centre, and seven through nine outboard, the group means are 6.1, about 5.87, and 5.5 mm. The illustrative difference between inboard and outboard means is 0.6 mm. That is a descriptive spread, not a diagnosis of alignment, suspension, steering, or any mechanical condition.

KMJ Tire performs tire services and oil changes only. When a pattern suggests a vehicle issue beyond tire service, the appropriate output is a neutral referral to a qualified mechanical provider. Software must not claim to identify or repair a mechanical cause from tread readings.

Keep Decision Thresholds Outside the Measurement Record

Measurements are durable; policies change. A stored depth should not become a different number when a policy updates. Keep thresholds in versioned rule sets with jurisdiction, tire category, intended use, evidence requirements, effective interval, and citation fields. Re-evaluation can then produce a new assessment while preserving the original observation.

Avoid equality traps. If a rule evaluates a boundary and measurement uncertainty overlaps that boundary, a binary green/red result may overstate confidence. A defensible engine can return clear, review, or insufficient_evidence, accompanied by the measured interval and exact rule version. The human-facing language must distinguish a legal minimum, a service recommendation, and a conservative planning threshold; they are not interchangeable.

This design article intentionally does not prescribe a universal replacement depth. Drivers can use seasonal tire change information and the tire buying guide for Calgary for broader planning, then have tire condition assessed in context. A code sample should not masquerade as individualized safety advice.

Test the Arithmetic, the Workflow, and the Failure Modes

Unit tests cover conversion and statistics, but pipeline credibility depends equally on adversarial and stateful tests. Start with table-driven conversion cases:

describe("normalizeDepth", () => {
  it("preserves millimetres", () => {
    expect(normalizeDepth("5.6", "mm").valueMm).toBe(5.6);
  });

  it("converts thirty-seconds exactly before display rounding", () => {
    expect(normalizeDepth("7", "inch_32").valueMm).toBe(5.55625);
  });

  it.each(["-1", "NaN", "", "about 6", "6,2"])("rejects %s", raw => {
    expect(() => normalizeDepth(raw, "mm")).toThrow();
  });
});

Property-based tests can generate non-negative decimal strings, run conversions, serialize records, and verify monotonicity or round-trip rules. The round trip needs a tolerance because display conversion may quantize. Tests must state that tolerance rather than hiding it in a generic matcher.

Integration scenarios should include an observation captured one second before calibration expiry, one exactly at the declared boundary, and one after. Decide whether intervals are closed, open, or half-open. Verify that a rejected calibration never qualifies. Test daylight-saving transitions even though canonical timestamps use UTC, because local reports may group events by Calgary date.

Failure injection belongs in the suite:

• object storage accepts an image but the manifest write times out;
• a duplicate idempotency key arrives with altered content;
• device time is two hours ahead of server time;
• a calibration certificate hash no longer matches;
• two operators assign the same local wheel label to different assemblies;
• a groove map changes after an observation has been accepted;
• one repetition is excluded, leaving too few inputs for the configured method;
• a conversion service deploys a different rounding mode;
• an offline client submits schema version zero after the server deprecates it.

The expected behaviour should be explicit: quarantine, retry, conflict, review, or hard rejection. “Logs an error” is insufficient if downstream processing still publishes a summary.

Construct Golden Datasets With Known Imperfections

A golden dataset should not contain only perfect readings. Include cases with debris, invalid units, expired calibration, missing photographs, uncertain location, repeated values, excessive spread, corrected identifiers, and legitimate zeros used in calibration checks. Each fixture needs an expected finding list and derivation outcome.

One compact fixture can describe a wet tire after snowmelt, three readings at a marked groove, a valid gauge check, and a photograph whose display is partly obscured. The expected result might accept numeric data while issuing an evidence warning. Another fixture can hold a clean-looking observation whose calibration ended before capture; its calculation must be blocked even if the value seems plausible.

Synthetic data should always be marked synthetic. Never blend it into operational reporting or use generated identifiers that resemble customer records. A namespace such as demo_ and a top-level data_classification: synthetic field reduces accidental misuse.

Snapshot tests are useful for reports but risky if reviewers approve huge diffs without understanding them. Pair snapshots with assertions about critical semantics: included IDs, excluded reasons, unit labels, uncertainty terms, and policy versions. A pretty report that drops a calibration warning is a regression even if its layout appears stable.

Observe the Pipeline Without Exposing Sensitive Evidence

Operational telemetry should measure system behaviour, not publish raw vehicle or operator details. Useful counters include schema rejection rates by error code, calibration lookup failures, retake reasons, evidence-upload latency, idempotency conflicts, and derivation-version distribution. Dimensions need cardinality limits; observation IDs do not belong in metric labels.

Logs can contain correlation identifiers and finding codes while leaving notes and image locations in protected stores. Traces may connect capture, validation, evidence persistence, and derivation, but access must follow least privilege. Redaction tests deserve the same seriousness as calculation tests.

Alerts need actionable boundaries. A sudden increase in WRONG_UNIT_SELECTED suggests an interface or training problem. A stream of missing calibration references suggests synchronization or configuration trouble. Neither alert should guess at tire condition. System health and physical measurement are separate domains.

For larger operations, the fleet management overview and commercial tire services page provide business context. They do not imply that the conceptual telemetry described here exists at KMJ.

Secure Provenance From Capture Through Retention

Threat modelling begins with ordinary mistakes, then includes deliberate tampering. An operator might select the wrong wheel accidentally. A compromised client could reuse a calibration ID. An object might be replaced after review. A privileged administrator could edit a result directly. Controls should make each problem detectable and recoverable.

Digitally signing client payloads can authenticate a device, though it does not prove the probe was placed correctly. Server-side append-only event storage reduces casual editing. Hash-linked manifests expose missing or reordered events. Role separation can require someone other than the original recorder to resolve certain conflicts. None of these controls transforms poor measurement practice into good data.

Retention policy must cover raw observations, corrections, images, calibration artifacts, derived reports, and access logs. Deleting a person-linked record for privacy reasons may conflict with retaining technical evidence, so identifiers should be minimized at design time. Tokenize operator identity where detailed names are unnecessary, and keep customer information outside the measurement payload whenever possible.

Exports need provenance too. A CSV without schema version, units, time zone, and derivation metadata invites misinterpretation. Prefer a package containing data plus a manifest, or embed required metadata columns even when repetitive. Human readability is valuable, but it cannot replace machine-verifiable context.

Handle Edge Cases as First-Class Domain Events

Tread systems encounter values and configurations that simplistic models reject incorrectly. A brand-new reference check may legitimately read zero after zeroing, while a physical groove observation of zero needs immediate review rather than automatic acceptance. A loose tire has no vehicle-relative inboard side until orientation is documented. A dual assembly needs inner and outer identity. A spare may have no recent route context.

Other edge cases include:

• a principal groove interrupted by a wear indicator at the planned station;
• stones removed between repetitions, changing the local surface;
• a gauge that toggles units mid-session;
• duplicate photos attached to two observations;
• an asymmetric tire mounted with sidewall orientation evidence unavailable;
• a casing rotated between measurement rounds;
• a value recorded with more decimals than the instrument displays;
• measurements split across midnight local time during offline work;
• a damaged area where probing is inappropriate and visual review takes precedence;
• a tire pattern whose groove count differs around the circumference.

Each deserves an explicit status or alternative workflow. The safest software response is often “cannot derive from available evidence.” That answer feels less satisfying than a number, yet it is more useful than manufactured certainty.

Damage assessment remains outside a depth-only model. Information about tire repair considerations in Calgary explains why location and condition matter. A pipeline can route a flagged record for tire-service review; it cannot declare every puncture repairable from tread measurements.

Present Results for Humans Without Flattening the Evidence

A useful report begins with scope: which wheel assemblies, when measured, which protocol, and whether evidence is complete. It displays the original and normalized units, maps probe positions visually, shows repeated readings, and distinguishes observed values from derived statistics. Warnings appear beside the affected result, not buried at the bottom.

Progressive disclosure suits different readers. A driver may first see a plain summary and a prompt to have uncertain tire condition checked. A technician or reviewer can expand location maps, instrument history, exclusions, and uncertainty components. An auditor can download the immutable manifest. Every layer should agree on the underlying IDs and algorithm version.

Avoid traffic-light colours as the sole communication method. Include text, symbols, and explanations. Do not display spurious decimals: a gauge resolving to 0.1 mm should not yield a prominent 5.600000 mm. Conversely, do not round an uncertainty interval so aggressively that a boundary crossing disappears.

For questions about vibration rather than groove depth, direct readers to the separate wheel balancing information. The report should not infer a balance issue from tread measurements. Clear routing protects both technical accuracy and the business boundary.

Stage Implementation With Reversible Decisions

A sensible implementation sequence begins with the measurement contract and paper trials. Ask several people to record the same marked locations and compare ambiguities. Revise the vocabulary before building interfaces. Next create schema validation and a local fixture suite. Add persistence only after identifiers, units, and correction behaviour are stable enough to test.

The following conceptual stages keep risk visible:

1. define measurand, reference frame, allowed units, and evidence minimums;
2. prototype capture forms using synthetic records;
3. test location reproducibility with marked training tires;
4. establish calibration-event handling and expiry semantics;
5. implement append-only observations plus correction links;
6. add derivations with versioned inputs and uncertainty models;
7. run adversarial fixtures and offline synchronization tests;
8. design reviewer screens around findings, not just final numbers;
9. define retention, access, export, and incident procedures;
10. conduct a controlled validation study before any operational reliance.

The validation study would need an agreed reference method, representative tire patterns, multiple operators, multiple gauges, and predeclared analysis. This article supplies none of those results and makes no claim that such a study has occurred. It only identifies what credible evidence would require.

Reversibility matters. Schema versions should coexist during migration. Derived reports can be regenerated from immutable inputs. Feature flags can prevent a new policy engine from changing accepted outputs unexpectedly. A rollback must restore calculation behaviour without erasing events created under the newer version.

Review Checklist for Engineers and Operations Teams

Before trusting a tread-depth data product, review its answers to concrete questions:

• Is the measurand defined in words, including groove base and probe orientation?
• Does every numeric observation carry its original unit and normalized unit?
• Can a reviewer locate the wheel, groove, and circumferential station unambiguously?
• Are raw attempts retained when excluded or retaken?
• Was the instrument's calibration valid at the actual capture time?
• Are resolution, repeatability, bias, and location effects kept distinct?
• Does every summary enumerate included and excluded observation IDs?
• Are policy thresholds versioned separately from measurements?
• Can the system return insufficient evidence without inventing a verdict?
• Do tests cover unit mistakes, offline retries, expiry boundaries, and altered artifacts?
• Are photos supporting evidence rather than uncalibrated numerical substitutes?
• Can exports be interpreted without tribal knowledge?
• Do dashboards avoid claiming mechanical causes?
• Are synthetic fixtures visibly separated from any real records?
• Does retention preserve correction lineage while minimizing personal information?

If several answers are “no,” adding a machine-learning layer will not repair the foundation. Measurement provenance is ordinary engineering discipline: explicit definitions, controlled transformations, honest uncertainty, and reviewable evidence.

Final Design Principle: Make Unknowns Durable

The strongest pipeline does not force every field into a confident number. It preserves unknown wheel orientation, uncertain probe location, expired calibration, incomplete photographs, and conflicting repetitions as durable facts. Those facts guide a retake or qualified review. Erasing them produces a cleaner dashboard and a weaker system.

Calgary's changing conditions make this discipline practical, not academic. Chinook meltwater, gravel, salt, cold-soaked tires, warm service spaces, and long highway travel all create context that may influence acquisition or interpretation. None justifies silently changing a value. Context belongs beside the observation, with source and time.

The conceptual architecture can be summarized as a chain: identify the assembly, define the probe location, capture the untouched reading, validate the instrument state, preserve evidence, quantify known uncertainty, derive a versioned summary, and keep policy judgments separate. When evidence is thin, stop. When a mechanical concern is suspected, refer it to a qualified mechanical provider; KMJ's scope remains tire services and oil changes.

For practical tire-service context, readers can review KMJ Tire's Calgary service area information or mobile tire service overview. Those links describe available tire-related help. They do not imply that the design exercise in this article is deployed, offered, or used in production.

Good measurement software earns trust by showing its work. The output is not merely 5.6 mm. It is a traceable claim: what was measured, where, with which instrument, under which method, supported by what evidence, transformed by which code, and surrounded by how much acknowledged uncertainty. That is the difference between storing a number and engineering a measurement system.