Picture a meeting room.
A test results report is open on the screen. Red bars, numbers, cryptic file paths. The developer speaks with confidence: "We hit 78% coverage. The 3 failing cases are edge cases — safe to ignore." The planner nods. Not because they understood. Because they had no language left to ask.
This is not the story of one team. It is a scene that repeats in nearly every software organization, every sprint.
Whose Responsibility Is Quality?
Software quality is "everyone's responsibility," they say. The planner must write clear requirements. The developer must implement carefully. QA must verify thoroughly. True enough. But look at the actual tools used to check quality, and the story changes.
Test coverage reports speak in source file paths. Bug trackers are filled with component names and stack traces. CI/CD pipelines judge success and failure by build numbers and commit hashes. The only people who can read these languages fluently are developers.
When a planner asks, "Was the email duplicate check on the sign-up screen properly tested?" — the answer usually goes: "Let me check the UserController coverage… hold on…" That "hold on" becomes five minutes, then ten, then "I'll get back to you."
Does a High Number Mean Safety?
Coverage: 78%. What does this number actually say?
It means 78% of the codebase was exercised by tests. But what about the other 22%? "Edge cases — safe to ignore," the developer says. The planner has no way to verify. They have no choice but to trust the developer's judgment.
There is a deeper problem. Coverage is measured against code. But the units that planners care about are not code. They care about "sign-up," "order cancellation," "password change" — whether those screens and functions actually work.
Code-based 78% might be feature-based 60%, or feature-based 90%. Nobody knows. The units of measurement were different from the start.
Why Are Test Documents Always Written at the End?
In many projects, test documentation is created near the end of the project. As the audit deadline approaches or the delivery date looms, someone opens a spreadsheet and begins "recording" test cases — retroactively documenting things that were tested weeks ago.
Everyone knows this is wrong. So why does it keep happening?
Because test execution and documentation were never connected from the start. Testing runs on top of code. Documentation lives in separate files. The two worlds are separated by design. Connecting them requires manual effort — and that effort naturally gets pushed to the end.
The Common Root
Look at the three fractures together:
These three problems share a single root: the unit of software quality management is "code."
When code is the unit, anyone who doesn't know code is permanently locked outside. When coverage is measured in code paths, you can't have a conversation with someone who thinks in screens. When tests are managed through code changes, there is no way to connect a planning change to a test change.
A different unit is needed. One that developers understand, planners understand, and PMs can nod at — all at once.
Manufacturing Already Solved This
The interesting thing is that manufacturing solved a very similar problem decades ago.
A single car is made of tens of thousands of parts. If designers, manufacturers, quality inspectors, and procurement teams all speak different languages, the factory cannot run for a single day. Manufacturing solved this with a BOM — Bill of Materials. Every part gets a unique ID. That ID becomes the common language through which design, production, quality, and procurement are all connected.
Doesn't software need something like this?
Not code files — but human-scale units: "sign-up screen," "order cancellation function," "password change process." And a unique ID on each unit, so that planning, development, testing, and documentation all connect under the same number.
That was the starting point for SOM.