Building and managing a comp approval matrix

A delegation-of-authority matrix is only as good as the discipline behind building it. This is the hands-on companion to the concept — how to actually author, override, and maintain the matrix without writing a line of code.

If you want the conceptual grounding first — what a delegation-of-authority (DOA) matrix is and why comp governance needs one — start with our explainer on the DOA matrix for casino comps. This guide assumes you are past that and ready to build. The aim is a matrix that centralises comp authority across every department and property, and that keeps holding as people move, roles change, and policy evolves.

Start from the org, not a spreadsheet

The instinct is to open a spreadsheet and list every person who can approve a comp. Resist it. A named list of people is stale the day someone is promoted, goes on leave, or transfers between properties — and the moment it is stale, it is a liability rather than a control.

AEGIS resolves the matrix at runtime against a live org chart. You define authority by role, and it follows the people who hold that role. Promote a host to VP Player Development and their authority changes automatically, because the matrix was never bound to their name in the first place. Delegation covers leave, and a licensing registry ensures authority is only ever exercised by credentialled staff. You are authorising positions in the organisation, not individuals — which is what keeps the matrix true over time.

The building blocks

Every rule in the matrix is four fields: role → comp type → dollar limit → on-exceed action. The on-exceed action is either Escalate (climb the reporting line until someone's authority covers the amount) or Hold for review (route the request for review rather than approve it). That is the whole grammar. A worked example of authority limits:

Read it as a ladder. A host approves within $5,000; a request above that escalates to VP Player Development, then SVP Marketing, and so on up the reporting line until it meets a role whose limit covers it. At the top, even the IR President's ceiling ends in a Hold for review rather than a silent approval — the largest comps stop for a human, by design.

Enterprise and property overrides

Few operators run a single property, and few want identical limits everywhere. AEGIS handles this with an enterprise→property hierarchy. Set a rule once at the enterprise level, then tighten it at a single property with an override. The most specific rule in force wins.

The practical effect: the same comp can ALLOW at the flagship, where the enterprise limit stands, and ESCALATE at a sister property where a stricter override binds. You are not maintaining a separate matrix per property — you are maintaining one matrix with local exceptions, and the engine resolves which rule applies to each request.

Publish with confidence

The reason the matrix is versioned data rather than code is that it lets you answer an honest question before you commit to a change: what would this actually do? Because AEGIS resolves decisions deterministically, you can simulate a proposed matrix change against months of real historical comp volume before you publish it — and see precisely which past decisions would have come out differently under the new rules.

That turns a policy change from a leap of faith into a measured one. Tightening a host's limit reads as an abstract idea until you see it would have escalated 40 real comps last quarter; then it is a decision you can defend. And once published, every decision records the exact matrix version in force, so there is never ambiguity about which rules governed a given approval.

Change management: versions, not edits

Maintaining the matrix is where most governance systems quietly fail — someone edits a limit, no one records why, and six months later no one can reconstruct what the rules were on the night in question. AEGIS closes that gap by treating the matrix as versioned: nothing is silently overwritten. A change creates a new version; the previous one is preserved.

That is what makes deterministic replay possible. You can take any historical decision and replay it against the exact rules in force at the time — not today's rules — using the AEGIS CLI to inspect versions and walk through the decision. When Finance, Audit, or a regulator asks "why was this approved?", the answer is not a memory or a meeting; it is the version, the rule, and the reporting line, reproduced on demand. Every decision is sealed to an immutable audit trail that carries the matrix version with it.

Built this way, the matrix stops being a document that decays and becomes a live service — one you can change deliberately, prove continuously, and hand to an auditor without a scramble. For the record-keeping side of that discipline, see our guide on building a defensible audit trail for comp approvals.