open-standards/wai/live-conformance/iscc

live-conformance/iscc — ISCC content identifiers

The corpus of 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.