Read/Write Parity

What happens when provisioning mappings and account rules drift apart, and how the platform catches it.

The problem

A classic IGA foot-gun: the read path (classification and ownership rules) and the write path (provisioning mappings and native filters) become asymmetric over time. The result: the platform creates accounts that it can no longer correlate or even see.

⚠ Note

This is not a bug you fix once — it is a continuous invariant. Every change to a rule OR a mapping requires you to check the other side as well. That is why RapidValue materializes this as an advisor detector plus an on-create probe.

The 5 sub-checks

AccountRuleProvisioningMismatchDetector bundles 5 parity checks into a single advisory. payload.subkind discriminates between them:

select_missing_field — ownership reads attributes.userPrincipalName but the object's $select does not retrieve it. 100% orphans.
identity_field_missing — a rule references identity.attributes.employee_id but no HR sync produces it. 100% orphans on the identity side.
filter_excludes_classification — native_filter='userType eq Guest' but the rule says userType equals 'Member'. 0% match.
self_blinding_write — the write-mapping sets userType='Member' but the type's filter is userType eq 'Guest' → the platform creates accounts it then never sees again. CRITICAL severity.
roundtrip_identifier_mismatch — the write correlates via field A but ownership reads field B → ownership fails on accounts the platform created itself.

The three gates we built

Daily sweep detector — surfaces existing mismatches across your whole tenant. Enabled from day one.
On-create probe — runs synchronously after every successful provisioning create. A mismatch produces a CRITICAL recommendation immediately.
Wizard pre-fill hint — shows a ⚠ banner plus a "Rule check" column in the PROVISIONING_CONFIG_REVIEW step when a write-mapping is incompatible with the seeded ownership rule. A frictionless correction moment before activation.

No auto-fix — by design

The detector's apply() always returns success=False. Every mismatch calls for a configuration choice (which field to rename, which convention to follow) that only the administrator can make — an auto-fix could silently choose the wrong side.

Further reading: