# Investigate one passing check Companion to “How to Audit a Passing Check in an AI Agent Workflow”: https://dargel-solutions.de/en/knowledge/audit-ai-agent-workflow/ Copy the blank worksheet for one requirement in one recurring workflow. Keep it locally or in your existing issue tracker. Nothing is submitted to Dargel Solutions. You may copy and adapt this newly created worksheet for your own work. Write `not run` for an action you have not performed and `unknown` for evidence you cannot establish. An empty field is not a favourable finding. Use disposable copies in an environment that cannot publish, send, pay or affect a live recipient. If you cannot isolate the test, record that limitation instead of running it live. ## Blank worksheet ### 1. Choose one outcome 1. **Workflow and boundary:** What happens, where is the output accepted, and who owns the workflow? 2. **Required result:** What must the recipient be able to do? What is outside this exercise? 3. **Output and conditions:** Record the exact file/version, date, and relevant application or environment. ### 2. Establish the scope 4. **Expected items:** Which items must be examined? Establish this from the requirement and output, independently of the checker's filter. 5. **Actual check:** Name its version/configuration/entry point, input, examined and skipped items. Link the run evidence to the output in field 3. If that link is unknown, say so. 6. **Meaning of the result:** Did the check run? What does its result establish, and what remains unknown? ### 3. Prepare and run the comparison 7. **Safe setup and good copy:** How are external actions prevented? Identify the good copy and verify it meets the requirement. Run the current check on it and record the response and the isolated workflow's acceptance decision before testing the defect. 8. **Bad copy and prediction:** Identify the single change, verify the intended defect is present, and write the expected rejection before running it. 9. **Bad-copy observation:** Run the same entry point/configuration under the same conditions. Record the response, examined scope and evidence. Was the intended defect detected, or did something else fail? Observe whether the isolated workflow's acceptance step actually blocks this copy; record that decision too, or `unknown` if you cannot establish it. ### 4. State the finding 10. **Finding and evidence:** Choose: demonstrated gap / detection observed / inconclusive. Explain both the check result and the acceptance decision. A rejection followed by acceptance is a demonstrated enforcement gap; an unobserved acceptance step leaves the end-to-end result unknown. 11. **Change or missing evidence:** What specific change or observation is needed next? Base selection on the independently established requirement; lowering a cutoff until this example passes is not proof of the required scope. 12. **Recheck after a change:** Record the good-copy and bad-copy results and confirm that the isolated acceptance step permits the good copy and blocks the bad one for the intended reason. Separately test missing input by directing the check at a nonexistent path in the safe test folder; leave both copies intact. Record whether that attempt is reported as incomplete. Link the evidence and repeat the recipient's application check where relevant. If the workflow does not read files, name the unavailable input you tested; if untested, write `not run`. ### 5. Leave a usable record 13. **Owner and trigger:** Who takes the next action, and when or after which change? 14. **Retained evidence and limits:** Where are the inputs and observations? What does this exercise still not establish? Choose “detection observed” only when the good copy is accepted, the known defect is rejected for its intended reason, the required scope is established, and the isolated workflow's acceptance step actually blocks the defective output. A standalone reject message does not establish this. A timeout, missing run, unknown file identity or unrelated failure leaves the comparison inconclusive. If the check uses a model, retain its prompt, input, configuration and response; repeat the same good and bad cases to look for variation. This exercise does not estimate a detection rate or certify the workflow. ## Completed teaching example Everything below is synthetic, including the date, application, filenames, run identifiers and evidence paths. They show how to complete the record. No such files or logs are supplied, and no execution in the named application is claimed. GOOD, BAD and UNREADABLE are defined test inputs; R1 and R2 are defined rules. The results describe those rules logically, not measured production behaviour. The example defines an acceptance step that permits an output only when the rule accepts it; rejection or incomplete checking blocks it. The named run records include that decision. A real run must observe it. ### 1. Choose one outcome 1. **Workflow and boundary:** An agent creates a weekly stock workbook; acceptance happens before delivery. Owner: the stock-workbook workflow maintainer. 2. **Required result:** Row 1 stays visible while scrolling Orders and Returns. Stock totals, formulas and missing orders are outside scope. 3. **Output and conditions:** Example record date: 12 September 2026. GOOD is `worksheet-demo/2026-09-12/stock-good-v1.xlsx`. It contains Orders with sixty rows and Returns with twenty, each with a row-1 header and data beneath. Target application in this example record: LibreOffice Calc; version `unknown`, application check `not run`. That missing observation limits the conclusion to the defined file-checking rules. ### 2. Establish the scope 4. **Expected items:** Orders and Returns, recorded in `requirement-v1.md` from the workbook's two tables and the recipient's requirement. The expected list is independent of R1's filter. 5. **Actual check:** Rule R1, configuration `long-sheets-v1`: open the supplied workbook and check header freezes only on sheets with more than forty rows. Entry point: the workflow's pre-delivery file checker with delivery disabled. Example run `R1-GOOD-01` receives `stock-good-v1.xlsx` and records its input filename, rule/configuration and scope in `R1-good.txt`. It examines Orders and excludes Returns. All paths are relative to the example folder above. 6. **Meaning of the result:** The example `R1-good.txt` record shows that only Orders passed the freeze check, although the workflow accepts the whole workbook. It does not establish the property on Returns. No claim about real execution or visible application behaviour follows from this synthetic record. ### 3. Prepare and run the comparison 7. **Safe setup and good copy:** Local copies with delivery disabled; the original output is untouched. GOOD has row 1 frozen on both sheets. The defined good-case check, `R1-GOOD-01`, passes GOOD and lists Orders only, recorded before the bad case; the defined acceptance step permits GOOD. `comparison.md` records the good copy's required freeze settings; the separate application observation remains `not run`. 8. **Bad copy and prediction:** Create BAD as `stock-bad-v1.xlsx` in the same example folder. It differs from GOOD only by removal of the Returns freeze. `comparison.md` records that exact change and the expected rejection naming Returns before the bad-case evaluation. This supplies a known file-setting defect; its effect while scrolling remains to be checked in Calc. 9. **Bad-copy observation:** Run `R1-BAD-01` receives `stock-bad-v1.xlsx` through the same entry point and the checker passes BAD too; `R1-bad.txt` lists Orders as examined and Returns as excluded. The defective sheet never enters the freeze check; no unrelated failure explains this result. The defined acceptance step permits BAD, also recorded in `R1-bad.txt`. The rule and configuration match the good case. ### 4. State the finding 10. **Finding and evidence:** Demonstrated logical gap in R1. Its filter omits Returns even though `requirement-v1.md` includes it; the same acceptance of GOOD and BAD follows from that filter and is allowed through by the defined acceptance step. The comparison is recorded in `comparison.md`, citing the two R1 records. Actual execution and recipient-view behaviour are not established. 11. **Change or missing evidence:** R2, configuration `required-tables-v1`, examines both required sheets, requires the freeze below each header, and lists its scope. Unreadable input or unknown required scope leaves the check incomplete. A real investigation must run these comparisons and record the Calc version and scroll observations. 12. **Recheck after a change:** In defined run `R2-GOOD-01`, the checker passes GOOD with both sheets examined and the acceptance step permits it (`R2-good.txt`). In `R2-BAD-01`, the checker rejects BAD because Returns lacks its freeze and the acceptance step blocks it (`R2-bad.txt`). For `R2-UNREADABLE-01`, supply the nonexistent path `missing-test-copy.xlsx` in the safe folder, leaving GOOD and BAD intact. R2 reports incomplete and the acceptance step blocks the missing-input attempt in `R2-unreadable.txt`; this does not count as detection of a freeze defect. R1's behaviour on missing input is not defined in this example and remains unknown. Calc scroll check: `not run`, recorded in `application-observation.md`. ### 5. Leave a usable record 13. **Owner and trigger:** The workflow maintainer runs the comparison and completes the application observation before using it as evidence for delivery. Repeat when the workbook generator or checker changes. 14. **Retained evidence and limits:** Example folder: `worksheet-demo/2026-09-12/`. Inputs: `stock-good-v1.xlsx`, `stock-bad-v1.xlsx`; requirements and analysis: `requirement-v1.md`, `comparison.md`; run records: `R1-good.txt`, `R1-bad.txt`, `R2-good.txt`, `R2-bad.txt`, `R2-unreadable.txt`; recipient-view record: `application-observation.md`. These are illustrative references, not downloadable evidence. The conclusion covers the logical gap in R1; real execution, application behaviour, stock totals, formulas and missing orders remain unverified. Created by Dargel Solutions with generative AI. The example is instructional, not a human user test.