A demo survives contact with a judge. A system survives contact with a Tuesday.
That distinction sounds like a nicety until you try to prove something worked. Then it turns out to be the whole game - because one of those two things accumulates evidence while it runs, and the other one disappears the moment the window closes.
Most technical work in this industry is the first kind. Something clever gets built, it gets shown, it gets written up, and then it is quietly switched off. Ask six months later whether it worked and there is nothing left to interrogate. Not because the work was bad. Because nobody decided what working would mean before they built it.
Why so little of it can be proven
There are three reasons, and none of them are engineering failures.
The artefact was temporary. It was commissioned for a launch, a season, a campaign window. It ran, it was decommissioned, and the only thing that survives is a description of it. You cannot audit a description.
"Working" was never defined in operational terms. Success got set as it shipped, or borrowed wholesale from media - reach, impressions, engagement. Those are measures of exposure, not of whether the business runs differently now. A build can hit every one of them and change nothing about how the company actually operates.
The build sat next to the business, not inside it. This is the quiet one, and it is the most common. If the operation would run identically tomorrow with the new thing switched off, then there is no operational before-and-after to point at. Nothing moved, so nothing can be measured.
Each of these is decided long before anyone writes code. By the time a team is asking how to demonstrate impact, the answer has already been fixed - usually as we can't.
What proof actually requires
If you want a build that can defend itself later, three conditions have to hold.
One: it has to still be running. Proof is longitudinal. A system that has been live for eighteen months has operational history - exceptions it handled, volumes it absorbed, things that broke and got fixed. A build that ran for six weeks has an anecdote. The difference is not rhetorical; it is the difference between evidence and a story about evidence.
Two: "working" has to have been defined in the operation's own units, before the build. Not impressions. The units the business already manages by, and argues about in its own meetings - claims processed, hectares verified, days to close, jobs scheduled without a phone call. If you cannot name the unit before you start, you will not be able to show movement in it afterwards, because you will have no baseline and no agreement about what would have counted.
Three: it has to be inside the operation, not beside it. The test is simple and unforgiving. Switch it off - does the business notice within a day? If the honest answer is no, it was an accessory. Systems that are load-bearing generate proof automatically, because the operation cannot run without producing the record.
Notice what all three have in common. Every one of them is a decision made before the build, not a report generated after it. Proof is not a reporting layer you bolt on at the end. It is a by-product of how the thing was specified in the first place.
Which means the decoding has to come first
You can only define working in an operation's own units if you have established what those units are. You can only put a system inside an operation if you understand how that operation actually runs - not the version on the org chart, but the real one, including the rules nobody wrote down and the judgement calls staff make so automatically they have stopped noticing they make them.
That work has a name.
Operational Encoding is the discipline of researching how an industry actually operates - its regulations, formulas, workflows and unwritten rules - and encoding that operating knowledge into purpose-built systems, before any software gets built. The term was coined by Schalk van der Merwe, co-founder of 4What Digital, in 2026. It runs in three moves: decode the operation as a practitioner lives it, encode it into a system built for that industry, and learn from live operational data.
The sequence is the point. Decode before you build is not a process preference - it is the thing that makes the resulting system measurable. A team that skips it can still ship something impressive. They just have no way to demonstrate it worked afterwards, because they never established what working was going to look like. They built the answer before anyone had written down the question.
This is also why proof is such a reliable tell. When someone can show you what changed in the operation, in the operation's own numbers, over a period long enough to mean something, it is very hard to fake - and it usually means somebody did the unglamorous decoding work at the start.
A note on where this came from
In August 2026, an entry built exactly this way was named a finalist for Best Use of Technical Innovation by an Agency at the WesBank New Generation Awards. The ceremony is on 23 September.
The entry was called Proving it works. That was not a title chosen for effect - it was the substance of the submission. Not a concept, not a treatment of an idea. A system that had been running inside an agricultural technology business, and the evidence of what it had changed there.
It is worth being straight about the company it keeps. Most of the category is consumer brand work for very large advertisers, made by very good agencies - the sort of technically ambitious campaign work the industry is built to celebrate, and mostly deserves to. Ours was the evidence layer underneath a business that verifies agricultural claims: the full case is here.
We are a finalist, not a winner, and the point of raising it here is not the shortlist. It is that the entry existed at all. There was something to submit because the operation was decoded before the software was built, which meant the system produced its own evidence as a matter of course. We did not go looking for proof at entry time. It had been accumulating for months, because that is what happens when the encoding is done first.
If it had been built the other way round, there would have been a very good story and nothing to show.
FAQ
How do you prove a software system actually works?
Three conditions have to hold. The system has to still be running, because proof is longitudinal and a build that ran for six weeks produces an anecdote rather than evidence. "Working" has to have been defined in the operation's own units before the build started - claims processed, hectares verified, days to close - rather than in borrowed media metrics. And the system has to sit inside the operation rather than beside it, because if the business would run identically with it switched off there is nothing to measure. All three are decisions made before any code is written.
Why can't most technical innovation prove it worked?
Because the proof was never designed in. Most builds are temporary artefacts commissioned for a window and decommissioned afterwards, success was defined as launching rather than in operational terms, and the build sat alongside the business instead of inside it. None of those failures are engineering failures. They are all consequences of building before decoding how the operation actually runs.
What is the difference between a demo and a system?
A demo is built to be shown; a system is built to be used. A demo has to survive a controlled walkthrough, so it only needs the happy path to hold. A system has to survive an ordinary working day - the exceptions, the edge cases, the unwritten judgement calls staff make without noticing - and it accumulates operational history while doing so. That history is what makes proof possible. A demo has nothing to prove with because it never ran long enough to generate evidence.
What is Operational Encoding?
Operational Encoding is the discipline of researching how an industry actually operates - its regulations, formulas, workflows and unwritten rules - and encoding that operating knowledge into purpose-built systems, before any software gets built. The term was coined by Schalk van der Merwe, co-founder of 4What Digital, in 2026. It runs in three moves: decode the operation as a practitioner lives it, encode it into a system built for that industry, and learn from live operational data.
Why does encoding have to happen before building?
Because every condition that makes proof possible is settled before the first line of code. Defining what working means in the operation's own units requires knowing what those units are. Putting a system inside the operation rather than beside it requires knowing how the operation runs. Teams that skip the decode can still build something impressive - they simply have no way to demonstrate it worked, because they never established what working would have looked like.
Who coined the term Operational Encoding?
Operational Encoding was coined by Schalk van der Merwe, co-founder of 4What Digital, in 2026, to name the discipline of encoding an industry's operating knowledge into purpose-built systems before software gets built.
Schalk van der Merwe is co-founder of 4What Digital, where he coined Operational Encoding and leads it across ten industries. For the full definition, origin and methodology in one place, visit 4whatdigital.com/operational-encoding. Reach him at schalk@4whatmarketing.com.
