The Evidence Standard

We publish the bar we have to clear.

Operations software is unusually easy to oversell. A demo proves someone can drive it. A successful deployment proves the code started. Neither proves your warehouse can rely on it at four in the afternoon on the worst day of the month. So here is the standard we hold ourselves to, in public, before any release goes near a real operation.

Nine gates

Every release. Every time.

These are not aspirations or a maturity model. A release either clears all nine on the exact version being shipped, or it does not ship.

01

Compiler and build

Zero type errors and a clean production build. No warnings waved through.

02

Automated checks

The full static and unit suite passes, with no skipped check that lacks a named owner.

03

Database and schema

Verified on a disposable database. A fresh install and an upgrade from the previous version must produce identical structure and behaviour.

04

Operational chain

A complete supplier-to-customer journey runs end to end — including the refusals, the approvals and the reconciliation, not just the happy path.

05

Named target

The specific customer environment, operating model and configuration are read and recorded. Nothing about a live environment is inferred.

06

Real people, real devices

Every role in the operation completes their actual physical work in a browser or on a handheld, including the recovery scenarios.

07

Three human sign-offs

A walkthrough, a genuinely tested restore from backup, and a named on-call owner who has acknowledged the release.

08

One release gate

A single automated gate must return go on the exact version being released. If the version changes, the evidence is re-earned.

09

Rehearsed rollback

Feature disable, deployment rollback and data recovery are practised before release — not discovered during an incident.

And the rule behind the rules: acceptance attaches to one exact version, in one environment, for one customer scope. If the version changes, the machine evidence is re-run and the human sign-offs are reassessed. A deployment that succeeded yesterday never carries acceptance forward to today.
Deliberate boundaries

What Lumanw is not.

Vendors are rewarded for saying yes to everything. It makes evaluation harder and deployments worse. These are the things we have decided not to be, and we would rather you know now.

A universal ERP or accounting ledger

We integrate with the system that owns your financial truth. We do not try to become it.

A full WMS, TMS or MES replacement

We provide fit-for-purpose native execution where you have a gap, and coordinate with specialist systems where you already have one.

A marketplace or a logistics operator

Lumanw is a technology company. We do not run warehouses, vehicles or fulfilment networks, and we do not compete with our customers.

A robotics or telematics manufacturer

We stay hardware-agnostic and integrate through certified adapters and partners.

Autonomous black-box AI

Every AI action stays evidence-backed, policy-bound, observable and human-governed. We do not ship autonomy we cannot explain or reverse.

A custom project dressed as a product

Your differences belong in versioned configuration, mappings and playbooks — not in a private fork of our codebase.

The obvious question

Why there are no customer logos on this website.

Because we have not earned them yet, and the alternative is to make them up.

Lumanw is in its founding deployment phase. We have built a substantial governed operational core — procurement, inbound, receiving and quality, inventory, orders and allocation, picking, packing, dispatch, delivery and returns — and we are proving it end to end with our first deployment partners against the standard above.

It would be straightforward to publish a set of plausible case studies with impressive percentages. That is common in this category, and it is one of the reasons operations leaders have learned to discount everything they read on a vendor website. We would rather give you three things you can actually check: the standard every release clears, the measures we agree with you before we start, and a first deployment narrow enough to judge on its own merits.

When our deployments produce measured outcomes, those outcomes — with their baselines and their caveats — are what will appear here. Until then, the platform overview explains how the coordination model works without presenting illustrative customer claims.

Founding Deployment Programme

Judge us on a single flow.

One site, one complete order-to-delivery flow, an agreed baseline and a published standard. If it does not move the numbers we agreed, you will know precisely that.