Privacy notices, terms & policies

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.

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.

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

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.

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, and compliance.publicDocuments to the public privacy and terms pages. wildo config document-releases writes both into backend-api/src/governed-document-releases.generated.ts through allow-list projections such as projectGovernedDocumentInteractionSurface, so governance scope and approval details never reach a public browser.

The same command records each new release, with the text it publishes, in specifications/src/document-releases/recorded-releases.generated.ts. A recorded release is never recomposed: editing the draft afterwards does not change it, and publishing new text is a new release version. wildo config validate --domain document-releases fails when the generated runtime module is out of date, so commit the regenerated files with the release decision.

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.