Skip to main content
Goal: decide completion from trusted evidence instead of the candidate’s own claim. You are done when: your customized check has a local passed: true report for complete evidence, a failed requirement, and an unavailable evidence source with no verdict. Use this recipe when an agent, CI job, or multi-step pipeline must produce required artifacts and test evidence before you accept its work. Do not treat candidate prose as proof that a tool ran, a test passed, or a file exists. A task with a matching artifact hash and required test IDs passes. A mismatch or failed test rejects; an unavailable evidence source returns no verdict.
1

Create the example

Expected result: selected_recipe is d, selected_check ends in recipe-d-completion-evidence.mjs, deployed_check ends in selected-check.mjs, and next_action tests selected-check.mjs.
2

Run the local cases

Run the printed command:
Expected result: passed is true. Check the labelled outcomes if a case fails.
  • labelled.d-pass-trusted-evidence as a pass;
  • labelled.d-reject-failed-tests as a rejection;
  • labelled.d-reject-hash-mismatch as a rejection; and
  • labelled.d-technical-evidence-store as HTTP 500 with no verdict.
Recovery: if the CLI does not recognize --recipe, stop. Check the install guide for a recipe-capable version; until it lists one, use its non-recipe path. If a labelled case fails, inspect its named results. Fix the evidence lookup or completion rule, then rerun the same local command.
3

Connect your evidence source

Replace readTrustedEvidenceById with a read from the system that owns the facts. The example map is only an offline fixture. Keep these rules:
  1. look up evidence by a bounded, safe identifier;
  2. fetch artifact bytes, the recorded hash, and named test results from that source; compare the computed hash with the record and your required digest, then require every test ID in your code;
  3. keep required steps and allowed-tool rules in your code;
  4. expose every required fact as a named boolean result;
  5. use semantic judgment only for optional explanation quality or a rule that explicitly includes human review;
  6. reject when trusted evidence proves a requirement failed, and return a technical failure when the evidence source cannot answer.
The generated example shares one evidence-read promise between runHardCheck and scoreQuality. Preserve that sharing so the verdict and score use one trusted record.The output-check request contains only the candidate. Your service must fetch repository, CI, or artifact facts from its own trusted source. Rerun the Step 2 command against selected-check.mjs after your edits. Deploy only when your own pass, rejection, and technical-failure cases all pass.
4

Continue to deployment

Read the shared endpoint contract and reserved-probe limits. Your next executable step is Deploy and test HTTPS. Continue with Recipe 0 for connection, paid-run approval, receipt reading, and recovery. In the final receipt for a checked run, confirm required_test_ids_present, required_tests_passed, and artifact_hash_matches under named results.
Require the assistant to name the trusted source for every required result. Reject any design that reads proof only from candidate prose. Supply source credentials through your service, never chat. Approve endpoint test traffic and each paid Millwork run separately.