Application assurance auditor
A dedicated service in development to assess application evidence and produce traceable findings.
Evidence requirements · review plans · findingsMake assurance findings traceable to your application.
> A review scoped to the product> Evidence that answers a defined question> Findings people can inspect and act on
An application assurance auditor examines declared commitments and supporting evidence, then explains what is established, what needs attention and what remains unknown.Wildo’s independent auditor is in development. Its foundation already connects application configuration to evidence requirements and review planning; the intended service turns that foundation into a recurring, evidence-backed review.
Give every conclusion a visible basis
Review the right scope
Start with the configured application and the commitments being examined. Establish which requirements apply before gathering evidence.
Separate evidence from judgment
Collect the relevant facts and observations, then evaluate them against a named requirement. Keep uncertainty visible.
Make findings actionable
Preserve the target, evidence and reasoning behind a finding so people can investigate it and reassess it after a change.
Example: Interpret an empty security-event window
No security events in a quiet period may be expected. No events despite relevant activity calls for investigation. A useful review connects the observation to the activity and requirement before deciding what it means.
For engineers
Understand the intended host and output
The designed auditor runs outside the audited backend, with one instance per application. It reads committed application information and scoped evidence sources, and writes its findings to a dedicated assurance repository.
Scheduled collection, judgment and the durable finding lifecycle are being completed. The current basis checks, evidence planner and historical pilots are inspectable building blocks; they are not a deployed continuous auditor.
Follow the existing preparation chain
| Existing mechanism | What it establishes |
|---|---|
| Source control markers and authority basis | Named objectives and their declared implementation/evidence expectations |
| Application programme validation | Consistency of programme declarations against supplied authorities |
| Capability applicability derivation | Which requirements are applicable, unavailable or unresolved as configured |
| Evidence collection planner | Which clauses need which evidence sources |
| Historical collection and review pilots | Concrete observations and calibration lessons for particular targets and windows |
The framework distinguishes SELECTED, CONFIGURED, OPERATING, EVIDENCED and ASSESSED. Declaring a required proof stage does not establish that the application has reached it.
Check the accepted basis in an application
Run this from an application with its specifications companion export available:
wildo context assurance-basis --check
The command checks declared basis references and compatibility generations against the installed framework registry. Unresolved declared generations fail the check. An absent declaration is reported as not declared; it is not a compliance verdict.
Keep external assessment distinct
An internal automated review can gather evidence and explain findings. It does not confer certification or replace an independent external assessment. The service design preserves the achieved review independence and calibration status rather than hiding them behind a single compliance label.
Decide what applies before asking for proof
Review the application that is actually configured, with its declared commitments and enabled controls.
The assurance basis helps distinguish an applicable requirement from one the current configuration does not support.
Keep the review specific
Name the commitment
Use a stable objective and evidence requirement so the reviewer knows what is being examined.
Inspect the configuration
Relate requirements to enabled capabilities and the application’s declared context.
Preserve uncertainty
A partly available dependency set is unresolved, rather than an automatic pass or a silent omission.
Example: Check a requirement tied to audit events
Before querying for audit evidence, establish whether the application enables the capability that supports the requirement. Missing events alone cannot answer that configuration question.
For engineers
Validate with the intended authorities
createAssuranceProgramValidationAuthorities composes the available authority from the framework basis, application capabilities and host facts. validateAssuranceProgramSpecification(program, authorities) returns consistency issues against that supplied context.
Calling the validator without authorities performs its structural checks; it does not provide the same authority-aware validation. Preserve the distinction in any application-creation or review integration.
Interpret capability applicability correctly
deriveExpectationCapabilityApplicability compares required capability references with available references. Its result is about configuration:
| Result | Meaning for the review |
|---|---|
APPLICABLE | The required capability dependencies are available; evidence is still needed |
NOT_APPLICABLE | The required capabilities are absent as configured |
UNDETERMINED | Only part of the dependency set is available; the unresolved portion remains visible |
A source marker points to an implementation site. It neither enables a capability nor proves that a runtime path executed.
Inspect a real application’s consequences
This is a framework-repository inspection tool, not an installed application CLI command:
node scripts/assurance/report-capability-consequence.mjs \
--app examples/wonder-crm --json
The report connects selected capabilities to the affected assurance expectations. Read it against the application’s current declarations; a historical result for another application or revision is not the current review scope.
Gather evidence that answers the question
A configuration setting, a recorded event and an observed refusal establish different things.
Evidence requirements identify what must be inspected and where it should come from, keeping collection tied to the claim under review.
Choose evidence by its meaning
Read declarations
Inspect the accepted configuration and specifications when the question concerns an explicit product choice.
Observe operation
Use relevant events or driven behavior when the question concerns what the application actually did.
Retain the context
Carry the application revision, observation window and scope with the evidence so its meaning survives the review.
Example: Check a security-event path
A declaration identifies the required event behavior. A recorded event demonstrates one occurrence. A driven test can examine a refusal or missing-delivery path. None alone proves that every event-producing path is covered.
For engineers
Route clauses to their evidence sources
A requirement body carries clauses, evidence homes, execution planes, minimum evidence, verification steps and interpretation guidance. Homes such as DECLARED, EMITTED, OBSERVED, PERFORMED and APPLICATION_RECORDED identify where collection must go.
For example, an emitted security event belongs to its store of record. A performed review needs the review evidence. A queue execution record is not automatically evidence of an unrelated scheduled process.
Inspect the existing collection plan
From the framework repository:
node scripts/assurance/plan-evidence-collection.mjs \
--app examples/wonder-todos \
--requirement evidence-requirement:security-event-record \
--json
This tool plans collection; it does not query the running application or judge the result. It resolves applicability first and groups the remaining clauses by evidence home.
The selected source below shows why an unavailable requirement is not treated like an empty successful collection. Comments are omitted.
if (applicability.status === 'NOT_APPLICABLE') {
return {
...base,
verdict: 'NOT_APPLICABLE_AS_CONFIGURED',
clausesByHome: [],
derived: true,
};
}
const byHome = new Map();
for (const clause of demand.body?.clauses ?? []) {
if (!byHome.has(clause.home)) byHome.set(clause.home, []);
byHome.get(clause.home).push({
clauseRef: clause.clauseRef,
plane: clause.plane,
obligation: clause.obligation,
requiredAuditEventMembers: [...(clause.requiredAuditEventMembers ?? [])],
});
}
return {
...base,
verdict: null,
derived: false,
clausesByHome: [...byHome.entries()]
.map(([home, clauses]) => ({ home, clauses }))
.sort((left, right) => left.home.localeCompare(right.home)),
};
For requirements needing evidence, verdict: null preserves that collection and evaluation have not occurred. The plan is useful preparation without pretending to be a completed audit.
Collect from the authoritative source
The intended service uses scoped application and provider access. Collector output must retain the source, target and time window; the judgment stage receives that evidence separately from collection decisions.
Provider-state acquisition and the standing collection loop remain implementation work. An unavailable evidence export is a finding about evidence access until the underlying control’s behavior has been established.
Explain the finding and the next useful action
A useful finding separates what was measured from what the reviewer concludes about it.
The intended assurance record keeps the evidence and reasoning together, allowing the application team to investigate, correct and reassess the same matter.
Make the result inspectable
Describe the observation
State the target, relevant activity and measured result before assigning a classification.
Explain the judgment
Connect the evidence to the requirement and preserve uncertainty or disagreement where it matters.
Reassess the matter
Keep a stable finding identity so repeated review follows the same problem instead of creating a new report each time.
Example: Avoid a false alarm in a quiet period
A historical calibration case supplied no events and no relevant activity. It exposed an overly broad rule that would have treated silence as a logging failure. The lesson was to check the triggering activity before classifying the absence.
For engineers
Use the verdict vocabulary precisely
| Verdict | Meaning |
|---|---|
CONFORMANT | The requirement is supported by the reviewed evidence within its scope |
OBSERVATION | A relevant matter is recorded without asserting demonstrated nonconformity |
NONCONFORMITY | Evidence establishes failure against the requirement |
INSUFFICIENT_EVIDENCE | The available evidence cannot establish the conclusion |
NOT_APPLICABLE_AS_CONFIGURED | The configured application does not support the requirement’s applicability |
This vocabulary exists in the assurance model. Its presence is not a persisted finding service or evidence that a scheduled review has run.
Learn from the full pilot sequence
The security-event pilot includes the original finding, calibration, an independent fresh-context judgment and recollection. The later review changed the interpretation; the final recollection concluded that the requirement was not applicable as configured.
Read that sequence as evidence of the review method. Do not reproduce the initial finding as a statement about today’s deployment or omit the later result that superseded it.
Design recurring review around stable identity
The intended service matches findings by requirement, deficiency and scope, with judgment confirming whether new evidence concerns an existing matter. Reassessment updates that matter; it should not flood the operator with duplicates.
The proposed output lives in a dedicated application assurance repository. Consolidated snapshots identify the application revision and framework generation. Notifications summarize meaningful changes, while critical findings have their own escalation path. These are the standing service’s delivery requirements, not current planner output.
Make review independence visible
Collection and judgment have different responsibilities. Fresh-context evaluation, independent authorship, model diversity where available and planted calibration cases address different sources of error.
Preserve the achieved independence and calibration status in the result. An internal panel still belongs to the operator’s assurance process; external assessment remains a separate authority.
A finding is useful when its basis can be questioned.
Scope, evidence and reasoning make assurance work inspectable. Wildo’s auditor is being built around that chain, so recurring review can support concrete improvements without turning uncertainty into a promise.
Building a B2B product or an internal tool?
Wildo is not self-service yet. Tell us what you have in mind and we will say plainly whether it fits, and what happens next.