Every criterion edit creates a new pipeline version. The version is a cryptographic hash of the ordered graph of nodes and their parameters — including rubric prompts. Candidates scored under one version stay permanently linked to it, even after the rubric evolves.

Practically: if you tighten the backend-experience rubric tomorrow, the candidates you rejected today cannot retroactively be re-scored by the new rubric without creating a separate, explicit re-score run. Both runs remain in the audit log side by side.

POST /api/decisions
↳ includes pipeline_version: 3a7f9c2
↳ server validates hash against stored graph
↳ record is append-only

Each decision — advance, hold, reject, or reviewer override — is serialized with:

• candidate_id · pipeline_version_id
• per-criterion scores with evidence snippets (verbatim)
• pipeline recommendation · reviewer override · reviewer id
• timestamp

The resulting record is hashed and the hash is stored with the record, making tampering detectable at audit time. Records are append-only — corrections are written as new records, never overwrites.

Every score ships with verbatim snippets from the résumé that support it. The scoring model is prompted to quote rather than paraphrase; quotes shorter than three words or exceeding 320 characters are rejected and re-requested.

If a score lacks at least one supporting quote, the score is flagged rather than accepted. This makes "the model said so" an impossible outcome.

Each criterion's generated prompt includes a do-not-consider list. Default exclusions span name, age, location, school, gender, and any explicit demographic signals. Criterion-specific additions (e.g., "native-English fluency" on communication criteria) are applied automatically.

Exclusions are visible on every criterion card and are recorded in the audit log, so an auditor can verify what was told to be ignored for any past run.

The pilot runs entirely on Cloudflare: static frontend served from Workers Static Assets, scoring engine on a separate Worker, records persisted in D1 (pilot uses browser localStorage).

Résumé PDFs are stored in R2 with per-bucket lifecycle rules. Raw text is never sent to the model in whole; candidate-profile JSON is prepared first and only relevant fields are included in each scoring call.