Privacy notices, terms & policies
Product-specific documents assembled from application facts, operating choices and reviewed clauses.
Privacy notices · terms of service · policies · language variantsMake your documents reflect your application.
> Statements grounded in product facts> Review with clear responsibility> Documents maintained as the product changes
Compliance documentation explains the application's commitments, data handling and operating responsibilities to the people who need to understand them.Wildo structures document preparation around application facts, operator decisions and explicit review. The result is a document set that can be examined and maintained with the product.

Connect readable commitments to their basis
Prepare the relevant documents
Distinguish public notices and terms from internal policies and operational guidance. Each document has its own purpose and audience.
Keep the facts attached
Connect clauses to their supporting facts and the concerns they address. Make unresolved decisions visible during preparation.
Review and maintain
Compose releases with explicit variants and review information. Reassess statements when the facts behind them change.
Example: Update a notice after a product change
An application adds a new category of contact information. The document process revisits the relevant facts and clauses, then prepares the appropriate language and market variant for review.
For engineers
Give each artifact a clear responsibility
| Artifact | Responsibility |
|---|---|
| Document definition | Purpose, required concerns and permitted audience/interaction structure |
| Application facts | Source-informed statements and attributed operator decisions |
| Document candidate | Readable clauses with fact references and completeness information |
| Publication variant and release policy | Intended locale/jurisdiction and release requirements |
| Composed release | Versioned identity joining the candidate, variant, policy and review decisions |
| Runtime interaction surface | Selected release metadata used by application interactions |
A draft is not a certification, and composing a release does not invent approval. Runtime evidence, specification-derived statements and qualified review remain different sources of authority.
Follow the preparation chain
The application-creation document-fact step prepares facts from available application information and obligations. Candidate drafting uses those facts and a document blueprint. Coherence checks examine references and coverage; the release composer then checks agreement among the selected candidate, variant and policy.
Generated fact authority labels do not independently prove that every statement was derived from the required source. Review the actual basis of material claims, including the application’s behavior and accountable operator decisions.
Connect a release to its application use
The composer and runtime interaction consumers exist. Automatic projection from composed specification releases into runtime configuration is separate work; the current reference application transfers that surface explicitly.
The parts below explain the actual source artifacts and review lifecycle. Full document serving, release selection and recording a person’s acceptance are separate contracts, not interchangeable meanings of publication.
Prepare the documents people actually need
Give public notices, service terms and internal governance documents distinct purposes instead of treating them as one generic policy.
Document definitions connect the intended audience to the concerns the content must address.

Match the document to its responsibility
Explain the public commitment
Notices and terms describe relevant product and operator commitments for the people using the service.
Organize internal responsibilities
Governance documents describe the programme, its scope and the responsibilities around operating it.
Address the required concerns
Use the document blueprint to guide coverage while writing readable clauses for the intended audience.
Example: Separate a customer notice from an internal policy
The notice explains relevant data handling to customers. An internal document explains who maintains that account and how changes are reviewed. Their relationship does not make their audience or purpose identical.
For engineers
Use the catalogue as a structured starting point
The initial document catalogue includes privacy notice, service terms, programme handbook, scope/system description, roles/responsibilities and document/record control definitions. Application-specific relevance and content still need to be established.
| Source family | What it owns |
|---|---|
specifications/src/document-facts/ | Produced application facts |
specifications/src/document-facts-authored/ | Attributed authored facts and decisions |
specifications/src/compliance/ | Application compliance specification material |
specifications/src/document-publication/ | Declared publication variants |
specifications/src/compliance-document-candidates/ | Structured document drafts |
These are application specification artifacts, not generated public pages. The framework authoring workflow and landing targets identify their ownership.
Make coverage more useful than a list of citations
A candidate’s sections and clauses can identify blueprint concerns, required sections or clauses, source facts and review guards. Valid fact references establish that the named inputs exist; coverage checks ask whether the required concerns were addressed.
Neither check, by itself, proves that a sentence is accurate or appropriate for its audience. Review the claim and its basis together.
Choose variants deliberately
Locale and jurisdiction identify the intended publication variant. Use the declared canonical variant when composing a release, rather than attaching an arbitrary language label after drafting.
The document set helps organize commitments. It does not establish that the operator satisfies every obligation merely because the corresponding definition is present.
Preserve the basis behind each statement
Connect readable clauses to what is known about the product and to decisions made by accountable people.
Keep missing facts and unresolved decisions visible while preparing the document, so the writer does not silently fill them with assumptions.

Make the basis inspectable
Begin with the application
Use declared product information and supported behavior to inform factual statements before drafting prose.
Attribute the decisions
Keep operator choices and qualified review distinguishable from technical declarations.
Expose what needs resolution
Record why a clause is incomplete and what would establish the missing information.
Example: Explain how a record is retained
The application supplies its configured retention behavior. The operator supplies relevant operating decisions. The clause explains their effect and keeps its references attached for review.
For engineers
Follow the two preparation steps
refinement.document-facts receives application information and fact obligations. refinement.compliance-document-candidate receives the established facts and blueprint. This gives prose a defined factual input rather than letting the drafting step create its own account of the product.
The fact authority vocabulary distinguishes APPLICATION_SPECIFICATION, RUNTIME_EVIDENCE, CREATOR_DECISION and QUALIFIED_REVIEW. Those names identify materially different bases; they cannot substitute for each other simply because the resulting sentence sounds plausible.
Use incompleteness to identify the next action
| Candidate information | Purpose |
|---|---|
| Source fact references | Identify the factual basis cited by the clause |
| Completeness category | Distinguish established content from unresolved content |
incompleteness.needs | Describe what is needed to complete the statement |
closedBy | Identify how the unresolved item can be settled |
awaitingFactRefs | Connect the unresolved clause to specifically awaited facts |
Missing application configuration, an operator decision and missing framework support are different causes. Preserve that distinction so resolution goes to the right place.
Review authority as well as wording
The current fact generator labels its output with specification authority. That label is not a proof that the statement was derived from an accepted specification or satisfies a blueprint’s qualified-review requirement.
Inspect the supporting source, its authority and the actual assertion. Do not elevate a declaration into runtime evidence or a model-written statement into an independently reviewed conclusion.
Revisit clauses when facts arrive
Application coherence checks combine the produced and authored fact families. When a clause still marks a fact as awaited after that fact has been established, they can report STALE_MARKED_CLAUSE.
That finding calls for redrafting and review. It does not automatically rewrite the clause or approve its replacement.
Review releases and keep them aligned with change
Give a document release an explicit identity, intended variant and review record.
As the application changes, revisit the facts and statements involved, then choose which release should be used by the application.

Preserve the meaning of a release
Join the right inputs
Compose the candidate with its document definition, publication variant and release policy.
Record real review
Approval decisions represent review that actually happened. A coherent draft can exist before approval.
Reassess after change
Check updated facts, revise affected clauses and carry the chosen release into the application’s delivery process.
Example: Prepare a revised privacy notice
The team composes a new release identity from the reviewed candidate and intended variant. It checks the application-facing release selection separately from producing the document record.
For engineers
Use the real release composer
This adapted Wonder CRM excerpt shows the composer inputs. The source resolves the catalogue definition, declared variant, policy and requirement first. Its inline parsed governance scope is named governanceScope here for readability; that declaration and imports are omitted.
const composed = composeGovernedDocumentRelease({
definition: privacyNoticeDefinition,
candidate: applicationComplianceDocumentCandidate,
variant,
publishedVariants: applicationDocumentPublicationSpecification.variants,
releasePolicy,
requirement,
identity: GovernedDocumentReleaseIdentitySchema.parse({
document: {
documentRef: 'document:public.privacy-notice',
documentVersion: 1,
},
releaseId: 'document-release:wonder-crm-privacy-notice-2026',
releaseVersion: 1,
}),
governanceScope,
approvalDecisions: [],
issuedAt: '2026-09-11T00:00:00.000Z',
effectiveAt: '2026-09-11T00:00:00.000Z',
});
composeGovernedDocumentRelease checks agreement among the candidate, variant, definition and policy. It derives class and interaction metadata from the selected definition instead of asking the application to duplicate those decisions.
The reference application’s release deliberately carries no approval decisions and remains unapproved under a draft-only policy. Its advisories are preserved. A coherent release record can therefore exist while review remains unfinished; resolveEffectiveDocumentRelease with requireApproved: true withholds unapproved records.
Keep the runtime surface narrower than the governance record
Application configuration exposes compliance.governedDocumentReleases to consumers such as registration and governed-interaction recording. The intended projection is projectGovernedDocumentInteractionSurface, which avoids exposing governance scope and approval details to a public browser.
The automatic specification-to-runtime projection is not yet connected. The reference application currently carries an explicit copy. Review that handoff when a release changes; editing the specification alone does not synchronize the running application.
Distinguish document access, acceptance and consent
Registration can select an in-force declared contract release and record explicit acceptance against its identity. A privacy notice is not automatically a contract-acceptance request or consent request.
Serving the full readable document, selecting its effective release and recording an interaction are separate responsibilities. Verify the intended release and interaction through the actual application journey, including refused or unavailable release cases.
Clear commitments begin with a clear account of the product.
Documents make that account readable. Wildo connects their preparation to facts, decisions and review, helping the application team maintain what it says as well as what it builds.
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.