Separate current state from event history
Course overview · 4 min reading + 12 min practice, estimated
Principles and method
Current state answers where the work is now; events explain how it got there. Record meaningful transitions with time, actor and reason where appropriate. Reopening an application should not erase the earlier withdrawal or decision history. Event definitions support analytics and audits, but avoid collecting unnecessary detailed behaviour. Decide which system owns each field and how conflicts are resolved. Two systems writing the same status without a rule can create loops or overwrite newer information. Integrations need stable identifiers and clear direction of authority.
Worked example
The ATS owns application stage while the communications system owns delivery events. A bounced email can create a review task but cannot automatically overwrite the candidate’s assessment decision.
Put it into practice
Map ownership and event flow between a fictional ATS, CRM and email tool.
Use fictional information and keep your work in your own notes.
Compare your approach: self-review guidance
Specify which updates are authoritative and which are signals for review. Include a conflict example and preserve the distinction between contact delivery and hiring status.
Sources and further reading
Original Academy teaching and fictional examples. These references provide context, not endorsement. Edition 2026.09; updated 2026-09-24.
- GOV.UK: Responsible AI in recruitment
UK guidance on procuring and deploying recruitment AI.
- NIST: AI Risk Management Framework
Voluntary framework for organising AI risks and controls.