Batch 010 found a bug that looked like good news.

The classification worker was finishing its work. Runs moved through the database. Product rows had candidate tariff codes. The regression suite was far enough along that a casual glance could have treated the classifier as alive.

Then one test forced three uncomfortable cases through the loop: no candidate, weak confidence, and a near tie. All three came back looking too clean. The worker was persisting the run as classified, even when the evidence said the product needed review or had no supportable recommendation.

That is the kind of bug I worry about in compliance software. Not the loud crash. The green row.

A customs classifier can fail by throwing an exception. That failure is annoying, but honest. The operator sees it. The queue stops. The job gets retried. The audit trail can say, plainly, that classification did not happen.

The worse failure is a result that looks complete while the evidence underneath is missing or contested.

That was the real Batch 010 scar. The engine already carried the domain rule in its intent: classification is evidence, not a label. But the persistence path was still treating classification as if the only final state that mattered was success. The runtime could produce rejected candidates and confidence values. The database could store failure reasons. The tests could express review states. One narrow path still flattened doubt into completion.

I was wrong about where the risk sat. I expected the hard part to be selecting the tariff code. The harder problem sat one layer later: making sure the code was not selected when the evidence did not deserve that much authority.

Customs data makes that tension obvious. A product row is rarely a clean ontology entry. It is a SKU, a commercial name, a description written by someone under time pressure, a country of origin, a jurisdiction, maybe a material list, maybe an intended use. The difference between a good HS or HTS recommendation and a dangerous one can be a phrase that is absent, ambiguous, or buried in the wrong field.

So I made the classifier refuse to pretend. If a product lacks a candidate, it should be blocked. If the best candidate is too weak, it should go to review. If two candidates are close enough that the lower one is still meaningful, the engine should preserve that tie instead of hiding it behind a confident-looking status.

The decision lives in a small Rust function, which is why I like it. The policy is not scattered across a UI badge, a worker branch, and a reporting query. The worker asks one question: given the runtime outcome, what status should the database store?

pub(super) fn outcome_decision(outcome: &RuntimeClassification) -> OutcomeDecision {
    if outcome.selected_code.is_none() {
        return OutcomeDecision {
            status: "blocked",
            failure_reason: Some("no_candidate"),
        };
    }
    if has_tie_candidate(outcome) {
        return OutcomeDecision {
            status: "needs_review",
            failure_reason: Some("tie_candidate"),
        };
    }
    if outcome.confidence < 0.82 {
        return OutcomeDecision {
            status: "needs_review",
            failure_reason: Some("low_confidence"),
        };
    }
    OutcomeDecision {
        status: "classified",
        failure_reason: None,
    }
}

That function from src/classification/outcome.rs is not clever. It is deliberately plain. It says the classifier has four questions to answer before it earns the right to call a run classified.

First, did the runtime select any code at all? If not, the run is blocked/no_candidate. The operator should not see an empty answer wearing the same status as a resolved classification.

Second, did the runtime find a meaningful tie? The rule runtime marks lower-ranked matches as rejected candidates, and a near tie gets the reason tie_score. In that case the selected code still matters, but it is not enough. The run becomes needs_review/tie_candidate.

Third, did the selected code clear the confidence floor? The current worker uses 0.82 as the line below which a product should not pass as clean. That number is a code-backed threshold, not a production claim. It is there because the engine needs a deterministic boundary for review routing.

Only after those checks does the run become classified.

The order matters. No candidate is different from low confidence. Low confidence is different from a tie. A tie with a selected code is different from a rule pack that found nothing. If those cases all share a green status, the UI can only lie or become complicated later. If the status and reason are precise at write time, the rest of the product can stay simpler.

The test that caught this is the kind of test I wish more systems had before they gained users. It does not test the happy path with a cotton shirt and a confident tariff code. It creates three products with names that force the worker to admit uncertainty.

One row has no matching rule. One row matches with a confidence below the floor. One row matches two close candidates, 6205.20 and 6205.30, close enough that the rejected candidate still belongs in the record. The assertion is not only that the worker completes three jobs. It checks the stored status, the failure_reason, the selected code where one exists, the candidate code list, and the tie_score reason inside rejected candidates.

That last part matters. I did not want a review queue filled with vague work items that say, "please check this." I wanted the queue to carry the reason the machine gave up authority. A reviewer should know whether they are handling an empty result, a weak result, or a contested result.

The same logic affects audit exports. An audit pack that says a product was classified is different from an audit pack that says the system found two close candidates and routed the run to review. In both cases, the export has value, but it answers a different question. One says, "here is the evidence behind the recommendation." The other says, "here is the evidence behind the refusal to recommend."

That distinction changes the product shape. The engine stores matched rules, rejected alternatives, confidence, risk band, rule pack version, input snapshot, reviewer decisions, and failure reasons. It also freezes the product and rule pack facts at queue time. If the product description changes after the job enters the queue, the worker still evaluates the snapshot it was handed. If the active rule pack changes later, historical runs still point back to the pack version that produced them.

That is slower to reason about than a direct request that always reads current product state. It is also safer. A compliance review is not asking, "what would the system say today?" It often asks, "what did the system know then, and why did it make that call?"

What surprised me was how much of the architecture flowed from that one sentence.

The classifier uses a PostgreSQL job table instead of pretending a background job is a fire-and-forget detail. A worker leases rows, marks attempts, and exits if a run is already terminal. Product import refuses rows that lack required facts such as SKU, name, description, country, jurisdiction, product type, materials, or intended use. Rule packs have activation gates before they become active. Reviewer overrides append structured corrections instead of mutating the machine result. Audit exports are rendered from frozen snapshots instead of live joins that could drift.

Those choices sound separate until Batch 010 ties them together. If the worker writes the wrong status, every careful snapshot around it becomes less trustworthy. The audit export preserves the wrong conclusion. The review queue misses the item. The dashboard looks cleaner than the evidence. Optional integrations can fire the wrong event. A bad status is not a display bug. It is an evidence bug.

The fix was small because the earlier design had already made room for it. The database had a status field and a failure reason. The runtime returned selected and rejected candidates. The tests could create all three edge cases. Once the regression exposed the lie, the code only had to make the domain decision explicit.

I also changed how I read passing tests after that. A test that proves a worker completed is not enough for a compliance loop. Completion is only a transport fact. The domain fact is whether the stored row still carries the same uncertainty the runtime produced. That is why the regression checks status, failure_reason, selected_code, candidate_codes, and rejected candidate reasons in one place. If any one of those drifts, the row may still look finished, but the evidence contract is broken.

That is the lesson I took from it, and I mean lesson in the practical sense, not as a slogan. If a domain has reviewable uncertainty, model that uncertainty before the happy path spreads through the codebase.

For this project, uncertainty has names: no_candidate, low_confidence, and tie_candidate. Those names are not UI copy. They are durable outcomes.

A classifier that always returns an answer is easy to demo. It is also easy to distrust. In customs work, the more serious promise is narrower: when the evidence is good enough, store the recommendation; when it is not, store the reason it stopped.

That is why the Trade Compliance Classification Engine refuses to treat every product as solved. Certainty is useful only when the record can prove how it was earned.