The software is the instrument.
The process is the product.
We are hired to make an operation behave predictably: to find where the work actually goes wrong, design the process that fixes it, and then build the thing that makes the new process hold when nobody is watching. Below are five working demonstrations of systems we have built and put into service. They are not videos. Press them.
None of this is a real client's data, and that is deliberate
The systems below run live operations. Their real contents — what is held, how much of it, where it sits, who moved it and when — are exactly the things an operator would least like published.
So every demonstration here runs on Meridian Provisions Co., a company we invented, in a building we drew, with a crew we made up, holding goods they do not sell. Nothing has been redacted or blurred out of a real screen. It was built new.
Why not just take the names off?
Because that does not work, and pretending it does is the actual risk. A floor plan is a fingerprint. A case study that removes the client's name while keeping their industry, their product line, their aisle scheme and their real capacity has not anonymised anybody — it has just declined to say the name out loud, while handing anyone who has stood in that building everything they need.
So the scale, the geometry, the product category and the identifiers here are all different on purpose, not lightly disguised. What is real is the method. If you become a client, this is the discretion you get.
Try to falsify this record
An append-only movement log where every record is hashed into the next. Change a quantity and watch the tamper announce itself — then do it the right way, by appending a correction that cites the original. Nothing is ever edited or deleted.
Open the demo →Stock that does not exist until somebody says so
Declared goods count as zero in every figure the business runs on until a named person approves them — enforced by the inventory system's own arithmetic rather than by a rule somebody forgets. Try to sell it. Try to walk it somewhere else.
Open the demo →The floor decides the number
One master layout derives every count downstream: positions, location codes, capacity, what the inventory system believes. Change the building with a slider and watch which figures follow — and watch the emailed capacity sheet sit there being wrong.
Open the demo →It has to work in the dead spot
Scan-to-place on the phone the operator already owns. Turn the signal off and keep working: the queue holds, says queued rather than showing a tick, and drains when the signal returns. Refusals name the exact permission that was missing.
Open the demo →No amount of crew fixes a wait
Earliest finish by headcount, derived from work content rather than asserted. Add people and most of the bar shrinks — and one block refuses to. That block is why the date could not land, and why we said so in September.
Open the demo →One plan, several systems, one direction
A role-loaded work breakdown kept in step across an issue tracker, a scheduling tool and the live operational system — with drift measured rather than assumed. On one engagement the embedded plan copy was 112 date rows adrift from the master and nothing had noticed. Detection took it to zero, and the missing refresh step became part of the build.
Described below ↓Three copies of a plan will disagree. The only question is whether you find out.
The shape
One generated master. Everything else is downstream of it and nothing writes back. Scope flows from the plan to the floor; status and dates flow from the floor to the plan; the two join on the work-breakdown code. The floor wins on what happened. The plan wins on what is meant to happen.
The failures we design against
A schedule import where every milestone is right and not one ordinary task carries a start or a finish — half right, which is worse than wrong, because it looks plausible enough to plan off. A reconciliation tool pointed at a plan copy two generations old, faithfully reporting gaps that did not exist.
The rule
Push once, then read the board back — never verify by echoing what you sent. Snapshot before the first write. Match on a stable identifier, never on a text summary somebody will reword. And keep a deliberately wrong case in the test set, so you can prove the check still fires.
A green check mark that has never been able to fail is decoration
Every system above is really the same commitment in a different costume: build the check that can catch you, then prove it can, then leave it running where it will be inconvenient.
That is why the ledger demo lets you break it, why the receiving demo tells you what the control cannot do, and why the layout demo shows you a sheet confidently being wrong. Those are not caveats we were talked into. They are the product.
- Derive, never assert. If a number can be computed from something real, computing it removes a whole class of future argument.
- Measure it before quoting it. And say plainly when a figure is an estimate instead of a measurement.
- Never fake a transaction. Not in a demo, not in a pilot, not to get through a meeting.
- Say the limit out loud. The thing our control does not cover is the thing the client most needs to know.
Proles Consulting — process optimisation, development and implementation. Every figure, name, code, location and date in these demonstrations was invented for the purpose. Where a real magnitude would have identified a client's premises, it was changed rather than published.