Know where to look for proof
A declaration, an audit event and a completed review answer different questions. Wildo’s assurance model distinguishes where the evidence lives and whether it describes configuration, a driven check or real operation.
That distinction turns an assurance request into a practical investigation: what to collect, from which source, over which scope and period.
Example — Confirm that a security event was recorded
For an authentication event, inspect the durable event record and its attribution. A setting that enables the audit trail is useful context, but it cannot stand in for the event itself.
For engineers
Follow the authored evidence body
The security-event requirement identifies an actual durable-record home and a production plane. The excerpt below is from assurance-evidence-requirement-bodies.definitions.ts; the surrounding applicability text conditions the demand on the audit capability being enabled.
clauses: [
{
clauseRef: "C1",
obligation:
"Authentication, authorization, privilege, credential and security-configuration changes each emit a typed auditable event.",
home: AssuranceEvidenceHome.EMITTED,
plane: AssuranceEvidenceExecutionPlane.PRODUCTION,
homeRationale:
"The demanded artifact is a per-occurrence row in the engine's own durable event store, so one collector query "
+ "serves every application. Not read off the attesting capability: it is read off the artifact the clause names.",
requiredAuditEventMembers: [
// authentication
CoreAuditableEventType.USER_LOGIN,
CoreAuditableEventType.USER_LOGIN_FAILED,
CoreAuditableEventType.USER_LOGOUT,
CoreAuditableEventType.USER_SESSION_EVICTED,
Its remaining event members, minimum-evidence description and verification steps define the rest of the requested population. A collector must inspect the store of record for that demand; a filtered convenience view is not necessarily the same population.
Match the evidence to the question
| Evidence | What it can establish | Context to retain |
|---|---|---|
| Committed declaration | The selected configuration or policy | Application and framework revision |
| Durable event or execution record | An occurrence and its outcome | Actor, target, time and relevant scope |
| Driven verification | Behavior under the exercised scenario | Scenario identity and tested version |
| Review or provider artifact | The performed review or external observation | Responsible party, period and source |
The body’s home and execution plane are authoritative. The repository’s older assurance:evidence-homes report derives proxy classifications from bindings and names; use it for exploration, not to override an authored clause.
Separate collection from judgment
The intended independent assurance workflow collects source artifacts before judging satisfaction. An unavailable export and a control that failed are different findings. A review should cite reproducible observations, preserve uncertainty and explain severity separately. This model defines what an evaluator needs; it does not turn an unexecuted demand into evidence.