Software Has Billions of Names. It Still Lacks an ISBN for What It Does.

Books can be endlessly created, yet the systems around them do not
need an endless list of categories. A book receives an identifier. Its
editions, language, publisher, and format can be described separately.
The identifier space grows with publishing, while the structure of the
identification system remains finite.

Software has not achieved the same clarity.

We have excellent identifiers for important parts of the software
world. We can identify source artifacts, packages, components, installed
products, releases, and exact build outputs. But a surprisingly basic
question remains difficult to answer in a canonical, machine-readable
way:

What does this software do, and what is the minimum blueprint
that defines it?

A calculator, a spreadsheet, a payment service, and an autonomous
controller may be implemented in thousands of languages and distributed
through thousands of packages. Their repository names, vendors,
interfaces, and build hashes can all change. Some part of their
functional identity remains recognizable across those changes—but we do
not have a broadly accepted way to represent it.

I started the Standard Ten Software Blueprint, or STSB, as a public
experiment to test whether that missing layer can be built.

The experiment begins with ten candidate functional roots:

compute, record, create,
observe, communicate, coordinate,
decide, transact, simulate, and
control.

The important word is candidate.

STSB does not claim that these ten roots have been mathematically
proven complete. Version 0.1 closes the vocabulary temporarily so that
the proposal becomes falsifiable. If software exists whose essential
behavior cannot be represented as a composition of these roots, that is
evidence against the proposal—and exactly the kind of contribution the
project needs.

The problem
is not the number of software projects

GitHub alone contains an enormous and continuously growing population
of repositories. Add private systems, embedded firmware, mobile
applications, industrial controllers, research code, scripts, models,
packages, and services, and any attempt to maintain a flat list of
“software types” becomes hopeless.

But an endlessly growing population does not require an endlessly
growing foundation.

Natural language creates unlimited sentences from limited alphabets
and grammars. Chemistry describes an immense number of compounds through
a bounded set of elements and composition rules. ISBN does not solve
publishing by enumerating every possible future book; it provides a
stable scheme that can keep assigning identities as books appear.

The corresponding software question is therefore not:

How many applications exist?

It is:

Can the behavior of every application be described as a composition
drawn from a finite, versioned set of functional primitives?

That is a much smaller question, but it is not an easy one.

Why
existing software identifiers are necessary but insufficient

STSB is not intended to replace existing standards. It is designed to
connect to them.

• SWHID identifies immutable source artifacts.
• SPDX describes components, licenses, and relationships.
• Package URL identifies packages across ecosystems.
• SWID identifies software products and installed versions.
• Cryptographic digests identify exact build outputs.

Each system answers an important identity question. None is primarily
a canonical statement of functional identity and reproducible
intent.

Two artifacts can implement the same functional blueprint while
having different source histories, packages, products, and build hashes.
Conversely, two versions of the same named product can acquire
meaningfully different capabilities. Names and artifact identities alone
cannot express that distinction.

STSB proposes an additional connection layer. A conforming record can
connect:

• the software’s primary functional root and additional
  capabilities;
• its family and product identity;
• a blueprint seed and the generator that interprets it;
• source, package, release, and build identities;
• deployment and execution identities when those exist.

This makes the record more like a chain of claims than a new
universal serial number. The functional claim can remain stable while
the implementation artifacts evolve, and every reproducibility claim can
point to the exact evidence required to test it.

A calculator is a useful
test case

People naturally call a calculator a category of application. That is
useful in conversation, but it does not tell us whether “calculator”
must be a permanent root in a universal software taxonomy.

Under STSB, a calculator is primarily an instance of
compute. It may also record a history,
communicate results, or observe external
input. A collaborative scientific notebook could combine
compute, create, record, and
communicate. A payment platform may combine
transact, decide, record,
communicate, and coordinate.

The application label remains valuable. It becomes a family or
product description rather than an irreducible foundation.

This separation matters because product categories multiply whenever
a market, interface, or deployment platform changes. Functional roots
should change only when genuinely new essential behavior is
discovered.

The proposal therefore establishes a demanding test for a new
root:

Demonstrate observable, essential behavior that cannot be represented
through any composition of the existing roots.

A new industry name is not enough. A different programming language
is not enough. A new interface is not enough. The counterexample must
expose a missing functional primitive.

How do we know ten is enough?

We do not know yet.

Counting repositories cannot prove completeness. Sampling ten
thousand applications and fitting them into ten boxes would show
coverage of the sample, not coverage of all possible software. The
project needs a stronger evidence program.

STSB treats the problem as adversarial testing:

1. Build a census of materially distinct software families.
2. Encode representative blueprints using the candidate roots.
3. Record ambiguity when independent reviewers choose different
   roots.
4. Test whether each root is independently necessary.
5. Invite counterexamples designed to break the vocabulary.
6. Require new-root proposals to include observable behavior and
   reproducible evidence.
7. Repeat the process through versioned releases rather than declaring
   permanent closure.

The meaning of “closed” is therefore precise and limited: schema
version 0.1 accepts exactly ten root values. Closure makes
implementations interoperable and the hypothesis testable. It does not
prevent a later schema version from adding, removing, splitting, or
merging roots when evidence demands it.

This is similar to how an identifier standard can remain finite in
structure while its assigned population grows without a practical
endpoint. The rules are bounded; the records are not.

From taxonomy to blueprint

A taxonomy alone would not be enough. The more ambitious part of STSB
is the blueprint connection.

A blueprint identifies a seed by digest and a generator by stable
identity. A reproducibility claim must also identify the target,
toolchain inputs, and resulting build digest. This distinguishes several
things that software discussions often collapse into one name:

• the function a system performs;
• the family or product people recognize;
• the blueprint that expresses reproducible intent;
• the generated source;
• the published package;
• the exact build;
• the deployed and running instances.

This distinction may be useful for software catalogs, supply-chain
analysis, archival systems, reproducible builds, AI code generation,
procurement, and long-term maintenance. It could allow tools to ask not
only “Which package is this?” but also “Which blueprint does it
implement?”, “Which other implementations share that intent?”, and “What
changed: function, blueprint, source, or build?”

Those use cases remain hypotheses. The immediate task is to make the
proposal concrete enough to test.

The experiment is executable

STSB 0.1.0-rc1 is published as an open release candidate. The
repository includes:

• a candidate specification;
• a machine-readable ten-root taxonomy;
• a JSON Schema;
• a dependency-free Python validator;
• mutation and conformance tests;
• four reference blueprints;
• mappings to established identifier standards;
• governance, contribution, and versioning rules.

The implementation baseline can be checked with one command:

python3 release.py

That command validates the current machinery. It does
not prove that the taxonomy is complete. Four examples
test the schema and validator, not the universe of software.

This distinction is essential. A green test suite proves that the
implementation behaves as specified. It cannot prove that the
specification has captured every possible function.

What would disprove the
proposal?

The fastest way to improve STSB is not to agree with it. It is to
find the strongest counterexample.

A useful counterexample should identify a software system or
behavior, explain why the behavior is essential rather than incidental,
attempt a composition using the existing roots, and show exactly where
that composition fails.

There are several possible outcomes:

• the behavior fits an existing root after its boundary is
  clarified;
• it requires a composition that the examples did not previously
  demonstrate;
• two roots should be merged because they are not operationally
  distinct;
• an existing root should be split;
• a genuinely new root is required;
• the entire finite-root approach fails.

Every one of those outcomes would be useful evidence.

Who should test it?

This project will improve fastest through disagreement between
different technical communities.

I am especially looking for participation from:

• software architects and domain-driven design practitioners;
• package registry and dependency-management maintainers;
• SBOM, SPDX, SWID, and software supply-chain specialists;
• reproducible-build and software-preservation communities;
• programming-language and compiler researchers;
• systems engineers working on embedded, industrial, robotic, and
  autonomous software;
• AI coding and program-synthesis researchers;
• ontology, classification, and standards experts.

The project also needs an independent validator written in another
language or architecture. A standard is not meaningfully interoperable
if its only implementation is the reference implementation maintained by
its proposer.

A public invitation

The goal is not to place every repository into a marketing category.
The goal is to discover whether software can have a stable,
compositional layer of functional identity connected to reproducible
blueprints and existing artifact identifiers.

Ten may be enough. Ten may be too many. Ten may be missing a crucial
primitive. The only responsible way to find out is to make the claim
precise, publish the machinery, and invite people to break it.

Read the specification, run the validator, submit a counterexample,
correct a standards mapping, or build an independent implementation:

Test
the Standard Ten Software Blueprint on GitHub

If the vocabulary survives serious adversarial testing, we will have
evidence for a useful new software identity layer. If it fails, the
failures will tell us what a better system must explain.

Either result moves the problem forward.