Perspective
Build the Reason for Every Public Decision Into the Case System
Public bodies often reconstruct their reasons only when challenged. We build the case system so a decision cannot be finalised without its reason, authority and evidence.
5-minute read5 November 2026
In Brief
- A body finds out whether it can explain a decision when somebody asks. The account is written after the outcome and rarely shows what was considered at the time.
- Four actions: require reason, authority and evidence in the step that releases a decision, hold facts by reference, append and never overwrite, and index at the time of entry.
- Thinqmesh maps the process with the officers who perform it, agrees the first version in writing, and builds case software in stages that you own.
A public body usually discovers whether it can explain a decision at the moment somebody asks. An applicant is refused a licence, a bidder challenges an award or an audit team requests a file, and staff begin to rebuild the reasoning from notes, email and memory. The account may be entirely honest, but it is written after the outcome.
A Case System Should Make the Reason Part of the Decision
Our view is that this is a software design problem as much as a records problem. A system that lets an officer finalise a decision without its reason, its authority and its evidence manufactures the gap a records officer will later be asked to close. Section 4(1)(d) of the Right to Information Act requires reasons for administrative or quasi-judicial decisions to be given to affected persons, and we read the other duties in section 4 as describing a record built into the work.
We build the reason into the transaction. The officer enters it at the moment of decision, the system holds the norm and the evidence that applied, and the entry cannot be altered later without showing the change. A short record, made in the moment, is more reliable than a long one reconstructed under pressure.
Four Things a Case System Should Require at the Point of Decision
Each one is a rule in the software, so the record is made at the moment the decision is made.
Require Reason, Authority and Evidence in the Same Step
The reason is part of the transaction that makes the decision, entered by the person responsible.
The record shows which officer or committee decided, under which delegated power, and which version of the applicable norm was in force that day. Routine approvals on a fixed checklist can generate their record automatically. Refusals, exceptions and discretionary awards require written text, and a supervisor reads a sample each month.
Get started
- Choose one decision type with a real refusal rate.
- List the fields a refusal must carry before it can be finalised.
Hold the Facts by Reference
Documents as they stood on the day of the decision, linked, so a later revision does not alter history.
Norms are versioned reference data, and the evidence attached to a case is held by reference to the document as it was. A later reader sees the rule that applied, and the facts relied upon, without having to rebuild them from email and memory.
Get started
- List the norms behind your chosen decision type and where each version lives.
- Check that each case file can point to the version in force on the day.
Append Entries, and Let a Correction Appear as a Correction
Nothing is overwritten, so the sequence of events stays readable.
Deliberation can sit in a separate note with its own access rules. The decision, its reason and the communication to the person affected cannot be optional. Structured fields also make it easier to release the part of a record that is not exempt.
Get started
- Decide which notes stay internal and which fields are always part of the record.
- Define how a correction is shown to a later reader.
Index When the Entry Is Made
Retrieval that depends on someone remembering a file number is the problem the Act addresses.
Decisions are indexed by type and subject at the time of entry, so a public register can be generated from the same records. We design the data model once and the register follows from it.
Get started
- Draw ten decisions from last quarter, at least five of them refusals.
- Give them to an officer who took no part and ask them to find the norm, facts, reason, decision-maker and date told.
How Thinqmesh Solves This
We map the process with the people who perform it, agree in writing what the first version must do, and deliver working software in short cycles. A first working version of a defined scope arrives within four weeks.
- Week 1
The Process, Mapped With Officers
We map how decisions are made with the people who make them, and agree in writing what the first version must do.
- Week 2
Reason and Evidence in the Flow
Screens, data and integrations are planned so the reason, authority and evidence are captured in the same step.
- Week 3
Built in Short Cycles
Working software is delivered in visible stages, so progress can be judged from what runs.
- Week 4
Tested on Real Scenarios
Testing uses your real scenarios and data, including awkward cases, and the code sits in your own repository.
You finish with working case software tested on your own decisions, and with documentation your team can continue from. The code and documentation belong to you.
