Every assertion in a report rests on something, and the something is either named or assumed. Producing assertions is the easy part of the work, because a conclusion can be reached long before the evidence that would support it has been obtained. The discipline is refusing to make an assertion that cannot be supported, including where it is correct.
That last condition is the one that decides how the work is judged over time. Being right on an unsupported finding is the outcome that costs most, because it succeeds on the day, it earns a reputation for insight, and it trains the practitioner to skip the step that protects them on the occasion the intuition is wrong. That occasion is the one management challenges, and a challenged finding with nothing behind it does not fail alone. It takes with it the findings in the same report that would have held, because a reader who has watched one assertion collapse reads the rest differently.
The established hierarchy holds, with adjustments for what these systems make available.
Strongest: direct observation of configuration. Effective permissions exports, API validation rules, orchestration configuration, and connector definitions. Each of these is the deployed state read directly, which is what an assertion about capability has to rest on, because capability is a property of the configuration rather than of the history.
Strong: the transaction and action record. Refund ledgers, action logs, and conversation records establish what occurred, over time, across a population rather than a sample. The record is decisive for a positive assertion, because eleven rows above a limit are eleven instances, and it is strong for a negative one, because an absence across a full period is a different claim from an absence across a sample.
Moderate: testing performed by the practitioner. A test is definitive for what it covers and narrow in what it covers. A successful test establishes that a capability exists, which is worth a great deal. An unsuccessful test establishes that one attempt on one phrasing was declined, and since the system is probabilistic that is a single sample. Tests are therefore reported asymmetrically: obtaining something is a finding, and being declined is not evidence that a control holds.
Weak: documentation. A design document evidences intent and approval, which nothing else evidences, so it is the right source for the question of who agreed to a capability. It does not evidence the current state, because it was written before the state existed.
Weakest: assertions by people. An interview establishes that a person believes something, which is a fact about the person rather than about the system. That is worth knowing, because it directs where expensive effort is spent, and it is not the basis on which a conclusion is drawn.
Corroboration by repetition. Three people giving the same answer is one source stated three times, because they share an organizational understanding rather than an observation, and a shared understanding can be wrong in the same way three times. Independent corroboration means a different kind of evidence, so an interview is corroborated by a configuration or a record rather than by a fourth interview.
Reporting from an unresolved contradiction. Two pieces of evidence cannot both be true, and the finding is written from the one that supports the conclusion already formed. This is the gravest defect on the list, because the report shows no trace of it and the contradiction is indefensible once found. A conflict between two sources is where expensive effort belongs, and where it genuinely cannot be resolved, an accurately reported unresolved conflict is a legitimate output and a more useful one than a resolution asserted without basis.
Take each assertion and name the specific artifact behind it, rather than the category it belongs to. The claim that the refund limit is not enforced rests on the API validation rules read on the fourteenth and on the eleven ledger rows above the limit. Where that sentence cannot be completed, the assertion is a hypothesis.
Hypotheses belong in their own section, labelled as such, each with the work that would settle it. A section of that kind states what the engagement did not establish and what it would take to establish it, which is a service to the reader. An assertion that should have been in it is the thing that gets challenged.
This brief is one of ten behind Module 1, The tool surface, a free guided walkthrough of an AI agent assessment at a credit union. The same engagement can be run unassisted, with the check questions above put to you against evidence rather than against a description.
NexNith advises boards and audit committees on exactly this work. How we work