The tour: from submission to the closed loop

Mass administrative procedures are broken by volume, not by hard cases: hundreds of thousands of submissions, most of them simple, have to be sorted before anybody can do substantive work at all. And the expensive failure is always the same one - something gets cleared as "no human needed" that needed a human.

The answer here is two separate planes: an evidence plane that is allowed to be probabilistic - it reads, extracts, routes and finds gaps - and a decision plane that is deterministic and reads only what has been proven. Between them sits a one-way valve: uncertainty can push a case towards a human and never away from one. That is not a statement of intent but a property, checked on every commit against the real decision table and the 101 real evidence records of the frozen corpus (ADR-004).

• The assistant decides nothing about people. It decides how closely a human has to look - tier 1 clear, tier 2 incomplete, tier 3 full review - and justifies each of those classifications line by line.
• No sentence written by a language model reaches an applicant. Messages are rendered from templates in versioned configuration; drafts wait for a human to confirm them.

On the intake page you pick one of four openly fictional applicants - obviously invented names, so that a screenshot of this demo can never look like a real case - and edit their prefilled employment-status application. You are meant to break it: delete the insurance number, enter a date of birth that cannot be right, push the start of the activity far into the future. Each of those changes triggers a different, real behaviour of the system.

The form goes through the same processing as any other incoming case: the same sealing, the same validation, the same journal. There is no demo path beside it.

Submit an application (phase 1)

Phase 2 shows seven stages in the order they ran: arrival, sealing, extraction, evidence, decision, message, queue. Every number on it comes from that case's journal. The page recomputes nothing - it cannot contradict what actually happened.

So that the seven stages are walkable before you have submitted anything, this tour points at a case from the frozen gold corpus: an old-age pension application that arrived without its start date. Result: Tier 2 - routable, incomplete, routed to Referat 312 - Altersrenten.

See the seven stages on that case

What to look for there

• Stage b, sealing. Name, date of birth, insurance number and address were replaced before the working copy existed. The table names the KIND of what was sealed and how many - never a value. A second, independent detector pass over the working copy found nothing; that is the verification.
• Stage c, extraction. Every extracted value carries a span that was verified twice: the literal quote AND the character offsets, independently, against the same text. Anything that fails is discarded rather than repaired - and a discarded value pushes the case towards tier 3.
• Stage d, evidence. The reported gap is shown together with the sentence the request for information would use. That sentence comes from the procedure configuration, not from a model.
• Stage e, decision. The decision table's reasons are listed in evaluation order, with the id of the row that fired. That is the point where "explainable" stops being a promise.

The case this step points at comes from the frozen gold corpus and not from anything you typed. That is why the side-by-side comparison of typed value and working copy is missing on that page: the scratch store holds only what a visitor typed themselves, and only for a short time, in memory. Everything else - sealing, spans, gaps, routing, decision, messages - comes from the journal and is all there.

And then the clearing unit asks the other side. An employment-status application has two parties - par. 7a Abs. 4 SGB IV requires the client to be heard before a decision is made. In this demonstration you play that client yourself: you see the letter that arrived for them and you answer it. Your answer runs through the same intake and becomes a sealed case of its own - the seal holds for both sides.

Play the other party

Now you swap hats. The caseworker surface shows queues per organisational unit, oldest case first, plus a central clearing queue for anything no rule could route (par. 16 Abs. 2 S. 1 SGB I obliges the wrong authority to forward without delay). The case view puts every piece of evidence above the three actions: confirm, re-route, escalate.

Each action appends a new journal event. None edits an old one and none deletes one: a correction is an entry beside the earlier decision, never in its place (ADR-008). Which is also why there is no button that undoes a confirmation.

To the Referat 312 - Altersrenten queue

Or straight into the case view of the same case: Case case-ar-0011-ohne-rentenbeginn.

What to look for there

• Re-routing demands a reason, escalating does not. The asymmetry is the one-way valve again: nothing may stand in front of the safe direction, which is more human review.
• The similarity suggestion is visible and decided nothing. It is fenced and labelled so that it can be contradicted, not so that it can vote (ADR-021).
• No natural person appears in the journal. The actor is always the system or an organisational unit; there is no field for a named individual (BPersVG par. 80 Abs. 1 Nr. 21).
• The deadline arithmetic comes before the confirm button. Four days of statutory service fiction (par. 37 Abs. 2 SGB X), then the response period, both moved to the next working day (par. 26 Abs. 3 SGB X) - with the holiday set that was used spelled out beside it.

Picking a unit is a demo convenience with no sign-in: the unit sits in the address bar. A real authorisation model with an identity provider is a pilot prerequisite (C-5) and does not exist here.

The simulated inbox shows what the applicant would actually have received: the receipt and - after routing - the status note. Both are automatic projections of the case journal, both are purely informational acts with no legal consequence (ADR-005), and every word of both comes from a versioned configuration file. No language model is involved.

Which is exactly why that page has no controls: no form, no button, nothing with which anybody could trigger, edit or re-send a message. Anything with procedural consequence goes the written-form route (par. 36a SGB I) and not through this page.

To the inbox (read-only)

A demo that only looks good is a brochure. Five things set this one apart, and all five can be checked:

All data is synthetic

The whole state comes from the frozen gold corpus corpus/gold/v4. There is no real person and no real case here. The fictional applicants on the intake page are additionally checked to make sure none of their values occurs anywhere in the gold corpus or in the canary set - otherwise a leak sweep could not tell a leak from a persona.

Ingest is deliberately closed

POST /ingest answers 403 without a valid token, and it does so before the request body is read - the check is middleware and not a route dependency, because a framework would otherwise decode the body first. This instance cannot receive a real application submitted by accident.

Four gates, every commit

The evaluation run over the frozen corpus fails if any of four things moves: the false-clear rate (budget zero, permanently), the redaction recall of the deterministic recognizers, the regression identity of the purely structured subset, and the readability of every scorer flag. The numbers of the last run are on the metrics page - which does not compute them, it shows them.

A restart resets everything

The state is rebuilt from the gold corpus at every start. Whatever you confirm or re-route here disappears with it - which is the only reason those actions can be left open at all. The intake page's scratch store lives in memory alone and dies with the process.

The source is open and fully documented

Licence EUPL-1.2. The architecture decision records, the specification, the known errors and the accessibility self-assessment are published with the source. To the repository

To the evaluation metrics

The accessibility self-assessment against EN 301 549 / WCAG 2.1 AA is a self-assessment and not a BITV 2.0 test. No external audit by an accredited body has taken place, and one is a pilot prerequisite. It says so here and not in a footnote, because a system that claims trustworthiness has to be honest about its own edges.