Portal task completion engine

Back-office case work, recovered from raw PC operation logs and then automated — with the parts it cannot safely do routed to a human instead of guessed at.

Where to go

Operator's view The portal with the assistant running. Click a row and watch it decide. Open → Reviewer's queue What the engine would not finish, why, and the override rate. Open → Shadow replay report The engine run over real recorded work, checked against the operators. Open → API decide · queue · metrics · outcome. Interactive reference. Open →

How it is doing

What the logs showed

click a work-item row → open a Word rule document to check policy → type a one-sentence summary into the note field → click the commit button → next row

Once every ~12 seconds, 644 times. The sentence turned out to be a fill-in-the-blank template, and every blank was a value already on the screen. 8 of 13 processes end with the same concluding sentence every single time — the work is transcription, not judgement.

Three cases worth clicking

Row	What happens	Why it matters
`…-009` ¥393,384 · 定常	Completes on its own	The routine path. Two buttons appear.
`…-002` 調整	Note prepared, auto-complete withheld	A flagged invoice is where a real discrepancy would be.
`…-004` ¥1,832,962 · 定常	Rule says complete it — the limit still stops it	A rule says what is correct; a limit says what a machine may do unattended.

Two honest caveats. The portal screen is a reconstruction — the real systems existed only inside the recording environment, so the automation is real and the system it drives is a mock. And no time-saving figure appears anywhere: the source recordings have compressed timings, and contain zero exceptions, which is a property of a test recording rather than of the business. A pilot has to measure both.

Deterministic rules engine · no model in the decision path · every decision auditable · built from the observed work, not from assumptions.