deep-dive
Aug 26, 2026Why statistical baselines, bounded evidence, and explainable detectors outperform fuzzy LLM classifiers when auditing enterprise AI coding workflows.
AI coding tools are moving from individual experiments into organization-wide infrastructure.
That creates a new operational problem.
An organization may know how many tokens it consumed, but not whether a sudden increase came from legitimate project work, a new integration, a looping agent, repeated failed tests, or a change in reporting coverage.
A single global threshold cannot answer that question.
It will repeatedly flag legitimate heavy users, miss abnormal behavior from lighter users, and turn normal technical novelty into unnecessary alarm.
ReclaimLLM uses deterministic anomaly detection for Enterprise observability to address this differently: compare activity with the relevant historical baseline, apply explicit eligibility rules, and preserve bounded evidence so an administrator can reproduce why a finding fired.
This is not machine-learning classification. It is not employee scoring. It is not automatic enforcement.
It is an investigation system.
Anomaly detection is only as reliable as the evidence beneath it.
A provider invoice can show that usage increased. It cannot reliably explain which completed sessions caused the change, whether tool failures repeated, whether a technology combination was genuinely new, or whether the underlying data was complete enough to support a conclusion.
Workflow observability provides the missing layers:
Without those layers, anomaly detection becomes guesswork attached to a graph. With them, an organization can move through a defensible operating loop:
Observe → detect → inspect evidence → decide → track resolution.
The detection engine is deliberately explainable.
Each detector has a stable version, stated thresholds, bounded inputs, eligibility requirements, and reproducible evidence. The system records evaluations that fire as well as evaluations that do not fire or lack sufficient data.
That design prevents three dangerous shortcuts:
When the data cannot support a conclusion, the correct result is insufficient_data—not a clean bill of health and not a finding.
The system evaluates daily session data across core detector families:
This detector identifies an unusually high completed day of session or token activity relative to that member's own recent active days.
It uses the previous 14 completed UTC days, requires at least seven active baseline days, and applies a guarded exponentially weighted baseline. A finding requires multiple conditions to align:
The important principle is simple: compare a person with their own history, not with the organization's heaviest or lightest user.
This detector identifies a materially new combination of technology or activity for a member.
It considers project-relative file extensions, manifest names, conservatively parsed dependencies or imports, command families, tools, models, providers, agent clients, and project roots.
One new extension or dependency is not enough to fire by itself. The detector requires a meaningful combination, such as a first-seen manifest ecosystem plus a related first-seen dependency, or a new project combined with a new command family. Even then, the finding means “first seen,” not “unauthorized.”
This detector looks for completed sessions that appear operationally stuck or disproportionately expensive.
Its deterministic sub-signals include:
Severity is rule-based: one crossed threshold produces a warning; two independent sub-signals or a sustained failed build/test loop escalates to high severity.
Repeated detections should not create an endless pile of duplicate alerts.
The lifecycle keeps one ongoing finding for the same detector, subject, and anomaly target. A repeated occurrence updates its last-seen time and count while preserving administrator acknowledgement or dismissal.
Administrators can:
Eligible quiet periods can resolve recurring findings according to detector policy. Missing data or detector errors cannot silently resolve an open issue.
An anomaly system should not create a second sensitive-data problem.
The background evaluation job operates on compact relational data and does not fetch or decrypt raw session blobs. Evidence is allowlisted and bounded: identifiers, normalized relative paths, hashes, counts, categories, statistics, and thresholds.
It excludes raw prompts, responses, tool inputs and results, file contents, secrets, complete commands, and personal absolute paths.
Anomaly detection in AI-assisted engineering should answer four questions:
If a system cannot answer those questions, an anomaly score creates more confusion than operational value. Observability should help an organization investigate its systems—not judge its people.