An AI agent proposes a change and a recruiter rejects it. Nothing needs to be sent or updated, but there is still a useful record to keep: what was proposed, why the person declined it and whether a revision is expected.
Use this template to document that ordinary review process. It connects the preparation to the person's decision without requiring a second copy of the candidate file. Start with one defined workflow and agree what a later reviewer needs to understand.
Record the proposal and the human decision separately
A proposed change is not an approved change. A person's approval is not evidence that a later operation completed. Give each event a clear description so the reader can tell which point the record documents.
For this worksheet, use these event categories:
| Event | What the entry should establish |
|---|---|
| Proposal prepared | Which task and version of the proposed output were available for review |
| Review decision | Who reviewed that version and approved, returned or rejected it, with the reason |
| Revised proposal | What changed and which earlier proposal it replaces for review |
| Review closed without action | Why the proposed work will not proceed, or what remains unresolved |
| Action result, if applicable | What was attempted and what the available evidence confirms happened |
These are suggested categories for your team's record, not names of guaranteed product events. Keep them specific to the work. A rejected draft message needs different context from a proposed change to an existing candidate record.
If an external result is uncertain or an action appears to have happened twice, use the separate duplicate-action investigation record. This log provides the preceding proposal and review history; it does not replace an investigation.
Copy the event log template
Keep one row per event, connected to the same task by a shared reference. The reference helps an authorised reviewer follow the sequence without putting a candidate's name in every row.
| Field | What to enter |
|---|---|
| Event reference | A distinct reference for this entry |
| Task reference | The reference linking related proposals, reviews and results |
| Time | Event time and time zone; distinguish a later entry time if you are recording retrospectively |
| Workflow | The defined preparation task and relevant system or workflow version |
| Actor | The system or authorised person responsible for the event |
| Proposal version | The exact output or proposed change the person reviewed |
| Evidence reference | A permitted source reference sufficient to understand or check the proposal |
| Decision and reason | Approved, returned, rejected or unresolved, with the reason and reviewer's scope |
| Next step | Named owner and agreed action, or an explicit close without action |
| Result reference | Evidence of a completed action, where one follows; otherwise say not applicable or unconfirmed |
Put access and retention arrangements in the header so they apply to the whole log: who may read it, who maintains it, where the referenced material is held and who decides what is retained. Add the date and reason when that arrangement changes.
The ASD's event-logging guidance recommends consistent log structures and timestamps. Its subject is cybersecurity event logging. Borrow that discipline for a readable review record, while keeping the underlying security logs and their technical controls separate.
Work through a proposal that ends in rejection
Here is a hypothetical sequence for an AI-prepared change to an existing professional summary. A recruiter checks the proposed wording against its source and decides the revision still goes beyond the evidence. No record change is authorised.
| Event | Version and evidence | Human decision or next step |
|---|---|---|
| Proposal prepared | Original proposal and permitted source reference | Await the assigned recruiter's review |
| Review decision | Recruiter checks that version against the source | Returned: wording implies ownership the source does not establish; request narrower wording |
| Revised proposal | New version linked to the original, with the change identified | Await a fresh decision on this version |
| Review decision | Recruiter checks the revised wording | Rejected: the proposed summary still does not preserve the source's qualification |
| Review closed without action | Links to the rejected version and its review | No update authorised; recruiter retains the existing summary and records any separate follow-up needed |
The reason is more useful than a generic “quality issue”. It identifies the departure from the source and explains why this particular change should not proceed. Keep the explanation factual; the entry should not become an unsupported assessment of the candidate.
Do not rewrite the first proposal so it looks like the corrected one. Link the versions and preserve the evidence needed to understand the decision under the team's access and retention rules. If an earlier entry itself was wrong, add a correction that identifies the original entry and explains the repair.
Notice what the example does not record as complete: no field update, message or provider delivery follows the rejection. The end of this review is a decision to leave the record alone. That is a legitimate outcome for the template, not a failed attempt that needs retrying.
Keep enough evidence without copying the whole record
Decide what the reviewer needs to establish the event. A source reference and a short, appropriately restricted explanation may be enough. Avoid copying the entire CV, interview transcript, prompt or private note merely because the log has an evidence column.
For entities covered by the Australian Privacy Principles, APP 3 guidance addresses necessary collection and data minimisation. The OAIC's commercial AI guidance also addresses personal information in AI inputs and outputs. A review log containing those details needs its own handling decisions.
Use the language of the source carefully. “The source says supported” and “the draft says led” describes the wording difference. “The candidate exaggerated their role” adds a conclusion that this comparison alone does not establish. APP 10 guidance addresses personal-information quality, including the distinction between an opinion and an objective fact.
Retention needs an owner rather than a permanent default. The OAIC's APP 11 guidance covers reasonable security measures and destruction or de-identification when personal information is no longer needed for a permitted purpose, subject to its exceptions. Agree the applicable retention requirements and review them when the workflow changes. This worksheet does not prescribe a universal period.
Check that another person can follow the record
Give an authorised colleague the proposal, source reference and event log for the hypothetical sequence. Ask them to explain which version the recruiter checked, why it was rejected and what was authorised to happen afterwards. If they need your memory to finish the account, identify the missing reference or explanation and repair the record.
Then check the access boundary. A useful reference should resolve for the person entitled to review it, without making restricted material available to everyone who can see the log. Fix gaps in the record or access arrangements before using the sheet routinely.
Repeat that small review when the workflow or available evidence changes. A new tool, different output format or revised approval step may leave the old fields unable to explain what happened. Update the template deliberately and keep its version with the record.
Compare the worksheet with the controls in FluxHire
In FluxHire's Global AI Centre, AI-prepared changes to existing records wait for a person to approve, edit or reject them. Unanswered proposals expire after ten minutes, and AI-planned actions go to a tamper-evident audit log. During early access, record edits are made by people with the records editor permission. They still need to check the proposed change and its source before deciding what should be written.
Use this sheet to make that review discussion concrete. Ask which proposal, decision and action details are available for your supported workflow, who can inspect them and how a rejected or expired proposal is represented. Do not assume every event category in this template is a field in the product's log. A separate spreadsheet also does not acquire tamper-evident protection by being called an audit log.
Read how FluxHire handles security, then Request early access with the workflow you want to examine. Supported records, integrations and review steps are confirmed with each team. The useful test is whether an authorised person can explain the proposed work and the human decision, including a clear decision to take no action.