Designing a Tire-Service Document Redaction Pipeline

Design exercise: The operational setting is real: Calgary tire-service paperwork can mix useful technical details with information that should not accompany a public explanation. The software architecture below is a proposal, not a description of KMJ Tire's production infrastructure. Every identifier, measurement, capacity, and example document is illustrative. This is engineering guidance, not legal advice or a compliance certification.

Approved brand illustration for general context, not a customer document, software screenshot, or evidence of a completed service.

A tire-size explanation does not need a driver's street address. A discussion of a damaged sidewall does not need a vehicle plate in the background. Those statements sound obvious until someone forwards the original photograph because the cropped preview looked fine. The interesting engineering problem is not how to draw a dark rectangle. It is how to produce a new artifact whose entire contents match a deliberately narrow disclosure decision.

Calgary adds useful context without needing personal context. Chinooks, road salt, gravel season, and large day-night temperature swings explain why someone might preserve a tire inspection image. They do not justify publishing the surrounding receipt, a journey along Deerfoot, or the exact location of a vehicle. Build that distinction into the data flow before choosing an OCR library.

Start with a disclosure question, not a detector

Suppose a developer is building an educational export for a tire-service business. An authorized operator wants to show how a tire-size notation differs from a load index. The input might be a digital invoice, a phone photograph, or a scanned worksheet. The proposed output is a short explanation with a selected technical value and, where useful, a tightly framed image. The audience does not need the full history of the source document.

Write the purpose as a concrete sentence: “Explain this notation using a synthetic example derived from an approved technical field.” That sentence rules out most of the original material. It also gives reviewers something better than a vague request to remove sensitive information. They can ask whether each surviving element helps answer the stated question. If not, exclusion is the default.

A page about reading tire sidewall markings provides the domain context for this example. A technical reference is a better educational destination than a reproduced invoice. Separating the explanation from the paperwork often eliminates the need to export the paperwork at all.

The design should distinguish three purposes from the outset: private service continuity, a restricted evidence exchange, and public education. Their recipients, necessary fields, and retention decisions are different. A document suitable for the first purpose is not automatically suitable for the third. A single “sanitized” badge erases those differences and encourages reuse outside the original decision.

Threat model the artifact and its surroundings

Assume that a recipient can download the released file, inspect its metadata, extract text, zoom into small details, and compare it with other public information. Do not assume sophisticated exploitation is necessary. A filename, a visible reflection, or selectable text behind an opaque annotation may reveal more than the main page preview. The release boundary includes everything delivered, not merely what the operator noticed.

The proposed adversary does not need access to internal storage. They receive the intended export and use ordinary document tools. That keeps the design exercise manageable: protecting the original storage system remains important, but a correct storage permission does not repair a leaking export. Conversely, an excellent export does not secure a public source bucket.

Consider a synthetic photograph of a tire next to a worksheet. The obvious text regions include a customer name and a registration number. Less obvious regions include a handwritten gate instruction, a barcode, a vehicle reflection in a window, and a shipping label on the bench. A detector trained to find names can miss all four. Your threat model must include identifiers that are not words.

There is also an inference boundary. A service date, rare vehicle description, and exact neighbourhood might identify someone together even after direct identifiers disappear. Generalizing each field separately is not enough if the combination remains distinctive. For public education, substituting an explicitly fictional example is often more useful than trying to preserve a real record with increasing numbers of black boxes.

Prefer an allowlisted summary over a patched original

There are two fundamentally different workflows. One removes forbidden information from an existing document. The other constructs a new document using only approved information. For structured input, prefer the second. Start from an empty export schema and add fields that have a stated purpose, rather than serializing an internal object and deleting a few familiar keys.

Here is a small illustrative boundary:

from dataclasses import dataclass

@dataclass(frozen=True)
class EducationalTireExample:
    notation: str
    unit_explanation: str
    example_kind: str = "synthetic"

ALLOWED_KEYS = frozenset({
    "notation", "unit_explanation", "example_kind"
})

def validate_export_shape(payload):
    if set(payload) != ALLOWED_KEYS:
        raise ValueError("unexpected export shape")
    if payload["example_kind"] != "synthetic":
        raise ValueError("unsupported evidence category")

This is intentionally not a complete validator. It demonstrates that the export contract has its own shape. Production validation would also constrain types, lengths, acceptable characters, and the permitted vocabulary. A string field remains capable of carrying a whole pasted invoice unless the design limits its semantics. A familiar key does not make an arbitrary value acceptable.

For a load-index explanation, the output might retain a clearly illustrative index and a link to the explanation, without keeping a vehicle identity or service timestamp. Preserve the distinction between a technical educational example and a fitment recommendation. Removing identity does not make an unsupported tire recommendation accurate.

Separate structured fields from free-form attachments

A relational row and a phone image require different review strategies. An allowlist can give strong structural control over a row when values are properly validated. It cannot tell you what appears in the pixels of an attachment. Treat the attachment as a separate disclosure candidate, not as a harmless field attached to an otherwise clean record.

A useful ingress manifest records the file category, byte length, observed format, page count where relevant, and an internal random job reference. It should not copy the original filename into a broadly accessible queue. A source name such as a person's surname plus vehicle registration can itself leak information. Store any necessary original naming privately, away from the release manifest.

Reject unsupported content rather than silently dropping it. If the input contains an archive, a password-protected component, an unexpected embedded file, or a format your inspection stage cannot enumerate, the export remains unresolved. An operator needs a specific explanation: “This document contains an attachment the reviewer cannot inspect.” A green result for the first visible page would be misleading.

For public guidance about seasonal tire changes, there may be no reason to include a source worksheet. A concise technical summary can teach the distinction between mounted wheel assemblies and loose tires without importing account details. The highest-value privacy feature may be a workflow that avoids an attachment entirely.

Give the pipeline explicit intermediate states

A boolean named redacted cannot represent the work. It blurs detection, editing, verification, and release. Model those as different states with clear transitions. A failed inspection should not accidentally inherit a previously successful flag from another version of the document.

An illustrative sequence is received, classified, candidate_built, review_required, validated, and released. Failed parsing belongs in a separate terminal or retryable state with a reason code. A human decision that a document cannot safely support the stated purpose should end in withheld, not in an indefinite processing spinner.

Attach every transition to an artifact version. A reviewer approving candidate version seven must not authorize version eight after someone changes the crop. The same rule applies to generated captions. A clean picture with a revealing caption is not a clean release. Bundle the image, accessible description, filename, and surrounding text into the reviewed version.

For resumability, persist the candidate identifier before running expensive verification. If the worker stops, a later run can inspect the existing version. It should not silently create a different output and carry forward the earlier review. This is less about elegant state machines than preventing the mundane error of approving one thing and distributing another.

Canonicalize geometry before interpreting boxes

OCR coordinates are meaningful only in a known coordinate system. A phone photograph may have orientation metadata. A scanned page may be skewed. A PDF may have a page rotation and a crop box. If detection and masking disagree about the visible surface, technically correct rectangles can cover the wrong part of the page.

In this proposal, each image candidate is first decoded and oriented into a canonical pixel plane. Record its width and height after that transformation. Run recognition on that exact plane, then apply masks to the same version. Do not detect against a thumbnail and later multiply coordinates by an assumed scale unless the transformation is explicit and tested.

For an illustrative image of 2400 by 1600 pixels, a half-size preview maps coordinates by a factor of two only when there is no cropping, rotation, or letterboxing. A preview component that adds margins breaks a naive mapping. Store the transformation, not merely the displayed dimensions. Test points at every corner as well as the middle.

PDF libraries have their own coordinate conventions. PyMuPDF documents that most page coordinates relate to the unrotated page and provides rotation and derotation matrices. Treat that as an integration contract to test against the version you install, not as something to infer visually. PyMuPDF page coordinate documentation.

Use OCR as a suggestion engine

Recognition is helpful for finding likely text. It is not proof that all identifying content has been found. Low contrast, handwriting, curved surfaces, glare, and tiny print can defeat a detector. Calgary road salt on a tire or a wet receipt makes the example more realistic, but realism should increase caution rather than inspire a confidence claim.

The proposed interface presents candidate regions and lets the reviewer add, expand, or reject them. A low-confidence token is not automatically safe to leave visible. In some circumstances uncertainty is exactly the reason to remove a larger area. The interface should make “uncertain region” a first-class classification instead of forcing a choice between recognized name and harmless text.

Avoid exposing recognized identifiers in the routine job log. The OCR worker can hold them within its restricted working boundary while producing region categories for other components. An operations view can say that three potential identity regions need review without displaying the actual strings. That is enough to coordinate the task.

A tire image intended to accompany puncture repair guidance should focus on the tire evidence relevant to the explanation. It should not suggest that a visual export determines repairability. Privacy review and tire assessment are separate activities; neither substitutes for the other, and a readable picture cannot capture every physical condition.

Region masks need conservative edges

A tightly fitted rectangle can leave fragments of letters around its boundary. Antialiasing, skew, and a detector's approximate geometry all matter. Build a margin policy and evaluate it against representative synthetic fixtures. The margin is not a universal number: a tiny preview and a high-resolution source need different treatment.

For example, a fixture might place a fictional identifier near the right edge of a rotated scan. The expected mask covers the full glyph area plus an explicit safety margin, stays within image bounds, and remains aligned after export. Test the result at full resolution. A mask that looks sufficient at a reduced preview may leave readable fragments when enlarged.

Solid replacement is easier to reason about than blur or pixelation. Blur can retain patterns, and pixelation can preserve enough structure to support guessing. For this design exercise, approved sensitive regions become a fixed opaque colour in the new pixel array. That does not guarantee the whole artifact is private; it makes the treatment of the selected region unambiguous.

Sometimes the right region is the entire surrounding area. A crop around a tire marking can remove a worksheet, a doorway, and a reflection together. But cropping is safe only when the exported artifact contains the cropped pixels, not an editable crop instruction attached to the original. Inspect what was written, not what the editing interface currently displays.

PDF redaction is not a drawing operation

An opaque overlay may conceal text during ordinary viewing while leaving the text recoverable. A PDF can contain objects beyond the visible page: form values, annotations, embedded files, metadata, and other structures. A pipeline that treats it as a flat screenshot without checking the container has an incomplete release model.

If preserving a PDF's structure is necessary, use supported redaction operations and understand their options. In PyMuPDF, adding a redaction annotation and applying redactions are separate steps; the documentation also discusses handling of text, images, graphics, and saving. The precise behaviour depends on configuration and version, so pin and test the implementation. PyMuPDF redaction API.

For an educational illustration, a simpler proposed boundary is often preferable: render the selected page to pixels inside the restricted environment, construct the approved crop and masks, and place only that result in a new export. Do not attach the original PDF to the new artifact. This sacrifices selectable text and some fidelity, which may be acceptable for a small illustration but unsuitable for other purposes.

The trade-off must be explicit. A restricted evidence exchange may need searchable documents and retained structure; a public explainer may not. If accessibility requires text, generate a fresh description from approved content. Never reattach the original OCR transcript merely to make the image searchable, because that transcript can reintroduce everything the visible masks removed.

Rebuild image exports with a narrow metadata policy

Pixels are not the only information in an image file. Review EXIF, textual metadata, orientation, thumbnails, and other format-specific fields. A release that removes a street address from the picture but preserves location metadata has not met its purpose. The safest export policy is narrow and explicit rather than “keep everything except GPS.”

The proposed image path decodes the source, applies orientation, converts to an approved output mode, writes the reviewed pixels into a new image, and encodes that new object without carrying arbitrary source metadata forward. Check the resulting file independently. Library defaults are not a policy, and a future helper function might copy metadata that an earlier implementation omitted.

Pillow exposes image information and separate EXIF-related interfaces, with behaviour depending on format and operation. Its documentation is useful for implementation details, but the security claim belongs to your tested export boundary, not to the fact that a particular library was used. Pillow image API reference.

Retain only information with an explicit need, such as an intentionally selected colour profile if your format and workflow require it. Even then, validate the actual emitted fields. Do not use a broad metadata preservation option for convenience and hope that the identifying fields happen to disappear.

Keep technical meaning after removing context

Over-redaction can produce an image that reveals nothing but teaches nothing either. The purpose statement helps find the right balance. An explanation of sidewall notation needs the relevant marking, legible enough to discuss. It does not need the original vehicle, invoice, or exact capture time. If masking destroys the useful detail, a clearly synthetic diagram may be the better artifact.

Similarly, a discussion of wheel balancing can use an educational description of measurement and correction without displaying a particular person's service record. Do not invent a completed procedure to make the example more engaging. Label hypothetical values visibly, and avoid captions that imply the pictured equipment produced the figures.

A meaningful review includes a domain question: could the remaining material mislead a driver? Cropping a photograph might remove a qualifier, an arrow, or a second measurement needed to interpret it. An apparently successful privacy edit can create a technical error. If a value no longer has its units or context, either restore safe explanatory context or leave it out.

KMJ Tire's service scope here is tire services and oil changes. This article is not an offer of mechanical work, and software should not turn a tire observation into a diagnosis outside that scope. Where a concern needs a qualified mechanical assessment, the educational material should direct the reader to an appropriate provider rather than make a fabricated service claim.

Design the review screen around the final recipient

Show the release candidate as the recipient will see it, alongside a clearly separate restricted view when the reviewer is authorized to inspect the source. A small green rectangle on a busy original is not a substitute for looking at the candidate itself. The interface should make it difficult to confuse the two surfaces.

Provide controls for full-resolution inspection and page-by-page navigation. State how many pages were received, processed, and included. A missing page should be explained, not silently omitted from the summary. For an intended single-image export, make the one-image boundary explicit so a reviewer does not assume the full PDF was processed.

The approval statement should name the purpose and recipient category. “Approved for public educational illustration” is more meaningful than “looks good.” It is also more restrictive: a later user cannot pretend that the decision authorizes retaining the underlying record in a training corpus or forwarding it to an unrelated destination.

Do not make the operator responsible for hidden implementation properties they cannot inspect. They can judge visible content and context; automated checks must verify file structure, metadata, artifact identity, and release packaging. Effective review combines those responsibilities instead of asking a person to certify that a preview contains no embedded files.

Build adversarial fixtures before using real records

A fixture suite can exercise the release boundary without accumulating private paperwork. Generate deliberately synthetic documents containing sentinel strings, invented plate-like patterns, fictional addresses, and non-identifying barcodes. Label the fixtures as test data. Make the sensitive regions known ahead of time so evaluation does not depend entirely on another imperfect detector.

Include a faint identifier in a corner, text rotated ninety degrees, handwriting-like shapes, a field hidden behind an annotation, and a label outside the intended crop. Add examples with multiple pages and with a filename that resembles an identity string. Each fixture should test a different way the pipeline could violate its promise.

The expected result is not merely “OCR finds nothing.” Some sentinels may be intentionally invisible to OCR while still extractable from the container. Other fixtures may contain visual shapes that require human judgment. Use complementary assertions: extracted text, metadata enumeration, attachment checks, byte-level packaging inspections where suitable, and visual review.

An example about winter tire choices can use invented values and a generic synthetic worksheet. There is no educational advantage in recycling a real driver's record into a test corpus. The fixture's job is to challenge the redaction implementation, not to recreate a person's history.

Test the negative space, not just the happy path

Tests should prove that forbidden material is absent from the released object while necessary educational information survives. A positive test that the heading exists says little about privacy. A negative test that a sentinel cannot be extracted is useful, but it also needs a control demonstrating that the sentinel was present in the original fixture.

A compact test plan might contain these cases:

• The input sentinel is extractable before processing and absent from the new artifact afterward.
• A one-pixel movement in a crop boundary does not expose the protected glyph edges.
• A candidate with an unreviewed second page cannot reach the release state.
• An unexpected metadata field causes validation to fail.
• A changed caption invalidates the earlier approval.
• An export request cannot choose the source object's storage key.

These assertions cover different layers. Do not reduce them to one detector score. A detector can succeed while a packaging bug attaches the original. A renderer can produce a clean image while an audit event records the full recognized text. A reviewer can approve the right candidate while a release worker uploads an older one.

For every failure case, verify that the user sees an actionable reason and that no partial artifact becomes publicly reachable. Failures are part of the normal design, not an exceptional reason to bypass checks. The release boundary must remain closed when a library crashes, a timeout occurs, or the inspection service returns an unfamiliar response.

Audit decisions without duplicating identifiers

An audit trail should explain what happened to an artifact. It does not need to become a second repository of the private content. Store a random job reference, policy version, candidate version, transition, responsible role or access-controlled actor reference, timestamp, and result code. Keep detailed sensitive review material in a separate restricted boundary if it is genuinely required.

Avoid logging raw OCR text, source filenames, query strings containing identifiers, or full request payloads. Error handling is a common leak path: a validator that includes the rejected object in its exception may copy private content into a system with broader readership. Design error messages around field categories and reason codes instead.

OWASP's logging guidance discusses excluding or masking sensitive information and protecting logs themselves. That supports the general direction, while the exact audit schema here is a proposed design choice. OWASP Logging Cheat Sheet.

Even hashes need careful interpretation. Hashing a short, predictable identifier does not turn it into anonymous data. A digest can also become a persistent link across systems. If correlation is necessary, document who needs it, how long it is retained, and whether a keyed construction or random mapping is more appropriate. Do not add a content fingerprint simply because it feels audit-friendly.

Keep originals and release objects in different lanes

A storage layout should make accidental publication difficult. The restricted source, temporary working files, reviewed candidate, and final public artifact belong in distinct logical areas with separately scoped access. Giving the publishing component unrestricted access to the entire processing workspace defeats much of the design.

The release worker needs the validated candidate and the minimal publication metadata. It should not fetch the original invoice to calculate a caption or recover a missing thumbnail. If the approved candidate is unavailable, stop. An automatic fallback to the source object is especially dangerous because it may activate only during a failure that no one tested.

Use random object names rather than human identities or original filenames. Set the response content type from verified output format rather than untrusted input. Ensure that the downloadable file is the same version that the preview and approval referenced. If a CDN or image service transforms the file, verify the delivered version too.

For mobile tire service context, source material might plausibly include a yard location or access instruction. The public educational output does not inherit a need for those details. Design the storage and naming boundary so location information cannot travel through a path, filename, or automatic caption after it has been removed from the visible image.

Make retention a separate decision from export

Creating a sanitized educational image does not decide how long to retain the source. Those are different questions with different operational and policy inputs. The pipeline should accept an explicit retention policy from the organization rather than invent one in code. This article deliberately supplies no universal retention period.

Temporary files deserve particular attention. A worker may produce decoded pages, OCR intermediates, thumbnails, and crash artifacts. Treat them as source-equivalent while they retain private content. Inventory where each form can land, including local caches and debugging outputs. Avoid sending these artifacts into general analytics or unrestricted error-reporting systems.

Deletion should be described honestly. Removing a temporary path is not proof that every backup, replica, or previously delivered copy has vanished. Record the scope of a completed cleanup action and handle failures visibly. If a platform retains previous versions, the workflow needs a platform-aware procedure rather than a reassuring local success message.

The public copy also needs ownership. Someone should be able to locate it later, understand the approved purpose, and withdraw it if a problem is discovered. That requires a release register linking the artifact version to its publication destination, without embedding the private source data in the register itself.

Accessibility must use the sanitized content

A redacted image still needs a useful description when it carries educational meaning. Write that description from the approved candidate, not from unrestricted OCR output. An automatic accessibility helper that narrates hidden or removed text can reverse the privacy work in a different channel.

For example, an appropriate description might say that a cropped tire marking illustrates size notation. It should not mention a removed customer name or imply that the image documents a particular vehicle's suitability. If the example is synthetic, include that context in the caption or nearby prose so readers do not mistake it for service evidence.

The same rule applies to translated captions, downloadable transcripts, social previews, and search snippets. These are separate outputs, not harmless decorations. Include them in versioning and review when they derive from the candidate. A good release manifest enumerates the files and text variants that will leave the restricted environment.

General tire care education is valuable when readers can understand it without seeing unnecessary personal detail. Accessibility and privacy are not opposing goals here. Both improve when the explanation is composed intentionally from the useful technical content rather than generated from an entire unfiltered document.

Evaluate utility and privacy with different measures

Do not collapse the pipeline into one impressive percentage. Count distinct failure categories: missed identity region, incorrect geometry, retained metadata, unintended attachment, caption disclosure, and wrong-version release. Their remedies differ, and averaging them can hide a severe defect behind many easy cases.

Also evaluate educational utility. Can a reader identify the intended marking? Are the units visible? Did the process remove a qualifier needed to interpret the example? For a technical tutorial, a completely blank output is private but useless. The goal is a narrow useful artifact, not maximum deletion as a substitute for thought.

Any illustrative throughput estimate must account for review effort and unresolved inputs. A system that processes clear synthetic pages quickly may still require careful human attention for photographs. Do not extrapolate a fixture benchmark into a claim about live service records or staffing savings. This proposal has no production performance results.

Differentiate known coverage from unknown input diversity. Passing every current fixture means those cases passed with those versions and settings. It does not prove the detector understands every handwriting style, PDF producer, or camera workflow. Add a new fixture when a new failure mode is understood, without turning a private incident into a public example.

Treat parser workers as a restricted boundary

Documents are untrusted inputs even when the person submitting them is authorized. A legitimate file can be malformed, extremely large, or simply outside the assumptions of the decoder. The proposed worker therefore has explicit byte, page, pixel, memory, and runtime budgets. These are operational limits chosen for the application, not evidence that a file below the limit is harmless.

Separate parsing from publication. The decoder does not need public publishing credentials, and the release component does not need arbitrary document execution capabilities. A narrow worker receives an internal reference, produces bounded intermediate results in restricted storage, and reports a result category. It cannot pick an external destination based on text found inside the document.

That last constraint matters if a language model assists with captions or region classification. Instructions printed in a document are document content, not instructions to the pipeline. A synthetic fixture can include a sentence telling the system to upload the original elsewhere. The expected behaviour is to treat that sentence as untrusted text and keep the configured destination unchanged. No amount of confident wording inside a receipt grants authority.

Network access should follow the processing purpose. A decoder does not need to retrieve a URL written on a worksheet, and an OCR stage should not automatically fetch remote resources referenced by an input. If an approved external processor is part of the design, its data handling becomes an explicit boundary requiring organizational evaluation. Do not quietly introduce it as a fallback when a local worker struggles.

Specify a release receipt that can be checked

A release receipt should be small enough to inspect but precise enough to prove which artifact left. In this proposal it records the candidate version, output media type, byte length, validation policy version, approval reference, and destination reference. The contents themselves remain in the appropriate storage area. A receipt is not permission to reproduce the source document in an audit export.

Before transmission, the worker verifies that the candidate matches the approved version. After transmission, an independent read of the delivered object confirms that the expected artifact is reachable at the intended destination. Where a platform recompresses images, compare the resulting visible content and inspect the transformed metadata rather than requiring byte equality that the platform cannot preserve.

A delivery error must not downgrade the validation rules. If a destination rejects the approved format, create a new candidate through a documented conversion path and inspect it. Do not rename a different file extension, attach the source as a convenience, or send a lower-quality preview whose content was never reviewed. Compatibility is a separate engineering task.

Think of the receipt as the answer to a future maintenance question: which reviewed output should be removed or replaced? It should resolve that question without exposing the person's original paperwork. This is particularly useful when an educational image appears in several channels, because removing one post does not necessarily remove every delivered copy. The register tracks those destinations while preserving the separation between public artifacts and restricted evidence.

Walk through one synthetic release from end to end

Imagine a fictional two-page worksheet created solely for testing. The first page contains an invented customer block and a technical size notation. The second contains a synthetic route note mentioning Stoney Trail and an invented yard code. The requested educational output needs only an explanation of the notation. No real customer record is involved.

Classification identifies the input as a multi-page document. The purpose policy chooses a structured summary instead of reproducing either page. The reviewer selects the permitted notation field, confirms that it is an illustrative example, and writes a fresh explanation. The candidate contains no image of the original worksheet, no route note, and no hidden second page.

Validation confirms the export schema, safe filename, expected metadata, and absence of source attachments. The reviewer inspects the explanation and its accessible description. Approval binds to that candidate version. The release worker receives only the new artifact, and the release register stores its destination and version. A restart after approval resumes from the saved candidate rather than rereading the original.

Now change the purpose: the tutorial must explain where a marking appears visually. A new candidate uses a synthetic tire diagram, explicitly labelled as such. The older approval does not transfer. That extra review is not bureaucracy; the output changed from text to an image, bringing a different set of visible and metadata questions.

A small implementation boundary worth shipping first

Begin with a deliberately limited product: structured educational summaries from synthetic inputs, no arbitrary attachments, explicit approval, and a release worker that cannot read source storage. This establishes the purpose and versioning boundaries before adding OCR complexity. It also creates useful tests for the most damaging class of mistake: releasing the wrong object.

Next add a single image format with deterministic orientation, constrained metadata, solid region replacement, and full-resolution review. Introduce PDFs only after the team can inspect their additional structure and defend the export strategy. Rejecting an unsupported format is better than accepting it with undocumented assumptions about what might be inside.

The Calgary setting remains relevant throughout. A discussion of road salt, chinooks, or a Highway 1 west trip can help a reader understand tire care without revealing anyone's itinerary. Useful domain context is not the same thing as identifying context. That distinction is the organizing principle of this design.

The final question before release is concrete: does this exact downloadable artifact contain only the information needed for this exact explanation? If the answer depends on a preview hiding something, on a detector being infallible, or on the recipient not looking closely, the candidate is unfinished. Construct less, inspect what actually leaves, and preserve the technical meaning without carrying the person's record along with it.