Delegation-of-Authority Matrix Builder & Routing Simulator

The problem this kills

Your delegation-of-authority matrix decides who can approve what: a $5,000 IT purchase routes to the department manager, a $50,000 capital request needs the VP, anything over $250,000 needs the CFO — and when the director is on vacation, their delegate stands in. In most companies this lives in a fragile spreadsheet that nobody fully trusts. People aren't sure it's current. Nobody can tell you, with confidence, where a given request will actually land. And the scariest part: when someone edits a row to fix one thing, they have no idea what else they just broke for everyone downstream.

So policy changes happen by nervous guesswork. A controller tweaks a limit, crosses their fingers, and finds out it was wrong only when a $300,000 request silently routes to a manager who never had the authority — or worse, routes to nobody because the edited row no longer matches any rule.

You need a place to author the matrix safely, see exactly who a request would route to before you change anything, and publish changes as clean, dated versions that downstream tools read — with a real human signing off and a full history you can defend.

What you'll build

A small, private web app that turns your scary spreadsheet into a governed source of truth:

• Import your current matrix (rows of conditions → approver chain), your approver roster with titles and limits, your category and cost-center lists, and your delegation / out-of-office overrides.
• Edit rules in a guarded draft UI that catches problems as you type — gaps (a request that would match no rule), conflicts (two rules that disagree on the chain), and broken chains (an approver who doesn't exist or whose limit doesn't cover the band).
• Simulate any request: type in an amount, category, and cost center and instantly see the exact approver chain it would route to — against the draft and against the live version, side by side, so you can see precisely what your change does.
• Compare draft vs live across a set of sample requests, so you can prove the change before it goes anywhere near production.
• Publish — only a policy owner can promote a draft to a new numbered version with an effective date. Until then, draft edits never affect live routing.
• Serve the active version to your downstream tools via a read endpoint and a clean CSV export.

Crucially, this tool defines and tests routing — it doesn't replace your purchasing system. It is the authoritative rulebook your other tools (or people) read from.

What's inside the Implementation Plan

The plan is a complete, paste-and-go runbook for an AI coding agent. The very first thing it does is interview you about your business — how your approvals are structured today, the exact fields and naming in your matrix and roster, how limits and bands work, how delegations are recorded, and the messy exceptions that trip up your current process. It reflects a short tailored spec back to you and waits for your thumbs-up before it builds anything, so the tool models your routing logic — not a generic template.

From there it walks you, step by step, through:

• Standing up the Next.js app, Supabase database, and login.
• Designing the data model around your conditions, chains, roster, categories, and cost centers.
• Importing your current matrix, roster, and overrides (with a duplicate guard on rule signatures).
• The guarded rule editor with live gap / conflict / broken-chain validation.
• The routing simulator and the draft-vs-live comparison.
• The policy owner's publish gate, version history with effective dates, and the downstream read endpoint + CSV export.

Every build step ends with a ready-to-copy prompt you paste into your agent.

The governance it includes (this is the point)

This isn't a throwaway script — it governs who can spend your company's money, so it's built like it:

• Login so only your policy team can open it.
• Row-level security so each organization only ever sees its own matrix, roster, and versions.
• A complete audit trail — who edited which rule, who ran which simulation, and who published which version, with timestamps.
• A human-in-the-loop publish gate: edits live in a draft and never change live routing until a designated policy owner reviews, signs off, and publishes a new version.
• Duplicate guards — a rule signature (a hash of its conditions) so the same rule can't be entered twice, and an enforced, sequential matrix version number on every publish.

Who it's for

Procurement managers and finance controllers who own approval policy and are tired of a spreadsheet nobody trusts. If you can describe your approval rules and pull a CSV of your matrix and roster, you can build this — no developer required.

You've got this. Open the Implementation Plan, paste the first prompt, and let the agent interview you.