# live-conformance/iscc — ISCC content identifiers

The corpus of [`extensions/iscc.md`](../../extensions/iscc.md) §6: the ISO 24138 codes WAI computes,
held to the standard's public test vectors, and WAI's own cases of pre-processing and matching.

**Files.**

- `public.json`, not generated: the public test vectors, one case to a line, whose SHA-256 the
  extension pins. Its `image`, `audio`, `instance`, `code`, `seq_encode`, `seq_decode`, `data`,
  `video`, `text` and `meta` sections are transcribed from the ISCC reference implementation's
  conformance data, version 1.5.0 (a JSON file whose SHA-256 is
  `1609adb921983baf83f9aaf049ab8dc23f828c214f57c29e2bf852346c678eff`, published under the Apache
  License 2.0 by the ISCC Foundation): each case's name, its inputs (a 32 × 32 grey picture, a
  Chromaprint fingerprint, bytes in hexadecimal, units, frame signatures, a text, a name with a
  description and a meta element) and its expected output. A `meta` case's `meta` is the meta
  element as the source file gives it, `{"dataUrl": …}` or `{"json": …}`, the JSON object as the
  text the source file writes it in; its `payload` is the bytes §4.9 reads of it, in hexadecimal,
  which for a JSON object are the bytes the source file's own output states; `metaRead` is that
  output's `meta`, the data URL; and `titleRead`, `descriptionRead` and `metahash` are its `name`,
  `description` and `metahash`. Its `iep20_*` sections are typed from IEP-0020 §10.1 and §10.2 as fetched on
  10 November 2026: the four-unit sequence with its bytes, canonical form and base64, Table 2's
  sequences a decoder refuses (each with the table's reason), the sequence it accepts, and Table
  3's featureless Image-Codes with their bits set per segment.
- `vectors.json` and `pictures/`, written by `wai_iscc_vectors gen` from fixed seeds: each
  picture's size, the SHA-256 of its 32 × 32 picture (§4.3), its Image-Code of 256 bits and
  whether it is featureless; `thresholds`, one for each type that can be a candidate match;
  and each match of a soft binding (`binding`, an ISCC-SEQ in hexadecimal) against an asset: its
  bytes, a picture's PNG (`asset`) or a `buffer` by `length` and `seed` with the bytes at `flip`
  complemented, and the inputs the validator holds for it (`text`; `audio`, a fingerprint;
  `video`, frame signatures by `frames` and `seed`; `seed`, a `title`, a `description` and a
  `payload`), under the case's own `thresholds` where it states them, with what §5 states:
  `exact`, `matched`, `score` and each pair compared; and the generated cases of §4.6 to §4.9: `data` (a buffer by `length`
  and `seed`, its `chunks`' lengths and its Data-Code), `video` (frame signatures by `frames` and
  `seed`, and their Video-Code), `text` (a text, its `collapse`, its `characters` and its
  Text-Code) and `meta` (a `title`, a `description` and a `payload`, what §4.9 reads of them, the
  `metahash` and the Meta-Code; where the case gives a meta element, `meta` as above, the
  `payload` read of it and `metaRead`, its data URL), every code of 256 bits; and `metaRefused`,
  meta elements §4.9 refuses, each with its `reason`.

**Equivalence.** A conforming implementation computes every public vector's code, refuses or
accepts every sequence as stated, and gives every picture and match the values `vectors.json`
states (§6).

**Provenance.** The pictures are ramps, discs and bars the generator draws, written as PNG by the
packaging corpus's still writer; one is the first picture with one pixel altered after a binding
was computed from it, and one a single pixel.

**Checked by.** `wai_iscc_vectors verify` and `tests/iscc.rs` in `wai-rs`, and `../iscc_verify.py`,
the second implementation, written from the extension's text and the IEPs, which also requires
every mutated copy to be caught and every one of its own checks, dropped, to be caught.

**The four codes' tables.** The minhash, gear and winner-take-all tables are in the extension's
Annex A, transcribed from the reference implementation's source, version 1.5.0 (Copyright
2016-2026 Titusz Pan, Apache License 2.0), each source file named there by its SHA-256. The
Rust implementation holds them in `wai-rs/src/iscc/tables.rs`, and the Python one reads them
from the extension. The Rust implementation's Unicode data (`unicode_tables.rs`, of the Unicode
Character Database 17.0.0, Unicode License v3) is written by
`tools/wai_iscc_unicode_tables.py`; the Python one uses its own library's.

**Not cross-checked.** The JSON objects' payloads beyond the public vectors' four (the members'
order, the numbers' digits, the strings' escapes) are held to the two implementations here and to
RFC 8785 Appendix B's samples, which both replay in their own tests, not to another canonicaliser.
The pictures' Image-Codes, and so the matches of pictures, are WAI's pre-processing's
(§4.3); they are held to the two implementations here, not to another ISCC tool, whose
pre-processing differs (iscc §4.3). The public vectors are the cross-check of the transform, the
codec and the other codes. The generated texts' collapses are held to two Unicode libraries that
may be of different versions (iscc §4.7); they hold only characters assigned by Unicode 6.0.