Streamlined status determination under § 7a SGB IV

Submit a test application using one of the example scenarios

Pause the animation

1. Arrival An application arrives - as a form, an e-mail or a scan.

2. Sealing Every identity-bearing value is sealed immediately; the machine never gets to see it.

3. Decision A versioned decision table checks completeness and responsibility, and gives a reason for every row.

4. Queue The case lands in the responsible unit's queue and waits for a human.

5. Reply The applicant automatically receives a receipt - rendered from a template, never from a model.

Start here

Submit an application

You submit an application as an openly fictional applicant and then watch, step by step, what the system does with it. It is the same path every other incoming case takes.
Caseworker screens

Queues per organisational unit, the case view with every piece of evidence, and the three actions (confirm, re-route, escalate). Each action appends a journal event; nothing is ever overwritten.
Evaluation metrics

The numbers from the last evaluation run over the frozen gold corpus, including the four gates. The page computes nothing itself.

Two planes, one direction

The evidence plane is probabilistic and is allowed to be wrong: it extracts, routes and finds gaps. The decision plane is deterministic and reads only what has been proven. Uncertainty can push a case towards a human and never away from one - that is the one-way valve (ADR-004), and it is checked against the real decision table on every commit.
No model-written text reaches a citizen

No sentence produced by a language model ever reaches an applicant. Notifications are rendered from templates in versioned configuration; drafts wait for a human to confirm them. A model may read and may never write.
Identity is sealed at the boundary

Identity-bearing fields are sealed before the working copy exists; everything downstream sees placeholders. Re-hydration happens only when a letter is rendered. Redaction recall is measured and is a release gate.

All data is synthetic and comes from the frozen gold corpus corpus/gold/v4. There is no real person and no real case here.
Ingest is reachable only with this deployment's token (header X-Ingest-Token); without it POST /ingest answers 403. Do not send real data even with the token: this demo's storage backend is unencrypted.
The whole state is deleted on every restart and rebuilt from the gold corpus. Whatever you confirm or re-route here disappears with it - which is why leaving the actions open does no harm.
The demo's storage backend is unencrypted JSONL. That is defensible precisely because it holds nothing but synthetic data and because ingest is closed to anyone without the token; a production deployment replaces it with the encrypted store described in docs/vault-dpia-input.md.
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.

All of it on one page: About this demo