Keep the requirement, observed evidence and next authorized action together. A blank field is a missing answer, not a pass.
Use the blank record
Choose a guide-specific draft when a guide fits; it already identifies the exact method. Otherwise use the generic blank record. Name your task, environment/version and current authorization.
For a real record, change record_type to task_record, copy the chosen guide’s ID, build revision and source hash into method_reference, then list each required check. Preserve observed evidence and where to find it.
Mark each check pass, fail or unavailable.
Explain the overall check decision separately from the recommendation: keep, change, skip or investigate. Update the limitations and state only the next action that is actually authorized.
One demonstrated required failure means reject. If there is no demonstrated failure but any required check is unavailable, the decision is unknown. Accept only when every required check has positive evidence.
The filled record below is entirely fictional. It shows why a file that exists can still be an unknown handoff. No PDF, receiving agent or delivery was tested.
A PDF exists, but its contents cannot be checked
Task
Hand over a one-page project summary PDF.
Scope and version
Illustrative summary-v1.pdf; one page and the approved summary required.
Current authorization
In this fictional scenario, inspect the local PDF and prepare a handoff. Sending or uploading requires separate permission.
Required checks and evidence
A file exists at the expected local path.
Illustrative local file listing contains summary-v1.pdf.
Status: pass Fictional fixture note A, not a real log.
PDF opens, contains one page and the required summary.
The fictional environment has no available PDF inspection tool; these content checks were not performed.
Status: unavailable Fictional fixture note B, not a tool result.
The intended recipient can access the final copy.
No authorized delivery or access check has occurred in the scenario.
Status: unavailable Fictional scenario boundary, not a delivery receipt.
Decision: unknown
File existence passes, but required content and recipient-access checks are unavailable. There is no evidence that the PDF is defective or ready to deliver.
Next authorized action
Report the missing checks. Ask for an authorized way to inspect the PDF and the intended delivery permission; do not regenerate or send it merely to produce a success state.
Stop or recovery
Keep the original file unchanged until the missing evidence or authorization is available.
Fictional illustration · Decision: reject · No code or external action was run
This example shows why a known required failure is not downgraded to unknown just because other checks are missing. Its recommendation is change, but it does not establish a working repair or permission to implement one.
Task
In a fictional local rehearsal, decide whether a retry flow prevents a duplicate effect after a lost response.
Scope and version
Invented fake-sink trace F1 for one operation named demo-1. No real message, payment, provider or runtime was used.
Current authorization
The fictional scenario permits review of an invented local trace only. This example grants no authority to run code, retry an operation or contact a real service.
Required checks and fictional evidence
Confirmed completed work is not replayed.
Fictional trace F1: counter starts at 0. First dispatch of demo-1 commits one effect and records completion; counter becomes 1. The response is lost, but the fake sink’s completion record confirms that demo-1 completed. After restart, the retry flow dispatches demo-1 again without consulting that completion record; counter becomes 2. The same operation produced two effects in this illustration.
Status: fail Invented trace F1 stated in this example, not an execution log or provider receipt.
Unknown work remains blocked for reconciliation.
Fictional scenario limit: no separate unresolved-operation trace is supplied, so behavior when completion truly cannot be determined is unavailable.
Status: unavailable Illustrative scope note F2, not an observed runtime result.
Every retry stays within current authorization and provider semantics.
Fictional scenario limit: no real provider, user approval or provider-specific idempotency behavior was evaluated.
Status: unavailable Illustrative scope note F3, not an authorization record or provider test.
Decision: reject
Within the fictional trace, the required no-duplicate check demonstrably fails. That is enough to reject this retry flow for the stated requirement, even though other required checks remain unavailable. The missing checks do not erase the failure or establish which repair would work.
Next authorized action
In the fictional review, record the duplicate-effect failure and propose a bounded repair that checks the completion record before redispatch. Any real change or rehearsal requires its own current authorization; do not send or retry a real operation from this example.
Stop or recovery
Do not approve the affected retry flow on this evidence. Preserve the unresolved checks and any operation identity for reconciliation; do not attempt a compensating real-world action without separate authority.
Limits
Every observation and trace is invented. No program, customer workflow or external effect was executed.
Reject applies to the fictional flow and its stated no-duplicate requirement, not every retry design or provider.
Unavailable checks remain unresolved. No repair, runtime protection or performance benefit has been verified.
If you produce records repeatedly, a small Python checker can catch missing fields or a decision that conflicts with the marked check states. You can use the worksheet without it.
Review the code and run it only in an authorized local environment with Python 3.10 or later. It reads only JSON files you explicitly supply and makes no network requests or file changes.
Supply the exact local guide with --guide to compare its ID, revision and recomputed source digest. Add --manifest to check the supplied guide’s bytes against your selected reading-pack manifest. Files are explicit inputs; paths inside them are never followed.
A match detects agreement between those local inputs. It does not authenticate a publisher, fetch a current online version or verify any task evidence. Keep the original decision separate from the method-comparison result.
A zero exit status is not an accepted artifact. It can mean a consistent unknown or fictional record. The checker cannot verify evidence, source identity, task success or authorization.