Enrichment That Makes Scores Usable

Raw analytics output is uninterpretable. "Entity jsmith scored 84" tells an analyst nothing they can act on, and they will spend the next twenty minutes assembling context that the pipeline could have attached automatically.

Enrichment is that attachment. It is also where a deployment makes its most consequential privacy decisions, because every field added is personal data held in a security system and disclosable to the person it describes.

Enrichment that improves triage

Role and department. A developer moving code and a receptionist moving code are different events. This is the single most valuable enrichment and the cheapest.

Manager and organisational position. Needed for escalation and for peer group construction.

Location and working timezone. Turns "activity at 02:00 UTC" into "activity at 09:00 local", which is usually the end of the investigation.

Employment status. Employee, contractor, third party. Contractors sit outside most HR processes and their access lifecycle is different.

Account type. Human, service, administrative, break-glass. Determines which baseline applies and which explanations are plausible.

Asset attributes. For host entities: owner, criticality, environment, patch level, whether it is a domain controller or a laptop.

Data sensitivity of what was touched. Joining to the data inventory turns "accessed 200 records" into "accessed 200 records from the customer database".

Prior findings for this entity. Has this fired before, what was concluded, by whom. Without it, an alert dismissed three times by three analysts is a pattern nobody sees.

Whether an exclusion nearly applied. If the activity resembled an approved workflow but missed one condition, say so. It is frequently the explanation.

The high-value, high-sensitivity category

Employment events — notice period, recent role change, return from leave — are genuinely predictive. The departing employee is the most common insider scenario, and knowing someone resigned last week transforms the interpretation of identical behaviour.

They are also the fields most likely to bias an analyst and most likely to attract regulatory attention.

If you use them, three constraints:

Restrict who sees them. An analyst needs to know that an employment event occurred; they rarely need its detail.

Take the event, not the reason. "Notice period active" is defensible. "Under performance management" is prejudicial and will shape every subsequent judgement.

Document the lawful basis and the assessment before the feed is built, not after.

What should never be attached

Some fields will change an analyst's reading of identical behaviour in ways that cannot be defended:

Performance ratings. Salary. Grievance or disciplinary history. Union membership or activity. Health and absence data. Any protected characteristic, directly or by proxy.

The test is simple: if a field would change your interpretation of the same behaviour, and you could not justify that difference in writing to the person concerned, it does not belong on the screen.

Note that several of these arrive by accident. A generic HR feed frequently carries far more than was asked for, and a field present in the data will eventually appear in an interface.

Building it

Enrich at ingest, not at query time. Query-time joins are slow, and they resolve against today's data rather than the state at the time of the event — which means an investigation months later sees the person's current role, not the one they held.

Snapshot the context with the event. Role at the time, manager at the time. This matters in any process that has to reconstruct what was known.

Refresh the reference data on a schedule and monitor the join rate. A falling percentage of events successfully enriched is an early warning that something upstream changed.

Attach the entity's own baseline. "340 files, against a personal average of 12 and a peer average of 20" is the difference between an interpretable finding and a number.

Minimisation in practice

The instinct is to attach everything available. Resist it for three reasons.

Every field is personal data with retention, access and disclosure obligations. Every field is a potential bias vector. And an interface with thirty fields is one where the analyst reads none of them.

Attach what is necessary for the triage decision. For most alerts that is: role, employment status, location, account type, personal baseline, peer baseline, data sensitivity, prior findings. Eight fields, one screen.

Designing the alert screen

Enrichment succeeds or fails at the moment an analyst looks at it. The constraint is attention, not availability.

Eight fields, one screen, no scrolling. Role, employment status, location and local time, account type, personal baseline for the deviating feature, peer baseline for the same feature, sensitivity of what was touched, prior findings for this entity.

Lead with the behaviour, not the score. The first line should be a sentence a person can evaluate: what happened, against what normal.

Put the baseline next to the observation, not in a separate view. "340 files, personal median 12, peer median 20" carries more than three separate panels.

Make everything else one click away rather than on the screen. Depth should be available and not competing for the first ten seconds.

Show data confidence. Baseline age and source completeness for this entity, so the analyst knows how much weight the numbers carry.

An alert screen designed this way reduces triage time more than any model improvement.

Common false positives

Enrichment failures create their own noise:

Stale role data, producing comparison against a job the person left.

Missing enrichment for contractors and recent joiners, so the alert arrives without the context that would explain it.

Query-time joins showing current attributes rather than those in force at the time of the event.

Sensitivity labels applied inconsistently, so ordinary files appear as high-value assets.

Prior-findings lookups keyed to the wrong identifier, so an entity's history appears empty when it is not.

Blind spots and assumptions

That reference data is accurate. Directory and HR data contain a meaningful error rate. Sample twenty entities and verify before relying on it.

That enrichment is neutral. It shapes judgement by construction. The question is whether the shaping is defensible.

That the join is complete. Contractors, recent joiners and anyone in a system migration will be unenriched, and unenriched entities are frequently the ones that matter.

That analysts read past the first field. They read the first two. Order the display accordingly.