Production checklist

Use this checklist before shipping a workflow backed by ProveKit. It is intentionally conservative, ProveKit is still under active development and main may change proof, key, recursive-verifier, or API formats between commits.

1. Pin the implementation

Choose the branch or release. Use v1 for the current stable interface; use main only for early-adopter work.
Record the Git commit, Cargo.lock, and rust-toolchain.toml used to generate artifacts.
Record exact CLI commands, feature flags, and the prepare --hash value.
Rebuild from a clean checkout in CI before trusting a new artifact set.

2. Control artifact provenance

For every generated artifact, store the path, checksum, source commit, generating command, and owner.

Artifact	Required provenance
`.pkp`	Circuit source, hash, commit, generating command.
`.pkv`	Same generation record as the matching `.pkp`.
`proof.np` or JSON proof	Matching `.pkp`, input file, public inputs, commit.
`params_for_recursive_verifier`	Matching `.pkv` and proof.
`r1cs.json`	Matching `.pkv` and recursive-verifier export command.
Groth16 `pk` / `vk`	Setup ceremony or development-only generation record.

Do not mix artifacts generated from different branches, commits, hash choices, circuits, or verifier/proof pairs.

3. Lock the end-to-end workflow

Add a CI job that runs the exact deployment path:

mkdir -p artifacts
cargo run --release --bin provekit-cli -- prepare \
  . \
  --pkp artifacts/app.pkp \
  --pkv artifacts/app.pkv
cargo run --release --bin provekit-cli -- prove \
  --prover artifacts/app.pkp \
  --input Prover.toml \
  --out artifacts/proof.np
cargo run --release --bin provekit-cli -- verify \
  --verifier artifacts/app.pkv \
  --proof artifacts/proof.np
cargo run --release --bin provekit-cli -- show-inputs --hex \
  artifacts/app.pkv \
  artifacts/proof.np

If recursive verification is part of the product, add the export step and verify the Go/gnark path with the exact generated files:

cargo run --release --bin provekit-cli -- generate-gnark-inputs \
  artifacts/app.pkv \
  artifacts/proof.np \
  --params artifacts/params_for_recursive_verifier \
  --r1cs artifacts/r1cs.json

4. Define trust boundaries

Decide who is allowed to generate .pkp and .pkv files.
Decide where proofs are generated and where they are verified.
Treat public input encoding as an API contract; test it with show-inputs.
Keep private witnesses, prover keys, and generated proofs out of logs unless explicitly approved.
Document whether verification depends on the local CLI, embedded Rust, WASM, FFI, the verifier server, or the recursive verifier.

5. Harden integration hosts

Rust services

Reload or clone verifier state when verifying multiple proofs in one process.
Expose hash, compiler, and backend choices in configuration.
Add regression tests that confirm mismatched key/proof pairs are rejected.

WASM / JavaScript

Call initPanicHook() and initThreadPool() before proving when using threaded builds.
Create a new Prover for each proof, proveBytes() / proveJs() consume the prover.
Validate witness maps before calling proveBytes() or proveJs().
Load .pkp and .pkv artifacts from authenticated, integrity-checked sources.

FFI / mobile

Call pk_init() once before proving.
Configure the custom allocator or mmap memory before initialization.
Free every returned PKBuf with pk_free_buf().
Test low-memory and cancellation behavior on target devices.

Verifier server

Restrict artifact URL sources or proxy them through trusted storage.
Tune VERIFIER_MAX_REQUEST_SIZE, VERIFIER_REQUEST_TIMEOUT, VERIFIER_TIMEOUT_SECONDS, and VERIFIER_SEMAPHORE_LIMIT for real proof sizes.
Monitor /health, request IDs, verification latency, timeout rate, and invalid-proof rate.
Decide how long downloaded artifacts remain in VERIFIER_ARTIFACTS_DIR.

Recursive verifier

Manage Groth16 proving and verifying keys explicitly for production.
Treat development-time key generation as unsafe unless release-specific setup guidance says otherwise.
Re-run the recursive export after changing the proof, verifier key, branch, circuit, or hash configuration.

6. Capture operational evidence

Before launch, capture evidence for each check:

Check	Evidence to retain
Build reproducibility	Clean-checkout build logs and artifact checksums.
Local verification	`verify` success output and the command line used.
Public inputs	`show-inputs --hex` output reviewed by the application owner.
Negative tests	Proof/key mismatch or corrupted proof is rejected.
Performance	Proving and verification time and memory for expected circuit sizes.
Recovery	Procedure for regenerating and rolling back artifacts.
Observability	Logs and metrics that identify request ID, artifact version, and failure class.

7. Red flags

Pause deployment if any of these are true:

Artifact provenance is unknown or spans multiple branches or commits.
verify fails locally for a proof the service plans to accept.
Recursive-verifier params or r1cs.json were not regenerated with the current .pkv and proof.
Public input ordering is undocumented.
Verifier-server artifact URLs can be controlled by untrusted clients without filtering.
FFI buffers are not freed, or allocator setup happens after pk_init().
Browser proving reuses a consumed WASM Prover instance.
The deployment depends on main behavior without a migration or rollback plan.