Version / Conformance
Vectors

Compatibility Preserves Meaning; Conformance Proves Defined Behavior

The present candidate model separates three questions:

What does the governing Specification define?
What capability does the declared Conformance profile require?
What did the implementation actually prove?

Reference Vectors provide evidence for those questions. They do not create missing Specification mathematics or canonical institutional authority.

Day #126 lineage reconciliation further distinguishes mathematical identity, representation identity, format identity, and Specification identity. Compatible evolution may change the latter three only where lossless, deterministic correspondence preserves the same normalized mathematical object and established canonical place.

Compatible Evolution Must Preserve Established Place

Reference Vectors shall include canonical Points, Segments, SCPEs, and other supported objects established under an earlier compatible Specification and evaluated under a later compatible Specification.

Previously valid canonical spatial meaning shall remain unchanged. Compatible evolution may add newly expressible exact values or governed capabilities, but it shall not migrate or reinterpret established objects.

Unchanged Operations Must Produce Unchanged Results

Where an operation's governing semantics are unchanged across compatible versions, the same canonical input shall produce the same canonical result.

If a later version changes only representation while preserving mathematical meaning, Reference Vectors shall distinguish representational difference from semantic incompatibility.

Encoding Evolution Must Preserve Canonical Meaning

Reference Vectors shall test compatible interchange evolution around FSF-CJSON-1.0 and any later explicitly governed profile.

Where compatible versions permit different lossless encodings, semantic equivalence shall remain exact even if byte identity across distinct encoding versions is not required.

Later Compatible Implementations Must Continue to Understand Earlier Canonical Truth

The corpus shall include earlier valid canonical objects and serialized forms that a later compatible implementation is required to interpret correctly.

Backward compatibility shall preserve exact meaning rather than merely accepting syntax while changing interpretation.

Future Capability Must Be Identified Rather Than Guessed

Reference Vectors shall include valid future or optional capability outside the implementation's declared support scope.

Such cases shall be classified as VALID BUT UNSUPPORTED where the governing profile permits that state. Unsupported capability shall not be fabricated, approximated, or misreported as invalid canonical mathematics.

Extension Must Not Mutate Existing Canonical Meaning

Reference Vectors shall demonstrate changes that are compatible because they preserve prior canonical meaning while adding clarification, new optional capability, additional Reference Vectors, broader exact representational capacity, or explicitly governed lossless interchange.

Compatibility is therefore a semantic preservation claim, not merely a shared version family label.

Representations may evolve. Canonical place may not drift. A compatible successor may expand exact capability, governed limits, or lossless representation forms, but it may not use those changes to move, renumber, reinterpret, or silently migrate previously established canonical place.

Spatial Mutation Must Be Classified as Incompatible

A change that renumbers, relocates, reinterprets, or reuses an established canonical Point or geometry shall not be classified as compatible evolution.

Reference Vectors shall expose such mutation as an incompatibility. Conformance may detect the condition; it does not authorize it.

If BitPangea ever authorizes an intentionally incompatible successor, that event requires separate institutional succession / migration governance. It cannot be represented as ordinary compatible refinement.

Required Defined Behavior Must Pass

The corpus shall include known-good implementation outcomes for Mandatory Core behavior whose Specification semantics are fully defined.

Every evaluator applying the same Specification, Conformance profile, fixture, and expected result shall classify those cases as PASS.

Incorrect Required Behavior Must Fail

Reference Vectors shall include outcomes that violate defined Mandatory Core behavior, including incorrect exact result, incorrect canonical normalization, incorrect canonical bytes where required, or incorrect validity classification.

Such cases shall receive deterministic FAIL disposition rather than being excused as implementation variation.

Outside-Scope Optional Capability Must Not Automatically Fail the Core

Where a capability is optional or outside the implementation's declared Conformance profile, absence of that capability shall be classified as UNSUPPORTED rather than automatically causing Mandatory Core failure.

The profile claim itself remains testable: an implementation may not claim capability it did not prove.

Undefined Mathematics Must Not Produce Fabricated Conformance Truth

Where the governing Specification has not yet selected one authoritative mathematical result, Reference Vectors shall not manufacture an expected canonical output.

Such cases shall remain outside final conformance disposition or be explicitly classified as indeterminate under the governing candidate framework until the Specification closes the dependency.

Conformance Outcome Depends on Declared Required Scope, Not Alternate Spatial Truth

Reference Vectors shall demonstrate how the same observed implementation capability may be PASS under one valid profile and UNSUPPORTED or FAIL under another, depending upon what that profile requires.

Profile scope classifies implementation obligation. It does not create alternate versions of canonical space.

Every Formal Outcome Must Be Traceable to Evidence

The corpus shall include Conformance Report examples linking implementation identity, governing Specification version, Conformance profile, Reference Vector or fixture identity, observed result, expected result, disposition, and supporting canonical output where applicable.

A PASS without traceable evidence is not equivalent to demonstrated conformance.

Formal Claims Must Not Exceed Proven Scope

Reference Vectors shall test whether a Conformance Declaration accurately reflects the evidence contained in its governing Conformance Report.

A declaration that claims a broader Specification version, profile, encoding scope, or successful outcome than the evidence demonstrates shall be invalid.

Conformance Must Be Reproducible Beyond One Implementation Environment

Where the Conformance framework requires independent reproduction, Reference Vectors shall support execution by a second implementation or evaluator using the same governing inputs and expected outputs.

Agreement strengthens proof of deterministic Specification behavior. Disagreement requires investigation rather than majority voting.

Equivalent Canonical Meaning Must Be Distinguished From Byte Identity

Where the Specification requires one canonical representation, conformance requires that exact representation. Where multiple explicitly governed lossless representations are permitted, conformance may instead require deterministic canonical-result equivalence.

Reference Vectors shall make that distinction explicit rather than assuming every semantic equivalence test is also a byte-identity test.

Governed Metadata and Representation Do Not Become the Place

The candidate lineage model distinguishes mathematical identity, representation identity, format identity, and Specification identity. Specification, encoding, and Conformance-profile identifiers may govern how an object is interpreted or tested.

None of those identifiers shall become part of the canonical spatial identity of the Point, Segment, SCPE, or Survey location represented. Where compatibility is claimed, different governed representations or versions must correspond losslessly and deterministically to the same normalized mathematical object.

Independent Evaluators Must Reach the Same Governed Disposition

Independent evaluators applying the same Specification, profile, fixture, expected result, and evidence rules shall reach the same PASS, FAIL, UNSUPPORTED, compatibility, or permitted indeterminate disposition.

Disagreement indicates evaluation defect, Specification ambiguity, profile ambiguity, fixture defect, or unresolved version dependency.

Version and Conformance Testing Now Has an Executable Candidate Proof Model

The original page already captured the correct conceptual separation among compatible evolution, Conformance profiles, and canonical authority. The principal change is that the Conformance framework is now concrete enough to support real candidate evidence cases rather than only future categories.

Section 11 can therefore test compatibility preservation, Mandatory Core outcomes, unsupported capability, profile scope, evidence traceability, declaration consistency, and independent reproduction. It shall still refuse to turn unresolved Specification mathematics into artificial pass/fail truth.

Referenced Requirements

Version / Conformance Vectors will derive especially from Requirements Findings #10, #16–#17, #22, #59–#61, #63–#64, and #78–#85.