Methodology

The eval framework.

AI operator evaluation methodology — how to measure how people operate AI systems using content-free token telemetry. Five canonical metrics (Leverage, Yield, Token SNR, Log Leverage, Construction), percentile-band benchmarking, and governance-guardrailed composite scoring. Five questions: what is an operator eval, what is measured, how benchmarks are created, how bespoke evals are constructed, and how results are interpreted.

Review the Eval Framework See the Research
Question 1

What is an operator eval?

An Operator Evaluation measures how a person or team actually operates AI systems across relevant tasks, workflows, models, and operating conditions. It is not simply a test of AI knowledge. It examines observable operating behavior and performance.

What it is

A structured measurement of operator behavior against defined conditions. Produces a performance profile — not a knowledge score, not a certification, not a self-reported proficiency rating.

What it is not

  • Not an AI knowledge test
  • Not a certification exam
  • Not a self-reported proficiency survey
  • Not a productivity score
  • Not an employee ranking system

Two types

Standard Operator Evals

Common metrics usable across organizations — leverage, yield, construction, field position. Work for any deployment without customization.

Bespoke Enterprise Evals

Company-specific evals built around your workflows, roles, models, tasks, and operating conditions.

Question 2

What is measured?

MO§ES™ works from content-free or content-minimized telemetry — token counts and structural signals, not prompt text. The core data surface is four signals:

INPUT
Tokens in
OUTPUT
Tokens out
CACHE READ
Reused context
CACHE WRITE
New context built

Level 2 deployments add: timestamps, sessions, model/tool/agent identifiers, acceptance signals, retries, errors, and richer provider fields where available. No prompt content is required for any core measurement.

Five canonical derived metrics

MetricFormulaWhat it captures
Leverage(R + W) / IHow much context the operator reuses and builds relative to new input. Higher = more efficient context use.
YieldO / (I + O + R + W)Productive output share of total token flow. Higher = more of the token budget becomes output.
Token SNRO / (I + O + R)Output relative to input and reused context. Signal-to-noise ratio for productive generation.
Log Leveragelog(1 + L)Compressed leverage scale. Reduces outlier dominance while preserving rank order.
ConstructionW / RRatio of new context built to context reused. Higher = more original construction; lower = more reuse.

I = Input, O = Output, R = Cache Read, W = Cache Write. All metrics are computed from canonical telemetry. No prompt content is required.

Question 3

How are benchmarks created?

A performative benchmark compares how operators actually perform under observed or defined operating conditions — rather than relying only on self-reported proficiency, certification, or generic knowledge tests.

TASK × MODEL × OPERATOR × CONTEXT = PERFORMATIVE BENCHMARK

Six benchmark types

Standard

Common metrics usable across organizations.

Internal

Compare operators and teams within the organization.

External

Compare against relevant reference populations (SigRank field).

Bespoke

Built around organization-specific workflows, roles, and tasks.

Longitudinal

Compare performance over time.

Intervention

Compare pre- and post-intervention performance.

Percentile bands

Median
50th
Top 25%
75th
Top 10%
90th
Top 5%
95th
Top 1%
99th
Top 0.1%
99.9th

Benchmarks should be contextual. A high-performing operator in one workflow may not be the strongest in another. "Best operator" should require the same qualifier as "best model." Best at what?

Question 4

How are bespoke evals constructed?

MO§ES™ does not force every company into the same AI proficiency model. Enterprises define the workflows, roles, models, behaviors, risks, and operational questions that matter to them. MO§ES™ turns those into measurable, repeatable evals.

DEFINE QUESTION IDENTIFY SIGNALS BUILD EVAL VALIDATE DEPLOY

Enterprises define:

  • Roles
  • Workflows
  • Tasks
  • Models
  • Systems
  • Desired behaviors
  • Constraints
  • Operational goals
  • Risk boundaries
  • Performance questions

Then construct repeatable operator evals around those conditions. Configurations are saveable as JSON and shareable across CLI, TUI, and MCP.

Question 5

How are results interpreted?

The system never collapses measurement, diagnosis, intervention, and validation into a single claim. Every output carries an evidence label that declares its epistemic status.

MEASURED SIGNAL ≠ DERIVED METRIC ≠ BENCHMARK ≠ HYPOTHESIS ≠ VALIDATED OUTCOME
Measured Signal

Direct observation from telemetry. Labeled MEASURED or OBSERVED.

Derived Metric

Computed from telemetry via declared formula. Labeled DERIVED. Not independently validated as a performance measure unless separately tested.

Benchmark

Comparative position against a reference. Percentile bands, field position, team comparison.

Hypothesis

Diagnosis from pattern analysis. Labeled HYPOTHESIS. Carries evidence, alternatives, and governance status. Never presented as fact.

Validated Outcome

Result of intervention testing with declared target metric and follow-up window. Outcome joins labeled ASSOCIATION — never CAUSATION.

Governance

DEVELOPMENTAL gates route workflows, not people. ASSOCIATION never CAUSATION. HYPOTHESIS never fact.

PROVEN MEASURED OBSERVED DERIVED HYPOTHESIS PILOT VALIDATION REQUIRED DEVELOPMENTAL ASSOCIATION
Cohort Analysis

Operators are analyzed as a population.

Individual operators are measured in the context of the cohort, not in isolation. The cohort has distribution, shape, clusters, and movement.

Distribution

How metrics spread across the cohort. Shape, skew, gaps, outliers.

Clusters

Natural groupings of operators by operating behavior. Archetypes.

Bands

Stable performance tiers. Whether operators stay in their band or move.

Divergence

Where usage rank ≠ evaluation rank. High usage / low performance and vice versa.

Concentration

Whether advanced capability is organizational or isolated in a few people.

Movement

How operators change position over time. Acceleration, stall, reversion.

Intervention Testing

Baseline. Intervene. Re-evaluate. Learn.

Every intervention declares a target metric and follow-up window. Every verification shows target and non-target deltas. Outcome joins are labeled ASSOCIATION — never CAUSATION.

BASELINE INTERVENE RE-EVALUATE COMPARE RETAIN OR DISCARD

A correlation between an intervention and a business metric is not proof that the intervention caused the business change. Internal metric deltas and external outcome deltas are kept in separate fields. Join results carry ASSOCIATION labels and governance metadata.

Outlier Handling

Extreme performers are not noise.

In operator fields, performance forms a broad distribution with clear high-performing tails. Outliers are not discarded — they are analyzed. The top 1% and top 0.1% may reveal operating patterns that the rest of the cohort has not yet developed.

However, not every metric creates the same ranking. Top operators can differ by task, workflow, model, operating style, efficiency, leverage, and output behavior. The highest-volume AI users are not necessarily the highest-performing operators.

Provenance

Every measurement carries its history.

  • Source telemetry window and operator identifiers
  • Evidence label (PROVEN, MEASURED, OBSERVED, DERIVED, HYPOTHESIS)
  • Decision-use label (DEVELOPMENTAL, ASSOCIATION)
  • Synthetic-data flag (pilot runs on synthetic data by default)
  • Validation status (VALIDATION REQUIRED for unvalidated claims)
  • Intervention target and follow-up window (for intervention records)
Privacy Boundaries

Evaluate operation without surveillance.

The system can work from telemetry and structural signals rather than requiring full prompt-content inspection. This is not a claim of absolute privacy — it is a design principle.

DATA MINIMIZATION
  • Content-free or content-minimized telemetry where possible
  • Token counts, not prompt text
  • Structural signals, not conversation content
  • Cohort-level reporting by default
  • Individual identity requires separate authorization
GOVERNANCE CONTROLS
  • Configurable retention
  • Enterprise-defined usage policies
  • No adverse employment action in pilot
  • Provenance on every measurement
  • Decision-use labels enforced in code
Limitations

What the system cannot do.

  • MO§ES™ cannot directly prove business productivity, ROI, employee quality, or causal outcomes unless those are specifically being measured and validated through experimental design.
  • Outcome joins are labeled ASSOCIATION — never CAUSATION. A correlation between an intervention and a business metric is not proof that the intervention caused the business change.
  • Diagnoses are hypotheses. They carry evidence, alternatives, and HYPOTHESIS status. They are never presented as established fact.
  • Not all derived metrics are independently validated performance measures. Some are structural signals whose relationship to actual performance is still being tested.
  • The system does not measure prompt content by default. Some bespoke evals may require enriched data (Level 2), but content-free telemetry is the default.
  • Reference population comparison provides structural context, not a universal ranking of "better" or "worse" operators.
  • Longitudinal measurement requires multiple windows. Single-window measurements are snapshots, not trajectories.
Concept Reference

Canonical concepts, defined.

Each concept has a dedicated definition page with the formula, interpretation, how MO§ES™ uses it, and governance caveats.

(R + W) / I — context reuse and building relative to new input.

O / (I + O + R + W) — productive output share of total token flow.

O / (I + O + R) — signal-to-noise ratio in operator token flow.

W / R — ratio of new context built to context reused.

AI Operator Development Index — 0–100, weighted, DEVELOPMENTAL.

Usage-operation divergence — when usage volume doesn't match performance.

13 benchmark classes with a selection algorithm.

Targeted changes with pre/post re-measurement. ASSOCIATION, never CAUSATION.

INPUT, OUTPUT, CACHE READ, CACHE WRITE — content-free, no prompt text.

DEVELOPMENTAL / HYPOTHESIS / ASSOCIATION labels, no punitive use.

Read the FAQ How to Evaluate AI Operators How to Measure Performance
Falsifiability

The system is designed to be wrong.

If an intervention does not produce a measurable change in the target metric, the system says so. If a diagnosis cannot be distinguished from an alternative, the system says so. If an outcome join cannot be validated, the system says so.

This is a formal research framework, not established science. It carries papers, experiments, datasets, patents, and falsifiability work. It is presented with appropriate epistemic humility.

Read the Research