Designing an Explainable Tire-Recall Matching Pipeline Without Pretending Uncertainty Is Certainty

Design exercise: Tire identification and recall constraints are real, but the software system, records, identifiers, thresholds, and operational examples in this article are entirely illustrative. This is not a description of KMJ Tire infrastructure, and it does not imply that KMJ Tire operates this system.

A recall matcher looks simple until a real person enters an incomplete DOT Tire Identification Number, a source bulletin changes, or two records disagree about a production week. The naive implementation is a string comparison. The responsible implementation is an evidence pipeline that preserves what arrived, explains every transformation, distinguishes absence from uncertainty, and routes ambiguous cases to a human.

Calgary makes the stakes easy to picture. A driver can move from a cold morning commute on Deerfoot Trail to a warm chinook afternoon, then head west on Highway 1 where conditions change again. Tire questions are practical, not abstract. Software should help someone reach a careful conclusion without quietly turning a partial code into a definitive safety answer.

This article develops a reference architecture for that problem. Every sample record uses fictional placeholders. No sample TIN is presented as recall-affected, and none should be checked against a real campaign. The goal is to show how developers can model evidence, ingest changing sources, score possible matches, expose uncertainty, test boundary behaviour, and support human review.

For driver-facing background that complements the technical material, KMJ Tire explains what sidewall markings communicate, offers a broader Be Tire Smart guide, and describes tire load index concepts. Those pages explain physical tire information; the architecture below explores how software might represent it.

1. Begin With the Decision, Not the Database

The first architecture question is not “Which database should we use?” It is “Which decisions may the system make?” A matcher can safely support several different outcomes:

• Confirmed candidate: supplied evidence satisfies all machine-readable campaign constraints.
• Possible candidate: available evidence overlaps a campaign, but one or more required fields are missing or ambiguous.
• Not matched on current evidence: evaluated evidence does not satisfy any active rule set.
• Unable to evaluate: input quality, source quality, or system health prevents a meaningful comparison.
• Human decision required: conflicting or unusual evidence needs inspection.

Those outcomes are deliberately asymmetric. “Not matched on current evidence” is narrower than “not recalled.” The latter sounds universal and permanent; the former states exactly what the system knows. New bulletins, corrected source records, or a newly supplied full TIN could change the result.

Write the decision contract before the schema. Define which fields are mandatory for a confirmed candidate, what kinds of missing values produce a possible match, and which contradictions force review. This prevents a downstream UI from inventing confidence that the data model never supported.

An illustrative decision contract might require plant code, size code, and manufacturing-week overlap for automatic candidate status. It might allow a partial code containing only plant and size to produce “possible candidate,” never “clear.” The exact contract is fictional here; the enduring lesson is to make it explicit, versioned, and testable.

2. Model the Tire Identifier as Observed Evidence

A TIN is often discussed as though it were one clean database key. Input reality is messier. A person may copy only the visible sidewall, omit spaces, confuse similar characters, upload an image, or enter an older-format marking. Some tires place the complete identifier on one side and a partial marking on the other. The software must retain the observation rather than jumping straight to a normalized string.

Use an immutable observation record:

{
  "observation_id": "obs_fictional_01",
  "raw_value": "DOT AB C1 23 4024",
  "capture_method": "manual_entry",
  "captured_at": "2026-09-03T16:10:00Z",
  "locale": "en-CA",
  "declared_completeness": "unknown",
  "source_actor": "illustrative-user",
  "fictional": true
}

The raw_value is evidence and should not be overwritten. Corrections create new observations or annotations. That rule matters when an OCR pass yields one string and a reviewer later sees another. If normalization destroys the original, nobody can explain why a match changed.

Capture method also matters. Manual entry, barcode-like scanning, OCR, imported fleet data, and staff transcription have different failure patterns. Treating them identically discards useful context. A confidence score without capture provenance is just an unexplained number.

Physical inspection guidance belongs outside this hypothetical software architecture. A Calgary driver who needs practical help can review local tire repair information or seasonal tire change guidance. Any unrelated mechanical concern should be assessed by an appropriate mechanical service provider; KMJ Tire provides tire services and oil changes only.

3. Normalize Reversibly and Record Every Step

Normalization should generate a derived representation, not mutate evidence. A useful pipeline can uppercase letters, normalize Unicode, collapse separators, reject unexpected symbols, and preserve a trace of every action.

raw observation
  -> Unicode normalization
  -> trim outer whitespace
  -> uppercase locale-independently
  -> classify separators
  -> tokenize recognized groups
  -> validate allowed character sets
  -> produce normalized candidate plus warnings

The output should include both value and explanation:

{
  "normalized_compact": "DOTABC1234024",
  "tokens": ["DOT", "AB", "C1", "23", "4024"],
  "transformations": [
    {"kind": "uppercase", "changed": false},
    {"kind": "separator_removed", "positions": [3, 6, 9, 12]}
  ],
  "warnings": [],
  "normalizer_version": "illustrative-2.1"
}

Never silently map ambiguous characters such as O to 0. Store candidate interpretations if business rules permit them, attach a reason, and reduce confidence. An OCR system might propose two parses with separate probabilities, but the decision layer should not treat the top guess as observed fact.

Reversibility helps debugging. Given an evaluated result, an investigator should find the observation, normalization version, transformations, parser output, campaign snapshot, and decision-policy version. Without that chain, an explanation like “the computer said so” is all that remains.

4. Parse Structure Without Assuming Completeness

Parsing is where many string matchers accidentally invent data. A parser should emit optional fields, candidate spans, validation findings, and a completeness classification. It should never pad a missing date code or infer a production week from the current date.

An illustrative parsed object could be:

type ParsedTin = {
  formatFamily: "modern" | "legacy" | "unknown";
  plantCode?: EvidenceField<string>;
  sizeCode?: EvidenceField<string>;
  manufacturerCode?: EvidenceField<string>;
  dateCode?: EvidenceField<{ week: number; year: number }>;
  completeness: "full" | "partial" | "indeterminate";
  findings: ParseFinding[];
  parserVersion: string;
};

type EvidenceField<T> = {
  value: T;
  rawSpan: [number, number];
  confidence: "observed" | "interpreted" | "ambiguous";
};

Notice that confidence belongs to each field, not only the record. The plant code may be clearly observed while the date code is absent. A single record-level score would blur that distinction.

Date parsing needs strict calendar validation. The week component has a bounded domain; the year component needs an unambiguous century policy; malformed sequences should become findings rather than coerced values. Boundary tests should cover the first and final valid weeks, invalid zero, impossible high values, and source-defined special cases.

Partial codes deserve first-class representation. Do not use an empty date string and hope every query remembers what it means. dateCode: undefined plus completeness: "partial" communicates intent. A separate finding such as FULL_CODE_MAY_BE_ON_OPPOSITE_SIDEWALL can guide a human without claiming that is always the explanation.

5. Separate Campaign Facts From Matching Rules

A recall source may contain prose, tables, attachments, corrected ranges, manufacturer language, and effective dates. Store the source document separately from the structured rule extracted from it. This is essential because extraction is an interpretation.

One possible model has these entities:

The source document answers, “What did the authority publish?” The rule version answers, “How did we encode it?” Keeping those answers apart lets a reviewer correct an extraction without pretending the upstream document changed.

An illustrative match rule might include sets of plant codes, size-code predicates, inclusive production intervals, exclusion clauses, and required evidence fields. It should also include extraction status: machine-extracted, human-verified, disputed, or retired. Again, these are proposed design states, not statements about a live KMJ system.

6. Treat Provenance as Queryable Data

Provenance cannot be a text note buried in an admin screen. It should be queryable, exportable, and attached to every decision. At minimum, capture:

1. Publisher identity and jurisdiction.
2. Original source URL and retrieval timestamp.
3. Raw content hash and media type.
4. Document revision clues such as publication or update date.
5. Extraction method and software version.
6. Human verification state and reviewer role, where applicable.
7. Exact page, table, row, paragraph, or character span supporting each constraint.
8. Superseded and superseding rule identifiers.

This enables a useful question: “Show every candidate result derived from revision X of document Y before its rule was corrected.” If the system cannot answer that, remediation becomes guesswork.

Content hashes also distinguish a changing resource at a stable URL from an unchanged resource retrieved many times. HTTP metadata is helpful but insufficient; servers can omit or mishandle validators. Hash the bytes after transport decoding while retaining the original response details.

For general tire education rather than recall determination, developers can see how consumer concepts are explained in KMJ Tire’s guides to all-season tires in Calgary, all-weather tire use, and winter tire considerations. These links are contextual resources, not inputs to the fictional matcher.

7. Represent Effective Time and System Time

Recall data is temporal in at least two ways. Effective time describes when a rule applies in the represented world. System time describes when the application learned or stored it. Mixing them makes historical explanations unreliable.

Suppose an illustrative source revision is retrieved on September 3 but states that a corrected production range was effective on August 29. A decision made September 1 used the knowledge available then. A present-day reevaluation should use the correction. Both results can be valid relative to their knowledge snapshots.

A bitemporal rule table might contain:

CREATE TABLE match_rule_version (
  rule_version_id      TEXT PRIMARY KEY,
  campaign_id          TEXT NOT NULL,
  valid_from           TIMESTAMPTZ NOT NULL,
  valid_to             TIMESTAMPTZ,
  recorded_from        TIMESTAMPTZ NOT NULL,
  recorded_to          TIMESTAMPTZ,
  payload              JSONB NOT NULL,
  source_revision_id   TEXT NOT NULL,
  extraction_status    TEXT NOT NULL
);

Do not update rows in place when meaning changes. Close the relevant interval and append a new version. This makes “as known at the time” queries possible and prevents a historical result from mysteriously pointing to today’s rule.

Effective-date conflicts should block automatic certainty. If a source provides only a publication date, store that fact rather than relabelling it as an effective date. Precision is part of provenance.

8. Use Interval Logic for Production Dates

Production constraints are commonly ranges, so model them as intervals rather than lists of every week. Define inclusion at both boundaries explicitly. A surprising number of bugs live at endpoints.

Convert a parsed year-week into a sortable domain only after validation. ISO week utilities may not match source semantics automatically, so document the chosen representation. One safe approach is a typed ProductionWeek value with validated year and week fields, compared lexicographically under a defined calendar policy.

@dataclass(frozen=True, order=True)
class ProductionWeek:
    year: int
    week: int

def includes(interval, value):
    return interval.start <= value <= interval.end

The code is illustrative and incomplete by design. Production implementations would validate constructor inputs, address calendar rules, and prevent cross-type comparison.

When a date code is missing, the engine should not treat “unknown” as “outside range.” Three-valued logic is useful:

• TRUE: observed date falls inside the rule interval.
• FALSE: observed date falls outside it.
• UNKNOWN: no reliable date is available.

Combining predicates then requires a decision table rather than ordinary Boolean shortcuts. Plant TRUE, size TRUE, and date UNKNOWN can become a possible candidate. Plant FALSE may be enough to reject that specific rule even if date is unknown, provided plant evidence is reliable.

9. Compile Rules Into Explainable Predicates

A generic rules engine can become opaque quickly. Prefer a small typed predicate language whose operations correspond to source concepts:

ALL_OF
  PLANT_IN {fictional codes}
  SIZE_IN {fictional codes}
  PRODUCTION_WEEK_BETWEEN [fictional start, fictional end]
  NOT(EXCLUDED_VARIANT_IN {fictional variants})

Each predicate evaluation should return more than a Boolean:

{
  "predicate": "PRODUCTION_WEEK_BETWEEN",
  "result": "UNKNOWN",
  "observed": null,
  "expected": {"start": "illustrative", "end": "illustrative"},
  "reason": "DATE_CODE_NOT_OBSERVED",
  "source_statement_id": "stmt_fictional_44"
}

The aggregate decision can then expose which conditions matched, failed, or remained unknown. This is far stronger than a free-form explanation generated after the fact. Explanations should arise from the same evaluated objects that produced the decision.

Keep the predicate vocabulary deliberately limited. Arbitrary scripts inside rules complicate security, determinism, testing, and historical replay. When a genuinely new source concept appears, extend the language with a reviewed typed operator and explicit semantics.

10. Make Uncertainty Structured, Not Decorative

A confidence percentage often looks scientific while hiding incompatible causes. A result could be uncertain because a character is blurry, a field is absent, two sources conflict, a rule is unverified, or the identifier format is unfamiliar. Those conditions require different next actions.

Use reason codes and dimensions:

If a numeric score is needed for queue ordering, never let it replace these dimensions. Publish the scoring formula, version it, calibrate it against reviewed examples, and prevent UI wording from translating “0.82” into “82% recalled.” Ranking probability and factual status are different concepts.

The system should also say what evidence would reduce uncertainty. “Full identifier not available” is more useful when paired with “capture the complete sidewall marking and preserve an image.” It remains important not to imply that software alone replaces official guidance or physical verification.

11. Design Explicit False-Positive Controls

A false positive can create avoidable concern and operational load. Controls should focus on specificity without suppressing legitimate candidates.

First, require all source-mandated fields for a confirmed machine candidate. Plant overlap alone is rarely enough when a campaign also constrains size and production date. Second, model exclusions directly rather than hiding them in parser code. Third, namespace codes by format family where identical strings could mean different things.

Fourth, deduplicate observations without collapsing distinct tires. Two photos of one tire may be the same case; four tires on one vehicle are separate physical items even if codes appear identical. Entity resolution needs an explicit physical-asset identity and evidence links, not merely a hash of normalized text.

Fifth, quarantine rules whose extraction is provisional or contradicted. A broad provisional rule can still support research, but it should not drive a definitive outward result.

An illustrative false-positive test fixture could deliberately combine a matching plant, nonmatching size, and matching date. Expected outcome: that rule does not match, and the trace identifies size as the failed predicate. Another fixture can include all matching fields but a stated exclusion, verifying precedence.

12. Protect Against False Negatives and False Reassurance

False negatives are more dangerous when the application states certainty it does not possess. The first safeguard is language: absence of a match is scoped to supplied evidence and the source snapshot.

Next, search across relevant historical and current rule versions when policy requires it. A campaign may remain relevant even if a bulletin page is later reorganized. Supersession should not equal deletion.

Input ambiguity should broaden review, not narrow it silently. If one character has two plausible interpretations and either could match a rule, retain both candidates and route the case appropriately. Cap combinatorial expansion to resist abuse, but disclose when the cap prevents full evaluation.

Ingestion failures must affect decisions. If the authoritative-source refresh has failed beyond a defined freshness objective, the service should degrade to “unable to evaluate with current source data” or an equivalent cautious state. Serving an old snapshot as though it were current is a hidden false-negative risk.

Finally, offer a route to official confirmation or qualified physical inspection. Calgary conditions such as gravel-season sidewall grime, winter residue, and road salt can make markings harder to read. Software should make uncertainty visible, not push a user toward a convenient answer.

13. Build Idempotent Ingestion Around Content Identity

Scheduled fetches will retry. Workers will crash. Messages will be delivered more than once. Idempotence keeps those ordinary events from producing duplicate revisions or repeated reevaluations.

Use a stable ingestion key derived from source identity, retrieval target, and raw content hash. Insert immutable source revisions with a uniqueness constraint. If the same bytes arrive again, record a retrieval event if useful but reuse the existing revision.

CREATE UNIQUE INDEX source_revision_identity
ON source_revision (source_id, content_sha256);

Downstream jobs should carry deterministic keys such as:

extract:{source_revision_id}:{extractor_version}
compile:{statement_set_hash}:{compiler_version}
reevaluate:{case_id}:{rule_snapshot_id}:{policy_version}

An inbox/outbox pattern can atomically store a revision and the event announcing it. Consumers record processed event IDs. Exactly-once delivery is usually an illusion; effect-level idempotence is the practical target.

Retries need bounded backoff and dead-letter visibility. A poison document should not block every later source. Preserve the failed artifact, error class, parser logs, and retry count while avoiding sensitive input in broad operational logs.

14. Version Everything That Can Change Meaning

Source documents are not the only moving component. Normalizers, parsers, extraction models, rule compilers, decision tables, and display wording can all alter outcomes.

A complete evaluation envelope might record:

• observation revision identifier;
• normalization algorithm version;
• parser version and format policy;
• source snapshot identifier;
• rule compiler version;
• decision policy version;
• explanation renderer version;
• execution timestamp and trace identifier.

Semantic versions alone are not enough if an untracked configuration changes behaviour. Prefer immutable build identifiers plus hashed configuration. Container digests, source commits, dependency lock hashes, and feature-flag snapshots may be relevant depending on architecture.

Version migration should usually mean replay, not mutation. When parser version 3 improves partial-code handling, run eligible observations through it and create new evaluations. Keep older results accessible so reviewers can understand the difference.

The replay process should specify scope and budget. A corrected high-impact rule might trigger immediate reevaluation of every potentially overlapping case, while a wording-only renderer change may not need decision replay.

15. Store Decisions as Evidence Graphs

A flat result row cannot naturally answer why a result exists. An evidence graph links observations, derived fields, source statements, rule predicates, evaluations, reviewer actions, and supersession events.

You do not need a graph database. Relational tables with typed edges work well:

Observation --normalized_by--> NormalizationRun
NormalizationRun --produced--> ParsedIdentifier
ParsedIdentifier --evaluated_against--> RuleSnapshot
RuleSnapshot --contains--> MatchRuleVersion
PredicateResult --supported_by--> CampaignStatement
Decision --aggregates--> PredicateResult
ReviewAction --affirms_or_replaces--> Decision

The important part is stable identity and navigability. Every outward status should resolve to its supporting nodes. If a reviewer changes a decision, preserve the machine result and add a new authoritative review outcome with rationale.

This graph supports impact analysis. When a source statement is superseded, traverse to affected rules and decisions. When an OCR defect is discovered, find observations processed by that model version. Traceability becomes an operational capability rather than compliance decoration.

16. Put Human Review Inside the Product

“Send it to a human” is not a workflow design. A review queue needs prioritization, evidence presentation, allowed actions, and audit semantics.

A reviewer view should show the original observation, images when authorized, normalized and parsed forms, alternative character interpretations, predicate-by-predicate comparisons, source excerpts with locations, and current freshness. It should avoid leading language that pressures the reviewer to affirm the machine.

Possible actions include:

• request a clearer observation;
• classify the identifier as partial;
• select among parser interpretations;
• mark a source extraction for correction;
• affirm a candidate match;
• resolve the case as not matched on the reviewed evidence;
• escalate to the appropriate authority.

Each action needs a reason code and optional note. Permissions should separate source-rule approval from case review where practical. High-risk bulk actions deserve stronger controls than single-case decisions.

Queue age is an observability signal, but fictional examples should not be mistaken for performance promises. Choose service objectives through real operational analysis. The design principle is simply that ambiguity must land somewhere visible and owned.

17. Create a Testing Pyramid for Meaning

Unit tests should cover deterministic components: Unicode handling, separator logic, parser spans, character ambiguity, date validation, interval endpoints, three-valued operators, exclusions, and explanation rendering.

Table-driven examples make rule semantics readable:

Property-based testing can generate valid and invalid identifier shapes, assert normalization idempotence, and verify that formatting differences do not change parsed meaning. It can also prove interval invariants: values below start are false, values inside are true, and missing values stay unknown.

Contract tests should use saved fictional source fixtures to validate extractors. Golden tests can compare a complete explanation envelope, but keep them focused enough that legitimate wording changes do not create meaningless churn.

End-to-end replay tests should build a source revision, compile rules, evaluate observations, apply a correction, and verify that old and new decisions remain explainable. Inject duplicate messages and worker restarts to prove effect-level idempotence.

18. Test Adversarial and Messy Inputs

Happy-path identifiers do not represent field data. Add whitespace storms, mixed Unicode forms, punctuation, copy-and-paste labels, truncated codes, impossible weeks, old formats, overlong input, embedded markup, and confusable characters.

Security tests matter because ingestion accepts external content. Apply strict size limits, content-type verification, archive expansion limits, parser isolation, and outbound-network controls. Source documents can be malformed without being malicious; the defensive posture is the same.

For OCR, create synthetic fictional images with dirt-like occlusion, low contrast, curvature, glare, and rotated text. Measure field-level ambiguity, not only whole-string accuracy. A model that gets most characters right but frequently damages date codes may be unacceptable for this decision.

Mutation testing is valuable for boundary logic. Flip inclusive comparisons to exclusive and ensure tests fail. Replace unknown with false and confirm the decision-table suite catches it. These mutations target the exact shortcuts that create false reassurance.

Calgary-specific test narratives can improve realism without fabricating operational claims: a sidewall photographed after slushy Stoney Trail travel, an identifier entered during a chinook temperature swing, or a fleet record imported after Highway 1 use. They are scenario fixtures, not reported incidents.

19. Observe the Pipeline Without Leaking Sensitive Evidence

Operational telemetry should answer four questions: Is source data fresh? Is processing healthy? Are results changing unexpectedly? Is human uncertainty accumulating?

Useful metric families include:

• source retrieval success and age by authority;
• revision and extraction counts by status;
• parser finding rates by capture method and version;
• decision distribution by policy version;
• replay backlog and processing latency;
• human-review queue age and reason category;
• contradiction and supersession events;
• idempotency conflicts and dead-letter volume.

Avoid high-cardinality raw identifiers in metric labels. Never place full observations or uploaded images in ordinary logs. Use trace IDs and access-controlled evidence stores. Redact source text where licensing or sensitivity requires it.

Alert on meaning, not just CPU. A sudden disappearance of partial-code findings after a parser deployment could indicate accidental coercion. A large shift from possible to negative outcomes deserves investigation even if every request returns HTTP 200.

Dashboards should show version markers so deployments align with changes. Structured decision samples can support diagnosis, but access must follow least privilege and retention rules.

20. Design Safe APIs and User-Facing Language

The API should return status, scope, reasons, evidence requirements, freshness, and identifiers for audit—not merely matched: true.

{
  "status": "possible_candidate",
  "scope": "fictional source snapshot and supplied evidence",
  "reasons": ["PLANT_MATCH", "SIZE_MATCH", "DATE_NOT_OBSERVED"],
  "next_evidence": ["complete sidewall identifier"],
  "evaluated_at": "2026-09-03T16:20:00Z",
  "source_snapshot": "snapshot_fictional_07",
  "decision_id": "decision_fictional_91"
}

Consumer language should be reviewed like code. “No match found” needs context. “The supplied partial marking did not provide enough information for a complete comparison” is longer but safer when fields are missing.

Do not expose internal scoring as safety certainty. Do not tell a person to continue driving based solely on a software result. Provide official-source context and a path to qualified inspection. For KMJ Tire service information, readers can consult Calgary’s local tire service overview or see service areas. KMJ Tire’s stated scope is tire services and oil changes.

21. Plan Failure Modes Before Launch

Write runbooks for predictable failures:

Authoritative source unavailable. Continue serving the last known snapshot only if policy permits, show its age, and narrow claims. Escalate when freshness limits are exceeded.

New document format. Quarantine extraction, retain raw bytes, and route the revision for mapping. Do not guess column meanings from position alone.

Conflicting authorities. Preserve both statements, identify jurisdiction, block automatic resolution where policy cannot rank them, and seek authoritative clarification.

Parser regression. Stop the affected version, identify observations by build ID, replay them with a corrected release, and compare changed decisions.

Rule correction after decisions. Create a new rule version, compute impact, reevaluate affected cases, and preserve the earlier explanation.

Evidence-store outage. Avoid issuing results that cannot later be justified. A graceful technical error is preferable to an untraceable decision.

These modes should be exercised in game days with fictional data. Recovery procedures that exist only in a document tend to fail when dependencies and permissions have drifted.

22. Use Privacy and Retention Boundaries

A TIN may not identify a person by itself, but the surrounding case can include vehicle details, images, account information, location, and reviewer notes. Apply data minimization to the whole workflow.

Separate physical-tire evidence from personal identity where the product permits. Use opaque case identifiers. Restrict who can view images and raw observations. Define retention by purpose and legal requirements rather than keeping everything forever.

Deletion and audit requirements can conflict. One pattern retains non-personal decision provenance while removing or irreversibly dissociating personal fields when permitted. The exact policy needs legal and operational review; a schema alone cannot decide it.

Uploaded images may contain background details or metadata. Strip unnecessary metadata, limit access, and communicate intended use. Training a future model on operational evidence would be a separate purpose requiring its own authority and controls.

Audit logs should record actor, action, time, target, and reason without duplicating the sensitive payload. Tamper-evident storage can protect high-value review events.

23. Roll Out in Stages With Shadow Evaluation

A careful rollout begins offline. Validate source encoding and decision tables against fictional fixtures plus appropriately authorized reference cases. Then run shadow evaluations where the system produces no outward status but reviewers compare its reasoning.

Next, permit the system to organize evidence for humans without making automatic decisions. Measure disagreement categories and improve the model. Only after policy owners understand failure modes should selected low-ambiguity paths become automated.

Feature flags should control parser versions, source adapters, and decision policies independently. A global kill switch can disable outward evaluation while preserving evidence intake, though its exact behaviour must be rehearsed.

Canary releases should compare old and new decision distributions on the same immutable observation set. Differences require explanation, not merely statistical acceptance. For every changed result, the evidence graph should reveal the responsible parser, rule, or policy change.

No illustrative threshold in this article should be copied into production. Teams must derive limits from their source quality, review capacity, regulatory context, and observed error costs.

24. A Worked Fictional Evaluation

Consider a deliberately fictional observation: DOT ZX Q7 88 with no date component. The placeholder is not asserted to be a valid real identifier and is not associated with any recall.

The normalizer preserves the raw text, removes recognized separators in a derived view, and records its version. The parser identifies fictional plant candidate ZX, fictional size candidate Q7, another fictional field 88, and no production week. It marks the record partial.

An illustrative rule snapshot contains one purely fictional rule requiring plant ZX, size Q7, and a date inside a fictional interval. Evaluation yields:

plant predicate: TRUE (observed field equals illustrative rule value)
size predicate: TRUE (observed field equals illustrative rule value)
date predicate: UNKNOWN (no date evidence)
aggregate: POSSIBLE_CANDIDATE

The explanation links each true predicate to its input span and each expected constraint to a fictional campaign statement fixture. The unknown result links to the parser finding. The outward response requests the complete marking rather than guessing a date.

Now suppose a second observation supplies a clear fictional date outside the illustrative range. A new evaluation returns “rule not matched” with date as the failing predicate. It does not erase the earlier result; it supersedes the case status while preserving why the first answer was cautious.

That sequence demonstrates the architecture’s central property: conclusions become more specific as evidence improves, without rewriting history.

25. Schema Sketch for a Relational Implementation

A practical relational core could use the following bounded tables:

case
physical_tire
observation
observation_artifact
normalization_run
parsed_identifier
parsed_field
source
source_retrieval
source_revision
campaign
campaign_statement
match_rule_version
rule_snapshot
predicate_result
decision
review_action
supersession_edge

Large source bytes and images usually belong in object storage with content-addressed keys; the database stores hashes, media types, access policy, and immutable references. Transactional rows preserve relationships and constraints.

Use check constraints for enumerated statuses, foreign keys for provenance, and exclusion constraints where temporal intervals must not overlap. JSON can hold version-specific payloads, but core fields needed for integrity and queries should remain typed columns.

Partitioning may help high-volume observations or evaluation history, yet it should follow actual workload. Premature sharding makes replay and audit queries harder. Start with correctness, indexes aligned to access paths, and measured growth.

The schema should prevent destructive updates to immutable evidence through permissions or triggers. Administrative correction is an append-and-supersede operation, not a hidden edit.

26. Event Contracts and Replay Discipline

Events should describe facts in the past tense: SourceRevisionStored, RuleVersionApproved, ObservationParsed, DecisionProduced, ReviewCompleted. Commands express intent and can fail; do not confuse them with facts.

Include event identity, aggregate identity, schema version, occurred time, recorded time, causation ID, correlation ID, and payload hash. Consumers must tolerate redelivery and reject incompatible schema versions visibly.

Replay should run against frozen inputs and an explicit software build. If external lookups occur during replay, the result is no longer reproducible. Resolve dependencies into a snapshot first.

A bulk reevaluation job needs checkpoints and deterministic ordering. Store progress after effect-level commits. If interrupted, it resumes without duplicating decisions. Rate limits should protect review queues from a correction that suddenly creates many ambiguous cases.

Event retention must align with evidence retention. If payloads age out, retain enough metadata to explain that the supporting artifact is no longer available under policy rather than returning a broken link.

27. Calgary Context Without Turning Geography Into Logic

Local context helps people understand why legibility and timely inspection matter, but it should not distort recall matching. Chinooks, large day-night temperature swings, gravel, slush, and road salt affect observation conditions. They do not change the plant, size, and production constraints published by an authority.

Keep environmental context in guidance and capture metadata, not in the core campaign predicate unless an authoritative rule explicitly requires geography. A driver travelling on Deerfoot or Stoney Trail should receive the same identifier evaluation as someone elsewhere under the same jurisdiction and source snapshot.

Likewise, tire category education is separate from recall logic. KMJ Tire’s buying tires in Calgary guide and wheel balancing overview can help readers understand related tire topics, but those pages are not evidence that a specific tire is included or excluded from a campaign.

This separation keeps the matcher honest. Context can improve instructions for capturing a readable observation; it cannot substitute for identifier evidence.

28. Review Checklist for Architecture and Operations

Before approving a design, ask:

• Does the system preserve raw observations immutably?
• Can every normalized character be traced to an input span or stated interpretation?
• Are partial identifiers represented explicitly?
• Are source documents separated from extracted rule versions?
• Can constraints link to exact source locations?
• Do effective time and recorded time remain distinct?
• Are production intervals typed, validated, and boundary-tested?
• Does unknown remain different from false?
• Are explanations generated from predicate results?
• Can a corrected source trigger scoped replay?
• Are ingestion effects idempotent under duplicate delivery?
• Is every meaning-changing component versioned?
• Can reviewers see alternatives without being led?
• Do alerts detect semantic distribution shifts?
• Does outward language avoid false reassurance?
• Can the system stop safely when evidence or sources are unavailable?

This checklist is intentionally broader than matching code. Reliability emerges from source handling, human workflow, temporal modelling, language, and recovery as much as from a parser.

29. What Not to Automate

Do not automate past the evidence. A blurry partial identifier plus a provisional source extraction should not become a definitive determination because a queue is busy. The appropriate output is uncertainty and a next step.

Do not allow a language model to invent missing code segments. It may help classify document structure or propose candidate extraction, but every derived constraint needs provenance and appropriate verification. Fluent output does not create evidence.

Do not collapse official confirmation, software screening, and physical inspection into one status. They are different activities with different authorities. Interfaces should name them accurately.

Do not make unrelated mechanical recommendations from recall-matching inputs. If inspection raises a non-tire mechanical concern, direct the person to a qualified provider. KMJ Tire performs tire services and oil changes, not general mechanical work.

Finally, do not hide degraded operation behind a green health check. A responsive API using stale or incomplete source data is not healthy for its actual purpose.

30. The Core Engineering Principle: Preserve the Argument

The best recall matcher is not the one with the cleverest fuzzy-search score. It is the one that preserves the argument from observation to conclusion.

That argument begins with what was actually seen. It records reversible transformations, parses only supported fields, connects rules to authoritative statements, evaluates typed predicates under a versioned policy, and presents unknowns as unknowns. When evidence changes, it adds a new conclusion without erasing the old one. When software changes, replay shows the impact. When sources fail, the product becomes cautious rather than falsely confident.

For a developer or operations team, this approach costs more than string comparison. It also creates the properties a safety-adjacent system needs: explainability, reproducibility, bounded automation, reviewability, and honest failure.

For drivers, the underlying message is simpler. Tire markings deserve careful reading, and incomplete evidence deserves a careful answer. General information about commercial tire services and fleet tire management can support broader planning, while any specific recall question should be verified against current authoritative information and the complete physical tire evidence.

An explainable pipeline does not promise certainty. It earns trust by showing exactly where certainty ends.