Most platforms treat data quality as an assumed property of whatever's connected. Zluri treats it as seven separate, checkable properties, each with its own mechanism. A dataset can fail on any one of these while looking fine on the rest, which is exactly why each needs independent attention.
Data hygiene gets discussed loosely, as though "good data" is a single quality a platform either has or doesn't. In practice it's seven genuinely distinct properties, each with its own failure mode and its own fix:
- Accuracy — a data point reflects reality correctly right now, not just that some source reported something at some point.
- Completeness — nothing relevant is missing from the picture, not just that a lot of data exists.
- Traceability — a specific figure can be followed back to exactly where it originated and verified.
- Timeliness — the picture is current, not just that it was once correct.
- Consistency — the same underlying fact looks the same everywhere it appears.
- Validity — a record actually conforms to defined structure before its content is even worth evaluating.
- Integrity — the relationships connecting records stay meaningful as the records themselves change.
A platform can genuinely satisfy several of these while quietly failing one. This piece goes through all seven dimensions separately.
Accuracy: resolving conflicts rather than picking arbitrarily
Accuracy fails most often not because a source is lying, but because multiple sources disagree about the same fact and something has to decide which one is right.
Source priority hierarchy
Zluri's source priority hierarchy exists specifically for this. When sources conflict, they're resolved in this order:
- Manual entry or Workflow (highest priority)
- Direct Integration
- SSO
- Indirect Integration
- Browser or Desktop Agents
Whichever source was detected first wins ties within the same tier.
This isn't an arbitrary tiebreaker; it reflects a real accuracy judgment. A direct integration reports genuine usage data, while an SSO frequently reports status based on a single login or active token rather than continuous activity, which is precisely why direct integration outranks it when both are available for the same application.
In practice: an account showing Active despite no real use in over a month is almost always an SSO-sourced status inferred from a login event rather than ongoing activity. The fix, connecting a direct integration where one exists, is an accuracy fix specifically, not a completeness or traceability one.
The Account Type override rule
Account Type classification carries its own accuracy-preserving rule worth knowing precisely: a manual override to an account's type gets silently reverted on the next sync unless one of two conditions holds:
- That account's primary source is already Manual, or
- No backend configuration governs that classification at all
This prevents a one-off manual correction from creating a false sense that a systemic accuracy issue has actually been fixed, when the underlying rule will just override it again.
Name normalization and merging duplicates
Two mechanisms exist specifically to prevent a different kind of accuracy failure: fragmentation, where one real application ends up recorded as two.
- Name normalization strips special characters from incoming application names before matching, so "Slack" and "Slack #" aren't treated as two different applications purely because of a formatting quirk in how one integration reported the name.
- User and Application Merge is the direct correction mechanism when fragmentation has already happened. It consolidates what should have been one record into one, with the target record's own attributes explicitly protected from being overwritten by whatever the merged-in record brought with it.
Completeness: knowing what's actually missing, not just having more data
Completeness is a different failure mode entirely. A dataset can be perfectly accurate about everything it contains and still be dangerously incomplete if entire categories of application or identity never entered it in the first place.
Eight discovery sources, not one
This is exactly why Zluri pulls from eight distinct discovery sources rather than treating any single source as sufficient:
- SSOs
- Direct integrations
- Manual entry
- Transactions
- Agents
- MDMs
- CASBs
- Plugins
Each source is specifically good at catching a different adoption pattern. Relying on SSO alone, the most common single-source approach, structurally misses exactly the shadow IT adoption pattern that never touches SSO federation at all.
Gaps that hide inside a single, connected source
Completeness gaps exist even within one well-connected source, which is a subtler point worth naming directly.
User discovery through certain identity providers depends on whether that specific source supports both a List of Usersfolder and a separate Activities folder:
- Azure, OneLogin, and Okta support both.
- Google Workspace and JumpCloud don't.
A user discovered purely through an Activities folder, with no corresponding List of Users entry, starts out marked Inactive regardless of their real status. That's a completeness gap hiding inside what looks like a fully connected, single-source integration.
Custom Permissions
Custom Permissions address a related completeness gap on the entitlement side: filling in granular role and permission data manually for applications whose integration doesn't supply it natively. This exists specifically so the absence of that data doesn't get quietly treated as "this application has no meaningful entitlements to track," when the real story is simply that the API doesn't expose them.
Traceability: knowing where a specific number actually came from
This is the dimension that most directly determines whether a number can be trusted under scrutiny, in an audit, a dispute, or just a reasonable question about why a figure looks the way it does.
The baseline mechanics:
- Every identity attribute traces back to a specific primary source, visible and reviewable, not just a value sitting in a field with no record of its origin.
- Every application shows its full Sources column, every detection channel that's actually contributed to that record, expandable when there are more than a few.
- Every application carries a Discovery Date, an actual timestamp for when it first entered the system, rather than an assumed "it's always been there."
Two mechanics deserve specific attention because they represent traceability done unusually well.
Dated groups for license changes
When a license quantity changes through an API-detected increase, Zluri creates a new, dated group rather than silently overwriting the existing number in place. The full history of how a license's quantity actually grew over a contract's term stays reconstructable at any later point, not just the current total with no record of how it got there.
Cost vs. Spend, kept deliberately separate
- Cost is a derived calculation from contract terms.
- Spend is sourced directly from actual recorded transactions.
Keeping them separate rather than collapsing them into one number is itself a traceability practice: it preserves the distinction between a figure that's computed and one that's directly sourced from a real financial record.
Version History, Run Logs, and Audit Logs
At the governance level:
- Version History captures a full configuration snapshot at every policy publish, not just a diff describing what changed: author, timestamp, and the complete Basics, Scope, Rules, and Remediation state exactly as it stood at that version.
- Run Logs and Audit Logs tie every action, a provisioning event, a policy enforcement, an exemption grant, back to a specific trigger, actor, and timestamp.
Together, these are what make "why does this record show this value" an answerable question rather than a shrug.
Timeliness: data that was accurate then isn't the same as data that's accurate now
This is a genuinely distinct property from accuracy, worth separating out explicitly. Accuracy asks whether a data point correctly reflected reality at the moment it was recorded. Timeliness asks whether it still does, right now. A status resolved correctly last month can be badly out of date today if nothing refreshes it.
- Continuous discovery, not a single batch sync. Zluri's discovery model runs continuously across its source types rather than depending on one infrequent sync.
- Rolling windows for usage-based figures. Thresholds behind Unused and Underused license detection are calculated against defined, rolling windows (30, 60, or 90 days), specifically so "current" has an actual, current meaning rather than reflecting whatever the data happened to look like at some arbitrary point in the past.
Worth being honest about the real limits here too: Zero Touch Provisioning's HR sync, for instance, pulls hire-date data once daily at a fixed time. Even a continuously-run system has specific, known points where freshness has a real ceiling, not an instantaneous, always-current guarantee.
Consistency: the same fact represented the same way everywhere
Consistency is about whether an identical underlying fact gets represented identically across every place it shows up, rather than drifting into slightly different forms depending on which source or workflow touched it last.
- Name normalization prevents "Slack" and "Slack #" from being treated as two different facts purely due to formatting inconsistency between sources, the same mechanism from the accuracy section, doing consistency work here.
- One classification method per integration. Account Type classification is limited to one method per integration, rather than allowing a raw-data-field rule and a group-membership rule to both apply to the same source simultaneously. This prevents the same identity from being classified by two potentially conflicting logics at once.
- Cost and Spend, defined once, used the same way everywhere. Keeping the two as consistently, distinctly defined terms, one computed, one transaction-sourced, used identically in every report rather than occasionally conflated, is consistency applied to definitions themselves, not just to individual records.
Validity: data that actually conforms to the rules before it's trusted
Validity is a precondition accuracy depends on, and it's worth separating the two clearly. A record can be perfectly valid, every required field populated, every value in the correct format, and still be factually wrong. But a record that isn't valid at all can't be accurate in any meaningful sense, since there's nothing there to evaluate.
Zluri enforces this at the point of creation rather than as a cleanup task for later:
- Primary Owner is a required field when a Subscription, Contract, or Perpetual is set up.
- Vendor association is required on every contract.
These records can't exist in an incomplete, ownerless, or vendor-less state in the first place.
Permission Type is similarly constrained to a defined set of categories, Create, Read, Update, Delete, Admin, rather than open free text. That constraint is what makes it possible to actually calculate threat scoring consistently off that field, something free text could never reliably support.
Integrity: relationships that don't quietly break when what they point to changes
Integrity is specifically about whether relationships between records stay valid as the underlying records themselves change, rather than silently pointing at something that no longer meaningfully exists.
When two user accounts merge, these all transfer automatically to the surviving record, rather than continuing to point at an account that's been consolidated away:
- Application Owner
- IT Owner
- Financial Owner
- Contract-level ownership
- Vendor Owner
Without this, ownership data would technically still exist but reference something no longer functionally there, a relationship that's broken in practice even if the field itself still shows a name.
The deliberate exception: Negotiation Owner does not transfer automatically. That's itself an integrity-aware decision, not an oversight, it recognizes that blindly reassigning a relationship that wouldn't actually be valid for the new owner is worse than leaving it for a person to decide explicitly.
Active correction, not passive display
Underneath all seven properties above is one structural choice worth naming directly. Most platforms, once they've pulled a data point from a connected source, treat their job as finished: display it, trust it, move on. If two sources disagree, or a record has quietly fragmented into duplicates, or a manual fix gets silently reverted on the next sync, nothing in a passive architecture is actually watching for that, because nothing was built to.
Zluri's data layer is built to actively catch and correct these failures rather than just surface whatever a source last reported. This is exactly what the mechanisms covered above actually are, not isolated features, but a consistent pattern of active correction:
- Conflicting data doesn't get accepted from whichever source answered first. The source priority hierarchy resolves it according to which source is actually more likely to be right for that specific data point.
- Fragmented records don't stay fragmented. Name normalization prevents most fragmentation before it happens, and User and Application Merge catches and corrects it when it does.
- Manual corrections don't get silently overwritten. The Account Type override rule explicitly governs when a manual fix is allowed to hold against the next sync, rather than leaving that to chance.
- Relationships don't quietly dangle. Ownership fields transfer automatically on merge instead of continuing to point at a record that no longer functionally exists.
This is the difference between a platform that runs correctly on bad data and one that's actively verifying its data before anything runs on it. A passive platform will display a stale, login-inferred status with the same confidence as a status backed by real usage data, because nothing in its architecture is designed to tell the difference. An active model treats correctness as something the platform is responsible for producing, not something the customer discovers by noticing a number looks wrong.
Why all seven properties have to be checked independently
A dataset can fail in ways that pass most of these checks while quietly failing one, which is exactly why treating "data hygiene" as a single property misses real, distinct risks.
- Accurate + complete + traceable, but not timely: every fact was correct when recorded and its origin is fully documented, but nothing has refreshed it in months, so it's a faithful record of a reality that no longer holds.
- Valid + consistent, but not accurate: every record has its required fields populated in a uniform format, but the actual values are simply wrong.
- Accurate + valid, but lacking integrity: individual records are each correct in isolation, but the relationships connecting them, an ownership field, a merged account reference, point at something that no longer functions the way the field implies.
Genuine data hygiene requires all seven properties holding at once. A platform that only optimizes for the one or two most visible, typically completeness and accuracy, without equal attention to timeliness, consistency, validity, and integrity, produces a dataset that looks trustworthy on the dimensions people usually check while still failing in ways that only surface when someone needs to rely on it under real pressure.
Why this is the foundation underneath everything else
This connects directly to two categories of platform failure covered elsewhere in this series:
- The governance-workflow data problems that plague IGA platforms, fragmented records, missing entitlement catalogs, are fundamentally completeness and accuracy failures at their root.
- The risk-scoring data problems that plague identity security platforms, usage-free entitlement scans, context-free alerts, are fundamentally traceability and completeness failures. A risk score with no usage context attached is a number that exists without a traceable link to the activity data that would make it actionable.
Data hygiene isn't a separate concern from either of those problems. It's the underlying discipline that determines whether either one can actually be solved at all.
Frequently Asked Questions
Can a dataset be complete but still untrustworthy?
Yes, and this is a real, common failure mode. Every application and identity that exists might be discovered and represented, but if the underlying status values are stale or inferred incorrectly, or there's no way to trace a specific figure back to its actual source, completeness alone doesn't make the data trustworthy under real scrutiny.
Why does an account sometimes show as Active when nobody's actually used it in weeks?
This is almost always an accuracy issue tied to source priority specifically, an SSO-derived status inferred from a login or active token rather than genuine ongoing usage. Connecting a direct integration, which reports real activity data, is the direct fix, and it's worth knowing this is an accuracy problem, not a completeness or traceability one.
What makes the Cost versus Spend distinction a traceability practice specifically?
Because the two figures trace back to genuinely different origins, Cost is calculated from contract terms, Spend is sourced from actual transaction records, and keeping them as separate, distinctly labeled figures preserves the ability to know which kind of number you're actually looking at, rather than collapsing both into one undifferentiated "cost" figure with no way to tell whether it's computed or directly sourced.
Is completeness just about connecting more data sources?
Not entirely. More sources help, but completeness gaps can exist even within a single, well-connected source, depending on which specific data folders that source actually supports. Genuine completeness means understanding exactly what a given source can and can't see, not just adding sources and assuming the aggregate result is automatically comprehensive.
What's the actual difference between accuracy and validity?
Validity is a precondition: whether a record conforms to defined structure at all, every required field populated, values in the correct format. Accuracy is about whether the actual content is correct. A record can be fully valid, everything present and properly formatted, while still containing the wrong information, which is exactly why the two need to be checked as separate properties rather than treated as one.
Why does timeliness matter separately from accuracy if a data point was correct when it was recorded?
Because a fact that was true when captured can become false without the record ever being touched again, someone leaves the organization, a certification lapses, a status changes. Accuracy asks whether a data point reflected reality at the moment it was recorded; timeliness asks whether it still does right now, and a system that only checks the former can confidently display something that's been wrong for months.
How does referential integrity actually break in practice if nothing explicitly deletes a record?
Most commonly through a merge or consolidation event, when one record gets folded into another and anything still pointing at the old record, an ownership field, an assigned reviewer, effectively references something that no longer functions as expected. Automatically transferring those relationships to the surviving record during a merge is what prevents this specific kind of quiet breakage.
.svg)
