The pipeline

Detect the question's language, translate if needed, search the vector store, then generate an answer grounded in what was retrieved.

Scope retrieval by department

Policy chat is scoped by department, so people retrieve from the documents they should see. Filtering at retrieval time is safer than asking the model to ignore what it was handed.

Private documents are a different mode

"My Docs" is separate: uploaded files belong to a session and are purged after a time limit, so private material never mixes with organisation-wide policy.

Tables don't survive extraction

Credit policy is full of eligibility tables with conditional logic across loan products. Automated PDF extraction mangled them, so I restructured those tables by hand before indexing. Slower, but it's the difference between a right answer and a plausible one.

• VU needle rotation. The needle rotated around the wrong point because of a transform bug. Fix the transform origin first, then the angle math.
• White boxes around knobs. The knob PNGs had no alpha channel. They needed transparent backgrounds (or chroma-keying) to sit on the panel.
• Filmstrip drift. Mapping a value to a filmstrip frame drifted because of frame rounding in the rotation math.
• Smaller fixes. Button aspect ratio and overlapping VU labels.

The UI loads and renders. The parameter bridge to C++ isn't built yet.

Measure before you pick a language

The slowness was I/O-bound, not CPU-bound: the backend spent its time waiting on the database. A faster language does nothing for waiting.

What it actually was

• N+1 queries. One query for a list, then one more per row.
• Missing indexes, including trigram indexes (pg_trgm) for text search.

Both are fixed in the database and the query layer. No rewrite needed.

Takeaway

When "the backend is slow", find out whether it is computing or waiting. That single question decided this one.

Why LocalExecutor

LocalExecutor runs tasks as processes on the same machine, so there's no broker or worker fleet to run. The catch is that it needs a real database for metadata, not SQLite, which is why Postgres is in the picture from day one.

Keeping it alive

The webserver and scheduler each run as a systemd service, so they start on boot and restart when they die. That is most of the "operations" story on a single box.

What this doesn't give you

One machine is one failure domain, and every task shares its CPU and memory. It's a fine start for existing jobs. It's not where you stop if the workload grows.