Samuel Dirksz

System · My own venture

Lynus.ai

Prototype

Public-sector casework is full of processes that only exist in the head of whoever has done them longest. This is an attempt to let that person describe their process and have it run, without handing over the judgement.

Facts

Status
Prototype. No users, not deployed.
Stack
Next.js 15 · React 19 · Postgres · Drizzle · better-auth
Models
Provider abstraction with a per-model pricing catalogue
Showable
Test suite and Norwegian fixtures run without an API key
Proof
No public URL

The idea

A caseworker describes, in ordinary language, how she actually assesses an application. The system turns that description into a checklist. Each item is run by its own agent, allowed to answer only from the organisation's own rulebook. Nothing moves on until a human has approved it, and the approval is stored.

The point is not to replace the judgement. It is to avoid doing the same mechanical pass for the eighth time in one week.

How the citations are kept honest

The biggest risk in something like this is the model inventing a rule that sounds right. So documents are numbered by paragraph before they are used, and the agents have to cite by number.

When the answer is assembled, the server looks up the actual text of that paragraph from the document. The model's own rendition of the quote is never used. If it invents a paragraph number, that fails rather than standing as a convincing error.

What I did not build

An architecture was proposed with a queue, dedicated workers, orchestration and half a dozen more components. I wrote a note about why I did not want it, and built the simplest thing that actually holds instead.

A run starts without a queue. State lives in the database, the interface polls, and completed steps are skipped if the run is picked up again. That makes it resumable in practice without a single extra component to operate.

Before a run, the whole setup is frozen: the steps, the model, the provider and a checksum of the rulebook document. Two identical setups reuse the same version rather than creating a new one every time someone fixes a typo.

The log is append-only, enforced in the database with a rule that rejects both updates and deletes. Not in the application code, where somebody could route around it.

What this is not

It is a prototype. No users, no customers, not running anywhere. Everything above is built and testable, but none of it has met a real caseworker with a real case.

The European provider is written but has never been run against a real resource. Until that is done the system cannot lawfully take real personal data, and that is the main thing standing between this and a pilot.

There is a known gap in access control: who sees what is enforced where the lists are fetched, not on every individual lookup. That is fine for a demo, not for production.

I demonstrate it with fixtures. Five tests run the engine against a fake provider with no API key, and it ships with Norwegian sample applications, a rulebook and a reference report.

Back to the index