The short answer
A maintenance authorization matrix defines who may request, diagnose, approve, dispatch, expand, accept, and pay for work under specific conditions. Use amount as one input alongside urgency, property or owner rules, scope clarity, access, repeat history, and specialist requirements. Record the policy version and actual approval used for each job.
Key takeaways
- Approval to dispatch is not unlimited approval to expand scope.
- Urgent response needs a defined branch and retrospective record.
- Policy version and approver authority belong on the work record.
Separate the decisions hidden inside “approved”
Request intake, triage, diagnostic visit, work authorization, changed scope, access, completion acceptance, and invoice approval can belong to different people. Define them explicitly. A resident report can start intake; it does not necessarily authorize a purchase.
The matrix must defer to applicable agreements, policies, safety processes, and qualified judgment. This article supplies an operating structure, not legal or technical authority.
Build a condition-based authorization matrix
Use the narrowest authority that still allows the team to act. Record both the ordinary route and the exception route.
| Decision class | Conditions | Authority | Evidence retained |
|---|---|---|---|
| Diagnostic dispatch | Known service category; no repair commitment beyond limit | Named operational role | Request, triage, vendor acceptance |
| Routine work | Clear scope inside approved conditions | Role or owner defined by policy | Scope version, amount basis, approval |
| Changed scope | Vendor discovers added or substituted work | Explicit change authority | Before/after scope and decision |
| Urgent response | Defined urgent condition requiring immediate branch | Emergency policy and escalation path | Observed facts, actions, notifications, retrospective review |
| Specialist review | Condition outside general competence or policy | Appropriate qualified reviewer | Referral and limitation |
| Invoice release | Accepted work and supported variance | Payment approver | Acceptance and invoice match |
Prevent threshold splitting and scope drift
Several small invoices for one known scope should not evade a higher approval level simply because they are entered separately. Link related work and evaluate the commitment as the policy requires. Likewise, a diagnostic call-out should not silently become open-ended repair authority.
When the final amount differs, preserve the approved scope and the reason for variance. Do not backdate approval or rewrite the original limit.
Operational checklist
Mark your progress, then save a working copy. Selections reset when you leave this page. A checked box is not an approval or evidence of completion.
☐
Decision types separated
☐
Authority tied to named roles or owners
☐
Conditions include more than amount
☐
Urgent and specialist branches defined
☐
Policy version stored
☐
Changed scope requires a new decision
☐
Completion and invoice approval remain separate
0 of 7 marked
Edge cases
- Several units show the same issue: assess whether the work is one program or separate incidents under the approved policy.
- A vendor offers a cheaper substitution: price alone does not authorize different scope or material.
- No approver responds: use the defined escalation path; silence is not approval.
Sources and references
Follow each source to check the underlying claim. Access checks and professional review are different steps.
Continue the workflow
setting a maintenance spend capHand off open maintenance work without losing the next actionMaintenance completion acceptanceRevision history
2026-09-18
Initial Phase 2 operational article with an original decision artifact, explicit failure states, primary-source scope notes, and AI-assisted technical review.