Research: Contract C version compatibility and downgrade RC0

[camerontjs-dot]

Classification

Draft Research Infrastructure / Contract C version-compatibility evidence. Do not merge. No released Contract C mutation, official successor-version assignment, translation-adapter authorization, release, tag, promotion, Decision Engine production change, Contract E, or operational authorization.

Exact lineage

• qualified non-deciding predecessor receipt: ad1ffbd7906a7cf34cce5afa906a5797cd4a14ff (Draft PR Research: Contract C non-deciding shadow RC0 #85 lineage)
• exact base branch: research/contract-c-version-compat-rc0-base-20260910
• exact tested implementation head: a8ee05e758a7be97c567cdc95ff70db75814946d
• terminal-record head at PR creation: 194a84ec11fc19dbdfd1db5c5747951ae6364324
• released Contract C validator blob held fixed: 9c75ccfbf2223578a8d1a7bf0c39673b394fbea4
• released Contract C 1.0 schema blob held fixed: b0369de9b5c156322d6787261bbc7658a3b33781

The predecessor research/contract_c_non_deciding_shadow_rc0/** tree was held byte-stable during this compatibility experiment.

Question

Can the qualified non_deciding representation be migrated compatibly without laundering its neutral causal provenance into released Contract C 1.0, and what SemVer-class signal follows from observed consumer behavior under project governance?

Decisive execution

Run 34530811489: PASS.

• tested head: a8ee05e758a7be97c567cdc95ff70db75814946d
• disposition: SUPPORTED_PARALLEL_VERSIONING_AND_BREAKING_CHANGE_SIGNAL
• artifact: 10173394540
• digest: sha256:0080176223202f7c55bdedb602692429946518d04fa8c7fb52d6fbd62bc5f6eb
• released Contract C regression: 17 passed, 8 skipped

Observed compatibility

The cohort established:

• released 1.0 accepts released 1.0;
• released 1.0 rejects the widened successor/shadow unchanged;
• successor authority accepts the successor/shadow;
• an existing strict 1.0 consumer breaks on successor bytes;
• the supported migration pattern in this cohort is parallel_exact_version_authority_no_downgrade.

Validator selection is bound to an independently established expected profile. The object’s own version field must agree with that selected authority; it does not choose its own validator.

Validator-valid semantic-laundering downgrades

All three attempted successor -> 1.0 translations could produce validator-valid 1.0 objects while changing/erasing the qualified semantics:

1. map_non_deciding_to_support
2. map_non_deciding_to_counterevidence
3. drop_non_deciding_and_repair_basis

Therefore “it validates as 1.0” is insufficient evidence of a faithful migration. A semantic downgrade adapter is not authorized by this experiment.

Version-class signal

Project release governance says version class follows demonstrated consumer compatibility, not edit size. Existing strict 1.0 consumers do not accept the successor unchanged, so the evidence signal if this in-band successor were later promoted is MAJOR.

No official Contract C successor version is assigned here. This PR does not establish or authorize 2.0.0.

Bounded inference

Parallel exact-version authority with no downgrade is supported for this exact candidate. A major in-band successor remains viable, but this experiment does not establish that widening Contract C is the smallest sufficient architecture.

Highest-value successor

Test the strongest remaining alternative: a separately immutable companion receipt bound to exact Contract C 1.0 that preserves all neutral unresolved causal contributors and their multiplicity without changing Contract C 1.0 bytes.

A successful richer sidecar would falsify the claim that a major Contract C wire revision is presently necessary. A sidecar that loses evidence identity, basis membership, multiplicity, proposition/result binding, or fail-closed authority remains falsified.

[camerontjs-dot]

Successor update: richer-sidecar alternative tested

A stronger sidecar successor was pressure-tested in Draft Research PR #87. It repaired the old sidecar's evidence-level multiplicity defect and reached SUPPORTED_RICHER_SIDECAR_TECHNICALLY_SUFFICIENT on exact released Contract C 1.0, preserving U1/U2 and independent_sufficient_alternatives without changing Contract C bytes.

That result removes technical information transport necessity as an argument for an in-band successor.

However, reconciliation against EDR-002 / issue #17, Contract C promotion PR #18, the frozen 1.0 conformance manifest, and the accepted Contract/Apparatus Separation Invariant falsifies the richer sidecar as the governing-interface replacement under current authority. The required provenance and causal-multiplicity invariants are assigned to Contract C itself, and downstream authority must flow through the governing contract rather than a producer-side companion convention.

Therefore the in-band candidate remains the smallest currently authority-conformant repair among the tested alternatives. This does not promote it or assign an official version. The MAJOR compatibility signal in this PR remains evidence about a future in-band successor if later promoted.