The problem with distributed people data
In every mid-market company, headcount exists in at least 3 places: the ATS (recruiting pipeline), the HRIS (active employees), and payroll (compensation records). Each system was designed independently, each maintains its own copy of "headcount", and each is wrong in a different way.
The ATS counts candidates who have signed offers but not yet started. The HRIS counts active employees but lags terminations by 1–7 days. Payroll counts employees who received a paycheck last cycle, which includes some who have already given notice and excludes new hires not yet in payroll.
When the CFO asks "what is our headcount?", the answer depends on which system they query. This is not a minor inconvenience. It is a structural failure that causes budget errors, compliance gaps, and strategic decisions made on wrong numbers.
The cryptographic principle
HiFive AI enforces a single rule: there can be only one source of truth for any piece of data. Headcount, compensation, and employment status each have exactly one authoritative record. Every other system is a downstream consumer - never an independent authority.
We enforce this cryptographically. Every authoritative record is signed with a content hash. When a downstream system (a dashboard, a report, an API response) displays a number, it must include the hash of the underlying record. If the hash does not match, the system refuses to display the number.
This means: a dashboard cannot show "headcount: 142" unless there are exactly 142 signed employee records backing that number. If someone manually edits the dashboard, the hash fails and the number disappears. The system makes wrong numbers impossible to display.
Append-only event log
Underneath the authoritative records sits an append-only event log. Every state change - hire, termination, compensation adjustment, role change - is recorded as an immutable event with a timestamp, actor, and cryptographic signature. The current state of any record is the reduction of all events affecting it.
This gives us three properties. First, auditability: any number can be traced back to the exact events that produced it, with timestamps and actors. Second, replay: the system can be reconstructed at any past point in time by replaying events up to that timestamp. Third, non-repudiation: once an event is signed, the actor cannot deny having made the change.
Traditional HRIS systems use mutable state: a compensation field is updated in place, overwriting the previous value. The previous value is lost unless explicitly logged in a separate audit table. Append-only logs make this impossible - the previous value is always present, always signed, always retrievable.
Cross-module consistency guarantees
When a recruiter marks a candidate as "hired" in the talent module, three things happen atomically: (1) a new employee record is created in the HRIS with a signed hash, (2) a payroll setup event is enqueued for the next cycle, (3) the talent module's candidate record is updated to reference the new employee record's hash. All three operations succeed or all three fail - there is no intermediate state.
This atomicity is enforced through a two-phase commit protocol. The system first prepares all three writes, validates that all hashes will be consistent, then commits. If any step fails (e.g., payroll setup rejects the start date as a non-business day), the entire transaction rolls back. The recruiter sees an error; no partial state is left behind.
The result: headcount in Talent, headcount in HRIS, and headcount in Payroll are guaranteed to match. Always. Not "usually", not "after the nightly sync" - always, at every moment, with cryptographic proof.
Why this matters for compliance
Regulators increasingly demand proof of data integrity. GDPR Article 25 requires "data protection by design and by default" - meaning systems must be architected to prevent unauthorized changes, not just detect them after the fact. SOC 2 Type II requires evidence that data has not been tampered with. ISO 27001 requires integrity controls.
Cryptographic source of truth satisfies all three. Every record is signed. Every change is logged. Every number can be traced to its underlying events. Auditors can verify, in minutes, that the headcount reported to the board matches the headcount in payroll - because both are derived from the same signed records.
This is not a feature. It is a foundational property of the architecture. Competitors who bolt audit logs onto mutable-state HRIS systems cannot provide the same guarantee - they can only detect tampering after the fact, not prevent it.
- •Single source of truth: each data point has exactly one authoritative record
- •Cryptographic signing: every record carries a content hash; mismatches refuse to render
- •Append-only event log: every state change is immutable, signed, and replayable
- •Two-phase commit: cross-module writes are atomic - all succeed or all roll back
- •Regulatory compliance: satisfies GDPR Art. 25, SOC 2 Type II, and ISO 27001 integrity requirements