Designing an Explainable Tire-Repair Evidence Rule Engine

Design exercise, not a description of live KMJ production infrastructure. The tire-service constraints discussed here are grounded in real operational and safety concerns, but the rule engine, records, sample identifiers, code, figures, and calculations are illustrative. Nothing below claims that KMJ Tire runs this software, experienced a related incident, completed a migration, or measured production outcomes. A trained tire professional must make the real-world service decision after inspecting the tire.

Software teams like clean booleans. Physical inspection rarely gives them one. A driver arrives after noticing pressure loss on a cold Calgary morning. There is a fastener somewhere in the tread. The outside surface looks ordinary. The vehicle may have travelled after pressure dropped, but nobody knows how far. A technician can inspect the object location, the inner liner, the sidewall, the shoulder, the puncture channel, and the tire markings. Some evidence will be measurable. Some will remain uncertain. The responsible result is not an automatic promise that a tire can be repaired. It is an explainable record that distinguishes what was observed, what remains unknown, which policy constraints were evaluated, and why human review is required.

This article develops a reference architecture for that record. It treats repair evaluation as an evidence problem rather than a keyword classifier. The design uses explicit geometry, three-valued states, provenance, policy versions, reason codes, and human sign-off. It also keeps the business boundary clear: KMJ Tire provides tire services and oil changes. Damage suggesting steering, suspension, brake, or other mechanical concerns should be referred to an appropriate mechanical provider rather than represented as a KMJ service.

For background on what tire markings mean before modelling them, the tire sidewall information guide and load index explanation provide useful domain context. The software model still must preserve the technician's actual observations instead of inferring facts from a broad product category.

Begin With a Decision Boundary, Not an Automation Goal

The first architecture question is not which database or rules library to use. It is what the system is permitted to decide. A tire-repair evidence engine should organize information, test declared policy conditions, expose missing evidence, and produce an auditable recommendation state. It should not replace physical inspection or announce a repair before the tire has been properly assessed.

That distinction changes the output vocabulary. A weak design returns repairable: true. A safer design might return policy_result: eligible_for_human_review, accompanied by observations, unresolved questions, applicable rule versions, and a reviewer outcome. Even ineligible_under_policy should describe the policy evaluation rather than pretending software personally inspected rubber, cords, liner condition, contamination, or previous work.

Define several boundaries in writing:

• Evidence boundary: only signed observations and derived values from those observations enter evaluation.
• Policy boundary: machine rules encode documented screening logic, not intuition invented by developers.
• Authority boundary: the final physical-service disposition belongs to a qualified human.
• Business boundary: the workflow concerns tire service. It does not turn detected symptoms into promises of unrelated mechanical work.
• Communication boundary: customer-facing language must not overstate certainty or omit material unknowns.

This boundary is consistent with public guidance about tire repair in Calgary: the condition has to be looked at, and the location and nature of damage matter. In a system design, that becomes a requirement to capture evidence before evaluating eligibility.

The aim, therefore, is decision support with traceability. Automation is valuable when it prevents skipped checks, preserves measurements, keeps policy versions visible, and makes disagreement inspectable. It becomes dangerous when a convenient green status hides uncertainty.

Model the Inspection as Evidence, Not as a Form Submission

Typical forms flatten reality. A checkbox labelled “tread area” discards who observed the location, how it was measured, whether the tire was removed, and whether an image supports the entry. Instead, represent each observation as a first-class object.

{
  "observation_id": "obs_demo_0142",
  "case_id": "case_demo_0087",
  "attribute": "injury.radial_position_mm",
  "value": 61.4,
  "unit": "mm",
  "state": "observed",
  "method": "manual_measurement",
  "observer_role": "tire_technician",
  "observed_at": "2026-08-29T16:21:00Z",
  "source_artifact_ids": ["img_demo_outer_03"],
  "confidence": "direct",
  "notes": "Illustrative record only"
}

The important part is not the JSON syntax. It is the separation between the fact being recorded and the surrounding provenance. A later policy evaluator consumes a normalized view, but it should always be possible to trace that value back to its source.

Evidence objects should be append-only in spirit. If a measurement is corrected, retain the superseded observation and add a new one with a relation such as corrects_observation_id. Silent overwrites destroy the ability to understand why an earlier evaluation differed.

Useful evidence categories include tire identity, wheel position, pressure condition, visible injury geometry, inner-liner findings, sidewall and shoulder condition, tread depth readings, previous repair indicators, signs of running underinflated, contamination, and image artifacts. Avoid fields that merely restate a conclusion. “Safe” is not an observation. “No visible cord exposure during internal inspection” is an observation with a defined scope.

The Be Tire Smart resource gives drivers a broader maintenance frame, while the engine needs finer granularity. Good software does not confuse educational guidance with case evidence.

Give Unknown a Real Type

Most data models accidentally turn unknown into no. An unchecked box becomes false. A missing numeric value becomes zero. An absent photo is treated as evidence that no damage exists. Those defaults are convenient for databases and terrible for safety-sensitive reasoning.

Use an explicit state model. At minimum, a proposition should be true, false, or unknown. In practice, an evidence workflow benefits from more expressive states:

This is more than defensive programming. It prevents the evaluator from producing confidence that the workflow did not earn. Suppose inner_liner_damage is missing because the tire was not removed. Treating it as false could allow downstream rules to pass. Treating it as unknown_not_inspected correctly blocks a final screening result and explains what is needed next.

Three-valued logic also affects compound rules. In ordinary Boolean code, false AND unknown evaluates false. That may be acceptable for one policy test, but a report still needs to disclose the unknown if it matters to human review. Separate the mathematical result of a clause from evidence completeness. A case may be ineligible because one disqualifier is confirmed while also containing unresolved evidence worth recording.

policy outcome: ineligible_under_rule_R17
evidence completeness: incomplete
unresolved item: inner liner not inspected
communication: do not imply the unresolved item was negative

Unknown values should survive exports, analytics, and customer summaries. If reporting collapses them later, the careful domain model has accomplished nothing.

Represent Tire Geometry Without Pretending It Is One-Dimensional

Location is central to repair evaluation, yet “tread” is often stored as a single label. A tire is curved, layered, deformable, worn, and mounted in a particular orientation. An explainable model needs a coordinate convention that technicians can use consistently without suggesting laboratory precision.

One practical abstraction maps an injury in three ways:

1. Circumferential angle, measured from a documented datum on the wheel or tire.
2. Lateral position, measured across the usable tread reference width.
3. Depth or layer reach, recorded from inspection evidence rather than guessed from the exterior.

Store raw measurements and derived zones separately. For example, a technician might record distances from the left and right tread-edge reference lines. A geometry function then derives a normalized lateral fraction and proposed zone. The rule engine evaluates the derived zone but retains the inputs.

from dataclasses import dataclass
from decimal import Decimal

@dataclass(frozen=True)
class LateralMeasure:
    left_mm: Decimal
    right_mm: Decimal
    reference_width_mm: Decimal

def normalized_lateral(m: LateralMeasure) -> Decimal:
    if m.reference_width_mm <= 0:
        raise ValueError("reference width must be positive")
    return m.left_mm / m.reference_width_mm

This function is illustrative. A production-worthy specification would define the datum, measurement tool, rounding, validation tolerance, and behaviour when left-plus-right measurements conflict with the recorded reference width.

Do not infer a geometric zone from a photograph alone unless the capture process provides calibration and the policy explicitly accepts that method. Perspective distortion can move an apparent point across a boundary. Store image annotations as supporting artifacts, not magic measurements.

Calgary context matters because tires encounter pothole edges, gravel, road debris, freeze-thaw damage, and sustained highway use on routes such as Deerfoot Trail, Stoney Trail, and Highway 1 west. Context can guide questions, but it must not fabricate injury geometry. “Driver travelled on Stoney Trail” is not evidence that an injury sits in a particular zone.

Separate Raw Measurements From Policy Zones

Policy labels change more often than physical evidence. If the database stores only zone = center, a later rule revision cannot reliably reevaluate old cases because the original measurement is gone. The architecture should preserve raw values and calculate policy interpretations under a versioned geometry definition.

Consider this illustrative structure:

geometry_observation:
  injury_id: injury_demo_A
  lateral_distance_from_left_reference_mm: 61.4
  reference_width_mm: 198.0
  measurement_uncertainty_mm: 1.0
  method: manual_caliper

derived_geometry:
  geometry_policy: geo_demo_v3
  normalized_lateral: 0.3101
  candidate_zone: central_region
  boundary_distance_mm: 4.6
  boundary_status: near_threshold

The boundary_status is important. A deterministic comparison might place 61.4 mm on one side of a line, but a measurement uncertainty of plus or minus 1.0 mm may overlap a threshold. The honest result is not false precision. It is a boundary case for human attention.

Keep at least four values distinct:

• the observed measurement;
• the declared uncertainty or tool tolerance;
• the geometry policy used to derive a zone;
• the resulting classification and distance from relevant boundaries.

Policy authors can then decide whether overlap yields unknown_boundary, review_required, or another explicit state. Developers should not invent that behaviour silently inside comparison code.

Sidewall dimensions and service description resources can help explain terms to users, but the case model should link to recorded tire identity rather than scrape assumptions from a page. When someone needs a general primer, the tire sidewall guide is a readable companion; it is not a substitute for the actual marking captured on the inspected tire.

Treat Each Injury as Its Own Entity

A tire may have more than one visible object, old repair evidence, or multiple areas requiring inspection. A schema with one puncture_location field cannot express this. Create an injury entity and let a case contain zero, one, or several injuries.

create table injury (
  injury_id text primary key,
  case_id text not null,
  discovered_sequence integer not null,
  exterior_artifact_id text,
  interior_artifact_id text,
  channel_diameter_mm numeric,
  diameter_state text not null,
  geometry_state text not null,
  created_at timestamptz not null
);

The evaluator can then reason over collections. A rule may examine each injury individually, the distance between injuries, evidence of previous work, or whether all identified objects have corresponding internal inspection records. The exact service policy must come from the responsible domain authority. The data model merely makes the facts expressible.

Identity matters when exterior and interior observations are paired. Use a workflow that records how the technician linked an outside marker to an inside location. If the pairing is uncertain, represent the relation as uncertain. Do not let array position imply identity.

Multiple-injury handling also illustrates why a single overall result is insufficient. The report might say one injury failed a location rule, another remains unmeasured, and the tire-level disposition requires review. That explanation is more valuable than false because it tells the reviewer where to focus.

For public education about when to seek assessment, Calgary tire repair information gives practical context. The application, however, must never transform a general statement into a specific case conclusion.

Build a Provenance Graph, Not a Mystery Audit Column

Many systems add updated_by and call the record auditable. That records only the most recent writer. An evidence engine needs a graph connecting observations, artifacts, transformations, evaluations, and decisions.

A compact provenance model could use these node types:

• Artifact: image, measurement capture, scanner output, or signed note.
• Observation: a normalized claim tied to an artifact or direct entry.
• Derivation: a calculation that consumes observations and produces a value.
• Rule evaluation: an application of one policy version to a fact set.
• Human decision: a signed disposition with reasons and acknowledged unknowns.
• Communication event: a representation of what was conveyed, by which template version.

Edges should state semantics: supports, derived_from, supersedes, evaluated_by, reviewed_in, or communicated_as. With those edges, an auditor can start at a final reason code and walk backward to the measurement and artifact that supported it.

Hashing artifacts can help detect accidental replacement, but a hash alone does not establish truth. It proves that bytes did not change after a given point. Capture time, device identity, operator authentication, and case association remain separate concerns.

Provenance should be readable by humans. Generate a narrative such as: “Rule R17 used derived zone Z2 from calculation D44, based on observations O12 and O13, recorded by a tire technician; O13 was later superseded by O19 before final review.” That sentence can coexist with a machine graph.

Do not expose unnecessary personal data in routine reports. Use roles and internal identifiers where possible, enforce retention rules, and separate operational evidence from analytics datasets. Explainability is not a licence to retain everything forever.

Make Rule Definitions Declarative and Versioned

Hard-coded if statements scatter policy across application releases. A declarative format can make conditions, required evidence, outcomes, and explanations reviewable. The important property is not YAML versus JSON. It is that each rule has a stable identity, version, effective period, authority, input contract, and test suite.

rule_id: R-DEMO-17
version: 4
status: illustrative
description: Route uncertain geometry boundaries to human review
requires:
  - injury.geometry.normalized_lateral
  - injury.geometry.measurement_uncertainty_mm
when:
  operator: overlaps_boundary
  operands:
    - fact: injury.geometry.interval
    - policy_ref: geometry.central_region_boundary
then:
  outcome: review_required
  reason_code: GEOMETRY_INTERVAL_OVERLAPS_POLICY_BOUNDARY
explanation_template: >
  The measured interval overlaps a policy boundary, so location cannot be
  classified confidently from the recorded measurement alone.

Every deployed policy bundle should be immutable. Corrections create a new version. Evaluations store the exact bundle identifier and preferably a content digest. If a reviewer opens an old case, the interface should show both the historical evaluation and, when authorized, a clearly labelled simulation under a newer bundle.

Rule order must also be explicit. Some engines stop after the first disqualifier, which improves speed but hides other relevant findings. For evidence review, evaluate all applicable rules unless policy requires otherwise. Categorize results as decisive, advisory, incomplete, or informational.

The evaluator should reject facts that do not match its declared schema. Quietly coercing strings, units, or stale enumerations can change outcomes. Unit conversion belongs in a validated normalization layer with provenance of its own.

Design Reason Codes for People and Machines

Free-text explanations are flexible but hard to test. Numeric codes are compact but opaque. Use stable reason codes paired with plain-language renderings and structured parameters.

An effective reason object might contain:

{
  "code": "INNER_INSPECTION_EVIDENCE_MISSING",
  "severity": "blocking_unknown",
  "rule_id": "R-DEMO-05",
  "rule_version": 2,
  "parameters": {
    "injury_id": "injury_demo_A",
    "required_observation": "inner_liner_condition"
  },
  "human_text": "The inner-liner condition has not been recorded, so the screening evaluation is incomplete."
}

Keep the code stable even if editorial wording improves. Avoid codes that embed a conclusion broader than their evidence. TIRE_UNSAFE is usually too sweeping for a single missing field. INNER_INSPECTION_EVIDENCE_MISSING says precisely what the engine knows.

Reason ordering should be deterministic. Put confirmed policy blockers first, blocking unknowns next, then advisory findings. This makes snapshots and user interfaces predictable without pretending the first line is the only relevant fact.

Localization requires care. Translate the human text, not the underlying code or parameters. Have domain reviewers check that translations preserve uncertainty. Phrases such as “not observed” and “observed not present” are not interchangeable.

Customer-facing summaries should remain narrower than technician reports. They can say that further inspection is needed or that the recorded condition does not meet a stated repair-screening rule. They should not expose internal implementation details or turn a policy evaluation into a universal claim.

Use a Layered Outcome Model

A single status forces unrelated concepts together. Instead, maintain separate dimensions and derive a display state intentionally.

These states must not advance each other implicitly. eligible_for_review does not authorize work. human disposition = repair_selected does not mean work is completed. A delivered summary does not prove that every artifact was captured.

This separation supports honest interfaces. A dashboard card can show “Inspection evidence incomplete” without colouring the whole case green or red. A reviewer can acknowledge an indeterminate machine result and record the physical findings that resolve it.

It also prevents business-scope drift. If an observation suggests a non-tire mechanical concern, the allowed human disposition can be refer_to_appropriate_provider. The application should not create a phantom KMJ mechanical work state. KMJ's relevant public pages describe local tire service and wheel balancing; neither should be stretched into unrelated service claims.

Keep Human Review Substantive

“Human in the loop” can be meaningless when the interface presents a large green recommendation and a tiny override link. Real review requires the person to see source evidence, unresolved states, rule reasoning, and the consequences of confirmation.

The review screen should support several tasks:

1. inspect exterior and interior artifacts at useful resolution;
2. compare measurements with their declared methods and tolerances;
3. see every decisive and unresolved reason;
4. correct evidence without erasing history;
5. record an outcome using a controlled vocabulary;
6. add a concise rationale when departing from the machine screening;
7. sign with identity, role, and timestamp.

Do not measure reviewers by how often they agree with software. That creates pressure to rubber-stamp. Monitor evidence completeness, reconciliation quality, and whether overrides contain adequate reasons instead. Any illustrative analytics used in testing should be labelled synthetic, not presented as KMJ performance.

The interface should make uncertainty visually prominent without being alarmist. Grey for unknown may disappear next to strong colours; text labels and icons are more accessible. Keyboard navigation and readable artifact descriptions matter in a working service environment.

Human review also needs a pause option. If a tire must be re-examined or information is unavailable, the reviewer should be able to save pending_additional_evidence rather than choose an inaccurate final category.

Validate Evidence at Capture Time

Late validation produces confusing rule failures. Catch impossible or suspicious inputs close to entry while allowing a technician to document exceptional conditions.

Useful checks include:

• numeric ranges appropriate to the selected unit;
• required tire identity before injury association;
• timestamps that follow a plausible workflow sequence;
• artifact references that resolve to the same case;
• paired interior and exterior markers where required;
• measurement totals that agree within declared tolerance;
• explicit reasons when a required area cannot be inspected.

Avoid deleting a value merely because it looks unusual. A surprising measurement may reflect a typo, a different datum, an unusual tire, or an actual edge case. Flag it and ask for confirmation. If corrected, preserve both entries through supersession.

Offline capture deserves a plan. A mobile device in a service area may briefly lose connectivity. Generate collision-resistant local identifiers, retain capture timestamps, and mark server receipt separately. When syncing, never let last-write-wins erase a signed observation.

Input ergonomics influence data quality. Large touch targets, unit labels beside values, clear tire-position diagrams, and minimal scrolling can prevent mistakes more effectively than another backend constraint. Use defaults only when they represent workflow state, not unobserved facts.

Drivers reviewing general maintenance concepts can consult practical tire knowledge, while technicians need the specific inspection protocol approved for their work. Software should link reference material without pretending the link itself satisfies a required check.

Create a Deterministic Evaluation Pipeline

Determinism means the same fact snapshot and policy bundle yield the same rule result. It improves testing, debugging, and audit review. Capture nondeterministic enrichment outside the core evaluator.

An illustrative pipeline looks like this:

signed observations
    -> schema validation
    -> unit normalization
    -> geometry derivations
    -> immutable fact snapshot
    -> policy evaluation
    -> ordered reason set
    -> human review view

Each stage emits a versioned artifact. The fact snapshot should include references rather than copying large media. Its digest becomes an evaluation input. If evidence changes, produce a new snapshot and evaluation; do not mutate the previous result in place.

Time is another input. A policy bundle may have effective dates, but evaluation should receive an explicit as_of value. Hidden reads of the system clock make historical replay unreliable. Likewise, locale formatting belongs outside numeric calculation.

Cache carefully. Evaluation results can be keyed by the fact-snapshot digest, policy-bundle digest, and evaluator version. If any changes, the cache key changes. Never reuse results merely because the case identifier matches.

Deterministic output does not make the conclusion objectively true. It means the implementation applied its declared rules consistently to its declared evidence. The human reviewer still assesses the physical tire.

Test Invariants, Boundaries, and Missingness

Example-based unit tests are necessary but insufficient. Rule engines fail at boundaries, null handling, unit conversion, and unexpected combinations. Build a test strategy around invariants.

Potential invariants include:

• adding an unrelated informational observation cannot erase a decisive reason;
• converting an equivalent measurement between supported units cannot alter the derived geometry;
• replacing unknown with confirmed disqualifying evidence cannot make screening more permissive;
• every displayed reason traces to a rule evaluation and fact snapshot;
• no final reviewed state exists without a signed reviewer event;
• a superseded observation never appears in a new snapshot unless explicitly selected.

Property-based generators can create geometry values near policy boundaries, including exact thresholds and uncertainty intervals that straddle them. Mutation testing can verify that the suite catches reversed comparisons or dropped unknown checks.

Build a synthetic corpus with deliberately labelled cases: missing interior evidence, conflicting measurements, several injuries, corrupted artifact references, unit mismatches, and policy-version differences. Synthetic identifiers should look obviously artificial, such as case_demo_boundary_001, to reduce the risk that screenshots are mistaken for customer records.

Test the explanation, not only the outcome. Assert stable reason codes, parameter values, rule versions, and provenance links. Snapshot tests for prose can be brittle, so separate semantic fields from rendering.

Finally, conduct scenario review with tire professionals. Developers can prove a parser is consistent; domain reviewers determine whether the model asks the right questions and whether the screen encourages appropriate physical inspection.

A Worked Illustrative Evaluation

Consider a fabricated demonstration case, case_demo_20260829_A. It is not a KMJ customer record and does not describe real work. The purpose is to show information flow.

Recorded evidence:

• Tire identity markings were captured in artifact img_demo_11.
• One exterior injury marker was assigned injury_demo_A.
• Lateral position was measured as 58.2 mm from a defined left reference.
• Reference width was recorded as 192.0 mm.
• Tool tolerance was entered as plus or minus 1.0 mm.
• Injury-channel size was not yet measured.
• Inner-liner condition was unknown_not_inspected.
• Sidewall visual observation was recorded separately as no visible exterior anomaly within the inspected scope.

The normalization stage calculates an illustrative lateral fraction:

58.2 / 192.0 = 0.303125

Assume the demonstration geometry policy places a boundary at a derived position equivalent to 58.8 mm for this reference width. The observed interval is 57.2 mm through 59.2 mm after applying the declared tolerance. Because that interval overlaps the boundary, the geometry classification becomes unknown_boundary, not a confident central-zone label.

The policy evaluator returns:

{
  "screening": "indeterminate",
  "evidence_completeness": "incomplete",
  "reasons": [
    "GEOMETRY_INTERVAL_OVERLAPS_POLICY_BOUNDARY",
    "INNER_INSPECTION_EVIDENCE_MISSING",
    "INJURY_CHANNEL_MEASUREMENT_MISSING"
  ],
  "next_state": "human_review_requires_additional_evidence"
}

Notice what the engine does not say. It does not declare the tire repairable. It does not claim that the lack of visible exterior sidewall anomaly proves internal integrity. It does not replace an inspection. It identifies why the current record cannot support a completed screening.

If later observations are added, the evaluator creates a new fact snapshot. Both evaluations remain available, allowing a reviewer to see precisely what changed.

Preserve Policy History and Support Safe Re-evaluation

Policies evolve through clarified definitions, revised evidence requirements, and corrected logic. Historical cases should retain the result that was produced under the policy active at the time. Re-evaluation is a separate operation, not a rewrite.

Store these identifiers with every result:

• policy bundle name and semantic version;
• bundle content digest;
• evaluator build identifier;
• fact snapshot digest;
• geometry definition version;
• explanation catalogue version;
• evaluation timestamp and explicit effective date.

A policy registry should prevent deletion of referenced bundles. Deprecation marks a version unavailable for new work while keeping it readable. Emergency withdrawal can stop new evaluations and display a warning, but historical records still need context.

When simulating a newer policy, label the result counterfactual or replay. Never mix it with the original reviewed outcome. A difference report can show which rules changed, which facts were newly required, and whether the outcome category moved.

Re-evaluation also needs authorization. It may reveal that old records lack evidence required by a newer standard. That is useful for process improvement, but it must not be presented as proof of what a past physical inspection did or did not establish.

Observe the System Without Inventing Business Metrics

Operational telemetry should measure software health without creating misleading claims about tire outcomes. Track evaluation latency, schema rejection rates, artifact retrieval errors, queue age, policy-load failures, and counts of unknown states by cause. These are system signals, not evidence that repairs are safer or customers are happier.

For this design exercise, any dashboard fixture should be unmistakably synthetic:

{
  "environment": "demo",
  "window": "synthetic_fixture_01",
  "evaluations": 120,
  "missing_evidence_events": 17,
  "policy_load_errors": 0
}

Those numbers illustrate a schema. They are not production measurements, KMJ statistics, adoption figures, or performance claims.

Use service-level objectives for technical components only after observing a real baseline and gaining operational ownership. Alert on failures that threaten traceability: inability to persist signed observations, mismatched digests, missing policy bundles, or inaccessible artifacts. A slow nonessential analytics export should not block inspection capture.

Logs should contain identifiers and reason codes rather than raw personal details. Secure audit access, record who viewed sensitive artifacts, and test restoration. Explainability depends on durable evidence, so backup verification and retention enforcement belong in the architecture.

Design Failure Modes That Stay Honest

When a dependency fails, the system should degrade toward uncertainty, not confidence. If artifact storage is unavailable, do not show cached thumbnails as though the current evidence was verified. If the policy registry cannot supply the required bundle, do not fall back silently to a convenient version.

Define failure states explicitly:

• capture_pending_sync when signed evidence remains local;
• artifact_unavailable when a referenced file cannot be retrieved;
• policy_bundle_unavailable when evaluation cannot reproduce its rules;
• evaluation_failed when the engine encountered an internal error;
• review_blocked when essential evidence cannot be presented;
• communication_blocked when the approved summary cannot be generated accurately.

Retries need idempotency keys. A repeated request should return the same evaluation or create a clearly related successor, not duplicate decisions. Use an outbox pattern for downstream notifications so a database commit and message emission cannot drift unnoticed.

Manual fallback should be documented. A qualified technician may continue with the approved physical process when software is unavailable, but the later record must distinguish contemporaneous paper evidence from reconstructed data. The application should never imply that an unavailable digital check occurred.

Explain Results Without Turning Them Into Marketing Claims

The final report should be calm and precise. It can list observations, missing evidence, policy findings, and the human disposition. It should avoid dramatic language and unsupported assurances.

A useful technician summary might have four blocks:

1. What was recorded: measurements, condition observations, and artifacts.
2. What the policy evaluator found: reason codes with plain explanations.
3. What remains unresolved: missing, conflicting, or boundary evidence.
4. What the reviewer decided: signed disposition and rationale.

A driver-facing version should be shorter. It can explain that repair suitability depends on the tire's condition and injury location, and that a physical assessment is needed. Relevant public resources include tire repair guidance, seasonal tire service information, and mobile tire service details. Links should support understanding, not pressure a decision.

Avoid generating claims about availability, price, timing, or inventory from the evidence engine. Those facts live in other authoritative systems, if they are known at all. The rule engine has no basis to invent them.

Connect the Model to Calgary Driving Context Carefully

Local conditions help determine which evidence questions are useful. Chinook temperature changes can coincide with noticeable pressure variation. Freeze-thaw cycles contribute to rough road surfaces. Gravel season can bring sharp debris. Long stretches on Deerfoot or Stoney Trail may affect the driver's account of travel after noticing a problem. Highway 1 west adds sustained-speed context.

None of those facts should act as an automatic cause classifier. A rule such as if Calgary winter then sidewall damage would be nonsense. Instead, context can drive prompts: When was pressure loss first noticed? Was the vehicle driven afterward? Was there a pothole impact? Did a warning appear? The answers remain reported history until corroborated by inspection.

Temperature also demonstrates why timestamps matter. Pressure observations made at different temperatures should not be compared without context. Store the measurement, unit, time, and available ambient reading, then let a declared model perform any normalization. If ambient temperature is unknown, preserve that unknown.

For broader seasonal choices, readers can compare all-weather tires for Calgary, all-season tire guidance, and winter tire information. Those category decisions are separate from assessing a particular injury.

A Minimal Domain Schema

A compact schema can still preserve the critical distinctions. The following TypeScript types are illustrative and omit storage and privacy details.

type EvidenceState =
  | "observed"
  | "unknown_not_inspected"
  | "unknown_not_visible"
  | "unknown_conflicting"
  | "not_applicable";

interface Observation<T> {
  id: string;
  attribute: string;
  state: EvidenceState;
  value?: T;
  unit?: string;
  method: string;
  observerRole: string;
  observedAt: string;
  artifactIds: string[];
  supersedes?: string;
}

interface Evaluation {
  id: string;
  factSnapshotDigest: string;
  policyBundleDigest: string;
  evaluatorVersion: string;
  completeness: "complete" | "incomplete" | "conflicting";
  screening: "eligible_for_review" | "ineligible" | "indeterminate";
  reasons: Reason[];
}

interface Reason {
  code: string;
  ruleId: string;
  ruleVersion: number;
  severity: string;
  parameters: Record<string, string | number>;
}

Notice that Observation.value is optional only because some unknown states intentionally have no value. Validation must forbid an observed state without a value and should reject a value attached to incompatible unknown states.

The schema does not include isSafe. Safety is not a raw property that software casually toggles. The model captures evidence, screening, and review.

Implementation Sequence for a Responsible Prototype

Start small and keep the prototype labelled. A sensible sequence is:

1. Write the domain glossary with tire professionals.
2. Define observation methods, units, and unknown reasons.
3. Create a synthetic case corpus with no customer data.
4. Implement immutable fact snapshots and provenance links.
5. Add one narrow, reviewed rule family.
6. Build explanations before building a polished dashboard.
7. Test boundary values, conflicts, and missing evidence.
8. Run tabletop reviews where humans challenge every conclusion.
9. Add signed reviewer outcomes and correction history.
10. Conduct privacy, security, accessibility, and failure-mode reviews.

Do not begin by importing years of historical notes. Their language may be inconsistent, and retrospective normalization can create false precision. Develop the ontology with synthetic examples, then decide whether any historical material can be mapped honestly.

Prototype success should mean the model represents the workflow faithfully and reviewers can explain results. It should not mean a high percentage of cases receive an automatic green status.

For drivers seeking actual tire help rather than software architecture, KMJ's service areas and Calgary tire selection guide describe practical next steps without relying on this hypothetical engine.

Review Checklist Before Any Real Deployment

Before an organization turns a prototype into operational software, reviewers should be able to answer these questions with evidence:

• Is every decisive input tied to an observation method and provenance?
• Can unknown, not inspected, not visible, and conflicting be distinguished?
• Are raw measurements retained alongside derived zones?
• Do boundary tolerances route to an explicit review state?
• Can multiple injuries and prior work indicators be represented independently?
• Is every evaluation bound to immutable policy and fact versions?
• Are reason codes narrow, stable, and understandable?
• Can a technician correct evidence without erasing the old record?
• Does the reviewer interface show artifacts before confirmation?
• Are business-scope referrals represented without implying unrelated services?
• Are synthetic examples unmistakably labelled?
• Can the system fail without defaulting to approval?
• Are privacy retention and artifact access audited?
• Has a tire professional approved the inspection vocabulary?
• Can public summaries preserve uncertainty accurately?

A failed answer is not a reason to hide the issue. It is a concrete backlog item. Some items, such as unclear decision authority or missing physical inspection steps, should block deployment entirely.

The Architecture Principle That Matters Most

The strongest rule engine is not the one that reaches the most conclusions. It is the one that refuses to manufacture certainty, preserves the evidence behind every result, and makes the human decision easier to inspect.

For tire-repair evaluation, that means geometry with declared datums and tolerances, unknown values that remain unknown, provenance that reaches back to artifacts, immutable policy versions, stable reason codes, and substantive review. It also means respecting the service boundary: software can organize tire evidence, but it cannot turn an observed symptom into a promise of unrelated mechanical work.

The result is less flashy than a one-click classifier. It is far more useful. When a measurement falls near a boundary, the report says so. When the inner liner has not been examined, the field remains unresolved. When evidence changes, a new snapshot records the change. When a person decides, the decision carries a signature and rationale.

That is explainability in operational terms: not a paragraph generated after the fact, but a chain of evidence and authority designed into the system from the first schema migration. For general tire education, KMJ Tire's local resource remains a practical starting point. For any specific damaged tire, the correct next step is a real physical assessment by a qualified tire professional.