Routine HR operations become expensive when every record needs the same manual attention. Most requests are ordinary. A few are not, and those are the ones that need a person.
The platform organises normal processing and highlights exceptions, giving staff a clearer queue of work and the context to resolve each item.
The problem
Most back-office work is routine and a few cases are risky. When everything looks the same, the risky case gets the same quick glance as the rest, or the whole team is slowed down to catch it.
What the system does
- Employee and request records with role-scoped access for staff, managers and employees.
- Deterministic policy checks first, so predictable cases are resolved without a person.
- AI used to interpret or prepare uncertain material, such as an unclear document, then routed as an exception.
- An exception queue showing the reason, the evidence and a suggested next action, and an approval history.
A representative journey
- Step 1: Receive a request or recordAn employee submits a request, or a record arrives from another system.
- Step 2: ValidateRequired information is checked against the policy and the employee's record.
- Step 3: Apply rulesWhere the policy gives a clear answer, the case is resolved and logged.
- Step 4: Prepare the unclearFor an ambiguous document or entry, AI summarises what it found and what is uncertain.
- Step 5: Route an exceptionThe case appears in the queue with its reason, evidence and who is responsible.
- Step 6: Record the decisionA person decides. The decision, who made it and when are kept.
Exception queue · 3 of 214 records this week (synthetic)
211 resolved by rules| Item | Why it was raised | Evidence | Next action |
|---|---|---|---|
| Leave request, 3 days | Balance is 2 days | Balance record, policy 4.2 | Manager decides: partial or unpaid |
| Contract upload | Signature page unreadable | Scan, page 6, low confidence | HR requests a new scan |
| Overtime entry | Exceeds weekly limit | Timesheet week 45 | Manager confirms or corrects |
Illustrative counts. Pay and employment decisions always wait for a person.
Working prototypeUse a small working version of this on invented data, the way a person would.
Try the prototypeInspect the system
This anatomy is a proposed description of how such a system is put together. It is not an audit of a specific deployment.
Inspect the system
How Exception-driven HR operations is put together
- What it is
- Employee and manager portalWhere requests are made and approved.
- What flows through it
- Requests and approvals go in. Status and notifications come out.
- The decision
- Each role sees only what it needs.
Read the whole system as a list
- Employee and manager portal. Where requests are made and approved. Flow: Requests and approvals go in. Status and notifications come out. Decision: Each role sees only what it needs.
- Policy and validation layer. Rules that check a record against the policy. Flow: A request and an employee record go in. A pass, a fail or an exception comes out. Decision: Policies are explicit rules, so a decision can be explained.
- Workflow and AI assistance. Prepares uncertain material, such as an unclear document. Flow: An ambiguous input goes in. A summary with uncertainty marked comes out. Decision: AI interprets and prepares. It does not decide.
- Exception queue. The list of cases a person must resolve. Flow: Exceptions go in with their reason and evidence. A decision comes out. Decision: Every item states why it was raised and what to do next.
- Authorised update and audit. Applies an approved decision to downstream records and logs it. Flow: An approved decision goes in. An updated record and a history entry come out. Decision: Only an authorised role can approve a change that affects pay or employment.
Key decisions
Rules before AI
A policy that can be written down is a rule. AI is used where input is genuinely unclear, not to approximate a rule it could simply follow.
An explicit authority boundary
Money and employment decisions need an accountable person. The system prepares and routes, and payroll is not run without confirmation.
Show the reason
An exception that says only “needs review” wastes a reviewer's time. Each one states why it was raised and what evidence exists.
Outcomes and limits
We publish no measured outcomes for this project, because we have none we can evidence. The description above is of what the system does, not of results it has produced.
- Payroll, leave, onboarding and attendance are candidate modules. The set actually delivered is not stated.
- The system does not make employment decisions and no result such as hours saved is claimed.
- The examples are synthetic: no salaries, identities or real HR records appear.
Guardrail
Payroll and employment decisions need a person's confirmation. The system routes and prepares, it does not decide.
Technical detail
Technology named in the portfolio for this kind of system. Which parts a given engagement used is not stated.
- Next.js
- TypeScript
- Tailwind
- PostgreSQL