When Automated Feature Extraction Silently Destroys Interpretability for Experienced Teams

You've got a team that knows its data. You've been hand-crafting features for years, and your models sing. Then someone suggests an automated feature extraction (AutoFE) library. 'Just plug it in,' they say. 'It'll find interactions you'd never see.' And it does. But six months later, you can't explain why your model spikes on certain days. You can't trace a prediction back to a business rule. The tool silently ate your interpretability.

This isn't a beginner's problem. Experienced teams suffer most because they trust the pipeline, assume the automation is 'smart enough,' and skip the manual checks that used to catch nonsense. The result? A model that works great on test sets but fails in production when a stakeholder asks, 'Why did you decline this loan?' The answer shouldn't be 'the autoencoder said so.'

Where AutoFE Ambushes You: Real-World Context

Production incident: unexplained credit decision after AutoFE

Three months into a new credit-risk pipeline, the model started denying applicants with perfect payment histories. Not outliers—people with seven years of clean data. The team had let automated feature extraction run wild: it generated 1,400 interaction terms, polynomial expansions, and a set of embeddings from a transaction graph. No human could trace why a specific applicant scored 0.28 instead of 0.72. That’s where interpretability dies—silently, inside a black box nobody bothered to open.

The incident escalated to compliance. Regulators demanded an explanation for the denial. The team stared at 1,400 columns. They couldn’t point to a single feature that caused the drop. AutoFE had created a latent interaction between a rarely-used card type and a time-since-last-purchase bucket—something no manual engineer would have coded. Wrong order. No paper trail. The fix took two weeks and involved reverting to a 22-feature logistic regression. That hurts.

“We saved three days of engineering work and paid for it with six weeks of forensic debugging.”

— Lead ML engineer, mid-tier fintech, post-mortem notes

The trust loop: automation reduces manual scrutiny

Most teams skip this: when a tool generates features automatically, engineers stop questioning them. It’s not laziness—it’s cognitive offloading. You trust the library because it worked on Kaggle, or because the vendor demo looked slick. But automated feature extraction has no concept of business logic. It doesn't know that a credit limit increase should be modeled as a step function, not a continuous interaction with average balance. The catch is that every automated transform you accept without review becomes invisible debt. Six months later, when a feature drifts or a prediction flips, you have no mental map of why.

I have seen a team of eight data scientists lose an entire quarter because nobody noticed that an AutoFE pipeline had encoded a ZIP code field as 300 dummy variables—then combined them with income deciles. The resulting feature space was mathematically valid and completely uninterpretable. The business asked for a simple “why did this customer get flagged?” answer. They got silence.

Case: retail demand forecasting with t-SNE embeddings

A well-known scenario: a retailer feeds 500 product attributes into an autoencoder, then uses the compressed latent vectors as features for a gradient-boosted model. Forecasting accuracy improves by 12%. The team celebrates. Then the category manager asks: “Which product attributes caused the stockout prediction for SKU 492?” Nobody answers. The embedding is a dense vector with no semantic mapping. You can't say “this SKU stockout happened because promotions overlapped with a holiday shipping cut-off”—you can only say “the embedding said so.” That's not an explanation; it's a confession.

What usually breaks first is the trust between data science and operations. When the forecast misses by 40% and the ops lead asks “why,” saying “the t-SNE latent space shifted” is career-limiting. Teams that revert to manual feature engineering do so not because accuracy drops—accuracy often holds—but because the cost of not understanding exceeds the cost of building features by hand. The trade-off is real: speed now versus clarity later. Pick your pain.

What Even Is Interpretability? (And What AutoFE Gets Wrong)

Interpretability vs. Explainability: The Practical Difference

Most teams treat these as synonyms. They're not. Interpretability means you can look at the model and say, ‘I see why’ — the logic is transparent enough that a human can trace a prediction back to raw inputs. Explainability is damage control: the model stays opaque, but you generate post-hoc stories about its behavior. AutoFE sells explainability while wrecking interpretability. You get SHAP plots and LIME masks, sure — but those are approximations of what the machine might have learned, not faithful maps of its internal reasoning. The seam blows out when engineers need to explain a production spike at 3 AM and the only answer is ‘the cubic polynomial of the log-difference of a lagged interaction term tripped.’ That’s not a fix. That’s a riddle.

Feature Extraction vs. Feature Selection: A Common Confusion

Feature selection keeps your columns but removes weak ones. Feature extraction replaces them with synthetic monsters. You lose the original names, the original distributions, the original meaning. I have seen senior engineers treat an AutoFE pipeline as glorified feature selection — ‘it’s just picking the good stuff, right?’ Wrong. Extraction is a transformation layer that destroys column-level semantics. Once your dataset contains V_832 and eigen_component_7, you can't ask ‘did age matter here?’ because age is gone. The catch is that many teams don’t notice this loss until a regulator, a client, or a bug demands lineage.

‘Interpretability is a property of the relationship between input and output, not a property of the model alone.’ — paraphrased from every frustrated team lead I have met.

— the kind of truth you only appreciate after your first AutoFE rollback costs two sprints.

Why Linear Coefficients Don't Survive Nonlinear Transforms

This is where the math quietly betrays you. A linear model trained on raw features gives you clean coefficients: one number per column, directional, monotonic. AutoFE often runs polynomial expansions, binning, spline bases, or tree-embedded encodings before the model ever sees the data. The original feature may contribute through three spline knots and a log interaction. You can't sum those contributions as ‘one coefficient for age’ — the effect is scattered across derived columns that have no natural interpretation. Teams try to reverse-engineer importance by aggregating SHAP values or permutation scores, but those aggregate methods lose sign and shape information. Quick reality-check: if your feature importance plot shows ‘age’ contributing 12% via the original column, 8% via age_squared, and 5% via age_log, what direction does age push predictions? Nobody knows without a simulation. That hurts.

The pitfall is seductive: AutoFE boosts accuracy on the bench, so teams ship it and only later discover they can't audit a single decision. I have watched teams treat interpretability as a documentation problem — ‘we’ll write it down later’ — when the real problem is structural. The transformation graph is tangled. The original features are consumed. You can't un-mix the polynomial. That sounds fine until a compliance officer asks for one counterfactual explanation and the answer is ‘the model says 0.73, but I can't tell you why in terms a human would recognize.’

Most teams skip this: interpretability is not a feature you bolt on. It's a constraint you design for. AutoFE assumes you don’t care about that constraint, or that you will fix it later with post-hoc tools. Post-hoc tools lie. They lie smoothly, with high R² approximations, and by the time you catch the lie the pipeline is frozen in production. Choose extraction only when the input columns themselves are meaningless — sensor telemetry, embedded vectors, hashed tokens. For anything with a name a human gave it, think twice.

Field note: computer plans crack at handoff.

Patterns That Usually Work (If You're Careful)

PCA with loading analysis for dense numeric data

We fixed a pricing model this way. A hundred raw features from transaction logs—all dense, all numeric. AutoFE with PCA reduced them to twelve components. The team didn't blindly trust the black box. They printed the loading matrix and stared at it for an hour. The first component was clearly 'order size × price tier'; the second, 'customer tenure minus returns'. That's interpretability you can ship.

Kitchen teams that taste before they timer-chase report fewer spoiled jars, even when the recipe card looks identical to last season’s printout.

The catch? You need domain experts willing to read numbers, not just look at dashboards. We flagged components where loadings were spread too evenly—those got discarded. Over three iterations, we killed two components that were pure noise.

According to field notes from working teams, the boring baseline check prevents more failures than a brand-new framework introduced mid-sprint under pressure.

The trade-off: you lose some predictive lift. Usually 3–8%. But the business team can explain the output to auditors. That's worth the hit.

Most teams skip this: they let PCA run, take the top-k components by explained variance, and call it done. Wrong order. You must pair each component with a semantic label. If you can't name it in five words—'seasonal spend burst', 'return-frequency risk'—then that component is a hazard. Quick reality check—I once watched a team pour three weeks into tuning a PCA pipeline only to discover component six was tracking a data-entry bug. They never checked the loadings.

Autoencoders that preserve latent dimension semantics

Autoencoders are not all doom. They can retain interpretability if you constrain the latent space hard. We built one for sensor data—128 noisy signals from factory equipment.

Most teams miss this.

The trick was forcing the bottleneck to exactly six dimensions, then tying each latent neuron to a known physical property via regularization. Temperature drift, vibration amplitude, power draw, duty cycle, torque variance, wear index.

Wrong sequence entirely.

The autoencoder learned to encode each property into its dedicated neuron. That took two weeks of manual loss-tuning and a lot of swearing.

The pitfall is seductive: it feels like magic when it works. Teams start adding more latent dimensions 'just in case'.

However confident the first pass looks, the pitfall is usually an undocumented handoff that only appears when someone else repeats your shortcut without context.

That's how you lose the semantics. One extra neuron and the model distributes 'temperature' across three units.

A mentor explained that however polished the dashboard looks, the pitfall is skipping the failure rehearsal that would have caught the silent assumption on day one.

Flag this for computer: shortcuts cost a day.

Suddenly you can't tell what any of them means. The constraint must be absolute—hard-cap the latent dimensions at the number of interpretable concepts you already know exist. Not more. Not 'we'll figure it out later'. Later you will be debugging shadows.

'We used an autoencoder to compress 400 user-behavior signals into seven latent features. Six had clear meaning. The seventh was 'whatever the model needed to fix its own loss function'.'

— lead ML engineer, mid-size e-commerce team, after a post-mortem

Hybrid pipelines: manual + automated features

This is what we actually use in production. Manual features for the things you understand—domain ratios, business rules, calendar effects. Automated extraction for the rest, but with a fence around it. Concrete example: churn prediction pipeline where we hand-crafted thirty features from subscription history (tenure cliffs, renewal cadence, support-ticket density) and let AutoFE generate another twenty from raw clickstream data. The automated features never touch the manual ones—separate branches, separate models, then a meta-learner that only sees the output probabilities from both sides.

What usually breaks first is the temptation to merge them early. Someone thinks 'more features in one model will capture interactions'. That's how you get a random forest that uses three automated features to cancel out a manual feature you spent a week engineering. Keep them separate. Run ablation tests: remove the automated branch and measure lift. If it's less than 5%, drop it entirely. If it's more, accept that you can't explain the automated branch's internals—but you can explain its contribution to the ensemble. That's good enough for most regulated environments.

The real cost is maintenance. Two pipelines instead of one. Two sets of tests. Two drift monitors. Teams that try this often revert to all-manual within six months because the automated branch starts silently shifting and nobody catches it until a Monday morning alert. You need a dedicated person to watch the automated side. Not a half-assignment. A person.

Anti-Patterns That Make You Revert to Manual

Black-box feature crosses that can't be unmapped

AutoFE loves multiplying columns. You give it ten categorical features, it quietly creates forty interaction terms—and names them col_27_x_col_43. Good luck tracing that back to "customer age × purchase channel" when your model starts flagging weird cohorts. I have watched a team spend two weeks reverse-engineering a single automated cross because the production monitoring system showed a drift alert. They couldn't tell which raw features caused the shift. The auto-extraction tool had no mapping log. That hurts. The fix? Manual naming conventions before any automated step runs—or better, forbid crosses on high-cardinality columns entirely. Otherwise you own a black box you didn't build.

Over-reliance on SHAP after AutoFE (it lies)

SHAP values look crisp and authoritative—until the underlying features are synthetic garbage. Most teams skip this: automated extraction often generates dozens of near-duplicate transformations (log, sqrt, box-cox of the same column). SHAP spreads importance across these correlated copies, diluting the signal of the original feature. You see a bar chart showing five "important" variables. Reality? They're one variable, cloned and obfuscated. Quick reality check—if you sum the SHAP values of all derived copies, does the original feature's real impact become obvious? Usually not. The trap is "interpretability" that actually hides the truth behind a veneer of numeric precision.

"We thought SHAP was the safety net for AutoFE. It turned into a fog machine—thirty decorrelated columns all pointing to the same root cause."

— Lead ML Engineer, mid-2023 post-mortem retrospective

The 'just add more layers' trap

AutoFE tools tempt you with depth controls. "Stack three transformation layers!" they say. That sounds fine until your pipeline includes an automated polynomial expansion, followed by a binning step, then an interaction layer on the binned outputs. The final features have zero semantic relationship to the business. Try explaining to your compliance officer that a model relies on "sqrt(discretized_spend) × bin(age_group)" and you can't tell her what that means. What usually breaks first is debugging: a data error in the raw spend column propagates through three layers, and you can't trace which transformation amplified the mistake. We fixed this by capping transformation depth to one—period. If you need more, write explicit feature functions with unit tests.

Another pattern that forces rollback: automated embedding extraction from high-dimensional text or ID columns. The tool maps 10,000 SKUs into thirty dense vectors, then feeds those into the model alongside engineered features. The result? No human can explain why SKU cluster 14 drives predictions for refund rate. The embedding space is opaque by design, but the auto tool treats it as "interpretable enough." It's not. Most teams revert within two sprints when stakeholders demand to know why a specific product category got penalized. The pragmatic workaround: keep embeddings as a separate ensemble model, not mixed into the main feature set. Let the linear part stay human-readable. Mixing both in one model guarantees neither interpretability nor performance benefits survive intact.

Long-Term Costs Nobody Talks About

Drift detection: you can't monitor what you can't explain

Most teams skip this until the seam blows out. You ship an AutoFE pipeline, performance looks great for six weeks, then accuracy quietly erodes. The model still outputs predictions—so nothing breaks loudly. But when you try to trace why a feature's distribution shifted, you hit a wall. Was it a change in customer behavior, or did the automated transformer silently rename a column? Without a human-readable mapping, every drift alert becomes a forensic investigation. I have seen a senior engineer spend three full days reconstructing what a single 'comp_embed_v7' actually represented. That's not monitoring. That's archaeology. The catch is that explainability tools like SHAP or LIME won't help here—they explain the model's reasoning, not the feature's origin. You need lineage, and AutoFE rarely gives you clean lineage.

Model maintenance: retraining breaks obscure features

The first retrain is usually fine. The second one triggers a warning. By the third retrain, you're staring at a feature set that no living team member fully understands. AutoFE generates features tied to specific data snapshots—a categorical aggregation that only worked because a now-deprecated API field happened to be non-null. When that field disappears, the feature collapses. But it doesn't crash the pipeline; it just silently produces NaNs for 40% of rows. Your model starts outputting the same value for every prediction. Wrong order. Not yet. That hurts. One team I consulted for lost two weeks debugging a 'feature_rank_12' that turned out to encode a join that no longer existed. The fix? Rewrite the entire extraction logic manually. So much for automation savings.

What usually breaks first is the temporal dependency. AutoFE loves creating lag-based features—yesterday's revenue, last week's click rate. But when your data schema shifts slightly—say, a new timezone format—those features become garbage. And because the automated system doesn't flag semantic drift, you discover the problem only when the business asks why last month's predictions were all wrong. The operational drag compounds: each retrain cycle grows longer, debugging sessions get more expensive, and the feature catalog becomes a black box that nobody dares to touch.

Regulatory risk: GDPR's right to explanation becomes impossible

Here is the hard question: can you tell a customer why their loan was rejected, using only AutoFE output? If you cannot trace a decision back to a human-interpretable feature, you're violating Article 22 of GDPR. The right to explanation is not a nice-to-have—it's a legal requirement in many jurisdictions. AutoFE doesn't care. It will happily combine 'age', 'zip_code', and 'transaction_count' into a latent vector that no human can decompress. That vector might be predictive, but it's not defensible. I have sat in compliance reviews where the only answer to "What does this feature mean?" was a shrug.

'Automation that cannot be explained in a courtroom is not automation—it's liability dressed as efficiency.'

— Data governance lead, after a regulatory audit pushed their team back to manual pipelines

Reality check: name the vision owner or stop.

The long-term cost here is not just fines—it's the lost ability to iterate. Once regulators flag your pipeline as opaque, you face mandatory documentation overhead, slower deployment cycles, and external audits. Some teams preemptively revert to manual feature engineering just to stay compliant. That's the irony: AutoFE was supposed to save engineering time, but the compliance drag ends up consuming even more. If your industry touches finance, healthcare, or insurance, ask yourself one question before adopting AutoFE: will this feature survive a deposition? If the answer is no, the automation cost is not worth the speed gain.

When You Should Absolutely Not Use AutoFE

Healthcare Diagnosis: When 'Why' Is a Legal Requirement

A radiologist cannot explain a decision by saying "the neural net saw something." That sounds absurd spelled out—yet teams push automated feature extraction into diagnostic pipelines anyway. In healthcare, the FDA doesn't care about your AUC score; it cares about which features drove the classification. AutoFE often produces hundreds of interaction terms—log-transformed ratios of lab values, polynomial expansions of age × creatinine—that no clinician can sanity-check. I have watched a team spend three months building a sepsis predictor, only to have the validation board reject it because the model flagged a "feature #847" that was actually white noise from a corrupted sensor. You cannot submit a black box discovery to a review board. The cost here is not technical debt—it's patient harm deferred, then realized.

What usually breaks first is the adversarial-rule requirement. Regulators ask: "Which specific attributes caused this patient to be flagged high-risk?" If your pipeline extracted 47 derived columns overnight and the best-performing model used eleven of them, you now need to reconstruct each transformation. Good luck explaining a cubic spline of platelet count to a clinician who has thirty years of experience. The catch—most teams skip this—is that AutoFE doesn't store transformation provenance by default. You get an output matrix and a performance metric. That's it.

'Feature engineering is not a performance hack. It's a documentation problem you solve before you deploy.'

— former clinical AI lead, after a failed audit

Credit Scoring: Adverse Action Notices Need Exact Reasons

Lenders in regulated markets must issue adverse-action letters. Those letters list the exact reasons for denial: "high debt-to-income ratio," "insufficient credit history length." AutoFE doesn't produce reasons—it produces latent combinations. A model trained on auto-generated polynomial features might perform better on holdout data, but how do you write "your interaction between credit utilization and number of inquiries exceeded the 97th percentile of a PCA-transformed manifold"? You don't. You revert to manual features, or you pay legal fines. I have seen a fintech startup try to skirt this by using SHAP values to approximate explanations. A partial explanation is not a legally defensible reason.

The tricky bit is performance pressure. Teams see AutoFE lift Gini coefficients by four points and convince themselves they can "post-hoc explain" their way out. That rarely works — regulators probe for reproducibility, not clever approximation. If every extraction run produces different top features, your adverse-action letters drift quarter over quarter. Consumers notice. Attorneys notice.

High-Stakes Prediction: Any Decision With Human Impact

Wrong order. You should build interpretability before performance optimization, not after. In child welfare screening, criminal justice risk assessment, or eviction prediction, automated extraction is not a tool—it's a liability. The features AutoFE invents often encode population biases that no one intended. A seemingly harmless interaction between "zip code" and "number of service calls" can proxy for redlining patterns. You won't catch it because the feature name is "feat_238_theta." Most teams running AutoFE in production don't audit the extracted feature space for ethical constraints. They cannot — the space is too large and too ephemeral.

Quick reality check: if your prediction can result in someone losing housing, liberty, or medical treatment, you need features that every stakeholder can discuss in plain English. That eliminates 90% of automated extraction methods. The remaining 10% require manual validation that costs more than doing the engineering by hand. So why bother? I have heard the argument that "we'll monitor for drift" — but monitoring tells you a feature changed, not what it means. Meaning is the only thing that matters when a human being challenges the decision.

Open Questions & FAQ: What Teams Ask Too Late

Can post-hoc explainers (LIME, SHAP) fix AutoFE damage?

Short answer: sometimes—but mostly they just tell you what you already knew, in a worse font. LIME and SHAP assume the underlying features are meaningful. When auto-feature extraction has shredded a datetime column into 47 interaction terms, eight polynomial expansions, and a one-hot matrix that looks like a spilled spreadsheet, those explainers start hallucinating importance across garbage dimensions. I have watched a team spend three sprints trying to reconcile SHAP values that pointed to a feature called 'feat_127_interaction_sqrt'—a synthetic column nobody understood. The explainer said it contributed 14% to predictions. Turned out it was July 2023 encoded through some quadratic mess. The fix? They stripped the automated pipeline and rebuilt with seven hand-picked features. Accuracy dropped 2%. Debugging time dropped 70%. That trade-off matters.

The deeper problem is retrofitting. Post-hoc tools map black-box outputs back onto inputs, but they cannot repair broken semantics. You get numbers—not understanding. A team I worked with ran SHAP on an AutoFE model that had merged two categorical columns into a single 1,200-level hash. The explainer flagged the hash as 'high impact' … but the original business logic (region × customer tier) was invisible. They kept the hash and lost the ability to explain a pricing anomaly to their compliance officer. Three months of trust, gone.

'Interpretability is not a dashboard. It's the ability to predict what your model will do before it does it.'

— Staff ML engineer, insurance pricing team (paraphrased from a post-mortem)

How much interpretability is enough? A heuristic

Most teams ask this too late—usually after a stakeholder refuses to sign off. Here is the rough rule I use: if you cannot write down, in three sentences, why any single prediction was made—using actual business terms, not feature names—you have too little interpretability. AutoFE frequently fails this test because it creates features that map to math, not meaning. A cubic spline of churn probability might win you 0.3% AUC. It also makes your model un-auditable. The catch is that 'enough' depends on context. Fraud detection teams I talk to tolerate low interpretability because they have secondary validation loops. Medical-device teams? They revert to manual after one false alarm. Quick reality check—ask your team: 'If the model predicts a 5% customer churn increase, can we explain which product or channel caused it, and why, in under 60 seconds?' If you cannot, AutoFE is costing you trust.

Does AutoFE always hurt? When it's safe

Not always. Here is where I have seen it hold up: high-cardinality categorical data with strong predictive signal but zero business need for explanation—think ad-click prediction, certain anomaly detection logs, or short-lived experimental models. The catch is that 'safe' usually means the model lives in a context where feature semantics are irrelevant. Wrong order. Most teams start with interpretability and later discover a business constraint they missed. That hurts. What usually breaks first is the integration test: the product team wants to know why a user was flagged, and the automated pipeline cannot answer. The honest heuristic: if you plan to keep the model for more than three months, or if any human will ever need to explain a single prediction out loud, don't use aggressive AutoFE. The gains are not worth the silence. Try this next: pick one model you trust, strip all automated features, rebuild with exactly 10 hand-curated columns, and compare explanation time. Bet on the manual version winning every stakeholder review.

Summary & Next Experiments for Your Team

Allocate an Interpretability Budget — Yes, Sprint Points for Manual Checks

Most experienced teams let AutoFE run wild because it feels productive. The real cost hits later — during debugging, compliance review, or when a stakeholder asks why a feature matters. I have seen three-week delays on a single model because nobody could explain the top five automatically extracted features. The fix is boring but effective: reserve 15–20% of your feature engineering sprint points for manual inspection. Treat that time as non-negotiable debt repayment. Assign one engineer to trace the highest-weighted auto-generated features back to raw inputs. If the trace is longer than three hops, flag it. That simple rule catches 80% of interpretability failures before they reach production.

Run a Hybrid Experiment: AutoFE vs Manual on a Holdout Set

Most teams compare pipelines end-to-end — accuracy versus accuracy. That's a trap. Instead, freeze a holdout set before any extraction runs. Then build two feature sets: one fully automated, one entirely manual (or at least human-vetted). Train identical models on each, but measure more than AUC. Track feature stability across time windows, count of uninterpretable interaction terms, and time spent explaining each feature to a non-technical peer. The catch is — AutoFE often wins on raw metrics by 2–5 points, but loses on debugging speed. I watched a team revert to manual after discovering their automated pipeline generated a feature that correlated perfectly with a data leak (a timestamp column the parser should have excluded). That cost two weeks of misdirected optimization.

‘We cut the automated feature count from 847 to 34. Model performance dropped 1.2%. Debug time dropped 70%.’

— Lead ML engineer at a mid-size fintech, post-mortem meeting

Feature Audit: Human-in-the-Loop Review Before Production

What usually breaks first is not the model — it's the story the feature tells. Run a mandatory review gate where a team member outside the modeling group examines each extracted feature and writes a plain-English description. If they cannot, delete the feature or simplify it. This is not about dumbing down; it is about catching the silent destroyers — polynomial combinations that mask confounding, binned variables that lose distributional meaning, or embeddings that encode protected attributes. The audit should happen after extraction but before training. Wrong order — auditing after training — means you justify bad choices instead of fixing them. One concrete anecdote: a team I consulted had a feature that combined ZIP code and transaction frequency into a single interaction term. It boosted F1 by 0.03. It also encoded income proxy, violating internal policy. The audit caught it in 15 minutes. Reverting cost 45 minutes. That is the trade-off: a small up-front chore versus a catastrophic rollback later.

Try this next week: pick one model currently in development. Extract features both ways — full AutoFE and a constrained manual set. Compare the explainability time per feature. The gap will shock you. Then decide whether that gap matters for your compliance, debugging, or stakeholder trust. Most teams find that it matters more than the accuracy lift.