Our Own Architecture Documents Say This Does Not Exist, and the Word "Subnet" Does Not Sound Like That

What this page describes is a specification with no deployment, and the vocabulary around it is the problem.

The vocabulary problem, in one line

"Subnet" is a noun that sounds deployed. So are "module", "layer", "runtime" and "execution environment". They name components, and a component is the kind of thing that either exists or does not.

Architecture vocabulary borrows that certainty. A diagram with six boxes reads as six things, and a reader has no way to tell which boxes are running, which are written and unshipped, and which are a paragraph in a design document.

That is not usually deception. It is the format doing the work, and it is why a buyer should ask about every box separately.

What this one is

A specification and some early exploration. There is no deployed subnet, no public endpoint, and nothing anyone outside can call.

Our own architecture documentation is direct about it: subnets, including this one, do not exist on the live network today. We are quoting ourselves because the internal document is more honest than the vocabulary is, and a reader encountering the word in a diagram would not guess that.

Why we are writing a page about something that does not exist

Because the alternative is that it appears in a list of capabilities and nobody says which kind of thing it is.

A specification is a legitimate artefact. Publishing a design before building it is how you get review, and pretending otherwise would be its own dishonesty. What is not legitimate is letting a specification sit in the same visual register as a running service and hoping the reader sorts it out.

So: this is a design. It has not been built. Nothing depends on it and nothing you build should.

The question a buyer should ask about any architecture diagram

"For each box: is it running, written but not deployed, or designed?"

Three states, and most vendor material collapses them into one. Ask for the list, and watch what happens to the diagram when the third category is coloured differently.

For us, on this component, the answer is the third, and several others on the same diagram are the first. The difference matters more than the diagram does.

What to ask any project with a modular architecture

"Which modules are deployed, named individually?" The list will be shorter than the diagram, everywhere, including here.

"What can I call today?" Endpoints are checkable. Boxes are not.

"What depends on the unbuilt parts?" If a shipped capability's story requires an unshipped component, the shipped capability is less shipped than it looked.

"Where does your own internal documentation contradict your marketing?" An unfair question, and the answer is informative. Ours contradicted it here, which is how this page came to exist.

Where this leaves a decision

If you need an execution environment for contracts, we do not have one, there is no endpoint, and no date attached to changing that.

If you are evaluating the parts of our architecture that are running, they are running, they have endpoints, and the honest way to read our diagrams is that some boxes are services and some are intentions until somebody tells you which.