SOM ID —
The Key That Makes Programs into Assets

The act of assigning a number looks simple. But it carries a powerful declaration inside:

"This exists. And it will continue to exist."

When a brake disc in a car factory receives the number P-4471, that component transforms from a piece of metal into a traceable asset. The number in the design drawing, the number on the warehouse shelf, the number in the quality inspection history — all the same. Whoever picks it up, whenever, wherever: P-4471 is P-4471.

SOM ID makes this declaration at the Program layer of software.

What Happens Without an ID

Consider the "sign-up screen."

The planner writes "Sign Up" in the screen definition document. The developer creates SignUpController.java and writes the sign-up.tsx component. QA creates test case "TC-SignUp-001." The documentation person saves "FunctionalSpec_SignUp_v1.2.xlsx."

The names are all similar. "Sign Up" appears in all of them. But the system has no way of knowing that these point to the same function. Connecting them requires a human to manually bridge the gap.

Six months later, the requirements change. Email verification is added to the sign-up flow. What needs updating? The screen definition? The test cases? The documentation? The code? If the right person remembers, you're lucky. If they've left the company, you start from scratch.

When the SOM ID Is Born

SOM ID is assigned at the planning stage.

This matters. Not after development is finished. Not after testing. Not after delivery. At the moment the screen definition is written — the moment the Program is confirmed — the ID is attached.

Because the ID is born at the planning stage, every subsequent artifact can reference it. When a developer writes code, they include // SOM-0042 as a comment or in the commit message. When QA creates test cases, they tag them with SOM-0042. The CI/CD pipeline connects execution results to SOM-0042. Documentation is automatically grouped under SOM-0042.

One number assigned by the planner runs through the entire project.

Everything One ID Connects

Taking SOM-0042 "sign-up screen" as an example:

All of this is connected under SOM-0042. From any direction, you can find everything else. A planner opening SOM-0042 sees test status. QA opening SOM-0042 sees requirements. A developer opening SOM-0042 sees the defect history.

The Lifetime of a SOM ID

The decisive difference between a Jira ticket and a SOM ID is lifespan.

A Jira ticket closes when the work is done. The "implement sign-up" ticket becomes Done and is forgotten by the next sprint. The feature is alive — but the ticket is closed.

A SOM ID never closes.

As long as the software is in operation, SOM-0042 is alive. A bug reported today accumulates in SOM-0042's history. When the UI changes next month, SOM-0042 is maintained. When the feature is overhauled in two years, SOM-0042's version increments — or it is retired. Even after retirement, the history remains.

This is what an asset means. Whether in use or retired, an asset has a history.

When Requirements Change

A requirement change arrives: email verification is being added to the sign-up flow. What happens to SOM-0042?

The planner updates SOM-0042's requirements. The change history is recorded in SOM-0042. The developer opens SOM-0042 to identify which components are affected. QA identifies which test cases linked to SOM-0042 need re-verification. Documentation auto-updates based on SOM-0042's change history.

No one needs to be asked. Open SOM-0042.

A Small Thing That Changes Everything

The SOM ID is not technically complex. It's a number.

But when you think back to what happened without that number — the retroactive documentation, the untraceable change impact, the quality information only developers could read — you realize how much one number changes.

This essay is based on the author's ideas and experience, written with the assistance of AI (Claude, Anthropic).