AI HR Assistant — Governed Self-Service on Live HR Data

Eleven services, all reached by asking rather than by navigating. It reads a leave balance across every plan an employee is enrolled in and explains what has accrued, what was taken and what remains. It submits a leave request. It detects an unapproved absence and offers to correct it. It generates salary and experience certificates. It corrects a time card. It requests overtime. It reports the status of anything already submitted. It finds people and their reporting lines, and shows what is missing from a profile. And it answers questions about HR policy from the law itself.

Underneath, these are not one-shot lookups. A leave submission is a chain of roughly ten calls across five gated steps — eligibility, type, dates, duration, balance, submission — each of which must succeed before the next is allowed. The employee sees one exchange and a reference number.

Before it, every one of those questions went to a person. Employees checked entitlements by contacting HR, requested documents by email, and chased the status of their own requests — and the same HR team answered the same families of questions for a workforce sized at twenty thousand today and planned for sixty.

That is the arithmetic the assistant changes. The questions do not get fewer as headcount grows; the number of people answering them does not grow with it. Self-service only helps if the answer is right, which is why correctness — not fluency — was treated as the thing to measure.

Entitlement questions have answers written down: how many days a grade is owed, when leave may be encashed, how much carries over. So the evaluation dataset was built from the labour law and its executive regulation article by article — sixty-eight questions, including every entitlement case in the first wave — rather than from what a subject-matter expert recalled in a meeting.

It also surfaced the risk worth naming before go-live rather than after: two editions of the regulation exist side by side, a draft and a final, and the answers traced back to the draft. A golden answer is only as good as the edition it came from, so which edition governs became a tracked dependency instead of an assumption.

Reading a balance is safe. Submitting leave, correcting a time card and requesting overtime are not — they change a record in a live HR system, and a confident mistake becomes a payroll problem.

So identity is injected by the gateway from the authenticated session and cannot be set by the client, which makes asking for a colleague's record impossible by construction rather than forbidden by prompt. Read and write paths are separated. Every write is shown back and confirmed before it is submitted. None of that shows up in a demo; all of it decides whether the assistant is allowed near production.

The same feature existed in three places — a clickable prototype, a design file and a live API — and none had been declared authoritative. So the API collection was read operation by operation and mapped against every capability: which calls exist, which are flagged as extensions that do not yet, what each response actually returns, and what a screen shows that no field behind it can supply.

That is where the useful findings live. A balance card displaying a share of an annual entitlement the API has no field for. A carry-over expiry date drawn on two screens and present in no response. A capability with a working flow in the prototype, an empty template in the design file, and no operation behind it at all. Between two versions of the collection, three operations quietly disappeared while the total count stayed the same, so the loss was invisible from the summary.

Requirements were being written on top of all of that. Making it visible per capability — which artefact governs, which call backs it, and on what date — is what turned eleven narrative descriptions into criteria that can pass or fail, and the same mapping is what the evaluation dataset was hung on.