---
title: "Verify"
canonical: "https://helm.docs.mindburn.org/reference/verify"
source: "helm-ai-enterprise/docs/public/reference/verify.md"
edit: "https://github.com/Mindburn-Labs/helm-ai-enterprise/edit/main/docs/public/reference/verify.md"
section: "trust"
access: "public"
sensitivity: "public"
last_reviewed: "2026-02-21"
checksum_sha256: "sha256:28586ce7cf7281e5309d6678590447ca72c894301b534efe798bd45b4e6820ab"
build_timestamp: "2026-05-24T13:40:27.882Z"
---
# Verify HELM Conformance

## Audience

## Outcome

After this page you should know what this surface is for, which source files own the behavior, which public route or adjacent page to use next, and which validation command to run before changing the claim.

## Source Truth

- Public route: `reference/verify`
- Source document: `helm-ai-enterprise/docs/public/reference/verify.md`
- Public manifest: `helm-ai-enterprise/docs/public-docs.manifest.json`
- Source inventory: `helm-ai-enterprise/docs/source-inventory.manifest.json`
- Validation: `corepack pnpm run docs:coverage`, `corepack pnpm run docs:truth`, and `npm run coverage:inventory` from `docs-platform`

Do not expand this page with unsupported product, SDK, deployment, compliance, or integration claims unless the inventory manifest points to code, schemas, tests, examples, or an owner doc that proves the claim.

## Troubleshooting

| Symptom | First check |
| --- | --- |
| A link or route is missing from the docs website | Check `docs/public-docs.manifest.json`, `llms.txt`, search, and the per-page Markdown export before changing navigation. |
| A claim is not backed by code or tests | Remove the claim or add the missing code, example, schema, or validation command before publishing. |

Verify any HELM release in one command. No configuration needed.

## Quick Start

```bash
npx @mindburn/helm-ai-enterprise
```

This launches the **interactive flow**:
1. Choose artifact source (latest release or local bundle)
2. Select conformance level (L1 or L2)
3. View verification results
4. Optionally drill down into gate details or generate an HTML report

## CI / Automation

```bash
# Verify local bundle — JSON on stdout, human summary on stderr
npx @mindburn/helm-ai-enterprise --ci --bundle ./evidence 2>/dev/null

# Exit code: 0 = pass, 1 = fail, 2 = error, 3 = no bundle
echo $?

# Pipe to jq for specific fields
npx @mindburn/helm-ai-enterprise --ci --bundle ./evidence 2>/dev/null | jq .verdict
# "PASS"
```

## Options

| Flag | Description | Default |
|------|-------------|---------|
| `--bundle PATH` | Local evidence bundle directory | — |
| `--level L1\|L2` | Conformance level | L2 |
| `--ci` | CI mode (JSON stdout, exit code) | — |
| `--json` | Alias for `--ci` | — |
| `--depth 0-3` | Output verbosity | 1 |
| `--report PATH` | Generate HTML evidence report | — |
| `--no-cache` | Skip download cache | — |
| `--cache-dir DIR` | Custom cache directory | `~/.helm-ai-enterprise/cache` |

## Output Depth

| Depth | Content |
|-------|---------|
| 0 | Badge + short hash |
| 1 | Summary table (structure, hash chain, signature, gates, roots) |
| 2 | Per-gate details with failure reasons |
| 3 | Full tree stats with leaf counts |

## What Gets Verified

1. **Structure** — §3.1 mandatory directories and files
2. **Hash chain** — every INDEX entry hash matches file contents
3. **Manifest root hash** — `sha256(00_INDEX.json)` for bundle identity
4. **Merkle root** — real Merkle tree over entry hashes (domain-separated)
5. **Signature** — conformance report signature (when present)
6. **Gates** — L1/L2 gate pass/fail against 01_SCORE.json
7. **Attestation** — Ed25519 signature over release attestation (when downloading)

## Examples

```bash
# Verify a specific bundle with detailed gate output
npx @mindburn/helm-ai-enterprise --bundle ./artifacts/conformance --level L2 --depth 2

# Generate an HTML evidence report
npx @mindburn/helm-ai-enterprise --bundle ./evidence --report ./report.html

# Verify at minimal level
npx @mindburn/helm-ai-enterprise --bundle ./evidence --level L1 --depth 0
```

## HTML Report

The `--report` flag generates a single-file HTML evidence report suitable for embedding in audit documentation:

```bash
npx @mindburn/helm-ai-enterprise --bundle ./evidence --report ./helm-ai-enterprise-report.html
open ./helm-ai-enterprise-report.html
```

## Programmatic API

```typescript
import { verifyBundle, computeMerkleRoot, LEVELS } from "@mindburn/helm-ai-enterprise";

const result = await verifyBundle("./evidence", "L2");
console.log(result.verdict);          // "PASS" or "FAIL"
console.log(result.roots.merkle_root); // real Merkle root
```

## Diagram

```mermaid
flowchart TD
    subgraph Ingestion["1. Ingestion & Context Plane"]
        s0["Quick Start"]
        s1["CI / Automation"]
        s2["Options"]
        s3["Output Depth"]
        output["Reader outcome"]
    end

    subgraph Ledger["4. Tamper-Evident Ledger Plane"]
        source["Verify HELM Conformance"]
    end

    %% Operational Flow Edges
    source --> s0
    s0 --> s1
    s1 --> s2
    s2 --> s3
    s3 --> output

    %% Premium Styling Rules
    style source fill:#2f855a,stroke:#276749,stroke-width:2px,color:#fff
```


## Operational Readiness

Use this page as the public operating layer for **Verify**. The source of truth is `helm-ai-enterprise/docs/public/reference/verify.md`; if this page and the implementation disagree, update the source-backed doc and rerun the validation command before publishing.

Before relying on this surface, confirm three things: the source path above still exists, the referenced commands or contracts are still present in the owning repo, and the docs-platform export surfaces still show this page in search, Markdown, `llms-full.txt`, and MCP without exposing protected routes.

Validation command: `corepack pnpm run docs:coverage && corepack pnpm run docs:truth`. For website parity, also run `npm run exports:boundary` and `npm run thin-pages:check` from `docs-platform`.

### Expected Output

A reader should leave with a concrete next action, the source file or contract to inspect, the command that proves the claim, and a clear boundary for what is public versus protected. For reference pages, the expected output is a correctly scoped request, schema, command, or diagnostic path. For operations pages, the expected output is a reproducible readiness or failure signal that can be attached to an evaluation or support thread.

### Failure Modes

If the validation command fails, do not patch this page in isolation. First identify whether the drift is in code, generated contracts, source-owner docs, or the docs manifest. If the public page needs a protected deep link, describe the protected document by name instead of exposing its route. Commercial operator details, tenant data, key ceremonies, and deployment-sensitive internals stay in protected customer or staff docs; this public page only exposes the safe developer contract.