Evidence from tools that have no API

Some evidence lives in an admin console with no suitable API or export. That does not make every screenshot trustworthy. The goal is a repeatable capture whose scope, route, time, and handling can be reviewed later—not a free-form browser session.

Use the strongest source available

Prefer a structured, read-only API response or export when it contains the needed facts. Structured data is easier to compare, validate, minimize, and recollect. Use a browser capture only when the provider-side UI is the authoritative or only practical view of the setting.

Before approving a playbook, write down:

• the requirement and exact fact the screen must show;
• the allowed host, route, and navigation sequence;
• the account, tenant, project, or other scope marker visible in the capture;
• the fields that must be redacted or excluded;
• the expected success state and bounded failure behavior; and
• the owner and cadence for revalidation when the provider UI changes.

Make the capture self-explaining

A reviewer should be able to identify the system and scope without relying on the filename. Capture the relevant page heading, setting label, selected resource, and timestamp. Preserve a navigation trail and content hash beside the image. Avoid collecting unrelated tables, notifications, user details, or secrets just because they happen to share the screen.

Plan for change and failure

Console layouts change. A safe playbook should fail closed when its approved route, expected labels, or target element cannot be found; it should not wander through the interface looking for a replacement. Treat a failed capture as an operational gap to investigate, not as permission to store whatever page loaded.

Revalidate after meaningful provider UI changes and retain the prior capture for audit history. If an API becomes available, reassess whether the browser route is still justified.

What AuditFetch does—and does not do

AuditFetch browser playbooks are declarative and bounded to approved routes. They preserve capture time, navigation context, redaction handling, and content-hash provenance through the same evidence lifecycle as supported connector artifacts. They are not free-form browsing, do not prove the truth of information outside the captured view, and do not replace reviewer judgment.

The discipline that keeps it trustworthy: API evidence first, screenshots only where the API can’t prove it. Structured exports are stronger, easier to validate, and harder to manipulate, so AuditFetch prefers them — and uses a browser playbook only where it’s the one way to get the proof.