When an Unknown Category Looks Like the Baseline

A categorical preprocessing path can pass an apparently reassuring set of checks and still erase a distinction that matters at the input boundary. The transformer is fitted. transform() returns successfully. The output width is exactly what the estimator expects. Yet a value never seen during fitting can arrive at the estimator as the same encoded vector used for a legitimate fitted baseline.

That is the failure examined here. The canonical training fixture contains one feature, plan, with basic, basic, plus, plus, and premium. The held-out value enterprise is deliberately excluded from every fit operation. Under OneHotEncoder(drop="first", handle_unknown="ignore"), the question is not merely whether enterprise transforms. It is whether its transformed identity remains distinguishable from the fitted category that was dropped.

The acceptance method is intentionally narrow. It uses a frozen fitted scikit-learn transformer, an independent raw-category ledger, known-answer vectors, warning and exception capture, and explicit decisions before downstream scoring. The documentary research cutoff is September 22, 2026; the executable fixture was recorded with Python 3.13.5, scikit-learn 1.8.0, NumPy 2.3.5, and pandas 2.2.3.

The goal is not to pronounce unknown categories inherently safe or risky. It is to determine whether the preprocessing contract preserves, rejects, groups, or silently destroys their identity, and whether that behavior is acceptable for the intended input policy.

Define the raw distinction the model must not silently erase

Start with the fact that the raw inputs are different:

•         basic is a known value observed during fitting.

•         enterprise is an unknown value deliberately held out from fitting.

That classification must exist independently of the encoder. The test oracle is raw identity against the approved fitted vocabulary, not whatever label can later be reconstructed from a numeric vector.

This distinction matters because scikit-learn expressly documents that handle_unknown="ignore" represents an unknown category with all zeros. It also documents that dropping a category removes one encoded column. Those two behaviors can compose into a many-to-one representation: the legitimate dropped category can be all zeros, while an unknown category is also all zeros. The OneHotEncoder API reference describes both the unknown-handling and dropping semantics.

The bounded input contract for this playbook is therefore:

Before encoding, the system must be able to tell whether plan is a fitted recognized value, a deliberately accepted grouped value, a missing value under a separately specified missing-value rule, or an unseen value requiring rejection or review.

That is an input-representation contract, not a model-performance verdict. Broader questions about evaluation populations, baselines, metrics, and decision thresholds belong in model-evaluation contracts and baselines; they should not substitute for proving what vector the model actually receives.

A model may legitimately have a policy that tolerates unknown categories, rejects them, or maps them into a fitted coarse bucket. None is universally correct. What is unacceptable is allowing the preprocessing representation to decide the operational policy accidentally after raw identity has already been lost.

Freeze the fitted encoder and its category vocabulary

A reproducible acceptance test needs more than a link to stable documentation. The stable selector is useful for the current vendor contract, but it is not an environment lock: the page can later describe a newer scikit-learn release. For this recorded experiment, the installed runtime was scikit-learn 1.8.0, while the retained evidence also records the interpreter and dependency versions.

The minimum evidence manifest is:

A compact environment lock can retain:

python==3.13.5
scikit-learn==1.8.0
numpy==2.3.5
pandas==2.2.3
fixture_revision==onehot-baseline-collision-v1

The python and fixture lines are manifest metadata rather than ordinary pip requirement syntax. Retain the actual package lock used by the project as well.

This is complementary to consistent preprocessing in deployed models, not a replacement for general packaging practice.

Separate fit-time knowledge from transform-time input

The fit data and transform data must remain visibly separate. Scikit-learn's common pitfalls and recommended practices advises fitting preprocessing only on the appropriate training data and applying the already learned transformation to later data; including test data in fit or fit_transform leaks information into the learned preprocessing.

For this fixture:

known_labels = frozenset({"basic", "plus", "premium"})
assert "enterprise" not in known_labels

Do not “repair” the test by refitting on enterprise. That changes the experiment from “what does the frozen artifact do with an unknown?” to “what does a newly fitted artifact do after being taught the value?”

Make category order and dropping visible

Never infer the dropped baseline from intuition alone. Inspect the fitted attributes.

The OneHotEncoder API contract defines categories_ as the categories learned during fitting, and drop_idx_[i] as the index into categories_[i] of the category dropped for feature i.

For the recorded scikit-learn 1.8.0 fixture with drop="first":

categories_             = [['basic', 'plus', 'premium']]
drop_idx_                = [0]
get_feature_names_out()  = ['plan_plus', 'plan_premium']

Only after inspecting those fields is it justified to say that basic is the dropped fitted category. A zero vector has no trustworthy meaning without that fitted configuration.

Build a minimal known-answer category fixture

The fixture should be small enough to audit by sight while still exercising every relevant category state. sparse_output=False is used only to make the arrays readable. The OneHotEncoder documentation notes that sparse output is normally available and is the default; dense arrays here are a testing convenience, not a production memory recommendation.

import platform
import warnings

import numpy as np
import pandas as pd
import sklearn
from sklearn.preprocessing import OneHotEncoder

FIXTURE_REVISION = "onehot-baseline-collision-v1"

train = pd.DataFrame({
    "plan": ["basic", "basic", "plus", "plus", "premium"]
})

held_out = pd.DataFrame({
    "plan": ["basic", "plus", "premium", "enterprise"]
})

known_labels = frozenset(train["plan"].unique())

raw_ledger = pd.DataFrame({
    "plan": held_out["plan"],
    "raw_class": [
        "known_baseline",
        "known_nonbaseline",
        "known_rare_in_canonical_fixture",
        "unknown",
    ],
})

versions = {
    "python": platform.python_version(),
    "scikit_learn": sklearn.__version__,
    "numpy": np.__version__,
    "pandas": pd.__version__,
    "fixture_revision": FIXTURE_REVISION,
}

assert known_labels == frozenset({"basic", "plus", "premium"})
assert "enterprise" not in known_labels
assert raw_ledger.loc[3, "raw_class"] == "unknown"

The recorded environment returned the versions shown in the previous section. That observation is specific to this execution environment; reproducing the laboratory elsewhere should compare its version record with the retained lock before treating differences as equivalent results.

The expected raw classifications are determined before transformation:

That last row is the most important test control. Even if a later inverse operation returns basic, None, or infrequent_sklearn, the independent ledger continues to say that the original submitted value was enterprise.

The test should stop if the fixture changes unexpectedly, enterprise appears in the fit data, the recorded dependency versions cannot be reproduced or consciously qualified, or the fitted attributes differ from the asserted vocabulary without review.

Reproduce the dropped-baseline collision

Now fit the configuration that creates the ambiguity:

drop_ignore = OneHotEncoder(
    drop="first",
    handle_unknown="ignore",
    sparse_output=False,
)

drop_ignore.fit(train)

assert drop_ignore.categories_[0].tolist() == [
    "basic", "plus", "premium"
]
assert drop_ignore.drop_idx_.tolist() == [0]
assert drop_ignore.get_feature_names_out().tolist() == [
    "plan_plus", "plan_premium"
]

with warnings.catch_warnings(record=True) as captured:
    warnings.simplefilter("always")
    encoded = drop_ignore.transform(held_out)

warning_text = [str(item.message) for item in captured]

assert encoded.tolist() == [
    [0.0, 0.0],  # basic
    [1.0, 0.0],  # plus
    [0.0, 1.0],  # premium
    [0.0, 0.0],  # enterprise
]

assert np.array_equal(encoded[0], encoded[3])
assert raw_ledger.loc[0, "plan"] != raw_ledger.loc[3, "plan"]

This result is consistent with the documented OneHotEncoder composition. drop="first" removes the first fitted category's column, while handle_unknown="ignore" encodes an unknown category as all zeros.

The known-answer table is therefore:

That is the collision: basic and enterprise are distinct raw values but identical encoded inputs.

In the recorded scikit-learn 1.8.0 run, transformation also emitted a UserWarning stating that unknown categories were found and would be encoded as all zeros. Treat that as captured evidence from this runtime, not as the admission-control mechanism. A warning is not an exception, and code that does not promote or inspect warnings still receives a transformed array.

This is why two common checks are false greens:

assert encoded.shape == (4, 2)  # passes
assert np.isfinite(encoded).all()  # passes

Both statements are true, but neither establishes that every raw category was recognized or represented distinctly.

Test what inverse transformation can and cannot tell you

inverse_transform() is useful as a diagnostic, but it cannot reconstruct information that the forward representation discarded.

The OneHotEncoder API is explicit: when an all-zero vector arises for an unknown category and the feature has a dropped category, the dropped category is used as the inverse. That makes the collision particularly dangerous for naïve audit code.

decoded = drop_ignore.inverse_transform(encoded).ravel()

assert decoded.tolist() == [
    "basic",
    "plus",
    "premium",
    "basic",
]

The complete observation is:

Nothing contradictory is happening inside the encoder. Given only [0, 0] and the fitted dropped-category configuration, both original cases are observationally identical. The inverse method must choose the documented interpretation available from the encoding. It does not have the original raw input hidden elsewhere.

Compare decoded labels with the independent raw ledger

The raw ledger is therefore authoritative for admission analysis:

audit = raw_ledger.copy()
audit["vector"] = encoded.tolist()
audit["decoded"] = decoded

assert audit.loc[audit["plan"] == "enterprise", "raw_class"].item() == "unknown"
assert audit.loc[audit["plan"] == "enterprise", "decoded"].item() == "basic"

An evaluation script should be rejected if it performs this sequence:

1.     Encode raw evaluation inputs.

2.     Inverse-transform them.

3.     Replace the original categorical column with the decoded value.

4.     Count unknown categories from that reconstructed column.

In this fixture, that procedure launders enterprise into basic and reports zero unknowns.

The decoder is evidence about the representation's reversibility, not an oracle of original identity.

Hold the downstream computation constant

To show why the representation matters without introducing estimator training, use a deterministic synthetic scoring function:

def synthetic_score(vector: np.ndarray) -> float:
    """Illustration only; this is not a fitted production model."""
    plus, premium = vector
    return float(0.20 + 0.30 plus + 0.50 premium)

basic_score = synthetic_score(encoded[0])
enterprise_score = synthetic_score(encoded[3])

assert basic_score == enterprise_score == 0.20

The equal result follows mechanically because the function receives equal vectors. A fitted estimator that is deterministic for a fixed input would likewise have no encoded information from this feature with which to distinguish those two rows.

That does not establish that an enterprise customer should receive a different business outcome, nor that an encoder setting alone determines risk. It establishes the narrower fact needed for acceptance: this representation has discarded the raw distinction before downstream computation.

Compare strict rejection with an undropped encoding

The first alternative is explicit rejection:

strict = OneHotEncoder(
    drop=None,
    handle_unknown="error",
    sparse_output=False,
).fit(train)

try:
    strict.transform(held_out)
except ValueError as exc:
    observed_error = str(exc)
else:
    raise AssertionError("Expected an unknown-category ValueError")

In the recorded run, scikit-learn raised a ValueError identifying enterprise as an unknown category in column zero. This matches the documented handle_unknown="error" behavior: encountering an unknown during transform raises an error.

Strict rejection is appropriate when only an approved vocabulary may proceed. It is not automatically appropriate when new legitimate categories are expected and the serving contract has a controlled review path.

Now remove dropping while retaining unknown ignoring:

undropped = OneHotEncoder(
    drop=None,
    handle_unknown="ignore",
    sparse_output=False,
).fit(train)

x = undropped.transform(held_out)

assert undropped.get_feature_names_out().tolist() == [
    "plan_basic", "plan_plus", "plan_premium"
]

assert x.tolist() == [
    [1.0, 0.0, 0.0],
    [0.0, 1.0, 0.0],
    [0.0, 0.0, 1.0],
    [0.0, 0.0, 0.0],
]

Now enterprise no longer collides with a known fitted category: every known label has a one-hot coordinate and the unknown gets zero. Its inverse is None, matching the documented unknown-category behavior when no category is dropped.

But identity is still not preserved among unknowns. enterprise, partner, and any other unseen string would share the same zero vector under this fitted encoder. So drop=None fixes the particular dropped-baseline collision; it does not create a unique representation for each unknown raw label.

The acceptance decision remains a policy decision: reject unknowns, review them before encoding, or deliberately collapse them under a trained grouping rule.

Prove that an infrequent bucket exists before relying on it

handle_unknown="infrequent_if_exist" is often attractive because an unknown can map to an infrequent-category coordinate. The crucial qualification is in the option's name: if one exists.

The OneHotEncoder infrequent-category policy maps an unknown to the infrequent category when such a category was created during fitting. If no infrequent category exists, unknown handling falls back to the equivalent of handle_unknown="ignore". Whether a group exists depends on min_frequency or max_categories.

Therefore this configuration is insufficient evidence:

OneHotEncoder(
    handle_unknown="infrequent_if_exist",
    min_frequency=2,
)

The acceptance evidence must include fitted counts, infrequent_categories_, and feature names.

Use a fixture with a genuinely rare fitted label

The canonical fixture has counts:

basic    2
plus     2
premium  1

With an integer min_frequency=2, the OneHotEncoder frequency rule defines categories occurring fewer than two times as infrequent.

rare_bucket = OneHotEncoder(
    drop=None,
    handle_unknown="infrequent_if_exist",
    min_frequency=2,
    sparse_output=False,
).fit(train)

assert rare_bucket.infrequent_categories_[0].tolist() == ["premium"]

assert rare_bucket.get_feature_names_out().tolist() == [
    "plan_basic",
    "plan_plus",
    "plan_infrequent_sklearn",
]

rare_x = rare_bucket.transform(held_out)

assert rare_x.tolist() == [
    [1.0, 0.0, 0.0],  # basic
    [0.0, 1.0, 0.0],  # plus
    [0.0, 0.0, 1.0],  # premium: fitted infrequent
    [0.0, 0.0, 1.0],  # enterprise: unseen
]

The documented inverse representation for the infrequent group is infrequent_sklearn. In the recorded run, both premium and enterprise inverse-transformed to that group label.

This is intentional grouping, not preservation of raw identity. premium remains a fitted known category in the independent ledger, while enterprise remains unknown. Both may be allowed to share the encoded bucket only because the admission policy explicitly permits that loss of distinction.

Repeat the policy with no fitted rare group

Use a second fixture where every fitted category meets the same threshold:

no_rare_train = pd.DataFrame({
    "plan": [
        "basic", "basic",
        "plus", "plus",
        "premium", "premium",
    ]
})

no_rare_bucket = OneHotEncoder(
    drop=None,
    handle_unknown="infrequent_if_exist",
    min_frequency=2,
    sparse_output=False,
).fit(no_rare_train)

assert no_rare_bucket.infrequent_categories_[0] is None

assert no_rare_bucket.get_feature_names_out().tolist() == [
    "plan_basic",
    "plan_plus",
    "plan_premium",
]

no_rare_x = no_rare_bucket.transform(
    pd.DataFrame({"plan": ["enterprise"]})
)

assert no_rare_x.tolist() == [[0.0, 0.0, 0.0]]
assert no_rare_bucket.inverse_transform(no_rare_x)[0, 0] is None

This is the acceptance test for the infrequent_if_exist missing-bucket problem: changing the parameter name did not manufacture a trained plan_infrequent_sklearn coordinate. The fitted artifact must prove that the bucket exists.

Dropping is intentionally absent from both infrequent branches. The OneHotEncoder grouping and dropping rules interact, including cases where an infrequent category can itself be dropped. That combination deserves a separate known-answer test rather than an assumption based on these results.

Keep missing, normalized, and unknown inputs separate

An unknown label, a missing value, and a value changed by normalization are different input populations. Do not collapse them into a single category called “bad data.”

For this playbook, define the raw contract narrowly: plan must be a string after an explicitly versioned normalization step. A possible business-owned policy might map an actual missing value to a literal sentinel such as "<MISSING>", but only when that sentinel is part of both training and serving specifications. The canonical collision test does not use such a sentinel, because mixing missing-value handling into the fixture would obscure the unknown-versus-baseline proof.

Likewise, normalization needs its own evidence. Suppose policy revision plan-normalization-v2 performs:

def normalize_plan(value: str) -> str:
    return value.strip().lower()

Then " Plus ", "PLUS", and "plus" intentionally become one value. That is another many-to-one mapping, but unlike the OneHotEncoder collision it occurs before encoding and should therefore be visible in the normalization contract.

A robust raw ledger should retain fields such as:

Do not assume None, np.nan, "", " ", and "enterprise" share library semantics. Define and test each accepted representation explicitly. The useful boundary is not “the encoder handled it”; it is “the input policy assigned a reviewed state before encoding occurred.”

Validate raw input before the representation loses meaning

The safest location for the unknown decision is before OneHotEncoder receives the value.

A minimal guard can use the independently retained approved vocabulary:

from dataclasses import dataclass
from typing import Literal

Admission = Literal["ACCEPT", "REJECT", "REVIEW"]

@dataclass(frozen=True)
class AdmissionResult:
    action: Admission
    reason: str

def classify_plan(
    value: object,
    approved_vocabulary: frozenset[str],
    *,
    unknown_action: Literal["REJECT", "REVIEW"],
) -> AdmissionResult:
    if not isinstance(value, str):
        return AdmissionResult(
            "REJECT",
            "plan must be a non-missing string under this contract",
        )

    if value in approved_vocabulary:
        return AdmissionResult("ACCEPT", "known fitted category")

    return AdmissionResult(
        unknown_action,
        "category absent from approved fitted vocabulary",
    )

The guard should emit a disposition before encoding. Raw values need not be copied into unrestricted application logs: operational telemetry can count known/unknown decisions, use approved low-cardinality codes, or apply controlled hashing where appropriate to the privacy model. The policy owner, not this playbook, sets any review threshold.

In a multi-column preprocessing graph, the ColumnTransformer API reference explains that selected column subsets are transformed separately and their generated features are concatenated. Its get_feature_names_out() support is useful evidence for the resulting feature meaning. A correct output width alone does not prove that the intended raw column was selected or that every submitted category was recognized.

Similarly, the Pipeline API reference documents that transformations are applied sequentially before an optional final predictor. Pipeline composition promotes consistency, but it does not turn an ignored unknown into a known value. Put the admission guard where it can still inspect raw identity, then keep the fitted transformation and estimator composition frozen behind it.

Build a policy-by-input acceptance matrix

The reviewer should now be able to compare policies against the same raw fixture instead of comparing parameter names abstractly.

The most important row is the second one. It demonstrates why the dropped-baseline configuration cannot use encoded output alone as an admission oracle.

Any later separate probability-calibrator acceptance gate operates downstream from this proof. Calibration evidence cannot determine whether enterprise and basic arrived at the scoring function through an unintended representation collision.

A policy can be accepted only when its raw disposition and encoded semantics agree with the intended contract. “Transformer returned an array” is not an acceptance condition.

Measure unknown handling without laundering the denominator

Operational measurement must start from the raw input boundary, not from values that survived preprocessing.

For a defined population of eligible inference attempts:

The denominator must not quietly exclude unknowns merely because they were rejected. Instead report dispositions separately:

eligible_raw_attempts
known_accepted
unknown_reviewed
unknown_rejected
missing_rejected
normalization_rejected

Suppose a synthetic fixture contains 1,000 eligible raw attempts, 20 unknowns, 15 rejected unknowns, and 5 reviewed unknowns. The unknown rate is 20/1,000, not 5/985 and not zero because the 15 rejects never reached the encoder. These numbers are an illustration of denominator design, not production measurements.

Health checks, retries, or duplicate requests may be excluded only through a defined eligibility rule that is applied consistently before numerator classification. Otherwise it is easy to create a favorable rate by deleting inconvenient attempts after their disposition is known.

Telemetry also needs boundaries. Do not emit unrestricted high-cardinality raw labels simply to calculate the metric. Retention periods, access permissions, hashing or tokenization rules, and cardinality controls should follow the application's privacy and security requirements.

Finally, a low unknown rate is not automatically an acceptance criterion. One unknown in a legally or operationally sensitive path may require rejection; thousands of unknowns may be perfectly expected in a reviewed discovery workflow. Rate measurement tells you how often a state occurs. It does not define the permitted action for that state.

Change the policy without mismatching the fitted estimator

Changing categorical handling can change both the number and meaning of estimator inputs. That makes it a model-interface change, not merely a preprocessing toggle.

Moving from:

['plan_plus', 'plan_premium']

to:

['plan_basic', 'plan_plus', 'plan_premium']

changes width. A downstream estimator fitted on two inputs plainly cannot accept the three-coordinate representation without coordinated retraining or another explicitly compatible interface.

The subtler case is unchanged width. Suppose a revised encoder still emits two columns but the vocabulary, drop index, or infrequent grouping changed. A width check can pass while feature meaning changes. The model might receive a coordinate named or ordered differently from the feature on which its fitted parameter was learned.

Scikit-learn's ColumnTransformer constructs a combined feature space from selected transformer outputs, and Pipeline passes transformed data to its final estimator. Consequently the compatibility record should include at least:

raw column selection
normalization revision
encoder parameters
categories_
drop_idx_
infrequent_categories_
get_feature_names_out()
downstream estimator identity/version
fixture revision
environment lock

This is distinct from serving-mode validation as a different boundary. The question here is not neural-network execution mode; it is whether the fitted estimator receives the same categorical feature meanings it was validated against.

Use RETRAIN-AND-REVALIDATE when a proposed fix changes the fitted feature space, category grouping, dropping semantics, normalization semantics, or otherwise changes the estimator's input meaning. Do not hot-swap an encoder merely because a smoke test reports the same array width.

A bounded recovery is preferable: restore the last known compatible preprocessing-plus-estimator combination, reinstate the previous admission rule if necessary, then evaluate the proposed categorical policy with the same known-answer fixtures before release.

Set rollback, ownership, and regression gates

The release decision should be explicit enough that data, model, and serving owners cannot each assume another team checked the raw-input boundary. For broader role boundaries, see ownership across data science and ML engineering.

Use four dispositions.

ACCEPT when the raw input is in the approved vocabulary, or when a documented fitted grouping policy deliberately covers it; the frozen artifact attributes match the retained evidence; known-answer vectors pass; and the downstream estimator is compatible with those feature meanings.

REJECT when strict vocabulary membership is required and an unseen category appears, when required evidence is absent, or when an ambiguous representation would proceed without a raw guard. drop="first" plus ignored unknowns should not be accepted as proof that the unknown is safely equivalent to the baseline.

REVIEW when the operational policy intentionally permits novel raw values to enter a controlled route before encoding. Review must preserve the fact that the value was unknown; it cannot be implemented by decoding a collided zero vector after the fact.

RETRAIN-AND-REVALIDATE when resolving the problem changes category vocabulary, grouping, dropping, normalization, feature names, output meaning, or estimator compatibility.

Ownership is correspondingly bounded. The input owner defines approved raw states and normalization. The model owner records fitted vocabulary and validates representation-to-estimator compatibility. The serving owner enforces admission before destructive transformation and retains the compatible artifact combination.

Regression tests should include at least these assertions:

assert "enterprise" not in known_labels
assert drop_ignore.categories_[0].tolist() == [
    "basic", "plus", "premium"
]
assert drop_ignore.drop_idx_.tolist() == [0]

z_basic = drop_ignore.transform(
    pd.DataFrame({"plan": ["basic"]})
)
z_enterprise = drop_ignore.transform(
    pd.DataFrame({"plan": ["enterprise"]})
)

assert np.array_equal(z_basic, z_enterprise)
assert classify_plan(
    "enterprise",
    known_labels,
    unknown_action="REJECT",
).action == "REJECT"

The first equality is deliberately a regression assertion for the hazardous representation: if the implementation is still configured this way, the test records that the collision exists and proves the guard is necessary.

If historical evidence contains only collided vectors such as [0,0], raw identity cannot be reconstructed from those vectors alone. The OneHotEncoder inverse contract demonstrates why: with a dropped category, that zero representation is decoded as the dropped category. Rollback therefore means restoring compatible artifacts and policies, not pretending lost raw identity can be reverse-engineered afterward.

Build data-science skills around explicit input contracts

The practical acceptance decision is straightforward: do not approve categorical inference by asking only whether transformation succeeds. Preserve an independent raw vocabulary test, inspect the fitted encoder's actual categories and drop index, and prove the expected representation for known, unknown, and deliberately grouped values. Use strict rejection where the vocabulary is closed; use review where novelty is expected; and rely on an infrequent path only after the fitted artifact proves that the infrequent bucket actually exists.

For practitioners strengthening the foundations behind this kind of work, Refonte Learning's Data Science & AI page lists Python data science, statistical modelling, machine learning and predictive modelling, and applied projects; its published tool list includes pandas, NumPy, and scikit-learn. The page describes a three-month program with an indicated 12–14 hours per week. Those published foundations should not be read as a claim that this specific OneHotEncoder collision laboratory is part of the curriculum.

The engineering lesson is narrower and more durable: a successful transformation proves that software produced an output; a justified category policy proves that the output still means what the system intends it to mean.