Canonical token telemetry.
Canonical token telemetry defines four content-free signals that power every metric in the MO§ES™ evaluation framework. No prompt text is required. The system works from token counts and structural signals — not conversation content, not prompt inspection, not surveillance.
The four signals.
The core data surface is four signals. Each is a token count — a number, not text. Together they describe the full token economy of an AI operator session without revealing what was said.
These four signals are the foundation of all five canonical derived metrics. Leverage, Yield, Token SNR, Log Leverage, and Construction are all computed from combinations of these four values. No additional data is required for any core measurement.
Why no prompt text is needed.
The system is designed to evaluate operator behavior without inspecting conversation content. This is not a claim of absolute privacy — it is a design principle that minimizes data collection and reduces surveillance surface.
- Token counts (INPUT, OUTPUT, CACHE READ, CACHE WRITE)
- Session timestamps and durations
- Model, tool, and agent identifiers
- Provider fields (where available)
- Acceptance signals, retries, errors
- Prompt text or conversation content
- Output text or generated content
- Personal communications
- Source code or proprietary content
- Anything beyond token counts and structural signals
Level 2 deployments can add enriched signals — timestamps, sessions, model identifiers, acceptance signals — but the core metrics require only the four canonical token counts. This means the system can operate in environments where prompt content cannot be shared for legal, security, or privacy reasons.
Five AI providers, one telemetry model.
The canonical telemetry model is designed to work across AI providers. In the synthetic demo cohort, telemetry is collected from 5 AI providers, each with different API surfaces and reporting capabilities.
OpenAI API. Provides usage token counts and cache metrics where available.
Anthropic API. Provides input/output token counts and prompt cache read/write signals.
OpenAI coding agent. Provides structured token telemetry for code workflows.
GitHub Copilot. Provides completion and suggestion token counts.
Cursor IDE. Provides session-level token telemetry across model calls.
16 read + 5 write MCP tools provide additional structural signals for context construction and retrieval.
The canonical telemetry model normalizes across these providers. Where a provider does not expose a specific signal, the system marks it as unavailable rather than estimating. This ensures that metrics are computed from observed data, not imputed values.
What telemetry does not tell you.
Canonical telemetry is labeled MEASURED and OBSERVED — the strongest evidence labels in the framework. But the metrics derived from it carry their own labels and caveats.
- Telemetry is measured; metrics are derived. The four signals are directly observed. The five canonical metrics computed from them are DERIVED — structural signals whose relationship to performance is still being tested.
- Content-free is not absolute privacy. The system does not collect prompt text by default, but Level 2 deployments may add enriched signals. Enterprises define their own data collection policies.
- Provider gaps are real. Not every provider exposes every signal. Missing signals are marked unavailable, not estimated. This can affect metric accuracy for operators on providers with limited telemetry.
- Not an employee surveillance tool. Cohort-level reporting is the default. Individual identity requires separate authorization. No adverse employment actions are permitted in pilot.
- Validation required for derived claims. Telemetry itself is observed. Any claim about what telemetry means for performance, productivity, or business outcomes requires separate validation.
Every telemetry record carries provenance: provider, session identifier, timestamp, signal availability flags, evidence label (MEASURED or OBSERVED), and synthetic-data flag where applicable.
Read alongside.
(R + W) / I — computed from canonical telemetry.
O / (I + O + R + W) — computed from canonical telemetry.
Privacy boundaries, data minimization, and decision-use labels.