A government resolution decides who gets a benefit, who is transferred, who passes. When officers apply it by hand, two things creep in: different readings of the same words, and discretion where the policy never intended any. A well-built system removes both. It applies the policy the same way to everyone, every time, and shows why it reached each decision.
Getting there is less about programming and more about translation. Here is the method we use.
Why policy is hard to put into software
Policies are written for people. They use words like “normally”, “as far as possible” and “in exceptional cases”. They rely on later circulars that add exceptions, and on amendments that apply from a certain date. A person fills these gaps with judgement and memory. Software cannot.
Step 1: Collect every source, not just the main resolution
Start with a complete set: the main resolution, every amending circular, clarifications issued to field offices, and the forms people actually fill in. Then build a rule register: one line per rule, each linked to the exact clause it comes from and the date it takes effect. If a rule has no source, it is someone’s habit, not policy, and the department should decide whether to keep it.
Step 2: Rewrite each clause as a condition and an outcome
Every clause becomes a sentence of the form if these conditions hold, then this outcome follows. Take an illustrative clause: “An employee who has completed five years at a posting is eligible for transfer, except those within two years of retirement.”
As a rule, it needs answers the clause does not give:
- Five years counted up to which date: the date of the order, or a fixed cut-off date?
- Do periods of long leave or deputation count towards the five years?
- “Within two years of retirement” measured from the same cut-off date, or from today?
Each answer becomes part of the rule. The finished rule names its inputs (date of joining the posting, date of birth, cut-off date), its outcome (eligible or not eligible) and its source clause.
Step 3: Settle ambiguity with the policy owner, in writing
The questions in step 2 must not be answered by a programmer. Keep a question log: each ambiguity, the options, and the decision of the officer who owns the policy, with the date. Many departments find this log useful in itself, because it shows where the policy text needs a clarifying circular.
Step 4: Test the rules with real cases before go-live
Ask officers who know the policy well to write test cases: a set of realistic applicants or employees and the result each one should get, with the clause that decides it. Include the awkward cases: the person who joined on the cut-off date, the one on deputation, the one who retires next month. The system is ready when it produces the officers’ expected result for every case, and when it explains each result in words they recognise.
Step 5: Keep rules as data, with effective dates
Policies change. If a rule is buried in program code, every change needs a developer and a new release. We keep rules and their limits, such as the five years or the two years above, as configurable data with a start date and an end date. When a new circular arrives, the department updates the value and the date, and the system applies the old rule to old cases and the new rule to new ones. Every past decision can still be explained by the rule that applied on that day.
What changes for officers and citizens
- Every decision shows its reason: which rule applied and which clause it comes from.
- Applicants can see their status, and why, instead of waiting for an answer.
- Discretion becomes visible. Where the policy does allow an exception, the system records who granted it and why, so exceptions are approved, not hidden.
- Audits get easier, because the audit trail is complete by design.
A short checklist
- Do we have every circular and clarification, not just the main resolution?
- Does every rule in the register point to a clause and an effective date?
- Has the policy owner signed off every ambiguity in the question log?
- Have officers written test cases, including the awkward ones, and do all of them pass?
- Can the department change a limit or a date without a new software release?
If you are preparing to digitise a scheme, a transfer process or an examination ordinance, we can help you build the rule register and test cases before any vendor writes code, or design the whole platform.