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:

# 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:

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:

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:

sha256sum customer-bundle.tar.gz