Skip to content

Role Compatibility Check

Pre-appointment screening procedure — instantiates Role Expectation Architecture

A pre-appointment screen that tests a proposed role assignment against the role's competence bar and against conflict and separation constraints, before the assignment is made.

A Role Compatibility Check is the gate a proposed assignment passes through before it becomes real. Its defining move is to evaluate the pairing — this holder, taking this role, given everything else they already hold — rather than the role in isolation. It tests two things at once: whether the candidate meets the role's competence and eligibility conditions, and whether their other roles and interests create an incompatible combination. Because it runs ex ante, it is distinct from every standing mechanism around it: a position description defines the competence bar, a conflict-of-interest disclosure surfaces conflicts on an ongoing basis — the compatibility check is the pass / fail / conditional screen at the moment of proposed appointment.

Example

An enterprise IT team is about to grant a finance-system user a new access role. The proposed grant is Approve Payments; the automated compatibility check reads the user's existing roles and finds they already hold Create Vendor. It flags the pairing as a segregation-of-duties violation — one person who can both create a vendor and approve its payments could stand up a fake supplier and pay it — and blocks the grant until either a different assignee is chosen or a compensating control (a second approver) is attached.[1]

The conflict is caught while it is still cheap — a line item in an access request — rather than after it is live and has to be discovered in an audit or a loss. Nothing about the individual's honesty is asserted; the check simply refuses to let one seat concentrate two powers that are supposed to be held apart.

How it works

  • Take the pairing, not the role. The unit examined is a specific (role, holder) proposal, evaluated against the holder's existing portfolio of roles and interests.
  • Test the competence gate. Check whether the proposed holder satisfies the eligibility and competence conditions the role requires.
  • Test the separation constraints. Check the pairing against encoded conflict and separation-of-duties rules — the "toxic combinations" that must not sit in one seat.
  • Return a verdict. Pass, fail, or conditional-with-compensating-control — a decision the appointment process can act on, made before the seat is filled.

Tuning parameters

  • Constraint set — which incompatibilities are encoded (separation pairs, independence rules, capacity limits). A richer set catches more but produces more false blocks.
  • Strictness and override — a hard block versus flag-and-allow-with-justification. Hard is safe and rigid; soft is flexible and leaks.
  • Automation — manual review versus a rules engine. Automation scales but only catches what has been encoded; a novel conflict passes silently.
  • Portfolio scope — whether the check examines only this system's roles or the holder's whole cross-domain portfolio. Wider scope catches conflicts that span systems, at the cost of data and effort.
  • Re-check timing — screened once at appointment, or re-run whenever the holder's other roles change. Re-checking catches conflicts that form later; one-shot is cheaper and goes stale.

When it helps, and when it misleads

Its strength is that it catches gaps, overlaps, and conflicts before they go live, when they are still a cheap edit to a proposal rather than an exposure to unwind. It converts "these roles feel incompatible" from a judgment call into an explicit, repeatable test.

Its failure modes follow from that same explicitness. The check is only as good as its encoded constraints: an un-encoded conflict sails through and, worse, the green light lends false assurance that the pairing was vetted. Set too strict, it blocks legitimate combinations in small organizations where one person must genuinely wear several hats. And the classic misuse is to run it to ratify an assignment already decided — quietly tuning the constraint set or granting an override until the favoured pairing passes. The discipline that keeps it honest is to keep the constraint set audited and current, log every override with its justification, and pair the ex-ante screen with ongoing disclosure for the conflicts that only emerge after someone is in the seat.

How it implements the components

This procedure fills the pre-appointment screening slice of the archetype — testing fit and separation before a seat is filled:

  • eligibility_and_competence_conditions — tests whether the proposed holder meets the role's competence and eligibility bar, applying the conditions the Position Description or Office Mandate defines.
  • role_conflict_and_interest_guard — tests the pairing against separation-of-duties and conflict constraints, blocking combinations that concentrate incompatible powers in one seat.

It applies the competence bar but does not define it (that is the Position Description or Office Mandate), and it screens for conflict once at appointment but does not run the ongoing conflict register (that is Conflict-of-Interest Disclosure); it is the gate, not the standing monitor.

Notes

The check and the Conflict-of-Interest Disclosure both guard against conflict, but at opposite ends of the timeline: the check is an ex-ante gate that can refuse an appointment, while disclosure is a standing declaration that surfaces interests as they arise once someone is already in post. Neither substitutes for the other — a pairing that was clean at appointment can develop a conflict later, and only the ongoing register will catch it.

References

[1] Segregation of duties — the control principle that no single individual should hold two responsibilities whose combination enables error or fraud (for example, creating a vendor and approving its payments). Compatibility checks in access governance are largely built to enforce it, which is why it anchors the example. ↩