Unique Verification Codes

What a UVC does

A cryptographic hash maps a defined input record to a fixed-length code. A small change in the input normally produces a different code. By storing the code and later recomputing it from the same canonical information, a system can check whether the record still matches.

Hybrid Intelligence applies this pattern to two objects: the model and the query result.

Model UVCs

A Model UVC can be calculated from a structured representation of the model, including selected fields such as:

• model name and version;
• creation time;
• deployment or registry reference;
• input and output configuration;
• module and partition identifiers and counts;
• IF-THEN rule expressions;
• equation coefficients; and
• symbolic parameter definitions.

The exact set must be specified and versioned. If a covered coefficient, rule or structural item changes, recomputation produces a different Model UVC.

This supports a precise question: does the model information under review match the registered reference?

Query UVCs

A Query UVC can cover:

• the submitted input or defined representation of it;
• prediction output;
• explanation and attribution information;
• active module and partition references;
• query time; and
• the Model UVC.

Including the Model UVC links the query fingerprint to the model version. A change to the covered model record can therefore affect verification of associated queries.

The UVC audit chain

The process is:

1. define the canonical fields and algorithm version;
2. serialise the fields in the specified order;
3. calculate the cryptographic hash;
4. store the resulting UVC with the governed record;
5. later reconstruct the same canonical input;
6. recalculate the hash; and
7. compare the two values.

A match supports integrity relative to the reference. A mismatch triggers investigation.

What a UVC does not prove

A UVC does not prove that:

• the source data was accurate;
• the model was valid for the task;
• the prediction was fair;
• a regulation was satisfied;
• the decision was correct in the real world; or
• the person or system creating the reference was authorised.

Those claims require separate evidence and controls. UVCs protect the integrity of defined information; they do not determine its substantive quality.

Canonical representation

Hashing is sensitive to representation. The same number written with different decimal precision, fields ordered differently or timestamps expressed in different zones can create different hashes.

A production specification should define:

• field names and inclusion rules;
• order;
• number and date formats;
• missing-value treatment;
• character encoding;
• model and UVC schema version;
• hash algorithm; and
• any salt, key or signature mechanism used outside the basic hash.

The final implementation and security design should be confirmed by UMNAI engineering and security review.

The specification should also support algorithm and schema versioning. If the canonical fields or hash algorithm change, the record needs to state which procedure created each historical UVC. A newer verification service must preserve the ability to check older codes or document a governed migration.

Internal and external verification

The runtime can expose functions to generate and verify UVCs. Independent parties can also implement the same documented algorithm. External verification supports forensic and cross-system use, provided both parties use the identical canonicalisation.

Storage and wider trust systems

UVCs can be written to ordinary audit stores or, where justified, to append-only or distributed-ledger systems. The storage choice should follow the threat model, governance requirements, cost and data architecture.

Storing a UVC outside the model environment can strengthen separation of duties, but it does not remove the need to protect the data and metadata required for authorised recomputation.

Key technical concepts explained

• Model UVC: a hash fingerprint over a defined representation of an XNN model.
• Query UVC: a hash fingerprint over defined query, output, explanation and model-reference information.
• Tamper-evident: capable of revealing that covered information no longer matches its reference.
• Collision resistance: the difficulty of finding two different inputs with the same cryptographic hash.
• Verification check: recomputation and equality comparison against the stored UVC.

Simplified scenario

A model version is registered with a Model UVC. A query later generates a prediction, rule path and Query UVC that includes the Model UVC. During review, an auditor recomputes both codes. The model code matches, but the query code does not. Field-level diagnostics show that an attribution value in the stored result was altered after inference.

Why it matters

Explanations are only useful as evidence if their integrity can be checked. UVCs provide a compact mechanism for detecting change across model and query records while keeping the scope of the integrity claim explicit.

They also make integrity portable across systems when the same canonical specification can be implemented and verified independently.