Found while investigating #251 (which turns on exactly this ambiguity, for one table row). Filing unassigned and separately, because #251's scope is a single row in reference/environment-variables.mdx while this is corpus-wide.
Measured on content/docs/ at origin/main = 8e665c7.
What is wrong
The bare phrase "the runtime image" is used on 11 pages with two incompatible referents, and no page disambiguates it at the point of use.
Referent A — the licensed, commercial ObjectOS image, selected by OS_EE_IMAGE, digest-pinned, distributed from a private registry:
deploy/index.mdx:3,6 — "ObjectOS Self-Managed is delivered as a licensed, pre-built runtime image."
deploy/docker.mdx:3 — "Run the licensed ObjectOS runtime image with Docker"
deploy/air-gapped.mdx:84 — "The runtime image lives in a private registry"
Referent B — the Apache-2.0 ObjectStack framework image:
resources/license.mdx:104 — "What's Apache-2.0 (in the framework repository): the runtime image, all @objectstack/* npm packages ..."
Neutral or unscoped uses that inherit whichever referent the reader arrived with: architecture.mdx:120, reference/environment-variables.mdx:89 and :159, reference/runtime-capabilities.mdx:59, build/marketplace.mdx:60, configure/runtime.mdx:25.
reference/cli.mdx:55 is the only site that disambiguates, and it does so in prose rather than by a convention: "on the ObjectOS runtime image a non-default value refuses the boot".
Why it matters
The two images have different licences, different distribution channels, and different boot behaviour. A sentence about one is not true of the other, so an unscoped "the runtime image" sentence is unverifiable by construction — a reader cannot tell which artifact to test it against, and neither can a contributor fact-checking the page.
This is not hypothetical: #251 was filed because a reader measured an unscoped behavioural claim against referent B when the page's own frontmatter scopes it to referent A. The measurement was correct and the conclusion it invited was wrong. That failure mode is available on every page in the neutral list above.
It also interacts with the boundary that closed #59 set — "previously published images are out of scope — do not document, reference, or preserve compatibility with them" — which reads as a decision that this site speaks about referent A, while resources/license.mdx still (correctly, and necessarily) speaks about referent B.
What a fix probably needs
Not a rename of every occurrence. The cheap, durable shape is a naming convention applied where a sentence is behavioural rather than descriptive:
- Pick distinct terms — e.g. "the ObjectOS runtime image" (A) and "the ObjectStack framework image" (B) — and use the bare phrase nowhere that a claim depends on which one is meant.
- Apply it first to the pages that make falsifiable boot claims (
reference/environment-variables.mdx, reference/cli.mdx, deploy/*), where an unscoped sentence is actively misleading.
- Leave the descriptive, referent-independent uses (release-axis framing in
architecture.mdx / configure/runtime.mdx) alone.
⚠️ Sequencing note: the specific row at reference/environment-variables.mdx:159 is already owned by #251 and is blocked on a reading of the release deploy bundle. Do not resolve that row here — this card is the convention, not the row.
Related: #251, #59, #60.
Found while investigating #251 (which turns on exactly this ambiguity, for one table row). Filing unassigned and separately, because #251's scope is a single row in
reference/environment-variables.mdxwhile this is corpus-wide.Measured on
content/docs/atorigin/main=8e665c7.What is wrong
The bare phrase "the runtime image" is used on 11 pages with two incompatible referents, and no page disambiguates it at the point of use.
Referent A — the licensed, commercial ObjectOS image, selected by
OS_EE_IMAGE, digest-pinned, distributed from a private registry:deploy/index.mdx:3,6— "ObjectOS Self-Managed is delivered as a licensed, pre-built runtime image."deploy/docker.mdx:3— "Run the licensed ObjectOS runtime image with Docker"deploy/air-gapped.mdx:84— "The runtime image lives in a private registry"Referent B — the Apache-2.0 ObjectStack framework image:
resources/license.mdx:104— "What's Apache-2.0 (in the framework repository): the runtime image, all@objectstack/*npm packages ..."Neutral or unscoped uses that inherit whichever referent the reader arrived with:
architecture.mdx:120,reference/environment-variables.mdx:89and:159,reference/runtime-capabilities.mdx:59,build/marketplace.mdx:60,configure/runtime.mdx:25.reference/cli.mdx:55is the only site that disambiguates, and it does so in prose rather than by a convention: "on the ObjectOS runtime image a non-default value refuses the boot".Why it matters
The two images have different licences, different distribution channels, and different boot behaviour. A sentence about one is not true of the other, so an unscoped "the runtime image" sentence is unverifiable by construction — a reader cannot tell which artifact to test it against, and neither can a contributor fact-checking the page.
This is not hypothetical: #251 was filed because a reader measured an unscoped behavioural claim against referent B when the page's own frontmatter scopes it to referent A. The measurement was correct and the conclusion it invited was wrong. That failure mode is available on every page in the neutral list above.
It also interacts with the boundary that closed #59 set — "previously published images are out of scope — do not document, reference, or preserve compatibility with them" — which reads as a decision that this site speaks about referent A, while
resources/license.mdxstill (correctly, and necessarily) speaks about referent B.What a fix probably needs
Not a rename of every occurrence. The cheap, durable shape is a naming convention applied where a sentence is behavioural rather than descriptive:
reference/environment-variables.mdx,reference/cli.mdx,deploy/*), where an unscoped sentence is actively misleading.architecture.mdx/configure/runtime.mdx) alone.reference/environment-variables.mdx:159is already owned by #251 and is blocked on a reading of the release deploy bundle. Do not resolve that row here — this card is the convention, not the row.Related: #251, #59, #60.