Record an audit event for each consequential step

Keep the chat transcript as source material. Build the audit history from structured events attached to the assessment run, so reviewers do not have to infer consequential steps from conversational text.

Record the creation of the run, methodology version selection, question presentation where required, answer submission, proposed mapping, respondent confirmation, reviewer amendment, calculation, report generation and finalisation. Each event should have a stable identifier, timestamp, actor, run identifier, event type and payload appropriate to that event.

Use append-only events for the history and current-state records for efficient application behaviour. A correction creates a new event and updates the current answer view. It should not erase the earlier answer. Protect event integrity using database permissions, controlled write paths and backups. Cryptographic chaining may be justified in some settings, but ordinary access control and disciplined event design should be implemented first.

An audit export should allow a reviewer to reconstruct a result without access to hidden application state. Include the methodology definition or immutable reference, confirmed input values, amendments, calculation output, reason codes and report version. Exclude secrets, model credentials and unrelated conversation content.

Design correlation identifiers early. The run identifier should connect the interview, evidence records, calculations, reports and operational logs. If a user reports an unexpected score, support should be able to locate the relevant records without searching by personal data or manually comparing timestamps.

Audit access itself may need recording. Assessment material can reveal organisational weaknesses or personal information. Apply role-based access, scoped exports and retention rules. Test that a reviewer sees only the runs they are authorised to inspect.