Every people analytics model trains on data. The question that matters – and the one most implementations skip – is which layer.
Three layers
Geoffrey Moore named two of them in 2011, in a white paper for AIIM. The third followed naturally.
System of Record (SoR) is the memory layer. Employee records, compensation history, tenure, role changes, performance ratings, exit types, compliance data. Where SAP, Workday, and most HRIS platforms live. Structured, auditable, and covering everything that was formally recorded.
System of Engagement (SoE) is the interaction layer. Where people actually work day to day – communicating, learning, completing tasks, recognising colleagues. The data here is behavioural, high-frequency, and reflects what is happening now rather than what was recorded last quarter.
System of Intelligence (SoI) is the interpretation layer. Models that read patterns across the other two, make predictions, and – ideally – trigger actions.
Most people analytics today trains on SoR data. Almost exclusively.
SoR data is useful. That is not the argument.
Structured HRIS data has real predictive power. Research on attrition prediction confirms that tenure, compensation trajectory, years without a promotion, and manager quality are genuine signals. Pay compression relative to market predicts attrition. Survival analysis on tenure data works. These are not trivial.
The question is not whether SoR data is sufficient. It is whether it captures everything relevant – and whether what it misses matters for the specific predictions you want to make.
SoR data knows when someone was promoted. It does not know when they stopped learning voluntarily. It knows when someone left. It does not know that their peer recognition dropped to zero three months before. It records the outcome. It misses the trajectory.
What behavioural data actually looks like
GFoundry was designed from the start to generate SoE data as a side effect of normal platform activity. Because people use it voluntarily every day – not just when HR requires it – the data it produces is structurally different from HRIS exports.
Specifically: whether someone logs in on a given day when there is no mandatory task waiting for them. Learning behaviour at the module level – time per unit, retry rates on assessments, abandonment points – not a binary “completed course X.” Peer recognition patterns – who recognises whom, how often, in which direction across the team. Task-by-task onboarding completion rather than a single flag. Pulse survey response rates over time, independent of what people actually answer. Points velocity. Streak patterns. Voluntary participation in challenges.
None of this lives in payroll files or HRIS exports. It is generated only if the platform captures daily voluntary behaviour, and only if people actually engage voluntarily. Both conditions require deliberate product design. Neither is guaranteed.
The privacy question gets harder, not easier
Richer behavioural data raises the privacy stakes. Worth being explicit about how we approach it.
No personally identifiable information enters a training pipeline. No names, email addresses, employee IDs, or combinations that could allow re-identification. This is enforced at the data extraction stage, not as a policy statement added afterwards.
What does enter training: numbers, ranges, and aggregations. Not “37 years old” but “age range 35-40.” Not “company X” but “organisation with 500-1,000 employees in the technology sector.” Behavioural patterns as aggregated scores, never as individual event sequences traceable to a person.
Training data and inference data run on separate pipelines with no shared state. The model learns population-level patterns from anonymised historical data. When it responds to a query about a specific user, it applies learned patterns to new inputs – it does not retrieve anything it stored about that user.
We apply k-anonymity: any aggregation small enough to risk re-identification is discarded before entering training. For reference, Microsoft’s Viva Insights defaults to a minimum group size of 5 for similar privacy thresholds. Contributing organisational data to model improvement is an explicit opt-in decision, not a default.
The questions we have not answered yet
This is the honest part.
Does behavioural frequency data add real predictive lift on top of SoR data? For which outcomes? Under what conditions? We have hypotheses and early evidence in specific domains – particularly around engagement trajectories and learning effectiveness. We do not have a complete, validated answer.
How much does voluntary engagement data suffer from selection bias? The people who engage most with the platform generate the richest behavioural signal. The people we most want to model – those quietly disengaging – may generate the thinnest data. Gallup estimates that about 50% of the US workforce falls into this “quiet quitting” category. Modelling disengagement from engagement data is a real methodological problem.
Where does anonymisation introduce distortion? Generalising into ranges and cohorts preserves privacy but loses precision. At some point, the signal degrades enough to hurt model quality. We are mapping those thresholds, but we are not done.
Where this leaves us
The three-layer structure gives us a dataset that most pure SoR platforms do not have. Whether that richness translates into meaningfully better predictions – and for which specific outcomes – is what we are still learning.
We would rather say that honestly than claim we have solved it.