Skip to content

World substrate vNext: synthesis, promotion dispositions, and kernel boundary #1140

Description

@zachshallbetter

Parent: #1111
Depends on: completion/evidence from the vNext research graph, including #1112-#1139 as applicable

Goal

Produce the final evidence-bound architectural disposition for the World substrate vNext research program.

This is not an implementation epic and not a vote to merge everything that survived experimentation. It is the terminal synthesis gate that determines what, if anything, belongs in the shared Fundamental kernel.

Inputs

Consume the committed evidence from:

  • concept binding and terminology collision work;
  • boundary-extraction methodology and provenance graph;
  • IEPE/EQP research governance and anti-collapse conformance;
  • commitment, assurance, evidence durability, and closure/delta experiments;
  • semantic access/surface/expression/representation experiments;
  • history, admissibility, counterfactual, stochastic, and stability experiments;
  • physics/control specializations where they produced evidence;
  • HCML and SPS adversarial substrates;
  • cross-lane composition experiment;
  • foreign-substrate control;
  • independent validation.

A dependency may legitimately end HOLD/REJECT/NOT APPLICABLE. Synthesis must preserve that result rather than treating incomplete promotion as missing work.

Required disposition vocabulary

Every candidate concept/contract receives exactly one primary disposition:

PROMOTE

Evidence supports a domain-independent shared contract in the Fundamental kernel.

EXPERIMENT

Useful and sufficiently coherent to retain, but evidence is not mature enough for kernel promotion.

ADAPTER-ONLY

Needed to bridge a particular substrate or family of substrates, but not demonstrated as a shared kernel concept.

HOLD

Plausible research direction with insufficient evidence or unresolved collision. No kernel dependency may require it.

REJECT

Generalization failed, was falsified, duplicated an existing concept without value, or violated a protected boundary.

NOT APPLICABLE may be recorded per substrate/evidence source but is not a terminal candidate disposition.

Promotion record

For every candidate, record:

  • canonical name and Concept ID from provenance work;
  • exact proposed contract/API if PROMOTE;
  • originating pressure(s);
  • independent recurrence evidence;
  • foreign-substrate result;
  • composition result;
  • negative controls and falsifiers exercised;
  • structural / representational / convenience churn;
  • provenance grade and independence grade;
  • external prior-art relationship;
  • known non-applicable domains;
  • rejected adjacent generalizations;
  • terminology collisions;
  • migration/compatibility cost;
  • why the chosen disposition is warranted by the evidence rather than by conceptual appeal.

Kernel-boundary test

PROMOTE only if all are true:

  1. At least two genuinely different substrates require the distinction or contract.
  2. At least one supporting evidence path is not merely shared-author/shared-ancestry recurrence.
  3. Removing/collapsing it causes a demonstrated loss of truth, safety, authority, evidence, or explanatory fidelity.
  4. The concept has a negative control showing where it does not apply.
  5. It does not collapse an existing protected lane.
  6. It survives the cross-lane composition fixture.
  7. Its maturity does not outrun provenance.
  8. The kernel representation is smaller and more stable than leaving substrate-specific special cases in shared code.
  9. A simpler established abstraction does not explain the requirement equally well with less machinery.

Failure of any item prevents PROMOTE. It does not automatically imply REJECT.

Anti-bundling rule

Do not promote a conceptual family as a package merely because its members were researched together.

Examples:

  • WorldHistory may promote while ActionFunctional remains specialization-only.
  • evidence envelopes may promote while closure/delta remains experimental.
  • access projection may survive while a four-contract semantic split does not.

Each boundary earns promotion independently.

Required synthesis artifacts

  • candidate disposition matrix;
  • final dependency graph showing kernel vs experimental vs adapter/specialization surfaces;
  • promoted API/contract diff;
  • explicit list of concepts intentionally not added to the kernel;
  • retained negative-result ledger;
  • migration plan for promoted contracts;
  • deprecation/rename plan for terminology collisions, including any Receipt collisions;
  • unresolved research queue for EXPERIMENT/HOLD candidates;
  • final statement of what the vNext evidence does and does not establish.

Stop conditions

Stop and refuse a release-wide promotion decision if:

  • provenance for a promoted candidate cannot be reconstructed;
  • independent/foreign evidence required by the kernel-boundary test is absent;
  • composition testing reveals unresolved authority or truth leakage;
  • a disposition depends on an unrun gate presented as if it passed;
  • the evidence base changed after synthesis began without the synthesis input being repinned.

Acceptance

  • Every candidate has a terminal disposition with evidence references.
  • Every PROMOTE candidate passes the kernel-boundary test explicitly.
  • Every HOLD/REJECT result is preserved and visible.
  • The proposed kernel is smaller than the full research vocabulary.
  • No specialized physics, planning, publication, HCI, or assurance concept enters shared kernel solely because it is elegant or reusable.
  • Owner can review one bounded synthesis artifact and decide the actual vNext promotion scope.

This ticket is the last research gate before any release-level kernel promotion. Passing it does not itself authorize release or merge; promotion authority remains with the repository's named owner/maintainer process.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions