# What should a policy acknowledgement product record?

By Sean Everett · October 6, 2026

Make document views, acknowledgements, understanding checks and completed work distinguishable. Connect each record to the relevant version and explain what the evidence actually captures.

Topics: Workflow design · Policy products · Product data

## Give each interaction an accurate meaning

A policy workflow can contain several different events: opening a document, submitting an acknowledgement, answering a question and completing a related task. Define them individually so the product can explain what happened without making an unsupported inference about the person.

Use labels that match the interaction being recorded. W3C's checkbox guidance describes checked and unchecked interface states and the need for an accessible label. Those states communicate a selection. Any meaning assigned to that selection depends on the wording and workflow around it.

For example, a person might acknowledge receiving an updated procedure while still needing help applying an exception. Provide a route to ask that question alongside the acknowledgement. Decide which event the workflow needs for its immediate purpose, and avoid a single completion status that silently combines several different expectations.

## Keep the record attached to the right version

Associate an acknowledgement with a specific document revision, the event time and the account involved. Retain the action's wording so a later reviewer can understand what the person was asked to acknowledge. Collect only the detail needed for the workflow, and limit access to the record appropriately.

W3C's provenance model treats document revisions as distinct entities with relationships between them. That offers a useful design principle here: a new revision should remain distinguishable from the version associated with an earlier event. The product can then show both history and current status accurately.

Give readers a concise explanation of meaningful changes and a route to the current procedure. Decide explicitly which changes require another acknowledgement under the organization's chosen process. Preserve the earlier event rather than making it appear that the person acknowledged wording they never saw.

## Test understanding and completed work separately

When understanding matters, test the content through a realistic task or question. Ask a reader to explain the next step in an ordinary scenario and observe where the wording leaves them uncertain. GOV.UK's moderated-testing guidance uses task performance to examine whether people understand a service and can use it.

Keep the scope of that check visible. Answering one scenario provides evidence about that scenario under those conditions. A completed procedure may need a different record, such as the resulting work item and the review it requires. Choose evidence that corresponds to the expected action.

In reporting, show the statuses separately and name unresolved cases clearly. This helps the owner decide whether to improve access, clarify the instruction, provide practice or investigate a blocked task. The design goal is an interpretable operational record whose meaning stays consistent from the interface to the report.

## Related reading

- [W3C guidance on checkbox states and labels](https://www.w3.org/WAI/ARIA/apg/patterns/checkbox/)
- [W3C primer on provenance and document revisions](https://www.w3.org/TR/prov-primer/)
- [GOV.UK guidance on moderated usability testing](https://www.gov.uk/service-manual/user-research/using-moderated-usability-testing)
- [Making an operating process repeatable](https://evergences.com/insights/operating-process-team-handoff/)

Source: https://evergences.com/insights/policy-acknowledgement-product-evidence/