Work with code and evidence

Use the pricing project from the library tutorial. You will find the library function, inspect its checked context and retain evidence for the consuming application.

These structured operations are useful to coding agents. People can use the same commands to inspect what the agent relied on.

1. Find the definition

From the directory containing pricing, run:

effectful code find ./pricing/consumers/example \
  --query scale --format json

Find the library’s scale definition in the result. A result carries an id and a snapshot. Keep both: the first selects the definition, and the second identifies the checked source snapshot.

Search is discovery. A matching name does not establish that a definition was executed or that a test covers it.

2. Retrieve its context

Replace the quoted placeholders below with the returned values before running the commands:

definition_id='PASTE_DEFINITION_ID'
snapshot='PASTE_SNAPSHOT'
effectful code context ./pricing/consumers/example \
  --id "$definition_id" --depth 2 \
  --expected-snapshot "$snapshot" --format json
effectful code show ./pricing/consumers/example \
  --id "$definition_id" --expected-snapshot "$snapshot" --format json

Context gives a bounded view of checked relationships. show includes the definition body. The expected snapshot prevents a request from silently using a different version after an edit.

Ask your agent to explain which definition belongs to the reusable library and which entry belongs to the consumer. The owner distinction remains meaningful even when two types or functions look alike.

3. Record a fresh observation

Use a new receipt directory so you cannot accidentally replace earlier evidence:

evidence_dir=$(mktemp -d)
effectful graph test ./pricing/consumers/example \
  --no-cache --evidence "$evidence_dir/run-001.json" --format json

The receipt binds the selected case results to the source and case inputs actually consumed, the compiled bundle and the recorded execution environment. A failed test produces failed evidence; producing a receipt does not mean the tests passed.

4. Ask what still applies

effectful code evidence ./pricing/consumers/example \
  --receipt "$evidence_dir/run-001.json" --format json

This command checks the current graph and compares its relevant inputs with the receipt. It does not run the tests again.

Read the case’s outcome and applicability separately. An applicable failure is still a failure. A missing or unknown observation cannot be treated as a passing test.

5. Make an edit, then compare

Make a deliberate change to the library or a consumer test. Run the evidence query again before creating a new receipt. Inspect the changed components it reports. A case whose relevant inputs changed is stale; a case unaffected by an unrelated edit can remain applicable even when the whole bundle changes.

Rerun the tests with a new receipt filename when you need a fresh observation. Do not edit a receipt to make it match the new source.

What this evidence covers

These are scripted, in-memory graph tests: inputs, supplied effect answers, messages, restarts and expected results, state or traces. They do not exercise a live payment provider, production ingress, UI or native adapter. The receipt’s integrity check detects accidental alteration; it is not an authenticated attestation.

Use the evidence reference for the exact applicability values and review an agent’s change to turn these observations into a useful review.