What we can be held to
Three commitments, checkable before you trust us.
None of these are settings. They are properties of how the thing is built — which is why we are comfortable writing them on a marketing page.
Read-only by construction
Ingestion runs one way. There is no write path back to your ERP — not behind a flag, not for administrators. The SQL an answer generates executes over a separate read-only database connection.
Abstention over confident-wrong
Deterministic guards sit between the model and you: sources shown, scopes enforced, and a plain "I don't know" whenever the ingested data doesn't support an answer. A confidently invented number is worse than no number.
On-prem or EU cloud
Deploy the whole hub inside your own walls — including the model, running locally — or on European infrastructure. Nothing has to leave your perimeter for lumnik to work.
One more, for the architects: isolation between organizations is enforced by the database itself, not by application code — the layer that cannot be bypassed by a bug in the layer above.
$ lm login To sign in, open: http://localhost:8180/realms/lumnik/device?user_code=EYQP-LLJN and enter code: EYQP-LLJN $ lm validate -f connectors/gp-customers.yaml ✓ connectors/gp-customers.yaml — valid $ lm apply -f connectors/gp-customers.yaml {"name":"gp-customers","connectorId":"8e01c813-7f57-4222-8d7b-e637dfcc94c3","endpointsApplied":1} $ lm connector run gp-customers run scheduled: e9cd433e-3a57-43ff-9ea7-737f2718be0a $ lm run list ID CONNECTOR ENDPOINT STATUS IN OUT SKIPPED DEAD-LETTERS STARTED ENDED e9cd433e gp-customers default Completed 12 12 0 0 2026-09-05 05:38 2026-09-05 05:38 f0466804 sage50-orders default Completed 10 8 2 2 2026-09-05 05:38 2026-09-05 05:38 $ lm ask --scope sales "How many GOLD customers in Columbus?" There are 2 GOLD customers in Columbus. data as of: 2026-09-13T00:39:29Z (last completed run) SQL: SELECT COUNT(*) FROM "connector"."v_customer" WHERE city = 'Columbus' AND segment = 'GOLD'
A complex infrastructure. One command to drive it.
Connectors, entities, pipelines, APIs, RAG: everything is declared in YAML and driven from
lm — a bit like Docker, as an experience. The plumbing becomes an
interface.
These screens have the exact shape of what lm prints today; only the connector
names are illustrative. Nothing is lost without being counted: IN = OUT + SKIPPED
holds on every row.
Isolation lives in the database. PostgreSQL enforces it row by row (Row-Level Security): a bug in the application cannot cross it — the database refuses.
Generated SQL can only read. It runs under a role with no write permission, whatever the model produces.
The audit trail cannot be erased. The application role holds no UPDATE or DELETE on it — revoked in the database.
Reversible. Plain PostgreSQL tables and a standard pg_dump. There is no vendor copy to reclaim.
Every claim has a command: verify it yourself, in five minutes. The exit is written down too: reversibility.
Go deeper
The documentation is public. Read it before you trust us.
Connectors, guards, the data model, the one-command self-host — all of it is written down, in English, and open to anyone who wants to verify before believing. No sales call stands between you and the technical truth.
Open-source edition — Apache-2.0
The hub is open source. We said this line would become the link the day it opened, and it has: github.com/icreated/lumnik-open — the whole defrost substrate, Apache-2.0, no feature flags and no stub where the extensions would be.
Beta
Where lumnik stands: beta. The product no longer grows surfaces; it gets fixed. What is missing is missing on purpose, and the page that says so is public. What we don't know yet: nobody outside this team has run it in production. You could be that first — and the first defect you find will be the one we couldn't have predicted.
Where lumnik stands, page by page · the guided path, three half-days