Skip to main content
Wildo.ai Coming soon

Privacy notices, terms & policies

Product-specific documents assembled from application facts, operating choices and reviewed clauses.

Privacy notices · terms of service · policies · language variants

> 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.

Application documents connect product facts, operator decisions and review.

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

ArtifactResponsibility
Document definitionPurpose, required concerns and permitted audience/interaction structure
Application factsSource-informed statements and attributed operator decisions
Document candidateReadable clauses with fact references and completeness information
Publication variant and release policyIntended locale/jurisdiction and release requirements
Composed releaseVersioned identity joining the candidate, variant, policy and review decisions
Runtime interaction surfaceSelected 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.

Public notices, internal policies and operational guidance have distinct document purposes.

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 familyWhat 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.

Application facts, operator choices and evidence support document statements.

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 informationPurpose
Source fact referencesIdentify the factual basis cited by the clause
Completeness categoryDistinguish established content from unresolved content
incompleteness.needsDescribe what is needed to complete the statement
closedByIdentify how the unresolved item can be settled
awaitingFactRefsConnect 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.

Drafting, review and publication are revisited when the product changes.

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.

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.