MO§ES™ vs Worklytics

Usage is not performance.

Native analytics measure usage. Skills systems measure predefined capability. Engineering systems measure engineering work. MO§ES™ measures the operator operating technology and builds upward from that object.

Worklytics and MO§ES™ both sit on top of AI system event data. They extract different things from it. Worklytics extracts adoption signals — who is using which AI tools, how often, how much spend, what ROI. MO§ES™ extracts performance signals — how effectively the operator uses the AI system, measured through canonical token telemetry and derived metrics.

The difference is fundamental. Knowing that 200 employees used an AI tool 5,000 times last month tells you about adoption. Knowing that one operator achieves 3x leverage while another achieves 0.5x leverage on the same workflow tells you about performance. Adoption analytics answer "is AI being used?" Operator evaluation answers "is AI being used well?"

Comparison at a glance.

Counting events is not measuring operators.

Worklytics processes event exhaust — the logs that AI platforms generate as employees use them. From those logs it derives adoption metrics: active users, session counts, tool distribution, spend per team, ROI estimates. These are valuable operational metrics for understanding whether AI investment is being utilized.

But adoption metrics are silent on performance. An operator who sends 500 prompts to an AI tool and gets poor results on every one has high adoption and low performance. An operator who sends 50 carefully constructed prompts and gets excellent results has low adoption and high performance. Worklytics sees the first operator as a power user. MO§ES™ sees the first operator as a low-leverage operator and the second as a high-leverage one.

This is the divergence problem: usage rank does not equal evaluation rank. In the demo dataset, 50 operators produced 1,668 observations across 5 AI providers. The highest-volume users were not necessarily the highest-performing operators. Some high-volume operators had low yield — most of their token budget went to input, not output. Some low-volume operators had high leverage — they reused and built context efficiently.

Adoption analytics cannot detect this. Operator evaluation can. The canonical metrics — Leverage, Yield, Token SNR, Log Leverage, Construction — are computed from the structure of token flow, not from event counts. They measure how the operator operates, not how much.

Each tool answers a different question.

These are complementary, not contradictory. An enterprise might use Worklytics to track adoption and spend, and MO§ES™ to measure and improve operator performance. The tools sit at different layers of the AI operations stack.

Event logs vs canonical signals.

Worklytics works from event exhaust — the logs that AI platforms emit when employees interact with them. These logs typically contain timestamps, user identifiers, tool identifiers, session metadata, and sometimes cost data. They are designed for operational analytics.

MO§ES™ works from canonical telemetry — INPUT, OUTPUT, CACHE READ, CACHE WRITE. These are token-level signals that describe the structure of the operator's interaction with the AI system. They are designed for performance measurement.

The difference in telemetry depth drives the difference in what can be measured. Event logs can tell you that an operator had 50 sessions with an AI tool. Canonical telemetry can tell you that across those 50 sessions, the operator achieved a Leverage of 2.1, a Yield of 0.34, and a Construction ratio of 0.8 — and that this places them in the 75th percentile of the cohort for leverage but the 40th percentile for yield.

In the demo dataset, the 5 canonical metrics were computed across 13 benchmark classes and 27 MCP tools, with 12 interventions tested against target metrics. That depth of analysis is not available from event exhaust alone.

When to choose which.

Go deeper.