Decision authority map
Responsibility for delivering the proposed solution does not give the FDE team authority over every dependency. This map assigns each decision to the role that can make it, names the person holding that role, and records what they must contribute. It is a list of decision responsibilities, not a list of separate hires.
- Enterprise
- Prepared by
- Date
- Version
Source: article two, "Assign each decision to the authority that can make it".
Who fills this in, and what it decides
The FDE lead drafts it from the dependencies in the engagement brief. Each named person confirms their own row: nobody can be assigned a decision without agreeing to hold it. The practice lead records the result. The map feeds three later decisions: where the practice sits, because its home must keep routes to these people open; the release decision, which needs the release authority and incident route named before production; and any escalation, which section 3 records.
One person may hold several roles in a small business unit. A large enterprise may require independent control assessment for some data or release decisions; the last column records where that applies.
Roles named in this document:
- Business workflow owner
- owns the process and the meaning of a useful result. In the specimen, the banking workflow owner.
- Data and control owner
- decides whether source data may be used, and under which conditions.
- Method owner
- defines what counts as a valid result. In the specimen, the valuation or risk owner.
- FDE lead
- owns delivery evidence and, until transfer, the build and maintenance of the solution.
- Platform product owner
- owns the shared AI primitives and their maintenance commitments.
- Release authority
- approves production use on technical, business, control, and operational evidence.
- Service owner
- operates the solution after the engagement, with the business workflow owner.
1. Reference map for the screening specimen
The specimen is hypothetical. It shows the level of precision each row needs.
| Decision | Accountable role | Required contribution |
|---|---|---|
| Define the screening result and supported cases | Banking workflow owner | Process boundary, acceptance criteria, and authority to change the screening procedure |
| Decide whether source data may be used | Data and control owner | Purpose, identities, fields, retention, and approved processing conditions |
| Define what counts as a valid comparison | Valuation or risk owner | Rules for entity, period, currency, source authority, and exception handling |
| Build and maintain the solution | FDE lead, later the service owner | Technical design, integration, testing, deployment, support, and change management |
| Provide shared AI primitives | AI platform product owner | Model access, retrieval, tool controls, evaluation support, and maintenance commitments |
| Approve production release | Designated release authority | Review of technical, business, control, and operational evidence |
| Operate the service after the engagement | Technical service owner and banking workflow owner | Staff, access, incident response, source updates, and continuing funding |
Of the seven decisions, the FDE team holds one. That is what the map is for: it shows the engineers which six people they need routes to.
2. Your map
Column definitions. Accountable role: the role from the list above, or an equivalent in your organisation. Named person: the individual currently holding it. Required contribution: what that person must supply for delivery to proceed. Confirmed by that person: they have agreed, in writing, that they hold this decision. Independent assessment required: a control function must assess this decision separately from the person making it.
| Decision | Accountable role | Named person | Required contribution | Confirmed by that person | Independent assessment required |
|---|---|---|---|---|---|
| Define the result and supported cases | yesno | yesno | |||
| Decide whether source data may be used | yesno | yesno | |||
| Define what counts as a valid result | yesno | yesno | |||
| Build and maintain the solution | yesno | yesno | |||
| Provide shared AI primitives | yesno | yesno | |||
| Approve production release | yesno | yesno | |||
| Operate the service after the engagement | yesno | yesno | |||
| Approve an expansion of scope | yesno | yesno |
3. Escalation
Escalation resolves a tradeoff. It does not transfer authority. When a decision owner permits less than the engineers or the business want, the FDE team supplies the consequence and an alternative; the owner decides; and a disagreement goes to one named leader who can fund the condition, narrow the workflow, choose another design, or stop.
The specimen: analysts want the solution to read detailed deal-room documents, the data owner permits selected files only, and the FDE team proposes retrieving a narrow document set under the requesting analyst's identity. The data owner still decides whether the use is permitted.
Record each escalation here.
- The conflict, in one sentence
- Decision owner
- What the FDE team supplied (the gap the restriction creates, and an alternative design)
- The owner's decision, and date
- If unresolved, escalated to
- That leader may
- fund the condition | narrow the workflow | choose another design | stop
- Outcome, and date
4. The incident route
Some decisions need an immediate route rather than a scheduled meeting. If an operator suspects that the solution retrieved data for the wrong case or team, someone must be able to pause processing and identify affected cases. Name these people before production release; the release authority should refuse a release without them. The FDE practice can implement containment, but the enterprise decides who has authority to stop the workflow and who assesses the business consequence.
| Decision | Named person | Backup | Confirmed |
|---|---|---|---|
| Pause processing | yesno | ||
| Identify the affected cases | yesno | ||
| Assess the business consequence | yesno | ||
| Decide whether to restore the capability | yesno |
- Enterprise incident process this route connects to
5. Fit with existing authorities
The practice should fit the enterprise's existing approval bodies rather than create an informal process that competes with them. Record each body whose approval a decision above needs, and which row connects to it.
| Existing body or control | What it approves | Rows above that connect to it |
|---|---|---|
- Map confirmed complete by the practice lead, and date