epiphany/CONFORMANCE.md

# Determinism Conformance Statement

This is the published conformance statement required by the core
specification's Determinism Contract (`core_spec` Appendix D,
§"Conformance Statement", `sec:det:conformance`). It covers the reference
implementation in this repository — the `epiphany-*` workspace crates — as of
the tree that carries this file. Every claim below is anchored by a test named
in the Canonical Byte-Layout Reference (Appendix E) or cited inline.

## Platform and floating-point library

The reference build and CI platform is Linux on x86-64, compiled with stable
Rust (MSRV pinned in `Cargo.toml`, `rust-version = "1.77"`), default target
options — no `fast-math`-class flags anywhere in the workspace.

Canonical state contains no *computed* floating-point values. Every float that
enters canonical state is a stored `CanonicalF64` (finite by construction,
`-0.0` canonicalized) serialized as its 8 little-endian IEEE 754 bytes
(`epiphany-determinism/src/float.rs`); no canonical algorithm derives new
float values into canonical state.

**Transcendental functions.** The only transcendentals in the workspace are
`f64::ln`/`f64::exp` from the platform's `std`/libm, used exclusively by tempo
integration (`epiphany-core/src/tempo.rs`, speed-linear and exponential
segments). Per the contract's required disposition, those conversion outputs
are declared **advisory and non-canonical**: musical time is the exact
rational, wall-clock time is exact integer nanoseconds, and no tempo-derived
float is stored in canonical chunks or hashed into canonical identity. If a
future feature promotes tempo-derived values into canonical state, adopting a
documented portable math library (or quantizing at the canonical boundary) is
a precondition, not an afterthought.

Content hashing is BLAKE3 (the `blake3` crate, workspace-pinned), which is
bit-exact by specification on all platforms.

## Parallel execution strategy

None. Every canonical algorithm — reduction, materialization, pre-passes,
encoding, hashing, layout solving — is single-threaded by construction; the
workspace contains no `rayon`, `std::thread::spawn`, or other concurrency in
any canonical path. The implementation *is* the single-threaded baseline, so
equivalence to that baseline holds by identity. Any future parallel execution
must demonstrate byte-identical output against this baseline before it ships.

## `-0.0` canonicalization and NaN/infinity rejection

`CanonicalF64::new` rejects NaN and ±infinity at runtime in **all build
profiles** (not just debug assertions) and canonicalizes `-0.0` to `+0.0`
before storage, so both are unrepresentable in canonical state. Decoding
treats non-finite float bytes as corruption (typed error, never silent
acceptance), and hash preimages accept only `CanonicalF64` values. Locked by
the unit tests in `epiphany-determinism/src/float.rs` and
`src/serialize.rs`.

## Rounding

Round-to-nearest-ties-to-even is used at every canonical quantization
boundary: `QuantizedCoord` (1/1024 staff space) quantizes via
`round_ties_even` and rejects NaN/infinity/overflow rather than saturating
(`epiphany-determinism/src/coord.rs`), and `ResolvedLayoutIR` quantizes its
f32 working coordinates through the same type at canonical emission.

Declared deviation, inside the advisory surface only: the non-canonical
wall-clock conversion in `tempo.rs` rounds nanoseconds with `f64::round`
(half-away-from-zero). It shares the tempo-integration surface declared
non-canonical above; it must be converted to ties-to-even if that surface is
ever promoted.

## Canonical iteration orders

All canonically-serialized collections iterate in the contract's orders
(§`sec:det:ordering`):

- Generic containers are `BTreeMap`/`BTreeSet` or explicitly sorted through
  `CanonicalMap`/`CanonicalSet`/`sort_canonical`, whose element types must
  implement the `CanonicalByteOrder` marker — a type whose `Ord` does not
  match its canonical byte order is rejected at compile time
  (`epiphany-determinism/src/order.rs`).
- Operation envelopes reduce in the canonical order: causal (Kahn topological
  over DVV coverage), then the HLC tuple
  (`epiphany-ops/src/reduce.rs::canonical_reduction_order`), property-tested
  for permutation invariance at 1,000 envelopes × 10 orders plus a
  10,000-set fuzz gate.
- Conflicts serialize ascending by `ConflictId`; integrity anomalies ascending
  by `IntegrityAnomalyId`; chunk references by `(kind, hash, offset)`;
  extension declarations by `(ExtensionId, SemVer)` as numeric tuples —
  each rejected (not normalized) on decode when out of order.

`HashMap`/`HashSet` appear only in non-canonical lookup indexes, caches, and
diagnostics, or are projected through a sort before any canonical output.

## NFC normalization

Unicode normalization uses the `unicode-normalization` crate
(workspace-pinned, `0.1.x`). Catalog identifiers NFC-normalize at
construction (`epiphany-core/src/pitch.rs`); envelope string fields
NFC-normalize before hashing (`epiphany-ops/src/encode.rs`, test
`nfc_normalizes_before_hashing`); system-derived pitch identity NFC-normalizes
at the derivation boundary. Free-text fields are raw UTF-8 by the ratified
codec convention (`req:format:codec-conventions`) and are not folded.

## Declared open-question algorithms

Per §"Open Algorithm Hooks", every open-question area is either
profile-declared with a versioned identifier or errors rather than
substituting a vendor heuristic:

- **Spelling**: `SpellingAlgorithmId` `"default"` — a Temperley-style
  line-of-fifths preference algorithm, v1 (`epiphany-core/src/prepass.rs`).
  The identifier is the crate's proposal pending ratification (P12-H1). A
  profile requesting any other id errors; nothing is silently substituted.
- **Notational decomposition**: `DecompositionAlgorithmId` `"default"` — the
  integer-grid metric splitter, v1, with its scope bounds recorded as
  P12-H4 (single governing meter, `MAX_DOTS = 1`, tuplet-nesting deferred).
  Same no-substitution rule.
- Both pre-pass outputs are **canonical derived annotations**: deterministic
  functions of `(materialized graph, profile, algorithm id)` recomputed on
  materialization, never stored canonical state — so an algorithm version
  change deterministically invalidates derived output without state
  migration.
- **Tempo curves**: `TempoShape::Curve` integration is unimplemented and
  declared as such — conversion returns `CurveIntegrationUnsupported`
  rather than a wrong or vendor-specific answer. The linear/exponential
  segment integration and the `wallclock_to_musical` inverse (deterministic
  continued-fraction with documented iteration/denominator bounds and a
  typed `TempoIntegration`-class tolerance) are advisory, per the
  floating-point declaration above.