FOI Triage Logger
Reads each inbound Freedom of Information request, extracts the reference, applicant, date and scope, routes it to the owning department and starts the 30-day statutory clock, then flags requests touching third-party personal affairs for exemption review before the officer signs anything.
An LLM reads the incoming request — email, PDF or scan — pulls the file fields, proposes a routing and a validity check against the FOI Act 1982 (Vic), and surfaces likely-exempt content for a human officer to decide.
Where this works well
The slow, invisible problem this surfaces is the front end of an FOI request — the locating, transcribing and routing that happens before any judgement is applied. In most small governance teams that work is manual and the statutory clock under the Freedom of Information Act 1982 (Vic) starts ticking the day after a valid request lands, whether or not anyone has logged it yet. This pattern reads the incoming request — email, PDF application form or scanned letter — pulls the reference, applicant, received date and scope, proposes the owning department, and starts the 30-day clock on day one instead of day five.
It earns its keep where intake is bursty and the team is small: a single FOI officer or a governance coordinator carrying FOI alongside other duties, handling a steady trickle that occasionally spikes. The win is not speed for its own sake — it is that the careful work (reading scope, weighing exemptions) starts sooner and against a clean draft register, and that a request touching a third party's personal affairs is flagged for s33 review at intake rather than discovered late.
Where it works badly
If your requests are highly heterogeneous — long, discursive letters that bury the actual scope in three paragraphs of context, or omnibus requests spanning several departments at once — the routing proposal gets weaker and the officer ends up re-reading anyway. The honest test: take your last twenty requests and ask how many had a scope you could state in one line and route to a single owner. If most needed a conversation with the applicant before you could even define them, this saves you less than you'd hope.
It also reads what is in front of it. A request whose plain wording looks routine but whose real sensitivity only an experienced officer would spot — a seemingly innocuous records request that, in context, would identify a complainant — is exactly the case where the model can be confidently wrong: no third-party name in the scope text, so no s33 flag, even though the officer would have raised one. The flag is a prompt, never a clearance.
What it doesn't do — and shouldn't
It surfaces; the officer decides. It proposes a routing, checks whether the request is valid under s17, starts the clock, and flags scope that touches third-party personal affairs (s33) or that may attract other exemptions — internal working documents (s30), legal professional privilege (s32). It does not apply the exemption, does not weigh the public-interest test, does not redact, and does not release or refuse. Every likely-exempt call is escalated; the officer applies the legal test and signs the decision.
That boundary is deliberate. An FOI decision is a reviewable legal act — an applicant can seek review by the Office of the Victorian Information Commissioner — and the unreasonable-disclosure judgement under s33 is a question of degree that turns on context the document text doesn't carry. Automating the clerical front end recaptures the officer's time for exactly that judgement; automating the judgement itself would put a defensible decision in the hands of something that can't be held to account for it.
What your data has to look like for this to work
Three things have to be in good shape, and most teams have only the first. One: the incoming requests need to be machine-readable enough to extract from — typed emails and PDFs are fine, but if a large share arrive as poor scans of handwritten letters, expect lower-confidence extractions that route to the officer rather than auto-log. Two: a current routing map — which department or unit now owns which class of records — because a restructure that isn't reflected sends requests to a stale owner. Three: the exemption framework encoded against the actual sections of the FOI Act (Vic), and a records-store mapping so the proposed owner matches where the responsive documents actually live.
That second and third piece is usually the real first job, and it is rarely about buying a tool. It is about writing down what your FOI officer already knows — how requests get routed, which grounds get raised most, where the records sit — in a form a system can check against. That encoding work is typically bigger and more valuable than the extraction layer on top of it, and it is the part we help with first.
Could it wave through a request that should have been exempt, or flag a release we shouldn't make?
It never makes the exemption decision — it proposes a classification and surfaces the ground it relied on (for example, scope text that names a third party, flagged under s33). The officer reads the flag, applies the legal test, and signs. The risk it removes is the missed flag — a request quietly logged as routine when the scope touches someone else's personal affairs — not a wrong release, because no release happens without the officer's signature.
Our requests come in as scanned letters and forwarded emails, not tidy forms. Will it cope?
Mixed intake is the normal case, and the demo deliberately includes a handwritten scan alongside typed PDFs and emails. The model reads all three, but a faint scan or an ambiguous scope line will lower its confidence — and a low-confidence extraction is meant to land in front of the officer, not be auto-logged. If a request is so unclear it isn't a valid s17 request, that is itself a flag for follow-up, not something to file silently.
Does this replace our FOI officer?
No. It replaces the half-hour of locating, transcribing and routing each request — the clerical front end. The judgement that defines the role stays human: whether a request is valid, whether an exemption applies, what gets redacted, and the signature on the decision. The officer gets the statutory clock started on day one and a clean draft register, and spends their time on the calls only they can make.
How current does the request data need to be?
The request itself is point-in-time, so currency isn't the issue there. What must be current is the routing map — which department now owns which records — and the exemption framework it checks against. If a team has been restructured or the FOI Act's exemptions or fees have changed and that hasn't been reflected, it will route to a stale owner or quote an out-of-date ground. Keeping that mapping current is part of the setup, not a one-off.
Where does the request data go — does it leave our environment?
It is built to run inside your tenancy — the demo's stack is Power Platform and SharePoint, so the requests, applicant details and the draft register stay in the council's own Microsoft environment rather than a third-party service. FOI requests routinely contain personal affairs information, so the deployment is scoped to keep that data inside your boundary and your existing access controls; the specifics are part of what we agree before anything is built.
Estimated build: 3–5 weeks. Most of it is template work we've already done.
Fixed scope, fixed price, fixed dates.
The cost band reflects the engagement shape, not a per-feature line item. We work on fixed scope, fixed price, fixed dates — see the services catalogue for what falls inside each band.
Considering this for your org?
The honest place to start is a bite-sized first piece — one contained change, low risk. Tell us where it hurts; we’ll play it back, scope it, and show you what’s possible.