Ask a Part 21J design office "who can approve a stress justification for this project?" and you will usually get an answer.
Ask "and where is that enforced?" and the room goes quiet.
The authority matrix — who holds signatory authority for what, at which risk level, on which projects — exists in almost every design organisation. It is in the handbook, approved by the authority, referenced in procedures. On paper, the office knows exactly who can approve what.
In practice, approval authority is enforced by convention. The document lands in an inbox; whoever feels responsible signs it. The shared drive lets anyone move a file into the Approved folder. The delegation that was granted verbally in March, when the head of office went on leave, was never revoked and nobody remembers its terms.
This gap — between the matrix the authority approved and the behaviour the tools actually allow — is one of the most commonly cited weaknesses in design organisation audits. It is also one of the most fixable.
How Authority Drifts
Nobody decides to bypass the authority matrix. Drift happens through small, individually reasonable events:
- Informal delegation. "Can you sign these while I'm at the supplier?" — granted in a corridor, scoped by memory, never expired.
- Role changes without permission changes. An engineer becomes a compliance verification engineer, or stops being one, and their practical ability to approve things changes on paper only.
- Urgency exceptions. A deadline arrives, the named signatory is unavailable, someone "just this once" approves outside their scope. It works, so it happens again.
- Tool indifference. Email and shared drives have no concept of signatory authority. Every control is a human remembering a rule while under time pressure.
- Multi-project ambiguity. An approver holds authority on Project A but not Project B; the documents look identical, and the folder structure does not know the difference.
Each event is minor. Accumulated over two years, the result is an office where the handbook describes one approval regime and the file system records another.
What the Gap Costs in an Audit
Signatory authority is not an internal convenience — it is part of what the authority approved when it granted the design organisation approval. When an auditor samples an approved document, three questions follow:
- Who approved this?
- Did they hold the authority to approve it, at that risk class, on that project, on that date?
- Show me the record that says so.
A spreadsheet-and-email office can usually answer the first question. The second requires cross-referencing the handbook, the org chart as it existed at the time, and any delegations in force — which typically live in email, if anywhere. The third question is where findings happen.
The damaging part is not the individual finding. It is what it implies: if the office cannot demonstrate that approvals were made by authorised people, every approval in the sample period becomes questionable. That is how a single delegation nobody documented turns into a systemic finding against the organisation's control of its own procedures.
The Fix: Make the Matrix Executable
The pattern behind every durable fix is the same one that fixes revision control and traceability: stop maintaining the rule beside the work and make it a property of the system where the work happens.
An executable authority matrix has four characteristics.
1) Authority Is Modelled, Not Described
The matrix should exist as structured data: person, role, artefact type, risk class, project scope, validity period. Not a table in a PDF — a set of records the document system reads before it offers anyone an "approve" action.
When the matrix is data, "who can approve what" stops being a lookup exercise and becomes a constraint. A person without authority for a document class does not see a greyed-out warning; they simply cannot execute the approval.
2) Delegations Are First-Class, Time-Boxed Records
Delegation is legitimate and necessary — offices cannot stall every time a signatory travels. What makes delegation dangerous is informality.
Every delegation should be a record with: who delegated, to whom, what scope, from when, until when, and who authorised it. Expiry should be automatic. A delegation that needs extending is re-granted deliberately; one that lapses silently is the system working as designed.
This single change eliminates the most common audit vulnerability: the unrecorded, unexpired, unscoped verbal handover.
3) Role Changes Propagate Immediately
When someone's role changes — promotion, project reassignment, departure — their approval capabilities should change in the same action. If updating the authority model is a separate task on someone's list, it will lag reality by weeks, and those weeks are exactly the ones an auditor will sample with unerring instinct.
The practical test: could HR-level changes (joiner, mover, leaver) leave your approval system granting authority to someone who no longer holds it? If yes, the matrix is decorative.
4) Every Approval Records the Authority It Was Made Under
The approval record should capture not just who and when, but under what authority: the role held, the matrix version in force, any delegation invoked. This is the answer to the auditor's third question, produced in seconds instead of reconstructed over days.
It also protects the approver. "I signed this under a documented delegation with these terms" is a very different position from "I signed it because it was urgent and the boss was away."
A Rollout That Doesn't Freeze the Office
Enforcement sounds like friction, and design offices are rightly wary of anything that adds delay to approvals. The sequencing below avoids the trap.
Week 1–2: Write Down What Is Actually True
Before enforcing anything, capture the real current state: who has been approving what, on which projects, over the last six months. Compare it against the handbook matrix. The differences are your findings-in-waiting — better discovered by you than by the authority.
Week 3–4: Reconcile, Then Model
Some differences will be resolved by updating permissions; others by updating the matrix itself, because reality was right and the paper was stale. Decide each one explicitly, then encode the reconciled matrix as structured data.
Week 5–6: Enforce in Warning Mode First
Turn on authority checks so that out-of-scope approvals are flagged but not blocked, and review the flags weekly. This catches the modelling errors — the forgotten legitimate delegation, the mis-scoped role — without stalling live work while you fix them.
Week 7+: Enforce Fully, With a Real Escalation Path
Switch from warning to enforcement, and pair it with a fast, documented escalation route for the genuine urgent case: a named backup signatory per document class, and a time-boxed emergency delegation process that creates its own record. Enforcement without an escape valve gets bypassed; enforcement with a documented escape valve gets used.
Signals This Is Already a Problem
- A delegation currently "in force" exists only in an email or a conversation
- Someone who changed roles in the last year can still approve documents from their old role
- The answer to "who can approve this?" differs depending on whom you ask
- Approvals have ever been made by someone outside their project scope because the folder structure allowed it
- Demonstrating a signatory's authority for a past approval would take more than five minutes
Two or more of these, and the gap between the paper matrix and operational reality is already material — the only question is whether you find it before the next audit does.
Final Takeaway
The authority matrix is one of the few documents in a design organisation that the regulator has explicitly approved. Running an office where the tools cannot enforce it means the organisation's most formally sanctioned rule is also its least protected one.
Making the matrix executable does not add bureaucracy — it removes the constant, invisible work of remembering the rules under pressure, and it converts every approval into evidence that the system of authority actually operates.
An office should be able to answer "who can approve what, and how do you know?" with one sentence: "The system only permits approvals the matrix allows, and every approval records the authority it was made under."