Compliance, risk and audit teams at German banks spend hours searching and quoting BaFin circulars, MaRisk, EBA guidelines and laws like the GwG and KWG. ChatGPT is off the table: the questions and documents fall under banking secrecy. They need answers they can verify, from a model that never leaves the bank's own infrastructure.

A citation-backed assistant over 50 regulatory PDFs (3,387 pages, 12,186 chunks). A natural-language question in English or German returns an answer in which every statement carries a [n] pointing to a file, section and page, plus a confidence score, a status and an audit-trail entry.

• Hybrid search, because the questions are English and the law is German. Plain dense + keyword search found an expected document for 5 of 31 questions. Adding a German query (an LLM rewrite plus an EN→DE compliance glossary) to both sides raised that to 20 of 31 with the local stand-in models.
• Chunks never cross a legal boundary. A chunker that knows § 10, Artikel 19 and AT 4.4.2 means every citation reads like 01_GwG.pdf | § 10 | p. 17-18.
• Distrust the model's citations. Markers pointing to sources that were never shown are removed, fewer than 2 citations triggers one retry, and NOT_IN_SOURCES produces an honest refusal.
• No Docker, no admin rights. Two shell scripts and a Go launcher for Windows install everything in user space and restore a prebuilt vector database.

• Parsing PDFs the way lawyers cite them: a non-breaking space in § 10, cross-references that look like headings, table-of-contents pages and EU recitals all broke section detection.
• A stale checkpoint bug kept old chunks after a chunker change. The checkpoint fingerprint now includes a hash of the ingestion code itself.
• Small models sometimes loop on citation markers or refuse and then answer anyway. Both are detected and cleaned up.
• 113 tests cover corrupt or encrypted PDFs, the embedding endpoint or LLM going down mid-request, a database failing during an audit write, and 16 concurrent requests.

The base machine, from Maru Machinery, crimps the lid onto a filled ice-cream cone so nothing falls out. Run by hand, every cone has to be positioned, pressed and removed one at a time, which is slow and tiring.

A slotted disc carries the cones. A motor-driven winch pulls the crimping piston down onto the cone, and on the way round a seesaw lever with a leaf-spring "spatula" knocks the finished cone out of its holder into a container. Slots for small and large cones are calibrated separately.

• An Arduino Nano reads two IR proximity sensors and a reed switch that signals when the crimp has reached full tension.
• Three relays: one drives the 12 V disc motor, and the 220 V crimping motor is switched through a 30 A secondary relay, because the 10 A relay module isn't rated for a motor with that much torque.
• A flyback diode on the DC motor absorbs the back-EMF so it stops the instant power is cut. A fan cools the relays.
• The USB port is brought outside the box, so a laptop can watch every state change live in the serial monitor.

• A small state machine. Cone at sensor A and nothing at B: turn the disc. Cone arrives at B: stop the disc, wait 100 ms to settle, run the crimp motor until the reed switch closes, wait 200 ms for the piston to retract, then wait for the next cone.
• Safe on power-up. Inputs use INPUT_PULLUP and the relay logic is inverted, so every motor is guaranteed off when the machine is switched on.
• Observable. Every change in sensor and motor state is printed over serial, for example Sensor A: ACTIVE | Sensor B: INACTIVE | Motor: ON.

Engineers investigating a failing board had to run the right test pipeline by hand, then dig through Jira for related history separately. Two disconnected tools, no shortcut from a symptom to its context.

A streamable HTTP MCP server on a lab gateway machine that exposes the diagnostics suite and Jira as tools an AI model can call, so a plain-language question returns real results from physical hardware.

• Streamable HTTP over stdio, so engineers reach the server from their own machines.
• Tools scoped narrowly to specific tests and ticket lookups, not open shell access, so a wrong guess from the model can't harm the hardware.

• Test pipelines run for minutes, so long calls must not block the conversation.
• Results need enough structure for the model to reason over, not raw logs.

• Lightweight polling instead of new monitoring infrastructure; the lab had enough moving parts.
• Tuned for fewer, trustworthy alerts: too strict pages someone for every blip, too loose misses what it exists to catch.

• Lab traffic is bursty (test runs, firmware flashes, hardware plugged in and out), so "normal" isn't a fixed number.
• A baseline that adapts to that without drowning in false positives was most of the work.

• WebSockets over HTTP polling. One persistent socket per van, broadcast through socket.io, keeps the map live without thousands of near-empty requests an hour. WebSocketClient.h and TinyGPS++ on the ESP8266.
• OpenStreetMap and Leaflet over a paid maps API, so it stays viable on a municipal budget.
• Coordinates as the primary key of a complaint, which is what lets complaints be assigned to routes automatically.
• Built to run on simulated GPS during development, the same approach the dashboard above uses.

• A GPS fix is not a position. Raw fixes jitter by tens of metres while a van sits still, so points are filtered before they are trusted.
• A moving fleet without melting the browser: updates batched, markers grouped by zoom level.
• Defining "route efficiency" as distance covered against bins actually served, and time in the zone against time getting there.

A self-contained box: NodeMCU ESP8266, NEO-6M GPS and antenna, a LiPo battery with micro-USB charging, and a toggle switch. Nothing needs attention during a round, because a tracker that needs attention gets switched off.

bcrypt-hashed passwords, explicit CORS, and each role reaching only its own endpoints. The system holds phone numbers next to home coordinates; treating that casually was not an option.

• Savings defined, not asserted. Saving = reference retail basket − actual landed cost. Großry takes 20% of that verified saving, and the cart shows every line of it.
• No single point of failure. Every crew job has a paid backup who takes over automatically.
• Aggregated insights, not data selling. Partners see totals only; products bought by fewer than 10 students are suppressed.

• GDPR data minimisation, with export and deletion in the profile.
• Food hygiene: everything handed out sealed as supplied; chilled and frozen goods stay out of student-run distribution.
• Terms and Privacy ship as clearly marked drafts.