What should I ask an approval-authority release to contain?
A checklist of eight record types to request, so that every approval in a release can be traced to a role, a grant, a limit and a policy version.
When requesting a release, ask whether each of these is present and linked by stable identifiers, so no part has to be inferred from another.
- A role hierarchy with reporting lines and cost centres, linked to every approver named in an event. - Limit tables by amount band, risk class and category, including rules that add a second approver. - Delegation grants with effective dates, scope, expiry and revocation events. - Leave and roster records, so availability can be checked against the request date. - Requests with amounts, risk ratings, requester roles and references to supporting documents. - Event logs of routing, approval, rejection, escalation and withdrawal, in order with timestamps. - Policy documents in more than one version, each with an effective date. - Expected outcomes and reason codes for each task, held apart from the inputs the model sees.
Asking for each layer by name and requiring stable identifiers prevents releases that look rich but cannot be verified.
- Audience:
- Model labs
- Content type:
- Checklist
- Buyer question:
- What can be generated
Content release: r-a220eb6e099b243b
Related questions
- What fields and links make up a generated approval record schema?
- Can the generated authority matrix follow the structure of our own approval process?
- How can a task pack represent a claim settlement split to stay under a limit?
- Which records can a generated approval dataset contain?
- What should I specify when requesting generated authority and approval data?
- What does a generated claims settlement approval case look like?