Standards & Foundations
One standard, shared by every product built on it
A protocol, a query language, a data format: a standard several products are built on is usually redefined inside each one, so the same spec lives in many places and drifts a little in each. UPG registers a specification once as a canonical entity in the shared registry. Specs relate to other specs, the primitives they define compose and reach the product surface, and every product that implements, exposes, or conforms to a standard links to that one node. The question of which products touch OpenAPI, and how each one touches it, resolves to a single read.
A specification lives once in the shared registry
A specificationspecificationA specification entity is a canonical registry entity, governed by the organisation that stewards it. Each productproductThe product being created, the root of the graph implements, exposes, or conforms to it with a typed edge, rather than carrying its own private copy as a feature.
The same standard is then one node, touched in several typed ways. When a version changes, the graph names every product that has to move, and the question “how does this product use OpenAPI?” resolves to a traversal.
Define a governed standard once as a canonical specification in the registry, then every product that implements, exposes, or conforms to it links to that one node instead of redefining it as a per-product feature. Ask which products touch OpenAPI, and the graph answers, including how each one touches it.
A specification relates to other specifications
A specificationspecificationA specification entity is governed by the organizationorganizationThe top-level organisational entity that stewards it, extends the version it succeeds, and competes with the alternatives in its space.
The foundations a portfolio rests on are then a queryable layer. Which spec a standard extends, or which standards compete for the same job, is a traversal of the graph rather than a fact held only in a senior engineer’s memory.
specificationA specification entityorganizationThe top-level organisational entityspecificationA specification entityspecificationA specification entityA specification is a canonical registry entity with a life of its own. It is governed by the organisation that stewards it, extends the version it succeeds, and competes with the alternatives in its space. So the foundations a portfolio rests on are a queryable layer, not folklore: ask which spec a standard extends, and the graph answers.
Primitives are the units a specification defines
Below specifications sit the compositional units they define. A primitiveprimitiveA primitive entity is defined by its specificationspecificationA specification entity, composes the other primitives it is built from, and is stored as the data type that persists it.
The foundation is then traceable from a governed concept down to the bytes that hold it. A block, a reference, a query value: each is a node, named once, rather than a definition re-explained in every implementation.
primitiveA primitive entityspecificationA specification entityprimitiveA primitive entityBelow specifications sit the compositional units they define. A primitive is defined by its specification, composes the other primitives it is built from, and is stored as the data type that persists it. So the foundation is traceable from a governed concept all the way down to the bytes that hold it.
A primitive reaches the product surface
A productproductThe product being created, the root of the graph exposes a primitiveprimitiveA primitive entity, a featurefeatureA product capability or feature manipulates it, and an api contractapi_contractAn API contract or specification speaks the specificationspecificationA specification entity directly.
A governed standard sits one edge from the feature that uses it and the contract that implements it. Change the primitive, and the graph names the features that manipulate it before anything breaks.
primitiveA primitive entityapi_contractAn API contract or specificationThe loop closes on the product surface. A product exposes a primitive, a feature manipulates it, and an API contract speaks the specification directly. So a governed standard is not an abstraction floating above the product: it is one edge from the feature that uses it and the contract that implements it.
One shared node, one queryable blast radius
This is where the registry pays off across a portfolio. Four products touch one specificationspecificationA specification entity, each a different way (one implements it, one exposes it, a featurefeatureA product capability or feature conforms to it), and all link to the same canonical node.
When the standard bumps from 3.0 to 3.1, the blast radius is a query: the graph names every product and feature that has to move, before a migration surprises one team at a time. The foundation is shared because every product links to the same canonical node.
This is why the registry matters across a portfolio. Four products touch one specification, each a different way, and all link to the same canonical node. So when the standard bumps from 3.0 to 3.1, the blast radius is a query: the graph names every product and feature that has to move, instead of a migration that surprises one team at a time.
Foundations is the layer a portfolio shares, so it pairs naturally with orchestration and the engineering that speaks the standards. Follow a thread:
Specifications and primitives, and the registry edges that bind products to them, with every property and edge.
The portfolio tier where a shared specification is registered once for many products.
The API contracts and services that speak a specification and expose its primitives.