Sixty | second termination revoke

The hire ships in twelve days and nobody notices. The leaver leaves accounts active across fourteen systems, somebody compromises one of them six months later, and now the company has a board-level conversation about controls. The asymmetry is exactly why the termination workflow is the single most valuable surface the platform exposes. Sixty-second revoke is not a marketing number; it is the difference between an audit finding and an audit pass.

The terminate endpoint on hr_employees_routes.py creates the revocation queue rows inside the same database transaction that flips the employment record. A Celery beat worker picks rows up with FOR UPDATE SKIP LOCKED, which is the lock pattern that lets multiple workers drain the queue without stepping on each other. Each adapter implements get_user_risk_summary plus revoke. The risk summary scans recent activity for anomalies. If something looks off, the row routes to revocation_approvals and gates on a human. If it looks clean, the row revokes and writes one audit log entry. The dashboard subscribes to the SSE stream and renders progress in real time.

Termination is half the loop. Rehire is the other half. The same architecture runs in reverse on /employees/{id}/rehire: the new employment_records row writes, the reactivation queue rows fan out to the same fourteen adapters, and the dashboard streams progress on the same surface. This is the part the build-your-own-Slack-bot category cannot replicate without the system of record. An orchestrator that does not own the employee table cannot reactivate on rehire because it does not know who got rehired.

Fifteen rows. Fourteen adapters plus the trigger. Each row records the timestamp, the actor, the target system, the action, the result, and the risk summary that was attached to the call. The whole thing is hash-chained, so a tampered row breaks the chain and surfaces in verification. SOC 2 evidence packs lift these rows verbatim. The auditor reads them, signs them, and moves on.