By Edris Yaghob//3 min read
Cut your critical data element list in half, and defend every field that's left
A short critical data element list is the only one you can defend. Here is how one team cut theirs from 60 fields to 20 in an afternoon, using a single question, and never missed the rest.
A steward I worked with had a list of 60 critical data elements for her workforce and payroll domain. It was neat. It was colour-coded. It had survived two audits. And she did not trust a single thing about it.
That is where most critical data element lists live: long, tidy, and quietly useless. Hers got cut to 20 in an afternoon. Here is how, and why nobody missed the other 40.
The list nobody could defend
The 60 fields were real. Employee email, manager ID, office location, last login, system role, tax classification, start date, cost centre. Each had reached the list the same way: someone in a workshop said "we need that," and it got added. The list grew by addition. Nothing had ever been removed, because removing a field felt riskier than keeping it.
So it kept growing, and every field on it carried the same governance weight. The tax classification that drives payroll sat next to the office location that drives nothing. Both labelled critical. Both treated the same.
One question, asked sixty times
We did not start with a framework. We started with one sentence, asked about each field:
If this is missing, wrong, or stale, what specifically breaks?
Not "it is important for reporting." Something concrete, with a name attached. Whose decision fails. Whose phone rings.
For tax classification the answer came fast: withholding is calculated at the wrong rate, the year-end statement does not match the tax authority, the head of payroll loses a week to corrections. That field stays.
For office location, the honest answer was a shrug. Useful for a facilities report. Nothing decides anything on it that breaks if it is a month out of date. Not critical. Adjacent.
We went field by field. It was slower than it sounds, because each answer had to be real, and a few were uncomfortable.
Where the other forty went
By the end, 20 fields could finish the sentence with a concrete consequence. The other 40 were not deleted from the universe. They moved:
- Some were operational metadata, useful for running a system, not load-bearing for a decision. They went to system administration.
- Some belonged to a different process, like access management, and got governed there instead.
- A handful were on the list only because a senior stakeholder had asked, once, in a meeting. Those quietly came off.
Why the short list is the defensible one
The relief was not just having less to do. It was that every field left could be defended in one sentence. When a project lead later said "you should add this element," she had a test instead of an argument: finish the sentence, name the consequence. If they could, it earned a place. If they could not, it did not. The conversation got shorter every time.
A list built by addition can never be defended, because nothing on it had to earn its way on. A list built by the consequence test defends itself.
The catch
Doing this for one field is easy. Doing it honestly across 60, holding the politics of removing inherited fields, resisting the pull of "but it is in a regulatory report," and keeping the test consistent when you are tired, is the hard part. Most stewards drift back to the long list within a quarter.
That is the work enabledat was built to hold with you: it walks each element through the test, keeps you honest, and rejects the ones that cannot earn their place. You bring the domain knowledge. It keeps the discipline.
Sixty fields became twenty. Nobody missed the rest.