Label engineering defines which categories security data and model training use so analysts and detectors share one meaning.
A label such as abuse, legitimate, or unknown is a decision with a written rule, not a casual tag that each team invents differently.
How it works
When two analysts mark the same login storm with different names, reports drift and a model learns a blurry target.
Engineering the label means writing the boundary, showing examples that belong inside it, and showing near misses that stay outside.
The practice covers both human review queues and the training sets that later automate a similar judgment.
It is not the live fraud score itself, and it is not a substitute for governance of who may accept residual loss.
Concrete examples
- A fraud team defines account takeover as a confirmed unauthorized session and refuses to use that label for a mere failed password.
- A mail team separates unsolicited spam from bulk mail the recipient once joined, and both labels stay stable for a year.
- A model is retrained only after reviewers sample the new label guide and agree on a set of disputed tickets.
Protective measures
- Write a short definition and two boundary examples for every label that drives a report or a model.
- Review a sample of labeled events each month and correct drift before you retrain.
- Keep an unknown bucket so staff are not forced to pick a confident label they cannot defend.
- Name an owner for the label guide and date each change so old metrics remain interpretable.