# Why zk-ML?

Machine learning systems are already making decisions about credit, healthcare, content moderation, hiring, and more. The problem is not just "does the model work?" but "can we *prove* what model ran, on what kind of input, without exposing everything?"

Zero-knowledge machine learning (zkML) answers that by attaching **cryptographic proofs** to ML computations. These proofs show that a model was evaluated correctly, while keeping sensitive pieces (such as model weights, user data, or internal activations) hidden.

In practice, most useful zkML applications today fall into two patterns:

1. **Model-owner proofs:**\
   The model provider proves that a specific, committed model produced a given output, without revealing the weights.
2. **User proofs:**\
   The user proves that their private data satisfies some property (age, risk score, eligibility, etc.) according to a model, without revealing the raw data.

The rest of this page focuses on these two patterns and the concrete use cases we're building toward.

***

### Pattern 1: Model owner as prover (model auditing)

#### The core problem: evaluation–deployment gap

Model audits, benchmarks, and certifications are only meaningful if the **model under test** is the same model actually **running in production**.

Today, a typical flow looks like this:

* The provider submits a model for evaluation or certification.
* The evaluator runs tests and publishes metrics.
* Later, the provider deploys "a model" behind an API or service.

There is usually **no cryptographic link** between the evaluated model and the deployed one. A provider can:

* present a compliant model for audit, then
* deploy a slightly different model (cheaper, less accurate, lightly fine-tuned, or partially compressed) in production.

Users and regulators have to trust that no substitution happened. There is no way to *check*.

zkML closes this gap.

#### What zkML adds

With zkML, the model owner can:

1. **Commit to a specific model**
   * Export the model (for example, in ONNX format).
   * Quantize it (fixed-point / integer form).
   * Compute a **cryptographic commitment** (a hash) to the model structure and weights.
   * Publish this commitment as the "certified" or "approved" model identifier.
2. **Prove each inference came from the committed model**
   * When the service answers a query, it also produces a **zero-knowledge proof** that:
     * it evaluated the committed model on the given input, and
     * the reported output matches the computation inside the circuit.
   * The proof hides the actual weights and internal activations but proves they are consistent with the published commitment.
3. **Let auditors verify without seeing IP or infrastructure**
   * An auditor (or even a smart contract) receives:
     * the input (or a challenge constructed by the auditor),
     * the output,
     * the model commitment hash,
     * and the zk proof.
   * They run a verifier that checks:

     > "Did the committed model produce this output on this input?"
   * If the proof fails, the service is out of compliance.

This gives **cryptographic evidence of model identity**, not just performance numbers in a PDF.

#### Example use cases

Some concrete scenarios where this pattern is valuable:

* **Regulated models (finance, health, public services)**
  * A credit-risk model certified by a regulator can be tied to a commitment.
  * During random or periodic audits, regulators can challenge the live system and verify that answers are produced by the certified model — without seeing the weights.
* **API providers and SLAs**
  * A model-as-a-service provider claims: "you're paying for our Tier-A model, not the cheaper Tier-B one."
  * zkML allows them to **prove** that each billed request was answered by the committed Tier-A model.
* **Benchmarking and reproducible evaluations**
  * An evaluation lab publishes benchmark scores for a committed model hash.
  * Later, downstream users can demand proofs that the deployed model matches that hash before trusting the published metrics.

In all of these, zkML is not about "AI safety in general." It is about one precise question:

> "Did *this particular* approved model produce *that* answer?"

***

### Pattern 2: User as prover (private inputs and identity)

In many situations, the *user* wants to keep their data private but still prove that it satisfies some property defined by a model.

Zero-knowledge lets the user prove statements of the form:

> "If you ran your model on my secret input, the outcome would satisfy property P."

without revealing the input itself.

#### Age and eligibility checks (zk identity)

One timely application is **age and eligibility verification** for online services, especially around:

* teen access to social media,
* age-restricted content,
* parental controls, or
* jurisdiction-based access (for example, different countries or regions).

A simplified flow:

1. A provider trains an **age or eligibility classifier**:
   * It might use signals like face images, voice, or interaction patterns.
   * The exact features depend on policy and regulation.
2. The user obtains an **offline evaluation** or credential:
   * The model (or a trusted third party) runs on the user's data.
   * Instead of storing the raw data, the system derives a compact representation (for example, an embedding or internal activations) and a classification result (like "over 16").
3. The user creates zk proofs for specific predicates:
   * "I am over 16."
   * "I am not on a banned device list."
   * "I belong to the allowed jurisdiction set."
4. The platform verifies the proof:
   * It never needs to see the raw face, voice recording, ID document, or full feature vector.
   * It only learns that the user satisfies the required condition.

This pattern is also relevant to **account bans and multi-account abuse**:

* A platform can require a proof that "this user is a unique person not tied to a previously banned identity,"
* without linking the user to a real-world name or exposing biometric data.

#### zk KYC and private scoring

A related class of use cases involves **KYC (Know Your Customer)** and private scoring:

* A bank or exchange runs a KYC / AML / sanctions model on a user's documents.
* Instead of storing or sharing all raw outputs, it issues a credential or runs an on-chain proof that:
  * "This user passed our KYC checks and is not on a sanctions list."
  * Or "this user's risk score is below threshold T."

The verifier (for example, a DeFi protocol or another institution):

* learns only that the user satisfies the required policy,
* but not the exact score, income, address, or sensitive details.

In these scenarios, zkML helps bridge **AI-based decision logic** and **privacy-preserving credentials**.

***

### How our stack fits in

Our current work focuses on making these use cases **practical**, not hypothetical:

* **Model auditing pipeline (model owner as prover):**
  * Export models to ONNX.
  * Quantize to fixed-point integers suitable for arithmetic circuits.
  * Compile to circuits and generate proofs using a transparent (no trusted setup) backend.
  * Bind each proof to a **model commitment hash**, so auditors can verify that a live service still uses the certified model.
* **Selective / slice-level proofs:**
  * For large models, we support proving only over selected "slices" (sub-computations),
  * so that high-stakes parts of a pipeline (for example, the final classifier head or a risk module) get proofs, while the rest runs conventionally.
* **Identity and eligibility prototypes (user as prover):**
  * We design circuits that model "over 16 / under 16", admission thresholds, or other policy predicates,
  * allowing users to prove eligibility without revealing the raw input.

The long-term goal is simple to state:

> Make it normal for ML systems to ship **proofs**, not just predictions.

zkML is the cryptographic layer that makes those proofs trustworthy, compact, and verifiable — on-chain or off.\ <br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.inferencelabs.com/zk-ml/why-zk-ml.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.