# Genomics compute layer — customer evaluation bundle

This bundle contains everything needed to evaluate the compute layer
before signing a free-pilot Letter of Intent. Walk it in this order.

## 1. Run the 5-second offline verify (no infra required)

The bundle ships a precomputed signed manifest. Confirm the verifier
works on your hardware before reading anything else:

```bash
# Install once (per the repo: pip install -e .)
genomics-verify \
  keys/sample-manifest.json \
  keys/sample-signature.json \
  --public-key keys/genomics-public.pem.example
# Expected: "OK — signature valid for this manifest."
```

The example public key fingerprint is:

    c45fed5f205aea057efa7314515ec3688109aa4f072aa71bd4a7fd4c48db102d

Hash the PEM yourself (`sha256sum keys/genomics-public.pem.example`)
and confirm it matches. This is the demo-key fingerprint;
production-pilot keys are pinned out-of-band per
`SIGNING_KEY_PUBLISHING.md` §3.

### Then inspect the sample QC report

Every per-sample deliverable ships a JSON QC report alongside the
signed manifest. The bundle contains a real one from a 2026-05-10
HG002 30× run on a single NVIDIA GB10:

```bash
cat sample-qc-report.json
```

Expected fields per `QC_REPORT_SCHEMA`: `schema_version`, `job_id`,
`sample_id`, `pipeline_version`, `generated_at`, `qc_status` ∈
{PASS, WARN, FAIL}, `qc_reasons[]`, `metrics{}`. The sample
shows PASS with `alignment_rate_pct=99.55`, `mean_coverage=32.49x`,
`ti_tv_ratio=1.99`, `het_hom_ratio=1.42`, `variant_counts=snp=3.9M / indel=0.9M`.

Schema-validate it with:

```python
import json
from compute_layer.qc.json_schema import validate_qc_report
validate_qc_report(json.load(open("sample-qc-report.json")))
```

## 2. Read the boundary statement

Open `INTENDED_USE.md`. It states exactly what we do and do not
claim — secondary analysis only, no interpretation, no diagnosis,
the lab remains the CLIA/CAP lab of record. Read this first; if
the boundary doesn't match what your QMS expects, the rest is moot.

## 3. Review the formal validation dossier

Open `VALIDATION_REPORT.md`. This is the document your QMS reviewer
signs against to authorize the LOI. It pins the pipeline version,
mirrors the in-scope SNP F1 0.9994 / Indel F1 0.9969 numbers,
documents the exclusion BED rationale, lists the three offline
commands the QMS reviewer reproduces independently, and provides
the sign-off block both Provider and Lab counter-sign.

## 4. Review the canonical quality source

Open `QUALITY_METRICS.md`. This is the single source of truth that
the validation report mirrors from. Use it to spot-check any number
the validation report quotes.

## 5. Review the signing-key policy

Open `SIGNING_KEY_PUBLISHING.md`. Two things matter for your QMS:

- The trust anchor is the **fingerprint**, delivered out-of-band via
  the executed pilot agreement, not the PEM file alone.
- The 18-month rotation overlap means manifests stay verifiable
  long after key rotation.

## 6. Review the API contract

Open `API_OPENAPI.json`. Frozen schema; LIMS integrators can pin
against it. CI catches drift on every push.

## 7. Sign the LOI

Open `LOI_ONEPAGER.md`. Populate the placeholders with your lab's
details, sign, and email back. Pilot kickoff sequence is the
provider's responsibility from there.

## Determinism guarantee

This bundle is byte-for-byte reproducible from the repo. The CI gate
"customer-bundle determinism check" rebuilds it twice on every push
and rejects non-matching output, so the SHA-256 you compute locally
matches the one your account team gave you out-of-band.

## Bundle SHA-256

Documented at delivery time in the email body, not embedded here
(self-referential hashes are a footgun). Compute with:

```bash
sha256sum customer-bundle.tar.gz
```