How AI drafts work
How FRA Flow uses AI to write specific report paragraphs, what the audit trail captures, and what the guards block before sign-off.
FRA Flow uses AI to write a small, specific set of paragraphs in the report. Everything else (action plan tables, risk rating tables, signature blocks, photo appendix) is structured rendering from the data you captured. This page explains what the AI is trusted to do, what stays under human control, and how the audit trail keeps the report defensible.
The five AI-written paragraphs
The AI writes one paragraph at a time, never the whole report in one go. That keeps each paragraph tied to a specific set of observations and prevents the model from blending findings across sections.
| Paragraph | Approximate length | What it summarises |
|---|---|---|
| Executive summary | 100 to 150 words | Property profile, observation counts by risk, top high-risk findings |
| Limitations | 30 to 80 words | Property limitations, areas not accessed, in-visit notes |
| Section observation | 60 to 180 words | Observations attached to one BS 9792 section |
| Section comment | 40 to 120 words | Reviewer-style comment on one BS 9792 section |
| Action plan introduction | 40 to 60 words | Counts of recommended actions by priority |
Tables, action lists, signature blocks, and photo evidence are generated from the structured data, not the AI. If the AI is asked to summarise a number, the number must come from a captured observation or a property field. The no-fabricated-numbers guard enforces this on every draft.
How a draft is produced
When the assessor or reviewer presses Generate draft, FRA Flow writes every paragraph in parallel. Each paragraph is produced from a fixed set of inputs:
- The property record (address, building type, storey count, unit count, known limitations).
- The observations attached to the relevant BS 9792 section.
- The recommended actions tied to those observations.
- A house-style brief so the prose matches the practice's voice.
The AI is told exactly which observations it can cite. It returns the paragraph plus the list of observations it referenced. Both lists are stored on the paragraph so reviewers (and, years later, auditors) can compare what the AI was given against what it claimed to use.
A whole-report draft typically lands in seconds because the paragraphs run in parallel rather than one after another.
The audit trail
Every paragraph in every report carries the metadata needed to reconstruct it:
- The paragraph itself (the words the model produced).
- Declared inputs: the observations the paragraph was supposed to be drawn from.
- Cited evidence: the observations the AI claimed to use.
- Model fingerprint: which AI wrote the paragraph (the model identifier, plus a fingerprint of the prompt template at generation time).
- Generated at: when the paragraph was produced.
The metadata is embedded in the final PDF and stored against the report so a challenge years later can be answered: "On the date of this report, this exact set of observations was sent to this AI, and these are the observations the AI said it used."
That is the source-linking the rest of the FRA tooling industry promises and rarely actually delivers. The audit trail goes deeper.
The three modes per paragraph
Each AI-written paragraph carries a mode that says who wrote it:
- AI draft. The default after generation. The paragraph can be regenerated. The Show source panel works.
- AI draft, edited. The reviewer or assessor edited the AI text. The Show source panel still works because the observation list stays attached. Regeneration is hidden so a stray tap does not overwrite the edit.
- Human authored. The paragraph was written from scratch. The observation list still attaches so source-linking continues to work. Regeneration is hidden until the paragraph is reset to AI mode.
The reviewer can flip mode per paragraph. Tenant-level defaults override per-slot. So if your practice always wants the executive summary written by hand, you can set that once and forget it.
The hallucination guards
The Show source panel automatically flags two divergences between what the AI was given and what it cited:
- Yellow. A declared input was not cited by the AI. The reviewer is prompted to confirm coverage is correct. This is a reminder, not a block.
- Red. The AI cited an observation that was never sent to it. This is the hallucination guard. Sign-off is blocked until the reviewer acknowledges the warning.
Two more guards run before sign-off:
- High-risk-in-narrative. Every observation marked high-risk must appear in at least one paragraph's cited evidence, otherwise the report misrepresents the site picture even when individual paragraphs read fine.
- No fabricated numbers. The AI is told to draw quantified detail (gap sizes, distances, counts) from the structured input. The guard scans the paragraphs for number-and-unit patterns ("8 mm gap", "three storeys") and flags any that do not match any input observation or property field.
Hallucination guards walks through what triggers each warning and how to clear it.
Why this design
The fully-generative approach (one big prompt, the AI writes the whole report) was rejected up-front. The model freelances, source-linking becomes post-hoc magic, and a single bad citation poisons the whole document. The pure template-fill approach (no AI at all) was rejected because the prose reads robotic and reviewers spend their day rewriting boilerplate.
The middle path (AI per paragraph, with the input set fixed before generation and the cited-evidence list checked afterwards) is the only one of the three where source-linking is a property of the system, not a feature bolted on later.
Where to go next
- The audit trail covers what is embedded in the PDF and how to retrieve a paragraph's history.
- Hallucination guards walks through what triggers each warning and how to clear it.
- Source linking shows the Show source panel from the reviewer's side.