Issue 123: the image registry is named after a role, and *artifact* is defined as one format #126

2026-09-26T13:37:55Z

jschoubben commented

2026-09-26 13:37:55 +00:00

Files the confusion itself, rather than leaving it in a conversation.

Three wordings disagree:

The glossary defines artifact as "an OCI image, by digest" — while a definition's own build vocabulary names four kinds, all in use in the catalogue: image (48), upstream (3), bundle (1), archive (1), with the controller's code documenting the field as "image or archive". The catalogue already builds artifacts that are not images; the word for them means image; the store named after the word serves images only.
The seat is named after a role, and no other seat is. ADR 0079 names foundation seats after their servers; ADR 0109 settled that a package registry seat is one per ecosystem. the-artifact-store is named after neither its server nor what it serves — the last registry named after the job it happens to be doing.
A module is not an image. An image is one thing a module may build; it may also ship archives, files, directories, databases and a service it did not build at all. Prose that says "the module's image" reads as though a module were an image, and the manifest's vocabulary does not — it says artifacts, each with a kind.

The report also records the question the naming hides. ADR 0075 keeps two provisions because packages and images are two protocols — a language's client cannot install from an OCI registry — and it already allows the forge to provide artifact-store, saying a mesh may choose it. So the second implementation rests on a bootstrap argument: something must serve images before the mesh can build. That argument is weaker than it reads, because the forge's server is an upstream public image and only its sidecar is built (issue 121's step 4, retracted in hq #125), and the store and broker have that same shape — which ADR 0078 raises at genesis as plumbing and adopts in place.

Open questions include the one worth deciding first: does the mesh need two registry implementations at all, or can the forge hold every registry seat once adopted in place? Plus what can be checked mechanically, so a rename does not become prose the code disagrees with.

Checks: cycle 287 documents, the chain holds; records 104, all passed; index current.

Files the confusion itself, rather than leaving it in a conversation. Three wordings disagree: 1. **The glossary defines *artifact* as "an OCI image, by digest"** — while a definition's own build vocabulary names four kinds, all in use in the catalogue: `image` (48), `upstream` (3), `bundle` (1), `archive` (1), with the controller's code documenting the field as "image or archive". The catalogue already builds artifacts that are not images; the word for them means image; the store named after the word serves images only. 2. **The seat is named after a role, and no other seat is.** ADR 0079 names foundation seats after their servers; ADR 0109 settled that a package registry seat is one per ecosystem. `the-artifact-store` is named after neither its server nor what it serves — the last registry named after the job it happens to be doing. 3. **A module is not an image.** An image is one thing a module may build; it may also ship archives, files, directories, databases and a service it did not build at all. Prose that says "the module's image" reads as though a module were an image, and the manifest's vocabulary does not — it says artifacts, each with a kind. The report also records the question the naming hides. ADR 0075 keeps two **provisions** because packages and images are two protocols — a language's client cannot install from an OCI registry — and it already allows the forge to provide `artifact-store`, saying a mesh may choose it. So the second **implementation** rests on a bootstrap argument: something must serve images before the mesh can build. That argument is weaker than it reads, because the forge's server is an upstream public image and only its sidecar is built (issue 121's step 4, retracted in hq #125), and the store and broker have that same shape — which ADR 0078 raises at genesis as plumbing and adopts in place. Open questions include the one worth deciding first: does the mesh need two registry implementations at all, or can the forge hold every registry seat once adopted in place? Plus what can be checked mechanically, so a rename does not become prose the code disagrees with. Checks: cycle 287 documents, the chain holds; records 104, all passed; index current.

jschoubben added 1 commit 2026-09-26 13:37:55 +00:00

Issue 123: the image registry is named after a role, and artifact means one format 3abb3a3c07

Three wordings disagree, and the confusion is the damage: the glossary defines artifact as an OCI
image while the build vocabulary already names four kinds in use, two of which are not images; the
image registry's seat is named after its job while ADR 0079 names foundation seats after their servers
and ADR 0109 names package seats after their ecosystem; and prose that says 'the module's image' reads
as though a module were an image.

Records the question the naming hides: ADR 0075 keeps two provisions because packages and images are
two protocols, and already allows the forge to provide the artifact store. The second implementation
rests on a bootstrap argument, and the forge has the same upstream-server shape the store and broker
have, which ADR 0078 raises as plumbing and adopts in place.

jschoubben merged commit 007e3f4b03 into main

2026-09-26 13:38:00 +00:00

jschoubben deleted branch issue/123-the-image-registry-is-named-after-a-role

2026-09-26 13:38:00 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#126