Conformance
Classes

Conformance May Now Test the Solved Core

Specification Sections 01–07 now contain an integrated candidate core sufficiently deterministic for executable Conformance work. Conformance shall test that defined core exactly as specified; it shall not invent semantics for open mathematical gates.

The current candidate mandatory scope includes exact coordinate representation, canonical frame behavior, core primitive geometry, exact validation and predicates, deterministic normalization, canonical machine serialization, precision-extension semantics, and implementation-independent canonical output.

Classify Capability, Not Truth

Conformance classes shall provide a structured way to describe which defined portions of the Foundational Survey Fabric Specification an implementation supports and has successfully demonstrated.

A conformance class may organize required tests, interfaces, representations, or optional capabilities, but it shall not create a competing canonical interpretation of BitPangea space.

A Common Exact Core Is Required

Every implementation claiming compatibility with the current candidate FSF core shall satisfy the mandatory behavior defined for all solved foundational capabilities within that claimed profile.

The candidate mandatory core presently includes, at minimum: exact CRPC parsing and normalization; canonical frame interpretation; Point, Segment, and SCPE validation; exact core geometry predicates; canonical geometry normalization; FSF-CJSON-1.0 parsing and serialization; ECEM-compatible precision behavior; deterministic validity handling; no silent snapping; and reproducible canonical results.

No optional class, optimization, alternate internal representation, derived encoding, or extension may substitute for failure to satisfy that mandatory core.

Additional Capability May Be Declared Separately

Conformance may define optional capability classes for functions, representations, or future Specification profiles that are useful but not required to establish compatibility with the candidate mandatory core.

Optional classes shall extend implementation capability without altering, overriding, weakening, or creating an alternate form of mandatory canonical truth.

No optional class shall be used to claim canonical support for mathematics that remain open in the Specification.

Unspecified Mathematics Are Not Conformance Classes

A capability whose canonical semantics or output closure remain unresolved in the Specification shall not be promoted into a conformant optional class merely because an implementation can compute some result.

Current examples include general Boolean/composite output closure, arbitrary exact rotation closure, unresolved exact general distance and path-length scalar forms, and other explicitly open Specification gates.

Conformance shall mark such capabilities unsupported, outside the claimed profile, or otherwise noncanonical until the governing Specification defines them.

Capability Boundaries Must Be Explicit

Each conformance class or profile shall define its scope, dependencies, required behaviors, applicable Reference Vector categories or proof obligations, and success conditions.

Implementations shall not infer compliance with one class solely from successful implementation of another unless the governing Conformance specification explicitly establishes that dependency.

All Classes Resolve to the Same Spatial Truth

Where two implementations claim support for the same canonical operation or expression, identical valid canonical inputs shall produce the same authoritative canonical meaning.

Where the governing Specification defines a unique canonical representation, normalization, or canonical byte sequence, conforming implementations shall produce that same canonical result.

Differences in programming language, architecture, storage, caching, optimization, or internal representation shall not alter authoritative output.

Classes Must Define Valid and Invalid Behavior

A conformance class shall identify the required validation behavior for the expressions and operations within its scope, including treatment of canonical input, valid noncanonical input, malformed expressions, out-of-domain references, unsupported result forms, and other invalid states applicable to that class.

For the current core, Conformance shall preserve the distinction among canonical valid, valid noncanonical, and invalid.

Invalid input shall not be silently repaired, rounded, snapped, guessed, or reinterpreted into canonical truth.

No Reduced Truth Through Class Selection

No conformance class may replace canonical exactness with tolerance-based equality, hidden snapping, unresolved approximation, implementation-specific state, or device-dependent precision.

Derived or lossy representations may be tested where explicitly defined, but they shall remain distinguishable from authoritative canonical output.

Compatibility Must Be Identifiable

Each conformance claim shall identify the applicable Specification identity or governed profile, version information where defined, normative serialization/interchange rules, and conformance class or classes against which the implementation was evaluated.

For the current solved core, canonical machine interchange is governed by FSF-CJSON-1.0. A claim covering canonical serialization shall therefore identify that format explicitly.

Final top-level FSF Specification identifier syntax remains a Specification-wide open item and shall not be invented by Conformance.

Every Tested Capability Needs Reproducible Proof

Each mandatory conformance capability shall be associated with applicable Reference Vectors or equivalent executable proof obligations sufficient to establish deterministic expected behavior.

Reference Vectors demonstrate the Specification. They do not create missing semantics, replace Specification text, or authorize behavior outside the defined profile.

Conformance Must Be Independently Demonstrable

A valid conformance class shall be defined so that independent implementers can evaluate the same requirements, execute the same applicable Reference Vectors or proof obligations, and reach the same conformance judgment.

Conformance shall not depend on proprietary interpretation, unpublished behavior, hidden test logic, exclusive institutional knowledge, or shared implementation state.

An Implementation May Claim Only What It Proves

An implementation shall claim only those conformance classes or profiles for which all mandatory tests and conditions applicable to that scope have been satisfied.

Partial support, experimental behavior, implementation-specific extensions, untested functions, or behavior for Specification-open mathematics shall not be represented as canonical conformance.

Failure Must Remain Visible

A failed mandatory test, canonical-byte mismatch, invalid normalization result, unsupported open-gate operation, or other required proof failure shall remain a conformance failure or unsupported capability as defined by the applicable profile.

Conformance shall not convert failure into success by tolerance, fallback interpretation, alternate canonical meaning, or implementation-specific exception.

Mandatory-Core Scope Is Now Concrete Enough to Test

The previous Conformance 01 structure correctly required one mandatory foundational truth and optional capability above it. The integrated Specification now makes the solved mandatory-core scope sufficiently concrete for executable Conformance design.

This section does not canonically adopt a final taxonomy for every future FSF capability. It establishes the testable candidate mandatory core and the rule that unresolved Specification mathematics remain outside canonical conformance until formally defined.

Primary Referenced Findings

This Conformance section references especially Requirements Findings #10, #24, #30, #32, #57–#60, #63–#66, #68, #71–#75, and #78–#85. The findings remain authoritative within the Requirements Framework; this page does not duplicate or replace them.