Store the evidence behind an AI recommendation

An AI recommendation is easier to review when its evidence is stored with it. Saving only the final sentence loses the source state and configuration that shaped the suggestion. A later document edit can otherwise make a past decision impossible to reconstruct.

For a synthetic internal recommendation, store the source snapshot IDs, prompt version and model configuration beside the generated content. Add a reviewer decision linked to the exact recommendation revision, with the reviewer and decision time.

A proposed record can distinguish these fields:

recommendation_id
recommendation_revision
source_snapshot_ids
prompt_version
model_configuration
created_at
reviewer_decision
reviewed_revision

These are application-design fields. They are not an existing database schema or a claim that any particular project stores them today.

Evidence and configuration identify a recommendation revision; approval belongs to that exact revision.

Preserve what the reviewer actually saw

A source URL alone can point to changed content later. Retain an authorized immutable snapshot or another reproducible revision reference under the application's retention policy. Record the extracted passages used in the request when full-document snapshots are unnecessary or prohibited.

Separate evidence from generated explanation. A model's statement that "the data supports this" is still generated text. The record should let a reviewer open the actual source values or passages and check the claimed relationship.

Database constraints can keep references consistent. Django's constraint documentation and PostgreSQL's constraints guide describe mechanisms such as uniqueness and referential integrity. Application logic must still check permissions and decide whether evidence is sufficient.

Exercise later changes

Create one recommendation from snapshot A, then update the live source to B. The old recommendation should continue to identify A, and a newly generated recommendation should identify B. A reviewer should not have to infer which version was used from timestamps alone.

Edit the recommendation after review and check that the old approval remains attached to the old revision. If the workflow requires renewed review, the edited revision must not inherit a completed decision silently.

Deletion and permission changes complicate auditability. Some source snapshots may need to be removed or made inaccessible. Preserve a restricted record of the resulting evidence limitation without exposing the deleted content. Do not call a recommendation fully reproducible after its supporting material is intentionally unavailable.

This design improves traceability, but it cannot prove the recommendation is correct or causally explain every model behavior. The review still needs to examine whether the evidence supports the suggestion and whether important contradictory information was missing from the original request.