Redundant fields

Redundancy grouping tells you which of your selected fields are saying the same thing.

What it represents

The Redundant fields block sits inside the diagnostics wall on the wizard’s Review and Train step, under the per-field table. Each card names two of your selected fields, says how closely they track each other, and suggests removing one.

The cost of leaving duplicates in is not really accuracy, it is readability. The model can split on either copy, so the credit for one real signal gets spread across two or three rows in your feature table. Company size stops looking like your top driver and starts looking like three mid-table fields.

Nothing is removed for you. The cards are advisory, and the fields you selected are the fields that train.

How it’s calculated

At dataset refresh, ax1om correlates your numeric fields against each other on the assembled data, ranks the candidates by how well populated they are, and reports every pair whose correlation clears the threshold, strongest pair first.

Two consequences are worth knowing. The block is numeric only, so two date fields tracking the same event or two picklists that always move together will not appear here. And it reports pairs rather than groups, so one real signal carried by three fields shows up as more than one card, with the same field named twice.

Read a card and decide

1. Press Run diagnostics and find the block

   Redundant fields renders between the per-field table and Recommendations. It is absent when there is nothing to report, which is the common case and means nothing is wrong.

   Read it in the same pass as the rest of the wall rather than coming back to it. Every fix here sends you back to the Data step, and you want to make all of those in one trip.

2. Read the pair, then say what they have in common out loud

   Each card names two fields and the strength of the link between them. Annual revenue and employee count are two views of company size. Created date and first activity date are two views of when the record arrived.

   If you cannot name the one thing they share, the link may be an artifact of your data rather than a real duplicate, and the safe move is to leave both in.

3. Pick which one to keep

   Three tiebreaks, in order. Keep the better populated field, because the thin one will be missing more often on live records. Keep the one your team actually maintains. Keep the one you would be willing to explain in a pipeline review.

   Check the fill percentage on the Pop column of the per-field table above, or on the row in Selected Fields & Health. It is usually decisive on its own.

4. Remove the other one on the Data step

   Go back to step 1 and untick it in Available fields, or use the remove control on its row in Selected Fields & Health.

   Remove one field per card, not both. The point is to keep the signal and drop the copy · dropping both takes the signal out with it.

5. Re-run diagnostics and read the table again

   Press Re-run Diagnostics. The block should shrink, and the field you kept should sit higher in the per-field table than either did before.

   If a card involving the field you kept survives, it has a third partner. Work the cards until each real signal is carried by one field.

6. Know when to skip all of this

   Leave the pair alone when you only care about the sorted list, the model performs, and nobody is reading the feature breakdown.

   Prune when someone has to explain the drivers, or when the duplicate is thinly populated and will be missing in production more often than the field it duplicates.

What it means for you

Read the block as a floor rather than a guarantee. It looks at numeric fields on the assembled data, so an empty section means no numeric pair cleared the threshold, not that your selection holds no duplicates. The categorical copies of one value, and the second date field for the same event, are still yours to spot.

Pruning also changes what the feature table says about your model, which is usually the reason to bother. A single well-populated field carrying a signal reads as one driver. The same signal split across three fields reads as three ordinary ones, and the person you are showing it to draws the wrong conclusion.

Check your understanding

The block shows two cards: annual_revenue and employee_count at 0.91, then annual_revenue and total_contacts at 0.87. All three are views of company size. annual_revenue is the best populated of the three, so you keep it, remove the other two on the Data step, and re-run.

Read that back against the cards. Two cards, one real signal · annual_revenue appeared in both, which is what told you they were the same story rather than two separate pairs. Ranking quality is likely to land about where it was. The feature table is the part that changes: company size shows up once, as itself.