Documents · Report template
What you get back
This is the skeleton of the report a client receives at the end of the audit week. It is a template: every value is a ⟨placeholder⟩, because a filled-in example would either be a real client's (which we do not publish) or invented (which we do not do). The format is the same one we used to audit our own agent.
The sections are in the order a reader needs them: the four questions, the per-agent verdict, the findings ordered by how quietly they fail, what is already right, the checks that keep each finding closed, and what the audit did not cover.
Header
- Subject: ⟨n⟩ agents, ⟨how they are scheduled⟩
- Date: ⟨date⟩ · Window inspected: ⟨dates of data examined⟩
- Method: read-only ⟨source inspection · database inspection⟩. No execution, no changes.
- Auditor: Smuz · Mykyta Lysenko
0. The question this audit asks
Not “is the code good.” Four questions, in order, because each is worthless without the one before it.
| Question | Why it's separate | |
|---|---|---|
| Liveness | Did it run? | A perfect agent that isn't firing is a dead agent. |
| Throughput | Did it do work? | A run that processes zero records exits 0 and looks healthy. |
| Effect | Did the work land? | “The API returned 200” is not “the thing happened.” |
| Ownership | Would anyone know if it hadn't? | An unowned failure is an indefinite failure. |
An agent passes only if all four are answerable from data, by a check containing no model.
1. Summary
| Agent | Liveness | Throughput | Effect | Ownership | Verdict |
|---|---|---|---|---|---|
| ⟨agent⟩ (⟨schedule⟩) | ⟨✓ · ⚠ · ✗⟩ | ⟨✓ · ⚠ · ✗⟩ | ⟨✓ · ⚠ · ✗⟩ | ⟨✓ · ⚠ · ✗⟩ | ⟨Verifiable · Not verifiable⟩ |
| ⟨agent⟩ (⟨schedule⟩) | ⟨…⟩ | ⟨…⟩ | ⟨…⟩ | ⟨…⟩ | ⟨…⟩ |
⟨One paragraph: how many agents, how many could answer all four questions, and the single most consequential finding — named, not teased.⟩
⟨n⟩ findings: ⟨n⟩ critical, ⟨n⟩ high, ⟨n⟩ medium.
Missing data renders “–”, never “✓”. A check that errored renders ERROR, never a pass.
2. Findings
Ordered by severity, never by discovery order. Each one has four parts:
F1 — ⟨one line, in your vocabulary⟩ · ⟨Critical · High · Medium⟩
Evidence. ⟨file and line, or the query and its result⟩
Failure scenario. ⟨real inputs, real state, the wrong outcome that follows⟩
Why it matters. ⟨what the symptom looks like from outside — ideally, indistinguishable from correct behaviour⟩
Fix. ⟨the smallest change that closes it, and the assertion that proves it stays closed⟩
A finding without a concrete failure scenario is an opinion, and is cut rather than explained.
3. What's already right
⟨Two to five things, specific — the dedupe, the cap, the retry discipline — whatever is genuinely well built, named at file and line like a finding.⟩
This section is not padding. Naming what is right is what makes §2 credible; a report that finds only fault reads as a sales document.
4. Proposed assertion set
Deterministic checks, no model anywhere. Two primitives only: scalar (a bounded number) and no_rows (a query that must return nothing). Every assertion states what it catches; one that cannot name its failure is not written.
| Assertion | Catches | |
|---|---|---|
| A1 | ⟨query or bound⟩ | ⟨the finding or risk it traces to⟩ |
| A2 | ⟨…⟩ | ⟨…⟩ |
Bounds are set here, never read from the agent's own configuration — a cap that verifies against its own config cannot detect a misconfigured cap. The set ships as a runproof profile you keep and run on your own infrastructure.
5. Remediation
Hours, not prices. Pricing is a separate conversation, held after you have read this.
| Work | Est. | |
|---|---|---|
| 1 | ⟨fix⟩ | ⟨hours⟩ |
| 2 | ⟨…⟩ | ⟨…⟩ |
6. What this audit did not cover
⟨Systems not inspected, windows not examined, claims taken on trust — scoped honestly.⟩
The rules that produce it
- 1.Severity is consequence × undetectability. A loud crash ranks below a quiet wrong answer, because somebody already knows about the crash.
- 2.A finding without a failure scenario is an opinion and is deleted, not explained.
- 3.Evidence is file and line, or a query you can run. Never “the send logic”.
- 4.Every assertion traces to a finding or a named risk. One that traces to nothing gets cut.
- 5.No AI in the checks. You cannot verify a system that makes things up with a second system that makes things up.
- 6.Only what was observed. No inferred architecture, no “you probably also…”.
What you would sign to get one is on the contract page. The audit is free if it finds nothing at High or Critical.