Rather than reimplement approvals in every module, we modelled what governed actions share and built one maker-checker approval engine, so a single rule set governs them all and the audit trail is complete by construction.
One pattern, many modules
Every serious school workflow needs a second pair of eyes on its consequential actions. A large fee waiver should not be self-approved. Examination results should not reach families before the principal has seen them. A student should not leave campus mid-day without someone accountable signing off.
This pattern, where one person proposes and another authorises, is maker-checker, and it recurs across admissions, fees, examinations and attendance alike. The question is whether you build it once or four times.
The temptation to copy-paste governance
The obvious way to deliver it is module by module, as you build each one: an approval flag on fee adjustments here, an approval step on result publication there, another on gate passes. It works, feature by feature.
But you end up with four implementations of the same idea, four subtly different audit trails, and four places to change when a school's policy shifts. The logic that most needs to be consistent and trustworthy becomes the logic that has been reimplemented the most times.
One engine, one shape
So we modelled what these workflows share instead of what makes them different. Strip away the module and every governed action reduces to the same shape: an actor proposes something, a rule looks at the situation, and the action either takes effect immediately or waits for an authorised person to decide. We built that once.
A rule evaluates conditions such as a threshold, a percentage, an amount or a class, and resolves any governed action to one of three outcomes. If no rule applies, or the matching rule says the case is routine, the action takes effect now and is still recorded. If a rule matches, the action is held as pending and routed to the approver the situation calls for. And when the resolved approver acts, their decision and identity are recorded, and the action either proceeds or is rejected.
Who approves? The scope map answers
The subtle part was never the yes or no; it is who gets asked. Hard-coding that the principal approves waivers fails the first school that delegates that authority to a coordinator above a threshold. So the engine does not hard-code the approver at all. It resolves them through the organisation-and-scope map: the class, section, division or department in question maps to its supervisor, and the approval routes there. Change the map and the routing changes, with no code involved.
A school can even make the approving role itself configurable, so any role it designates, down to a gate guard for a student exit, can hold approval authority for exactly the actions it should. Waivers over a set percentage might route to the class supervisor while smaller ones auto-approve; results route for the principal's sign-off before guardians are notified on the same path. The rule changes; the enforcement does not. A school edits a rule in one place and every module inherits the new policy at once.
The audit trail comes free
Because every governed action flows through one engine, every decision lands in one immutable audit log: who proposed, who approved or rejected, when, and against which rule. The actor's name and email are captured at the moment of the action, recorded alongside the decision, so the record stays accurate even if that person is subsequently renamed or leaves the school. A school's history of its own consequential decisions is complete by construction, not because each module remembered to write a log line.
The value shows up exactly when it is needed most. When a parent disputes a waiver, when an auditor asks who signed off a result, when a school reviews its own controls, the answer is in one place, in one shape, for every module. Refusing to build the same thing four times was not about saving effort. It was about making governance something a school can actually trust.