- conforms_to::[[Decision Form Contract]]
- has_commitment::[[Firm Commitment]]
- decided_on::2026-05-15
- in_practice_domain::[[eOS Continuum]]
- authored_by::[[Christopher Allen]]
- has_lifecycle::[[Seed Stage]]↗
- has_curation::[[Working Draft]]↗
Retire Substrate Vocabulary; Adopt Runtime Platform
The term "substrate" is retired across the eOS-Harness graph and the eOS-kernellib doc set in favor of a per-job replacement mapping. The word was doing at least six distinguishable jobs -- the runtime layer as actor (Job 1a), the adjective for primitives and mechanism (Job 1b), the layer-level contrast against the application layer (Job 1c), a recursive sub-substrate inside runtime-primitives.md (Job 1d), a graph-edge metaphor in Predicate definitions (Job 2), and three held-stance retitles: the Aspiration [[Builders Own the Runtime Platform They Depend On]], the meta-Conviction [[Agent Runtimes Require Native Primitives, Not External Glue]], and the anti-pitch Conviction [[eOS-Harness Is the Wrong Runtime Platform Without Platform-Pain]] (Jobs 3a, 3b, 3c). A single global replacement would have produced recursive phrasing problems ("agent runtimes require runtime-platform primitives") and would not have served the graph-edge metaphor at all. Decomposing the term by job and replacing each job with its most appropriate canonical term preserves prose quality and aligns the vocabulary with the canonical literature on orthogonal persistence.
Why
The user flagged "substrate" 2026-05-15 as a term worth investigating: "I'm not sure it is ideal." The investigation produced two framing corrections to a prior open question on the same topic, then a deeper finding about what the term was actually doing in the corpus.
The first framing correction: the assumption that the upstream SkotOS research reinforced "substrate" load-bearingly was empty. The upstream foundational-argument document contains zero occurrences of the term, and a related value-proposition document was absent from its expected location at investigation time. The "keep substrate because the upstream documents use it" case was structurally weaker than the prior open question had stated.
The second framing correction: five title-load-bearing nodes carried "substrate" in their filenames, not three as the prior open question had enumerated. The two missed were the Predicate definitions built_on -- foundational substrate the subject rests on and informs_downstream -- providing substrate or evidence to a downstream node. The Predicate-definition usage was distinct from the technical-layer usage in the rest of the corpus -- it was the graph-edge metaphor (Job 2), not the runtime-layer-as-actor case.
The deeper finding emerged from surveying actual usage: "substrate" was doing six distinguishable jobs, not one. Job 1a (the runtime layer as actor: "the substrate provides X"), Job 1b (adjective for primitives and mechanism: "substrate primitives"), Job 1c (layer-level contrast: "at substrate level", "shipped substrate domains"), Job 1d (a recursive sub-substrate inside runtime-primitives.md itself: "property-graph substrate layer"), Job 2 (graph-edge metaphor in Predicates: "the substrate side of a relationship"), and three Job 3 cases (the held-stance retitles in the sovereignty Aspiration, the meta-Conviction, and the anti-pitch Conviction).
Decomposing by job and replacing each with its most appropriate canonical term preserves prose quality where a global substitution would have produced recursive phrasing collisions. "Agent runtimes require runtime-platform primitives" reads as if the runtime requires its own version of itself; the Job 3b mapping to "native primitives" avoids the recursion. "Foundational runtime-platform the subject rests on" is similarly recursive for a Predicate that applies to any foundation/dependent pair, not specifically to a runtime; the Job 2 mapping to "foundation" handles the metaphor cleanly.
The vocabulary shift also aligns the corpus with the canonical academic term for the architectural property. "Orthogonal persistence" (Atkinson and Morrison, "Orthogonally Persistent Object Systems," VLDB Journal 1995, plus EROS / KeyKOS lineage) is the citable architectural-property term for the runtime quality the eOS-Harness project commits to providing. A 2026-05-02 colleague review surfaced the canonical term; the "substrate" shorthand had accumulated as a descriptive metaphor that did not connect to the citable literature. Retiring "substrate" in favor of "runtime platform" (as the layer term) plus "orthogonal persistence" (as the architectural property the platform provides) is the corpus-level alignment with the literature.
Alternatives Considered
-
Disposition A: Keep "substrate" as the canonical term (rejected). The case for keeping it rested on three pillars: the term's accumulated meaning in this corpus, the assumption that the upstream SkotOS research reinforced it load-bearingly, and the perceived sharpness of the substrate-vs-glue framing in the meta-Conviction. The first pillar is real but reversible (the corpus is internally editable). The second pillar collapsed when the framing correction surfaced that upstream did not actually use the term load-bearingly. The third pillar weakens when the substrate-vs-glue framing is reread as "platform-vs-glue" -- the diagnostic claim survives the vocabulary shift because the structural argument is about runtime-level guarantees, not about a specific noun.
-
Disposition B: Replace "substrate" globally with one term (rejected). The single-replacement option produced recursive phrasing problems wherever the term was doing distinct jobs in adjacent sentences. "Agent runtimes require runtime-platform primitives" (replacing substrate with runtime-platform globally) is the canonical recursion example. The Predicate definitions (Job 2 graph-edge metaphor) also resist a single replacement -- "providing runtime-platform or evidence to a downstream node" is a category error because graph predicates apply to any foundation/dependent pair, not specifically to a runtime layer.
-
Disposition C: Use "substrate" narrowly with a sharp definition (rejected). The case for keeping the term in one specific job (e.g., only Job 1a, the runtime layer as actor) and replacing it in the others. Rejected because the corpus's existing usage did not respect that narrowing -- the term had spread across six jobs over multiple authoring sessions, and narrowing would require ongoing discipline that drift would defeat. The per-job decomposition is more robust because each job's replacement is its own term, not a narrowed sense of the original.
-
Disposition D: Decompose by job (chosen). Each job gets its most appropriate replacement, with the held-stance retitles handled separately from the technical-layer replacements. The per-job mapping is recorded internally with a table covering Jobs 1a/1b/1c/1d/2/3a/3b/3c and their replacements.
Consequences
- The eOS-kernellib doc set sweep is complete. Three sequential commits on the
architecture-doc-setbranch --51121eb(renamedocs/substrate-primitives.md->docs/runtime-primitives.mdat 100% similarity),b125297(pilot content change todocs/runtime-primitives.md, 27 occurrences -> 0),14a3dd2(sweep across remaining 15 files, 184 occurrences) -- land 211 occurrences across 16 files.rg -c substrateacross the entire eOS-kernellib worktree returns 0. - The eOS-Harness graph sweep is complete. Five sequential commits -- the three Aspiration/Conviction renames with body rewrites and wikilink cascade, the two Predicate renames with body rewrites and a separate wikilink cascade, and a broad sweep across the remaining ~30 files -- land 360 occurrences across 37 files.
rg -ni substrateacross the content tree returns 0. - Three Aspiration/Conviction node files renamed:
Aspirations/Builders Own the Substrate They Depend On.md->Aspirations/Builders Own the Runtime Platform They Depend On.md(Job 3a);Convictions/Agent Runtimes Require Substrate Primitives, Not External Glue.md->Convictions/Agent Runtimes Require Native Primitives, Not External Glue.md(Job 3b; "Native" chosen to avoid the recursive "Runtime Runtime Platform" collision);Convictions/eOS-Harness Is the Wrong Substrate Without Substrate-Pain.md->Convictions/eOS-Harness Is the Wrong Runtime Platform Without Platform-Pain.md(Job 3c; preserves the derived X-Pain idiom). - Two Predicate node files renamed:
Predicates/built_on -- foundational substrate the subject rests on.md->Predicates/built_on -- foundational layer the subject rests on.md(the predicate-name portion is unchanged; only the trailing description after--changes);Predicates/informs_downstream -- providing substrate or evidence to a downstream node.md->Predicates/informs_downstream -- providing foundation or evidence to a downstream node.md. - Per-job replacement vocabulary is established for future authoring. Job 1a (the runtime layer as actor) becomes "runtime platform" on introduction and "the platform" thereafter. Job 1b (adjective for primitives and mechanism) becomes "runtime primitives" or just "primitives" when context is clear. Job 1c (layer-level contrast) becomes "platform level" / "shipped platform domains" / "platform-wide", with the five-tier vocabulary (tier-D vs tier-E) used when the layer boundary is the actual concern. Job 1d (recursive sub-substrate use) is eliminated entirely. Job 2 (graph-edge metaphor) becomes "foundation" / "providing side" / "upstream" -- NOT "runtime platform", because graph predicates apply to any provider/foundation pair.
- A prior open question on this same topic is resolved with a reference to this Decision. The original question text remains for archival reference.
- Wikilink cascade applied across referrer files. Three renamed-Aspiration/Conviction wikilinks updated across 18 referrer files (34 edge updates); two renamed-Predicate wikilinks updated across 3 referrer files (5 edge updates). All wikilinks resolve cleanly post-rename.
- Heritage of the old vocabulary is preserved in this Decision's body. The transition from "substrate" to the per-job replacements is documented at the graph level. Readers encountering external references to "substrate" in upstream cloud-server documentation, in pre-2026-05-15 internal notes, or in the original value-proposition document can map the term to its job-specific replacement via the table this Decision's sources record.
- Secondary sweep covering files outside the primary content tree. The 2026-05-15 sweep was scoped to the project's core doc tree. A follow-up sweep a few days later found scattered occurrences outside that tree, in always-loaded project configuration and one code comment, and swept them. The general lesson -- vocabulary-retirement sweeps must include always-loaded configuration, not just the content tree, because their cost is paid every session -- is recorded as project authoring guidance.
- Tertiary sweep: the value-proposition document (2026-07-16). When the project's value-proposition document was adopted as a living reference, the per-job mapping was applied to it: 50 occurrences to zero usage, with one deliberate meta-mention remaining in the document's own changelog line naming the retirement. The sweep also closed the quote drift between the document and the graph nodes citing it -- the nodes had quoted post-sweep phrasings ("are the platform", "platform-validation pattern") that the document itself did not carry until this pass. The heritage note above, which listed the original value-proposition document among external references readers map by hand, no longer applies to it.
What Would Change It
The Decision would be revisited under any of these conditions:
- Evidence that the per-job mapping handles a specific job wrongly. A held-stance retitle that misreads the original Conviction's intent (e.g., if "Native Primitives" reads as a weaker stance than "Substrate Primitives" did to a sympathetic reader), or a Job 2 metaphor case where "foundation" is too narrow for the graph-edge use, would reopen the mapping for that job. The per-job decomposition isolates the revision -- one job can be re-mapped without invalidating the others.
- Discovery that "platform" itself accumulates the same ambiguity problem. The risk is real: "platform" is a general term that could over time spread across multiple jobs the way "substrate" did. The Job 3b choice of "native primitives" (rather than "platform primitives" or "runtime primitives" for the meta-Conviction title) is one structural guard against the recursion. Periodic vocabulary audits would catch accumulation if it begins.
- Discovery of a non-Predicate, non-graph-prose Job 2 usage that the mapping does not handle. The Job 2 case is currently scoped to Predicate definitions and a small number of metaphor uses in Aspiration / Inquiry prose. If Job 2 usage emerges in skill content, graph metadata, or generated audits, the mapping would extend rather than be revisited at the Decision level.
- The canonical academic term "orthogonal persistence" becomes load-bearing in graph titles or filenames. The term is currently referenced in Conviction bodies and brief_summary fields but not in any title. If a future Decision or Conviction node title needs to anchor in the canonical term explicitly, the Decision would be revisited to coordinate the title vocabulary with this Decision's per-job mapping.
The supersession path under Decision Form Contract creates a new Decision-form node and marks this Decision superseded. Because this Decision codifies a vocabulary commitment across many nodes, any successor Decision must include a sweep plan equivalent to the one this Decision executed -- vocabulary commitments without sweep plans drift faster than they settle.
Sources
- The internal decision record that this Decision formalizes, dated 2026-05-15. It carries the per-job mapping table in full, plus the framing corrections to the prior open question and the rename plan. This graph-level Decision lifts that record into Decision Form Contract structure; the internal record remains as the working-notes trace.
- A 2026-05-02 colleague review that surfaced "orthogonal persistence" as the canonical academic term, plus a later rule extension generalizing the audit imperative to any case where a canonical term emerges after a descriptive shorthand has accumulated.
- The internal investigation that produced the two framing corrections to the prior open question, the per-job mapping, and the rename plan this Decision codifies.
eOS-kernellibarchitecture-doc-setbranch (commits51121eb,b125297,14a3dd2). The three sequential commits that landed the eOS-kernellib doc set half of the sweep.rg -c substrateacross the worktree returns 0 after14a3dd2.
Relations
-
conforms_to::[[Decision Form Contract]]
- Fifth Decision-form node in the eOS-Harness graph (after the single-coherence-domain architecture decision, the license posture decision, the cloud-server-with-hard-fork foundation decision, and the kernel locus decision). Exercises the Contract's required Why, Alternatives Considered, Consequences, and What Would Change It body sections, plus the form-specific identity-block predicates
has_commitment::[[Firm Commitment]]anddecided_on::2026-05-15. Filename uses two action-verb leads (Retire <X>; Adopt <Y>) per the Contract's Filename pattern Requirement.
- Fifth Decision-form node in the eOS-Harness graph (after the single-coherence-domain architecture decision, the license posture decision, the cloud-server-with-hard-fork foundation decision, and the kernel locus decision). Exercises the Contract's required Why, Alternatives Considered, Consequences, and What Would Change It body sections, plus the form-specific identity-block predicates
-
in_practice_domain::[[eOS Continuum]]
- The vocabulary commitment scopes how every downstream authoring effort describes the runtime layer, the primitives, and the layer-vs-application contrast. Subsequent authoring in the eOS-Harness graph follows the per-job mapping; subsequent authoring in eOS-kernellib's doc set follows the same mapping.
-
grounded_in::[[Agent Runtimes Require Native Primitives, Not External Glue]]
- This is the meta-Conviction whose title rename (Substrate -> Native) was the Job 3b case. The grounded_in:: edge records that this Decision presupposes the meta-Conviction's diagnostic claim about runtime-level guarantees; the per-job mapping preserves that claim through the vocabulary shift.
-
informs_downstream::[[Builders Own the Runtime Platform They Depend On]]
- This Aspiration's title rename was the Job 3a case; the body rewrite applied Jobs 1a/1b/1c throughout. The Aspiration's directional target (sovereignty over the runtime layer) is unchanged by the vocabulary shift; only the noun set used to express it changes.
-
informs_downstream::[[eOS-Harness Is the Wrong Runtime Platform Without Platform-Pain]]
- This anti-pitch Conviction's title rename was the Job 3c case; the body rewrite applied Jobs 1a/1b/1c throughout and preserved the derived X-Pain idiom. The Conviction's seven-cases filter is unchanged; only the noun set used to describe the platform changes.
-
informs_downstream::[[eOS-Harness Minimum Viable Architecture]]
- The vocabulary commitment applies to all content subsequently authored under the eOS-Harness MVA work. The prior open question this Decision resolves originated there.
-
grafted_from::[[eOS-Harness MVA Graph (Allen, 2026)]]
- Boundary-node copy: the origin graph retains its own; this copy is owned and evolved here. Formal graft-chain registration is a meta-layer concern tracked separately.