Ground obligations in the product and its context
The application’s obligations depend on what it does, the data it handles and the contexts in which it operates. A convincing document cannot replace that understanding.
Wildo separates research, evidence assessment, posture and programme design. The resulting declarations help connect policy choices to the product and the evidence needed to support its statements.
Example — Review a new operating context
A team plans to serve a new customer group. It reviews the relevant research and product facts, checks whether the available evidence is sufficient, and updates the application’s policy choices and implementation work accordingly.
For engineers
Read the posture method’s declared prerequisite
These selected fields come from the posture playbook definition. Method guidance and the longer output description are omitted:
{
"preconditions": [
{ "kind": "artifact_exists", "selector": { "family": "vision-brief" } },
{ "kind": "step_available", "ref": "compliance-adequacy", "requires": { "path": "verdict", "equals": "adequate" } }
],
"inputs": [{ "family": "vision-brief" }],
"outputs": [{
"family": "vision-brief",
"schemaRef": "saas-specifications:VisionSnapshot",
"description": "The existing vision refined with compliance constraints."
}]
}
The prerequisite names the adequacy result the method expects. Its output refines the vision’s relevant constraints while retaining the rest of the product intent. The shortened description above summarizes the authored definition rather than quoting it verbatim.
Follow the distinct outputs
| Activity | Role |
|---|---|
| Research | Gather attributed material relevant to the product context |
| Adequacy assessment | Judge whether that material supports the next decision |
| Posture | Record applicable constraints in product intent |
| Conception | Define the assurance programme and related publication/release choices |
The research umbrella admits research, adequacy and posture activities. Conception is a separate method. Research and adequacy results are not themselves the same file family as the accepted programme.
Keep claims attached to their basis
Product declarations, runtime evidence, creator decisions and qualified reviews are different kinds of support. A producer’s authority label is attribution; it does not automatically prove the statement it accompanies.
Programme choices must connect to the application’s actual controls and evidence. Candidate documents and publication have their own review and release lifecycle. Use the document-facts guide for that connection; a generated policy statement is not a certification of the application.