Operational flow
Shared calendars, dashboards, metric stores and rule engines depend on usable signals. Many systems — old or simply closed — offer no webhook, stream or socket.
lumnik breathes — reads, compares, timestamps — so every observed change becomes an event your tools consume through ordinary sockets: a webhook into Make, n8n or Power Automate, a plain email to the team, an export, a SQL query.
And every silence too: "unmoved for thirty days" is an alert no event-driven system can send you, precisely because nothing happened.
Every conventional integration asks for an account, a network path, sometimes a write into a fragile ERP — and the admin says no, usually for good reason.
With lumnik, your modern tools never get access to the old system at all: read-only on one side, standard sockets on the other. Day one's zero-risk posture extends to the whole ecosystem.
Every tool wired straight into the ERP makes that ERP a little harder to remove. The day it is finally replaced, everything downstream is rework.
Your tools plug into lumnik, not into the ERP. When the old system does go, you swap one connector — and nothing downstream notices. Invest in the modern stack without marrying the legacy one.
A dashboard wants trend lines; the legacy holds only current state, overwritten on every update.
The observation log manufactures the time series the source destroyed — so your BI tools finally chart trends from a system with no memory.
{
"type": "quote_unmoved",
"reference": "Q-4471",
"since": "2026-06-02",
"threshold_days": 30,
"source": "gp-columbus"
}
And your data becomes an API — every merged entity readable by your own tools: plain REST, read-only, bounded to each team's scope.
These events beat at the rhythm of ingestion — hours, not milliseconds. Fast enough for a calendar, a dashboard, a business alert; this is not real-time, and lumnik will never pretend it is. And nothing, ever, writes back to the source.
Real cases
Each case below exists today. The trigger is almost always the same: an expert leaves, a company is acquired, or a record sits still for too long.
Four plants, four systems (Dynamics GP, NAV, a homegrown app). When a line stops, maintenance phones the other sites — and a stopped line costs four figures an hour.
One part, one merged record, one question — the answer, plant by plant, in seconds. The first avoided stoppage pays for years of the tool.
The buyer discovers 40% duplicate SKUs between its GP and the acquired company's QuickBooks. Sales quotes two different prices for the same item.
The single product record is served within weeks, while the migration takes its time. The conflict register IS the dedup list the team was waiting for.
Sent on a Friday, marked "pending" — then nothing. The rep is on the road, the status hasn't moved in six weeks, and no system alerts on what doesn't happen. The customer signed elsewhere.
lumnik observes every record, ingestion after ingestion, and flags the unmoved: "pending for 42 days — business threshold: 15." All that's left is to pick up the phone.
Decommissioned in 2019, kept alive only because retention rules say ten years. License + server + the one admin who knows how to reboot it: five figures a year for a handful of lookups.
One last ingestion, then the machine powers off. The archive stays queryable forever. The ROI is a subtraction you can do in your head.
Small clients will never each budget a tool like this. An MSP or integrator operates one — each client sees only its own slice, isolation enforced by the database itself.
The multi-organization architecture isn't plumbing: it's the product. One deployment, fifty thaws.