Wildo is assurance-ready by construction: the control, its marker and its evidence are one grep apart

Wildo treats auditability, access control, privacy and evidence as properties of the engine rather than as a programme bolted on before an audit. Security-relevant actions emit audit events, authorisation fails closed, access decisions are recorded, and every place in the source that implements a control is marked with a stable objective identifier. What a compliance programme has to say about an application is then composed from what the framework demonstrably does, not from what someone remembers it doing.

The problem it answers

Assurance work in most software is reconstructive. The controls exist somewhere in the code, the policy document was written by someone else, and the evidence is gathered afterwards by people who have to rediscover the link between the two. Every application repeats the reconstruction, the link drifts each time the code moves, and the document ends up describing a version of the system that no longer exists.

The failure has a second, quieter form: a claim written against an external framework’s control identifiers instead of against the code. A row that says “this identifier is satisfied” is a compliance judgement, and forty or fifty of them authored in one pass by whoever happened to be building the artifact is precisely the kind of table nobody can defend later. Wildo’s recorded position is that this judgement belongs to a reviewer, that it lives at a reporting boundary, and that it never selects what the software does.

What it rules in, and what it rules out

Ruled in

A marker beside the code. A control is annotated where it is implemented, with a greppable assurance-control: comment naming one or more stable Wildo objective identifiers of the form WILDO.<AREA>.<OBJECTIVE>. An identified but unimplemented control carries the same marker under a TODO(assurance-control) prefix, so a gap is visible in the same search as a control.
Fail-closed authorisation and recorded denials. An unresolvable scope yields no rows rather than all rows; a denial is classified and audited; an audit-pipeline failure is itself made detectable.
A closed objective catalogue. Forty-nine WILDO.* objectives, each with a title and an intent, each bound in an authority basis to what it demands and which engine capability attests it. A marker naming an objective outside the catalogue fails a mechanical check.
Privacy as engine operations. Subject export and erasure are system-access operations that walk every resource, and a resource that has not declared its export posture refuses rather than defaulting.

Ruled out

External framework names in production code. External framework and control identifiers live only in a rights-classified mapping boundary used for reports. A checker scans nine trees of the repository, including the templates copied into every generated application and this public marketing tree, and refuses the vocabulary anywhere else.
A crosswalk table. The external mapping joins objectives to reviewed source requirements the authority basis already carries, each stamped with the reviewer that approved it. It decides nothing, reproduces no normative text, and asks the rights record of each source whether even storing metadata about it is permitted.
Claiming that a control has worked. A binding in the authority basis says what an objective demands and what attests it. It may not claim that the control has actually operated in a given deployment; that is evidence, gathered per occurrence, and a separate report admits which objectives currently have no evidence home.

What it means for someone building with Wildo

Ask the source what it does about a control and get an answer in one search: the marker names the objective, the catalogue names the intent, the basis names what attests it.
The evidence a programme needs is composed from declarations the application makes about itself (operator identity, jurisdictions, processors, personal-data categories) and from what the engine implements, so a document is regenerated when the application changes rather than rewritten from memory.
Your audit events reach your customers’ security tooling per organisation, in a format their products expect, with retry when their endpoint is down. Each customer sees only their own.
Subject export and erasure are decisions you make per resource, and the framework refuses to let you skip the decision. Retention that must survive erasure is a declared policy, not a manual procedure.
Wildo does not claim to comply with any external framework on your behalf. It gives a reviewer a rights-safe mapping from Wildo’s own objectives to reviewed source requirements, and keeps the external identifiers out of the code that runs.

For engineers

Where it lives in the framework

The chain is short enough to draw:

assurance-control: markers in engine and platform source
        |   checked against the catalogue by check-assurance-control-boundary
        v
INITIAL_ASSURANCE_OBJECTIVE_CATALOG          49 objectives: identifier, title, intent
        |
        v
the authority basis                          what each objective demands, what attests it
        |
        v
an application's compliance programme        which objectives this product commits to
        |
        v
governed documents                           clauses citing facts the application declares

Markers. Several hundred assurance-control: lines sit in engine/ and platform/ outside test trees; the count is re-derived by grep rather than quoted. A representative site is the delegated-authorisation consent flow, where the user’s refusal and the user’s approval of third-party access are each marked, and the token issuance that follows is marked again.
The boundary checker. check-assurance-control-boundary.mjs reads every marker, verifies each objective identifier against the catalogue, and refuses external framework vocabulary outside the authorised mapping fixture. It runs over engine, platform, examples, scripts, templates, marketing, .github, .claude and the root instructions file.
The audit trail. AuditLogsBackendService writes an authoritative audit-log row, dispatches the event to the owning organisation’s configured security monitoring system, and fans out to provider sinks through a composite sink. An event is real only when it has an enum member, a severity classification and a producer; the curated map records that two events once had the first two and no producer, which is why the third is checked by grep before an event is believed.
Per-organisation export. A SIEM_EXPORT_CONFIG resource per scope carries destination, authentication or signing, filtering and batching. Dispatch routes on the authenticated organisation and fails closed when there is none, so a caller-supplied organisation cannot redirect another tenant’s events. Structured JSON, CEF, LEEF and OCSF are produced from one projection contract; failed deliveries land in a dead-letter queue with requeue. The end-to-end lanes test the grammar with an independent receiver double; no commercial security product has yet parsed the export, and the corpus says so.
Subject export and erasure. exportSubjectAsSystem walks every resource whose configuration declares systemAccessPolicy.exportSubject, with no HTTP route on purpose, because the obligation binds the application as controller. Erasure runs with a retentionPolicy of RETAIN_ONLY or RETAIN_AND_IMPERSONALIZE, so a record the law requires to survive is kept, hidden, frozen and scrubbed field by field; a dogfood scenario drives the whole journey from self-service request to truthful receipt.
The mapping boundary. assurance-external-framework-mapping.ts composes the bridge from the authority basis and the source registry, reports per-source rights permissions, and records an objective with no reviewed source as unmapped with the reason rather than inventing one.