AI summarisation (coming soon)
Coming soon. Configurable AI summarisation is planned for end-user journeys. A service builder will choose the source information and summary instructions, with intended uses including pre-populated content and derived or calculated fields.
This page explains the intended approach. The examples illustrate configuration choices; they are not current Builder settings or an API contract. Final controls and supported destinations will be documented at release.
Specify what the summary should do
A useful summary has a defined purpose and audience. A short description for a respondent's review may need different detail from a handover note for a caseworker.
The planned configuration centres on selecting source values and giving instructions for the output. Parameters could express the desired length, format, tone and facts to include. State what must be preserved, such as dates, locations, requested outcomes or unresolved questions.
Summarise the reported problem and its impact in no more than three short sentences. Include the location and when it started if supplied. Use plain language. Do not add facts, infer a cause or promise a resolution.
This is an example of summary instructions for a facilities report. Your service's instructions should match its own purpose and data.
Pre-population and calculated fields
| Intended use | Service-design approach |
|---|---|
| Pre-populated answer | Offer the summary as a starting value that the respondent can review and edit where the journey allows. |
| Derived or calculated field | Produce a summary from earlier information for later display, review or workflow. |
For example, a respondent might describe a problem and its impact on two pages. A later page could pre-populate a short summary for confirmation. Alternatively, a derived summary could be displayed beside the original answers in a review or handover view.
Distinguish a respondent's original answer from generated content. If a person edits a pre-populated summary, decide which value later steps should use and whether the confirmed summary should be preserved when they navigate back.
Choose when to generate or refresh
Plan the summary after its source information is available. Decide how changes to earlier answers should affect an existing summary, especially one already edited or confirmed by the respondent.
A clear design avoids silently overwriting a person's edits. It also defines what a later review page, notification or downstream system should receive. Runtime timing and refresh controls will be specified with the released feature.
Check accuracy and handle missing output
A summary can omit a qualification, change emphasis or misread an ambiguous answer. Preserve access to the source information and include a review step where the summary affects someone's submission or staff handling.
- Test short, long, conflicting and incomplete source answers.
- Check names, dates, numbers, negation and uncertainty against the originals.
- Confirm that length and formatting suit the destination field or view.
- Define a usable journey when the source is blank or summarisation is unsuccessful.
- Test the handling of updated sources and respondent edits.
Use normal calculations for exact arithmetic and fixed rules. A generated summary is a representation of the source content, and should be reviewed for the purpose it serves.
See AI classification for planned category assignment, Pre-population, validation and testing for today's pre-population workflow, and Calculated value components for current derived values.