Most delegation registers are legal archives. Operators need a decision instrument.
Start with the question
The register must answer: may this person perform this action for this asset at this time? If it requires reading a mandate, board minute and email chain, the practical answer will be guessed.
Use one row per power
- Principal or granting body.
- Delegate.
- Exact act permitted.
- Asset, entity or service boundary.
- Value or consequence threshold.
- Required second authority.
- Effective and expiry dates.
- Permitted instruction channel.
- Evidence link and revocation status.
Avoid vague verbs such as “manage” and “handle.” Use executable language: approve invoices up to X; instruct provider Y; access property Z; sign contract type A; view but not export dataset B.
Separate authority from access
A person may have system access without legal authority, or legal authority without current credentials. Show both states. This prevents operators from treating a visible button as permission.
Make expiry the default
Temporary projects, travel cover and emergency delegations should expire automatically. Permanent delegations still need periodic confirmation. Every change should alert the small set of people and providers who rely on it.
Build two views
The governance view contains evidence and history. The operating view is fast: person, power, boundary, threshold, second authority, expiry and verification contact. Protect sensitive details without making the register inaccessible during a real decision.
Acceptance test
Give an operator five plausible requests and sixty seconds per request. If the register cannot produce a confident answer, rewrite the row or the interface. The objective is not a complete monument to authority. It is fewer unauthorised acts.