Failure
Conditions
The conformance conditions under which an implementation must be judged incompatible, nonconforming, indeterminate, or unable to support a claimed Foundational Survey Fabric capability.
Failure Conditions define when an implementation, result, serialization, profile claim, or compatibility declaration has not satisfied the governing Specification and Conformance rules.
The integrated Specification now makes many failure modes concrete across the solved candidate core. Conformance can therefore identify exact failures involving CRPC, Point / Segment / SCPE geometry, validation, normalization, exact predicates, ECEM semantics, FSF-CJSON-1.0 interchange, version compatibility, and independent reproducibility.
Failure classification must also preserve the difference among implementation defect, unsupported capability, Specification ambiguity, and behavior that lies outside the current canonical profile. A conformance framework is incomplete if it defines only success.
Conformance Principle A conformance claim is meaningful only if failure is defined.
Failure Is Now Executable for the Solved Core
The solved candidate profile now defines enough deterministic behavior to make failure directly testable rather than merely conceptual.
A failed exact predicate, invalid geometry acceptance, normalization mismatch, incorrect FSF-CJSON-1.0 byte sequence, ECEM meaning drift, hidden-state dependency, or unsupported capability misrepresented as canonical can now be identified as a concrete Conformance outcome.
Different Authoritative Results Constitute Failure
If an implementation produces authoritative canonical meaning that differs from the result required by the governing Specification for the same valid canonical input, the applicable Conformance claim shall fail.
Disagreement with an applicable exact Reference Vector likewise constitutes failure unless the fixture itself is shown to be defective or the underlying Specification is ambiguous.
Optimization, implementation preference, tolerance, or majority agreement shall not excuse disagreement in canonical truth.
The Same Input Must Receive the Correct Judgment
An implementation fails validation conformance if it classifies a canonical-valid input as invalid, an invalid input as valid, or a valid noncanonical input inconsistently with the governing normalization rules.
Where the current profile defines canonical valid, valid noncanonical, invalid, and explicitly unsupported behavior, those outcomes shall remain distinct.
Invalid Input Must Not Be Treated as Canonical
Acceptance of malformed CRPC, invalid Point / Segment / SCPE geometry, out-of-Domain content, malformed FSF-CJSON-1.0, ambiguous input, or other Specification-invalid data as authoritative canonical truth shall constitute failure.
Convenience repair may exist only outside canonical validation and shall not be represented as acceptance of the original invalid input.
Required Canonical Input Must Not Be Rejected
An implementation shall fail the applicable claim if it rejects valid canonical CRPC values, supported canonical geometry, required exact operations, or valid canonical FSF-CJSON-1.0 input that the claimed profile requires it to support.
A conforming implementation must recognize the canonical truth it claims to implement.
Equivalent Input Must Normalize Correctly
Where the Specification defines valid noncanonical representation, failure to normalize to the required canonical meaning or canonical form shall constitute failure.
This includes incorrect CRPC reduction, incorrect Segment endpoint order, non-idempotent SCPE normalization, incorrect traversal orientation, wrong start-vertex selection, or failure to remove exact redundant collinear middle vertices where required.
Normalization that changes mathematical or spatial meaning is likewise a failure.
Exact Geometry Questions Must Not Drift
Incorrect authoritative results for exact predicates within the supported core shall constitute Conformance failure.
This includes Point equality/order, orientation, Point-on-Segment, Segment intersection, Point-on-boundary, Point-in-SCPE, polygon validity, connectedness, containment, and geometric equivalence where governed by the Specification.
Tolerance and Approximation Cannot Establish Canonical Truth
Tolerance-based equality, silent rounding, hidden snapping, unresolved floating approximation, approximate predicate truth, implementation-specific convergence, or undetected lossy conversion shall constitute failure where exact canonical behavior is required.
Approximation may exist in rendering, UI, simulation, or higher-layer behavior, but shall not be mislabeled as foundational truth.
Mutable Context Must Not Change Canonical Output
If cache history, database sequence, storage order, random state, session context, user identity, ownership, locale, wall-clock time, or other hidden mutable conditions alter an authoritative result, the applicable Conformance claim shall fail.
State may improve performance. It may not participate in spatial truth.
Canonical Point Meaning Must Not Be Reinterpreted
A conforming implementation shall fail the applicable precision-semantics requirement if it interprets an exact canonical Point as a coarse cell, parent reference, uncertainty region, rounded location, or collection of finer descendants.
Compatible representational extension may increase exact expressive capacity, but meaning drift of a previously valid Point constitutes failure.
Canonical Serialization Must Satisfy the Governed Format
A serialization conformance claim shall fail if an implementation cannot correctly parse valid canonical FSF-CJSON-1.0, emits noncanonical bytes for a normalized supported object, accepts prohibited duplicate keys, misinterprets structured CRPC values, loses precision, violates required key order, or otherwise breaks the governed format.
Semantically equivalent but byte-different output is a failure where one canonical byte sequence is required.
Canonical Meaning and Bytes Must Survive Exchange
If canonical serialization followed by parsing fails to preserve identical canonical meaning, the applicable interchange claim fails.
Where the profile requires canonical byte reproduction after parse and re-serialization, failure to reproduce those bytes exactly also constitutes failure.
Compatible Evolution Must Not Change Place
A Conformance claim shall fail if an implementation applies a supposedly compatible Specification profile or encoding version in a manner that changes established CRPC meaning, Point meaning, geometry meaning, exact predicate result, normalization result, ECEM semantics, or governed FSF-CJSON-1.0 behavior.
Unknown or unsupported versions shall be identified explicitly rather than interpreted under guessed rules.
Canonical Truth Must Not Depend on Exclusive Access
An implementation fails the independent implementation requirement if authoritative results can be reproduced only through inaccessible code, proprietary services, private data, undocumented convention, exclusive institutional knowledge, or one privileged hidden implementation dependency.
Canonical meaning must remain derivable from the published governing materials.
Partial Core Support Is Not Full Conformance
Failure to satisfy any required capability of the claimed Mandatory Core profile shall prevent an implementation from claiming full compatibility with that profile.
Partial, experimental, or developmental support may be described accurately, but shall not be represented as full Conformance.
Canonical Truth Must Be Reachable
An implementation shall fail the applicable Conformance requirement if a valid finite canonical input cannot be resolved to completion where the Specification requires a deterministic authoritative result.
Indefinite convergence, potentially nonterminating interpretation, unresolved ambiguity, hidden dependency, or authoritative truth dependent on unresolved approximation is incompatible with the solved Mandatory Core.
Unsupported Is Not the Same as Incorrect
An implementation may encounter a capability, extension, future geometry type, or operation that lies outside its declared profile.
Unsupported behavior outside the claimed scope need not constitute Mandatory Core failure, but the implementation shall identify the condition clearly and shall not fabricate canonical behavior.
Undefined Mathematics Must Not Be Forced Into Pass or Fail
Where the governing Specification has not yet defined canonical semantics or output closure, Conformance shall not pretend the capability has a canonical success result merely because an implementation can compute something.
Such cases should be classified as outside the current canonical profile, unsupported, or otherwise indeterminate according to the eventual formal outcome taxonomy.
Current examples include unresolved general Boolean/composite output closure, arbitrary exact rotation, and unresolved general distance/path-length scalar forms.
Some Disagreement May Reveal a Defect in the Standard
If independent implementations reasonably produce different results because the governing Specification does not determine one authoritative answer, the issue shall be classified as a Specification ambiguity rather than automatically assigning implementation fault.
The ambiguity shall be resolved through the proper BitPangea Specification-governance process before a definitive Conformance judgment is made for the affected case.
Conformance testing may expose the need for clarification, but it does not itself establish amendment or succession authority.
Test Infrastructure Can Also Be Wrong
A disagreement with a Reference Vector or automated harness shall not automatically establish implementation failure if the fixture, expected result, parser, comparator, or test procedure itself is shown to be defective.
Conformance evidence shall therefore preserve enough provenance and reproducibility to distinguish implementation defect from test-system defect.
An Implementation May Claim Only What It Proves
A declaration that exceeds the Conformance classes, profile, Specification identity, normative encoding scope, operations, or capabilities actually demonstrated shall be invalid.
Reporting shall distinguish proven compatibility from unsupported, untested, experimental, noncanonical, or Specification-open behavior.
Different Problems Need Different Outcomes
The final Conformance framework should distinguish at minimum among: FAIL, UNSUPPORTED, INDETERMINATE, SPECIFICATION AMBIGUITY, and TEST / FIXTURE DEFECT, with additional categories only where operationally useful.
These names are candidate disposition concepts rather than final canonical machine-readable status identifiers. Final status codes and reporting schema remain open.
Correction Does Not Erase the Original Failure
A failed implementation may be corrected and retested, but the original failed result should remain distinguishable in Conformance evidence from the later successful result.
The formal retest procedure, evidence-retention policy, withdrawal rules, and superseded-declaration handling remain open.
Executable Failure Conditions Now Defined
Canonical-result mismatch; validity mismatch; invalid acceptance; valid rejection; normalization failure; exact predicate failure; approximation failure; hidden-state failure; ECEM meaning drift; FSF-CJSON-1.0 failure; round-trip failure; version drift; independence failure; incomplete core; nontermination; claim misrepresentation.
Still Open in Conformance
Final machine-readable failure codes; severity levels; formal disposition taxonomy; retest procedure; remediation process; test-harness defect procedure; withdrawn/superseded declaration handling; failure-report schema; and final treatment of indeterminate open-gate cases.
Failure Has Moved From General Doctrine to Concrete Candidate Outcomes
The original section correctly required Conformance to define failure rather than only success. The integrated Specification now supplies enough exact behavior to identify many concrete failure conditions across the solved Mandatory Core.
The remaining work is primarily formal outcome coding, retest/remediation procedure, machine-readable reporting, and final disposition rules for ambiguity, unsupported capability, open-gate behavior, and test-system defects.
Primary Referenced Findings
This Conformance section is derived especially from Requirements Findings #10, #24, #30, #57, #63, #66, #71–#75, and #78–#85.
Architectural Boundary Failure must expose incompatibility, ambiguity, hidden dependency, or unsupported scope. It must not be hidden by approximation, convenience, higher-domain leakage, or ambiguous claims.