Designing a Tread-Depth Measurement Data System for Calgary Fleets

Fleet tread depth looks like a simple number until someone tries to use it for planning. A technician places a gauge in a groove, records a value, and moves on. Months later, an operations analyst wants to know which tires are wearing unusually fast, whether a winter route changes the pattern, and how much confidence to place in a projected service date. The original number is no longer enough. The system needs position identity, instrument history, measurement context, uncertainty, correction records, and queries that do not quietly compare unlike observations.

This article designs that system from the data outward. It is intended for developers, fleet operators, and technical leads building an internal inspection tool rather than a consumer-facing tire app. Calgary is a useful proving ground because its operating conditions expose weak assumptions quickly. Chinooks can move pavement temperatures across a wide range in a day. Road salt and gravel obscure grooves. Deerfoot Trail creates sustained high-speed duty, while downtown delivery routes add curb encounters and repeated low-speed turns. Highway 1 west introduces a different loading and temperature profile again.

The goal is not to automate a safety decision or pretend that software can diagnose a vehicle. The goal is to preserve observations faithfully, make uncertainty visible, and give qualified people better evidence. When a record suggests tire damage or a mechanical concern outside tire service, the correct workflow is inspection by the appropriate qualified provider. KMJ Tire performs tire services and oil changes; the data model should never imply a broader mechanical service scope.

For foundational driver education behind the field vocabulary, the Be Tire Smart guide is a useful companion. The engineering work starts by treating every reading as an observation made under specific conditions, not as an eternal property of a tire.

Start With Decisions, Not Database Columns

A useful design begins with the decisions the fleet actually expects the dataset to support. Those decisions might include scheduling a closer tire inspection, identifying a tire-position combination that is wearing faster than comparable positions, checking whether readings from one gauge have drifted, or estimating when a tire will cross an internal review threshold. Each purpose creates different requirements.

If the only output is a current-condition list, a single latest value may appear sufficient. Trend analysis immediately breaks that design. A slope needs time, distance, and consistent position semantics. Instrument comparison needs gauge identity and calibration history. Audit review needs an immutable account of original values and later corrections. Route analysis needs exposure data that can be joined without pretending a vehicle spent every kilometre on the same route class.

Write the decisions as testable questions before choosing storage technology:

• Which tire positions have lost depth faster than their peer group over the last 8,000 kilometres?
• Which readings were captured with an instrument whose calibration status was expired at observation time?
• Did an apparent wear jump occur after a tire moved to another wheel position, or after a data-entry correction?
• How wide is the plausible range around a forecast crossing date?
• Can an auditor reconstruct exactly what the operator entered, what software transformed, and what a reviewer later amended?

These questions force a separation between raw evidence, derived facts, and operational interpretation. A raw groove reading belongs in an append-only observation record. A median across grooves is derived. A warning flag is an interpretation based on policy. Storing all three in one mutable row makes later reasoning fragile.

Keep guidance about service fitment separate from measurement telemetry. Tire sidewall markings provide important identity and specification context; the sidewall information reference explains what those markings mean for drivers. A fleet schema should store the observed marking and the normalized interpretation without silently overwriting one with the other.

Give Every Physical Thing a Durable Identity

Vehicle, wheel position, tire casing, mounted assembly, gauge, operator, and observation are different entities. Combining them into a spreadsheet key such as Truck-17-RR feels convenient, but it loses history when a tire is rotated, replaced, or temporarily removed. The identity model should reflect physical continuity.

A vehicle has a fleet identifier and a stable database identifier. A tire asset represents the individual casing, ideally linked to a durable fleet-applied tag. A mounting event connects that tire asset to a vehicle position during a time interval. A reading points to the mounting event as well as the tire. This makes the recorded context explicit and prevents later vehicle changes from rewriting historical meaning.

Position needs its own controlled vocabulary. Passenger vehicles often use LF, RF, LR, and RR, but commercial configurations may have steer, drive, trailer, dual-inner, dual-outer, and lift-axle positions. A string field will accumulate variants such as left rear inner, LRI, and rear-left-inside. Define a position catalog with axle number, side, role, and dual index.

{
  "position_code": "A2-R-INNER",
  "axle_index": 2,
  "side": "RIGHT",
  "dual_slot": "INNER",
  "role": "DRIVE",
  "schema_version": 2
}

Version the position schema because fleets evolve. A two-axle van and a tractor-trailer should not be forced into the same incomplete template. The application may show friendly labels while retaining normalized fields for analysis.

Tire identity should not depend exclusively on a photographed serial marking. Dirt, salt residue, lighting, and partial visibility can make transcription unreliable. Preserve the operator-entered text, any image reference, and a normalized value with confidence metadata. Never discard the raw transcription after normalization.

Load capability is another attribute that belongs to fitment context rather than the tread observation itself. The load index explainer gives the practical background. In the data system, store load-related facts as time-versioned specifications so a later catalog correction does not alter an old inspection silently.

Model Mounting as an Interval, Not a Checkbox

A tire can move between positions, vehicles, and storage. A Boolean is_mounted field cannot answer where it was at a particular odometer value. Use mounting intervals with exclusive time bounds and database constraints that prevent impossible overlap.

create table tire_mounting (
  mounting_id uuid primary key,
  tire_id uuid not null references tire_asset(tire_id),
  vehicle_id uuid not null references vehicle(vehicle_id),
  position_code text not null references position_catalog(position_code),
  mounted_at timestamptz not null,
  removed_at timestamptz,
  mounted_odometer_km integer,
  removed_odometer_km integer,
  source_event_id uuid not null,
  check (removed_at is null or removed_at > mounted_at),
  check (removed_odometer_km is null or mounted_odometer_km is null
         or removed_odometer_km >= mounted_odometer_km)
);

In PostgreSQL, exclusion constraints can prevent the same tire from occupying overlapping mount intervals. A second constraint can prevent two tires from occupying the same single-tire position concurrently. Dual positions remain distinct because their position codes include inner and outer slots.

The observation service should resolve the active mounting when a user starts an inspection, then store the resolved mounting_id in the observation. Do not resolve it dynamically every time a report runs. Historical records should retain the exact association accepted at capture time, even if a later correction creates a superseding mounting record.

Seasonal swaps make this especially important in Calgary. A fleet can move from winter equipment to another seasonal setup during a narrow operating window. The seasonal tire change guidance provides practical context, while the database must capture precise event boundaries. If a measurement falls close to a swap, timestamp and odometer consistency checks should flag ambiguity for review.

Avoid hard deletion. If a mounting was entered against the wrong vehicle, close or supersede it through a correction event. The initial mistake is part of the audit history; the current operational view can hide it without erasing it.

Represent Grooves Instead of Hiding Them in an Average

A single tire can have several measurable circumferential grooves, and wear is rarely perfectly uniform across them. Saving only an average removes evidence of shoulder-to-centre differences and makes it impossible to reprocess the data under a better aggregation rule.

Represent each probe location explicitly. A flexible model describes lateral bands from vehicle-outboard to vehicle-inboard, while a tire-pattern template maps those bands to recognizable grooves. The template helps the user place the gauge consistently without pretending every tread design has identical geometry.

{
  "observation_id": "01JZZ...",
  "tire_id": "01JTY...",
  "mounting_id": "01JMX...",
  "measured_at": "2026-07-31T15:24:11Z",
  "depth_unit": "mm",
  "probes": [
    {"band": "OUTER", "sequence": 1, "raw": "7.4", "value_mm": 7.4},
    {"band": "CENTRE_LEFT", "sequence": 2, "raw": "7.1", "value_mm": 7.1},
    {"band": "CENTRE_RIGHT", "sequence": 3, "raw": "7.0", "value_mm": 7.0},
    {"band": "INNER", "sequence": 4, "raw": "6.8", "value_mm": 6.8}
  ]
}

Store the literal input string alongside the parsed numeric value. That small choice helps distinguish 7.0 from a value transformed from another unit, and it supports investigations into locale or keypad problems. Store the canonical measurement in millimetres using a fixed-precision decimal type. Binary floating point is a poor choice for values that are displayed, rounded, and compared against policy boundaries.

An aggregate such as minimum groove depth may be computed for operational views, but label it with the algorithm version. Minimum, median, trimmed mean, and selected-primary-groove are different summaries. Keeping probes makes all of them reproducible.

The system must not translate uneven readings into a mechanical diagnosis. It can describe the pattern and request an appropriate inspection. Tire-related assessment can lead to tire service; suspected mechanical causes should be directed to a qualified mechanical provider. Software should report evidence without exceeding the business or professional scope.

Treat the Gauge as a Measured Asset

The gauge contributes uncertainty and can introduce systematic error. Give each physical gauge an asset record with manufacturer, model, resolution, serial identifier if available, acquisition date, status, and service history. A fleet with two visually identical tools still has two measurement systems.

Calibration is not a timeless flag. It is an event tied to a procedure, reference standard, environmental conditions, operator, observed deviations, and an interval of accepted use. A simple structure might include:

create table gauge_calibration_event (
  calibration_id uuid primary key,
  gauge_id uuid not null references gauge_asset(gauge_id),
  performed_at timestamptz not null,
  performed_by uuid not null,
  method_version text not null,
  reference_standard_id text not null,
  reference_depth_mm numeric(6,3) not null,
  observed_depth_mm numeric(6,3) not null,
  ambient_temp_c numeric(5,2),
  accepted boolean not null,
  valid_until timestamptz,
  evidence_uri text,
  notes text
);

Do not rewrite measurements by subtracting a newly discovered gauge bias unless the correction policy explicitly supports that transformation. Preserve the raw reading and create a derived, versioned adjusted value. Analysts can then compare results under the original and revised calibration assumptions.

Calgary weather adds practical complications. A gauge moved from a cold vehicle into a warm bay may carry moisture or experience a temperature transition. Road grit can prevent correct seating. The capture form should allow condition flags such as DEBRIS_CLEARED, TEMPERATURE_TRANSITION, or REPEAT_REQUIRED. These are not excuses to accept bad data; they are evidence that helps reviewers judge fitness.

Daily check blocks can complement formal calibration. An operator measures a known reference before a shift, and the system confirms that deviation remains within the organization’s accepted tolerance. The software should store the reference result, not merely a green icon. If the check fails, quarantine subsequent observations until review rather than deleting them.

Make Uncertainty a First-Class Field

Precision on the screen is not the same as certainty in the field. A display that shows hundredths of a millimetre does not prove that probe placement, groove debris, gauge repeatability, and operator technique support that precision. An honest system attaches an uncertainty estimate and records how it was derived.

For a practical model, separate contributors:

• instrument resolution and known calibration deviation;
• repeatability estimated from repeated probes at the same location;
• placement variation across the chosen groove band;
• environmental or surface-condition penalties;
• unit conversion and rounding effects.

If the contributors can reasonably be treated as independent, combine standard uncertainties using root-sum-of-squares. Suppose an illustrative reading has 0.05 mm instrument contribution, 0.08 mm repeatability contribution, and 0.06 mm placement contribution:

u_c = sqrt(0.05^2 + 0.08^2 + 0.06^2)
    = sqrt(0.0025 + 0.0064 + 0.0036)
    = 0.112 mm

An expanded uncertainty might apply a coverage factor, but the system must state the factor and method rather than presenting a mysterious plus-or-minus value. These numbers are illustrative, not KMJ operating tolerances or service promises.

Uncertainty belongs at the probe level when repeats differ across locations. The aggregate can derive its own interval through the documented algorithm. Do not merely average individual uncertainty values. For minimum-groove decisions, the uncertainty around the selected minimum and the possibility of selection switching both matter.

A conservative policy query can compare the lower plausible depth against an internal review threshold. Another report may use the central estimate. Both are valid if their semantics are explicit. What is dangerous is one unlabeled depth column serving every purpose.

Measurement uncertainty also changes forecast language. Instead of “replacement date is October 12,” report a central crossing estimate with a plausible interval and the assumptions behind it. A forecast is operational planning evidence, not a guarantee.

Capture Context Without Turning It Into Fiction

Wear depends on exposure, yet route context is often reduced to one dropdown. A vehicle that spends Monday on Stoney Trail, Tuesday in dense city delivery, and Wednesday on Highway 1 west cannot honestly be assigned one permanent route type.

Model route exposure over intervals or trips. Useful categories could include urban stop-start, ring-road cruise, high-speed divided highway, mountain corridor, industrial gravel access, and yard operation. Categories should be fleet-defined and versioned. They describe duty, not causation.

Weather should come from a traceable source and time window. Store source station, observation period, and transformation version for freeze-thaw cycles, precipitation, or temperature ranges. “Chinook exposure” needs an operational definition, such as a temperature rise crossing a specified band within a defined interval. Without a definition it is a story, not data.

Salt and gravel are similarly difficult. A route class may imply exposure probability, but it does not prove material was present on a particular trip. Keep inferred exposure separate from direct inspection notes. Fields should encode provenance:

{
  "gravel_exposure": {
    "value": "LIKELY",
    "basis": "ROUTE_CLASS_INFERENCE",
    "model_version": "route-exposure-3"
  },
  "groove_debris_observed": {
    "value": true,
    "basis": "OPERATOR_OBSERVATION"
  }
}

Distance is central to wear rate. Prefer a trustworthy odometer reading or integrated telematics total with source metadata. When sources disagree, preserve both and apply a reconciliation rule. Never force kilometre exposure to zero simply because a feed was unavailable.

For commercial operations, the fleet tire management overview and commercial tire service information provide service context. The telemetry model should remain vendor-neutral so the fleet retains a coherent history across service events.

Build a Write Path That Rejects Impossible Records

Validation belongs in layers. The mobile interface prevents common mistakes, the API enforces business invariants, and the database protects referential integrity. No single layer should carry the whole burden.

At capture time, require tire, mounting, gauge, operator, timestamp, depth unit, and at least the expected probe set or an explicit reason for incompleteness. Reject negative depth and absurdly large values at the API boundary. Keep configurable plausibility limits distinct from legal or safety thresholds.

Cross-field checks catch subtler errors:

• observation time must fall within the referenced mounting interval;
• vehicle odometer cannot be materially below the previous accepted value without a documented odometer event;
• gauge must exist and must not be retired at measurement time;
• calibration state must be resolved as-of the observation, not as-of query time;
• probe bands cannot repeat within an observation unless repeats are explicitly numbered;
• a converted value must retain original unit and conversion version;
• the operator’s local timestamp must include a timezone offset.

Calgary uses Mountain Time with daylight-saving changes. Store instants in UTC and retain the reported offset or IANA zone for display and audit. A naive 2026-11-01 01:30 can occur ambiguously around a clock change. Inspection ordering should never depend on an unzoned local string.

Idempotency is essential for mobile sync. Assign a client-generated observation identifier before upload. A retry with the same identifier and identical payload should return the accepted record. A retry with altered content should be rejected as a conflict, forcing an explicit amendment rather than silent mutation.

Offline capture also needs reference snapshots. If the position catalog or gauge roster changes before sync, the record should retain the versions displayed to the operator. The server can flag stale references while preserving what actually happened.

Separate Raw Events From Analytical Projections

An event-oriented core gives the strongest auditability. Capture ObservationRecorded, ObservationVoided, ObservationSuperseded, MountingStarted, MountingEnded, GaugeChecked, and CalibrationAccepted as immutable facts. Build current-state tables or materialized views from those events.

This does not require adopting an elaborate event-sourcing framework. A conventional relational database can use append-only tables, transactionally updated projections, and an outbox for downstream processing. The crucial rule is that edits produce new events.

create table tread_event (
  event_id uuid primary key,
  aggregate_id uuid not null,
  aggregate_type text not null,
  event_type text not null,
  event_version integer not null,
  occurred_at timestamptz not null,
  recorded_at timestamptz not null default now(),
  actor_id uuid not null,
  correlation_id uuid not null,
  causation_id uuid,
  payload jsonb not null,
  payload_hash text not null,
  unique (aggregate_id, event_version)
);

Hashing the canonical payload can expose accidental changes, but a hash is not a complete security system. Access control, backups, database logs, key management, and administrative oversight still matter. If cryptographic signing is required, document key rotation and verification procedures.

Analytical projections can flatten probe readings for speed. A warehouse fact table might contain one row per probe, with dimensions for vehicle, tire, position, gauge, route exposure, and calendar. The fact row should carry source event and transformation version so analysts can trace any result back to the accepted evidence.

Late-arriving data is normal. A mounting correction may appear after observations have been loaded into the warehouse. Use bitemporal fields or effective-date rebuilding so reports can answer both “what is currently believed?” and “what did the system believe when this report ran?”

Design Trend Queries Around Comparable Segments

Naive wear rate divides depth loss by elapsed days. Fleet tires experience distance, loads, routes, and seasonal conditions, so kilometres are usually the better exposure denominator when reliable. Even then, do not fit one slope across mounting changes or incomparable measurement methods.

First create segments that maintain tire identity, mounting position, depth algorithm, and acceptable instrument state. Then calculate distance-normalized change inside each segment.

with ordered as (
  select
    tire_id,
    mounting_id,
    measured_at,
    odometer_km,
    min_depth_mm,
    lag(odometer_km) over w as prior_km,
    lag(min_depth_mm) over w as prior_depth
  from accepted_tread_observation
  where calibration_state = 'VALID'
  window w as (
    partition by tire_id, mounting_id, algorithm_version
    order by measured_at
  )
)
select *,
  case when odometer_km - prior_km >= 500
    then (prior_depth - min_depth_mm)
         / ((odometer_km - prior_km) / 1000.0)
  end as wear_mm_per_1000_km
from ordered;

The 500-kilometre floor above is illustrative. A real organization should derive its minimum exposure interval from gauge repeatability and operational needs. When depth change is similar in magnitude to measurement uncertainty, the point estimate can swing wildly. Wider spacing may create a more stable signal.

Use robust regression for longer segments because one questionable observation should not dominate the slope. Weight observations by inverse variance only if uncertainty estimates are comparable and well-calibrated. Otherwise, the mathematical sophistication creates false confidence.

Peer comparisons need careful grouping. Compare similar position roles, tire types, duty patterns, and seasons. A steer position on Deerfoot-heavy service is not a clean peer for a trailer position on low-speed industrial routes. Publish the cohort definition beside every percentile or anomaly score.

For drivers and operators interpreting tire condition rather than building queries, the tire care and awareness guide offers plain-language context. The analytical system should complement physical inspection, never substitute for it.

Forecast With Intervals and Explicit Assumptions

A crossing forecast estimates when a tread metric may reach an organization-defined review threshold. It should not declare a tire safe until a date. Future route, distance, weather, loading, and measurement quality are uncertain.

Begin with a qualified segment: enough accepted observations, sufficient kilometre span, stable mounting identity, no unresolved gauge issue, and a slope direction that makes physical sense. Record why a segment qualified. If it did not, return “insufficient evidence” rather than manufacturing a date.

A basic distance-to-threshold estimate is:

remaining_km = (current_depth_mm - review_threshold_mm)
               / wear_mm_per_km

Propagate uncertainty from current depth and slope. Bootstrap resampling is often easier to explain than a closed-form approximation, especially with irregular observation intervals. Sample accepted readings within a documented model, refit the slope, and produce a distribution of crossing distances. Store the random seed, code version, input event identifiers, and model configuration for reproducibility.

Calendar conversion requires a distance forecast. Use a range based on recent duty rather than one fixed daily value. A vehicle assigned to seasonal projects can invalidate a trailing average. Allow dispatch planners to supply a scenario without overwriting the historical forecast.

Every output should show:

• the measurement metric used, such as minimum accepted groove;
• the internal review threshold and policy version;
• central distance estimate plus interval;
• assumed future kilometres per week;
• latest accepted observation time;
• exclusion reasons for any nearby readings;
• model and data versions.

The interface should emphasize inspection when evidence is stale or conflicting. It should not use red countdown theatrics to imply certainty. For physical tire damage, the Calgary tire repair information explains the service context, but software must not pre-judge whether damage is repairable.

Preserve Corrections Without Rewriting History

Field data will contain mistakes. An operator may choose the wrong tire, transpose digits, or measure a different groove sequence. A trustworthy system makes correction easy while keeping the original evidence visible to authorized reviewers.

Use a supersession pattern. The amendment references the original event, states a reason code, includes explanatory notes when needed, and contains the replacement payload. Current operational views select the latest valid branch; audit views show the full chain.

Reason codes should be specific enough for quality analysis:

• WRONG_TIRE_SELECTED
• WRONG_POSITION_SELECTED
• TRANSCRIPTION_ERROR
• UNIT_ERROR
• GAUGE_ID_ERROR
• DUPLICATE_CAPTURE
• MEASUREMENT_PROCEDURE_NOT_FOLLOWED

Do not let a reviewer change an operator’s record in place. The reviewer authors a new event under their own identity. Store actor role, authentication context, application version, device identifier where appropriate, and server receipt time. Avoid collecting unrelated personal data.

Voiding is different from correcting. A duplicate may be voided without replacement. A unit error usually has a corrected successor. Reports should exclude voided observations by default while allowing auditors to include them.

Notifications may be needed when a correction materially changes an active plan, but that is a workflow event, not a reason to mutate the old report. Generate a revised artifact with a reference to the superseded version.

Test the Measurement Pipeline Like Safety-Relevant Infrastructure

Tests should cover more than HTTP responses. The risk lies in semantic corruption: wrong positions, incorrect unit conversion, hidden time shifts, bad calibration joins, and forecasts built from incomparable points.

Property-based tests work well for invariants. Generate mounting intervals and prove that overlap constraints hold. Generate millimetre and thirty-second-inch inputs and confirm round-trip behavior within the declared rounding policy. Generate amendment chains and verify that current-state selection is deterministic.

Golden datasets can represent difficult Calgary scenarios:

1. A chinook week with rapid ambient change and repeated readings from a cold-stored gauge.
2. A seasonal tire swap followed by an offline observation that synchronizes late.
3. A dual-wheel vehicle where inner and outer position labels were reversed, then corrected.
4. A gravel-route inspection with debris flags and a repeated probe after cleaning.
5. An odometer replacement event that would otherwise create negative distance.

Contract tests should validate event schemas across mobile, API, and warehouse consumers. Adding a required enum value can break an offline client. Prefer tolerant readers, explicit schema versions, and migrations that preserve old payload interpretation.

Run mutation tests against unit conversions and threshold comparisons. A flipped operator near a boundary is exactly the defect ordinary happy-path testing may miss. Query tests should assert cohort membership, not just final averages.

Operational monitoring needs data-quality signals: rejected observations by reason, stale gauge checks, unexpected unit mix, duplicate client identifiers, correction frequency, missing kilometre exposure, and warehouse lag. Alert thresholds should come from observed baseline behavior and risk review, not arbitrary dashboard decoration.

Secure the System Without Blocking Field Work

Role-based permissions should mirror responsibility. Operators capture observations. Supervisors review exceptions. Calibration custodians record instrument events. Analysts read pseudonymized operational data. Administrators manage accounts but should not silently alter observations.

Use short-lived authenticated sessions on managed devices, encrypted transport, and encrypted local storage for offline queues. A lost device should not expose fleet history. Remote revocation matters, but queued observations need a defined recovery procedure so evidence is not casually lost.

The application should minimize data collection. Tread analysis needs an operator identifier for accountability, not unrelated employee details. Retention periods should reflect operational, insurance, contractual, and legal advice applicable to the fleet.

Audit logs need their own access controls. They can reveal routes, work patterns, and device metadata. Export actions should be logged, and bulk access should be restricted. Backups must be tested through restoration exercises rather than assumed healthy because a job reports success.

Threat modeling should include ordinary failure as well as malicious behavior: shared logins, copied spreadsheets, clock drift, offline retries, duplicated events, and a well-meaning administrator fixing data directly in SQL. Guardrails against accidental corruption often deliver more immediate value than exotic controls.

If a tire observation indicates a service need, a human should decide the next step. The mobile tire service page describes one tire-service option in the Calgary area, while fleet workflows should route any non-tire mechanical concern to a suitable qualified provider.

Ship in Stages and Keep the Evidence Portable

A sensible first release captures durable tire identity, normalized position, mounting interval, gauge identity, calibration state, individual groove readings, odometer, timestamps, and correction events. That foundation supports credible current-state views before advanced forecasting exists.

The second stage can add route exposure, uncertainty calculations, robust trend estimates, and exception queues. Forecasting belongs later, after measurement repeatability and data completeness have been observed in production. Machine learning is not a substitute for stable identities and calibrated inputs.

Design exports early. A fleet should be able to retrieve documented CSV or Parquet tables, event JSON, schema definitions, and attachment manifests. Proprietary dashboards are useful, but they should not become the only way to interpret the history.

Measure system success with evidence-quality outcomes:

• percentage of observations tied to an unambiguous mounting;
• proportion captured under valid gauge status;
• repeat-measure variation by operator and instrument;
• time from exception creation to review;
• correction rates by cause;
• share of forecasts meeting minimum evidence criteria;
• ability to reproduce a report from immutable inputs.

Do not reward staff for generating more readings regardless of quality. A smaller set of well-controlled measurements is more valuable than a dense stream of ambiguous numbers.

When a fleet needs tire-specific operational support, information about commercial tire services, wheel balancing, and Calgary service coverage can connect the data workflow to real tire service. Those links do not change the core engineering rule: observations, interpretations, and service decisions remain separate records.

A Practical Review Checklist for the Architecture

Operate Data Quality With Lineage and Service Levels

Once the capture system is live, data quality becomes an operational product. A weekly spreadsheet cleanup is not enough. Define service-level indicators for the evidence pipeline and make ownership explicit. Useful indicators include the percentage of uploads processed within fifteen minutes, the share of accepted observations linked to a valid calibration event, the age of unresolved position conflicts, and the maximum delay between an event reaching the transactional store and appearing in an analytical projection. These measures describe system health; they do not claim anything about tire safety.

Every derived field needs lineage. For a value such as wear_mm_per_1000_km, retain the two or more source observation identifiers, mounting segment, kilometre source, exclusion policy, algorithm version, and execution timestamp. A dashboard user should be able to move from a plotted point to the underlying probes without searching through unrelated tables. That drill-through path is also the fastest way to resolve disagreements between an operator and an analyst.

Projection rebuilds deserve a rehearsed procedure. Create a clean schema, replay an immutable event snapshot, recompute hashes or row counts at defined checkpoints, and compare the rebuilt results with the active projection. Differences must be explainable through software versions or corrected source events. If a rebuild depends on whatever reference table happens to be current, the system is not reproducible. Snapshot or effective-date every lookup that affects meaning.

Quarantine queues should be visible and finite. Records can enter quarantine because of an expired gauge check, an impossible odometer sequence, an ambiguous mounting, or a missing probe. Each queue item needs an owner, reason, creation time, permitted resolution actions, and a record of the outcome. “Ignored” is not a resolution. If the evidence cannot be recovered, mark the observation unusable for specific analyses while retaining it for audit.

Schema changes need compatibility tests against old events. Before deployment, replay representative payloads from every supported mobile version. Verify that unknown enum values do not become null, decimal precision remains stable, and timestamps retain their intended instant. A migration that makes the newest screen work while changing the interpretation of last winter’s measurements is a data incident.

Create a small incident playbook for gauge drift. Identify the affected calibration interval, freeze related forecasts, tag potentially affected observations, assess whether adjusted derivations are justified, and issue revised analytical outputs. Do not mass-edit raw readings. The response should distinguish confirmed impact from possible exposure and should record who approved each conclusion.

Finally, test portability on a schedule. Export one vehicle’s complete history, including tire assets, mounting intervals, probes, calibrations, amendments, and model metadata. Load it into a blank verification environment and reproduce a selected trend. Portability is proven by reconstruction, not by the existence of an export button.

Before approving the design, walk one real tire through its entire lifecycle. Tag it, mount it, measure four grooves with two repeats, sync one observation offline, move the tire, discover a gauge issue, correct a position error, and reproduce a historical report. If any step requires overwriting evidence, the audit design is incomplete.

Ask the database questions directly. Can two active mountings overlap? Can a retired gauge appear valid because its current state was joined instead of its historical state? Can a daylight-saving transition reverse event order? Can a unit conversion be changed without changing the algorithm version? Can a warehouse rebuild produce the same result from the same event set?

Review the user interface in Calgary conditions. Gloves, bright snow glare, a dirty screen, weak yard connectivity, and rushed shift changes influence data quality. Large position diagrams, explicit units, visible gauge identity, and a review screen before submission are engineering controls, not cosmetic preferences.

Finally, inspect language. The interface should say what was observed: “inner groove reading differs from prior accepted observation.” It should avoid unsupported diagnoses. It should state when evidence is missing and show why a record was excluded. A technically modest sentence is often safer and more useful than an overconfident recommendation.

The deeper lesson is that tread depth is not merely a decimal. It is a time-bound measurement made by a person, using an instrument, at a physical location, on a tire occupying a particular position, under imperfect conditions. Preserve that chain and the fleet can build trends, forecasts, and audit trails that deserve attention. Collapse it into one editable cell and every polished dashboard rests on an assumption nobody can verify.