uor_addr/onnx/
mod.rs

1//! **`uor_addr::onnx` — the ONNX realization of UOR-ADDR.**
2//!
3//! Typed content-addressing for ONNX `ModelProto` files under a
4//! protobuf-canonical structural form. The default σ-projection is
5//! [`prism::crypto::Sha256Hasher`]; [`address_blake3`], [`address_sha3_256`],
6//! [`address_keccak256`], and [`address_sha512`] select the other axes
7//! ([`crate::hash`]).
8//! As with GGUF, the skeleton's leaf commitments are SHA-256 by
9//! canonical-form definition and the selected κ-axis `H` is applied on top
10//! (κ = `H(skeleton)`); the sha256 κ-labels are byte-identical to prior
11//! releases. Admits any known IR revision
12//! (`ir_version` in `1..=`[`ONNX_IR_VERSION_MAX`]`
13//! = 13`, the latest in `onnx.proto`); the `ir_version` is bound into the
14//! canonical form, so distinct revisions of the same logical model
15//! address distinctly.
16//!
17//! ## Authoritative sources
18//!
19//! - ONNX protobuf schema — <https://github.com/onnx/onnx/blob/main/onnx/onnx.proto>
20//! - ONNX IR specification — <https://github.com/onnx/onnx/blob/main/docs/IR.md>
21//! - ONNX versioning — <https://github.com/onnx/onnx/blob/main/docs/Versioning.md>
22//! - Protobuf v3 wire format — <https://protobuf.dev/programming-guides/encoding/>
23//! - SHA-256 σ-projection — NIST FIPS 180-4.
24//!
25//! ## Canonical form
26//!
27//! The ONNX spec defines no canonical form (protobuf v3 admits many
28//! byte-encodings of the same logical message); this realization defines
29//! one (canonical form v2 — [`CANONICAL_FORM_VERSION`]). It is a **flat
30//! skeleton**: the `ModelProto` structure emitted inline (opset imports
31//! sorted by `(domain, version)`, nodes in Kahn-topological order with
32//! lexicographic `(name, op_type, domain)` tie-break, name-sorted
33//! initializers / IO, typed-data-to-`raw_data` reduction, depth-bounded
34//! subgraph recursion emitted inline), in which every variable-length
35//! leaf — tensor data, strings, opaque sub-message payloads — is
36//! represented by its 32-byte SHA-256 digest, so the skeleton's size
37//! grows with structure, not model size, while still binding every weight
38//! byte into the κ-label. See [`value`] for the full byte layout.
39//!
40//! Under ADR-060 the **full skeleton** flows through the pipeline as a
41//! [`TermValue::Borrowed`](prism::operation::TermValue) carrier and ψ₉
42//! folds it through `H = Sha256Hasher` — there is no two-level commitment
43//! and no count / width cap. Two ONNX models that decode to the same
44//! logical content canonicalize to byte-identical skeletons and therefore
45//! to the same κ-label.
46
47pub mod dtype;
48pub mod model;
49pub mod pipeline;
50pub mod protobuf;
51pub mod shapes;
52pub mod value;
53pub mod verbs;
54
55/// Canonical-form version (see module docs). Bumped to 2 under ADR-060:
56/// the canonical form is now the full flat skeleton (no two-level
57/// commitment), so v2 κ-labels differ from the v1 commitment's.
58pub const CANONICAL_FORM_VERSION: u32 = 2;
59
60pub use dtype::OnnxDataType;
61pub use model::{
62    AddressModel, AddressModelBlake3, AddressModelKeccak256, AddressModelSha3_256,
63    AddressModelSha512, AddressRoute,
64};
65#[cfg(feature = "alloc")]
66pub use pipeline::{address, address_blake3, address_keccak256, address_sha3_256, address_sha512};
67pub use pipeline::{AddressFailure, AddressOutcome, AddressWitness, VerifyError};
68pub use shapes::bounds::{ONNX_IR_VERSION_MAX, ONNX_OPSET_VERSION_MIN, ONNX_SUBGRAPH_DEPTH_MAX};
69pub use value::OnnxCarrier;
70#[cfg(feature = "alloc")]
71pub use value::{canonicalize, OnnxValue};
72pub use verbs::{address_inference, VERB_TERMS_ADDRESS_INFERENCE};
73
74/// The shared, format-independent ψ-tower (re-exported for convenience;
75/// canonical path is [`crate::resolvers::AddressResolverTuple`]).
76pub use crate::resolvers::AddressResolverTuple;
uor_addr/onnx/mod.rs

uor_addr/onnx/
mod.rs
