SigRank console
What SigRank is, how it works, and what the leaderboard measures. Start here if you are new.
What it is
Ranks the operator, not the model - four integers in, full ledger out.
SigRank is the operator leaderboard for AI. It ranks the operator, not the model — by the architecture of their token cascade. Four raw integers in, the full ledger out, ranked live.
Volume alone is noise. Yield is signal. The same four token counts reveal whether you compound signal or burn it - and whether you're a Burner, a Builder, or a 10xer.
What the board shows
The leaderboard ranks every operator by Υ Yield — the headline cascade metric — across four scoring windows: 7-day, 30-day, 90-day, and all-time. Each row shows the operator's class tier (ARCH+ down to IGNITER), their four raw token pillars, the full cascade (Υ Yield, SNR, Leverage, Velocity, 10xDEV), cost per million tokens, and their efficiency vs the Artificial Analysis 7:2:1 baseline.
Every number is derived from four raw integers: input, output, cache-read, cache-write. No word counts, no message content, no self-reported fields. The server recomputes everything from the raw payload. Derived metrics cannot be altered independently of the four pillars. The telescoping identity detects inconsistent calculations. Fabricated pillars are handled separately through signed telemetry, provenance, plausibility checks, and review.
What the signature is — and isn't. SigRank measures the token-cascade signature honestly: a real coordinate of how an operator works the tools — leverage, efficiency, the shape of their cascade. It is not a verdict on the quality of the work itself, and it doesn't claim to be. Read it as one signal, set beside the operator's actual work — together they say more than either does alone.
The three archetypes
These are not fixed labels - they are cascade shapes. An operator can be a Burner on Monday and a 10xer by Friday if their architecture shifts. Archetype describes shape. Class describes qualification. Rank describes position. All three are recomputed every scoring window.
Branding note: Burner, Builder, and 10xer are informal marketing labels, not the canonical archetype system. The actual system classifies operators into 10 build archetypes (CONVERGENT, KINETIC, BUILDER, RECURSIVE, AMPLIFIER, INPUT-BOUND, PRIMING, CONTEXTUAL, DEEP READER, ARCHIVIST). Rough mapping: Burner ~ INPUT-BOUND/PRIMING, Builder ~ BUILDER/RECURSIVE, 10xer ~ AMPLIFIER/CONVERGENT.
The product hierarchy
Six layers: Pillars, Operating Ratio, Archetype, Class, Rank, Drift. Each answers a different question.
The product hierarchy
Six layers, each answering a different question. They are independent: knowing one does not determine the others.
| Layer | Question answered | Persistence |
|---|---|---|
| Pillars | What raw activity occurred? | Raw record (signed) |
| Operating Ratio | What is the current composition? | Window-specific |
| Archetype | What shape does the cascade resemble? | Dynamic (per window) |
| Class | Which qualification tier? | Recomputed by window |
| Rank | Where does the operator stand? | Dynamic (board) |
| Drift | How far from own signature? | Temporal |
Archetype describes shape. Class describes qualification. Rank describes position. None are permanent. All are recomputed per scoring window (7d / 30d / 90d / all-time).
Submit
run the agentHow to get your token counts and land on the board — from the zero-paste agent to paste fallbacks.
Run the agent (MCP / CLI)
The fastest, recommended path — npm i -g sigrank / npx sigrank. Zero paste, reads 19+ platforms. Board entry is managed from your profile.
Run the local agent (MCP / CLI)
The SigRank agent reads your local session logs across 19+ AI coding platforms (Claude Code, Codex, Gemini CLI, Copilot CLI, Amp, Goose, Kilo, and more) and counts the four token pillars per window — zero paste, token counts only, never your prompt content. One command:
# install once (recommended) npm install -g sigrank # …or run with no install npx sigrank
npx sigrank opens your dashboard — the cascade across every detected platform and window, the 5-source token comparison, and your board position. Submitting to the board is managed from your profile (sign in, then publish) — so your numbers land verified and stay yours. Full command + tool reference is in the local-agent page ↗.
Verified-passive measurement. The agent reads token counts. It does not read your prompts, your replies, your code, or your file contents. The four integers are all that leaves your machine. The server derives the cascade from those four - no content is transmitted, stored, or seen by anyone. This is not a privacy compromise we tolerate; it is the architecture the Conservation Law predicts. Full detail in the Proof section below.
How it works (3 steps)
01 agent reads tokens · 02 compute the cascade · 03 account + review → board (via your profile).
Why account + review?
The board is public and ranked. Without a gate, it would fill with observer-inflated entries — tooling that reports numbers the operator didn't actually produce, or synthetic data designed to game a single metric. The account ties a submission to a real identity; the review checks that the token counts are physically plausible and that the source logs haven't been edited.
The review is lightweight — it runs the plausibility gate (range checks, cross-field ratios, cadence bounds) and the source-attestation cross-check (log file hashes that detect tampering across submissions). Benford's Law runs as a backstop but is cosmetic at per-session scale (n=4); its real power is aggregate, across the whole board. If the numbers compose, the entry lands. If they don't, it gets flagged. The gate is mechanical, not editorial — we don't judge whether your work is good, just whether your numbers are real.
What you keep private
The agent reads token counts. It does not read your prompts, your replies, your code, or your file contents. The four integers (input, output, cache-read, cache-write) are all that leaves your machine. The server derives the cascade from those four — no content is transmitted, stored, or seen by anyone.
This is not a privacy compromise we tolerate — it is the architecture the Conservation Law predicts. EXP-007 established that conserved structure is detectable without reading content. Token counts are a legitimate statistical witness; we never need to see what you typed.
Other ways — paste ccusage
No agent? Paste ccusage --json for an instant PROJECTED cascade. Calculator only — not saved to the board.
Run numbers — paste ccusage output
No agent installed yet? You can still see your cascade in 30 seconds. Run ccusage --json in your terminal — it prints your four token pillars per session. Paste the output below and the calculator derives your full cascade: Υ Yield, SNR, Leverage, Velocity, 10xDEV, and your projected class tier.
Accepts full JSON, partial fragments, Codex exports, or four bare numbers (input, output, cache-read, cache-write). Calculator only — not saved to the board. When you're ready to land on the board, install the agent above.
Or just run it:
$ bunx sigrankreads your logs, scores your cascade, puts you on the boardOther ways — manual entry (advanced)
No token counts at all? A rough estimate from coarse activity proxies, reduced confidence. Approximation only.
▸ ▾ Estimate without token counts (advanced)
No token counts handy? This fallback estimates a rough cascade from coarse activity proxies (sessions, turns, account age) at reduced confidence. It is an approximation only — the board ranks on the four token pillars, so run the local agent (or paste ccusage --json above) for a real read.
Contact / help
mailto hello@signalaf.com + @burnmydays.
Paste not parsing, reader we don't support yet, or just want to talk? Reach us — we read everything.
Agent & Profile
sigrankThe SigRank MCP server — install, CLI commands, all 15 MCP tools, and how the agent feeds your operator profile. sigrank@0.0.205.
The local agent (MCP)
Full reference: install · all CLI commands · all MCP tools · how the agent feeds your operator profile (the write path). sigrank@0.0.205.
The local agent (MCP)
The SigRank local agent is an MCP that reads your token counts straight from local session logs — 19+ platforms supported, including Claude Code, Codex, Amp, Gemini CLI, GitHub Copilot CLI, Goose, Kilo, and more — and keeps your live cascade in sync with the board and your operator profile. You never touch a number; the agent is the verifier. It counts tokens; it never reads the content of your prompts or replies.
What it does
Supported platforms
tokenpull reads local session logs from 19+ AI coding platforms. Each adapter reads that platform's own log format — you don't reconfigure anything.
“Estimated cache-write” means that platform's log format doesn't expose cache-creation tokens; the other three pillars are exact. Env-var overrides let you point any adapter at a custom log path.
Install
# install globally (recommended)
npm install -g sigrank
# or run without installing
npx sigrank
# wire into Claude Code — .mcp.json
{
"mcpServers": {
"sigrank": { "command": "npx", "args": ["sigrank"] }
}
}In a terminal it opens the TUI. Wired into your AI client it starts the MCP stdio server automatically — no extra config. Verified on Node ≥18, macOS + Linux.
CLI commands
MCP tools — callable by your AI client
When wired into Claude Code or Cursor, your AI agent can call these tools directly — no paste, no copy-out.
tokenpullOn-device read → 4-window cascade. Zero paste, token-only.tokenpull_submitRead + publish to the board in one call. Server re-scores authoritatively.tokenpull_compareAll four sources side-by-side: tokenpull / ccusage / token-dash / tokscale with delta % per pillar.rank_pasteScore a ccusage / tokscale paste locally. Returns Υ + narration card.rank_windowsScore all four windows from a dashboard paste at once.submit_pasteRank a paste AND publish it to the board in one call.submit_verifiedSign + POST the verified cascade to /api/v1/snapshots (the ranked path).enrollPaste a key from Settings → "New key" → bind this device (signed submit).get_leaderboardLive leaderboard from signalaf.com, any window.get_operatorOne operator's live profile by codename.watch_tokenpullStreaming cascade snapshot — diffs on each poll.diagnose_cascadeDiagnoses where your token cascade is leaking efficiency — ranked findings with severity + estimated Υ impact.simulate_changePrescriptive "what if" — test proposed pillar changes and see the exact Υ delta + class change before committing.suggest_improvementsGenerates ranked, simulated improvement suggestions — tests strategies and returns them sorted by Υ yield impact.self_improveOne-click optimize: diagnoses, suggests, and simulates the best change in a single call.Open by design — the cascade math is public; proprietary threshold cuts stay server-side. Canonical anchor: rank_paste reproduces MO§ES Υ 18,436.98 exactly.
How the MCP feeds your operator profile
The agent is the data pipeline between your local session logs and your public operator profile at signalaf.com. Here is the exact path, step by step.
The profile is not separate from the MCP. The MCP is the write path. Every cascade metric your profile displays — Υ Yield, SNR, Leverage, 10xDEV, class tier, per-window history — originates from a tokenpull_submit call (or a manual paste through the calculator). The profile is the read surface; the agent is the write path.
The contamination constraint (non-negotiable)
Any live observer that prompts generates the tokens it measures. We learned this directly: a memory observer that auto-prompts (low-input / high-output) inflated a real operator's output by ~25% — visible openly on the live board as the inflated-vs-clean pair (rows 2 and 3). So every SigRank instrument that touches a live session is read-only against telemetry and emits no prompt — no auto-memory, no keep-alive, no self-query. Verified-passive, or it re-contaminates every operator running it. This is a hard requirement, not a caution — and it is the moat: the instrument that doesn't disturb what it measures.
This is the same rule that governs signature drift: the agent is the live reader the drift instrument runs on, and because it never prompts, the drift it reports is the operator's own — not the observer's. A live observer that prompted would inflate the very numbers it reports; this one cannot.
The agent is how board entries become exact and live — vs. the manual paste calculator, which runs your numbers but does not save to the board or update your profile. Account + review still gate the board so it stays honest.
Build out — the stack
Every piece of technology across the SigRank ecosystem, from the web app to the MCP server to the SIGNOMY marketplace surface.
Token counts only — never prompt content. Verified-passive by design.
Metrics
token-onlyThe four raw token counts every score is built from, and the derived cascade metrics the board ranks on.
The four pillars
The four raw token counts every score is built from (T.01–T.04).
Every score starts from four raw token counts. Not your prompts, not your code, not your word counts — four integers. The whole cascade is derived from these.
Fresh prompt tokens you send — the cost of asking.
Tokens the model generates back — the work produced.
Tokens served from cache — cheap reuse of held context.
Tokens written to cache — context you build forward.
Sum of all four pillars — the raw scale of the work.
Blended USD per 1,000,000 tokens — the wallet pillar.
Why these four
The four pillars are not arbitrary — they are the complete token economy of an AI coding session. Input is what you pay to ask. Output is what the model produces back. Cache-write is context you build forward (paying a premium to store it). Cache-readis context you reuse (paying almost nothing because it's already held).
The cascade is the relationship between these four. An operator who writes a lot of cache and then reads it back is compounding — their cache-read dwarfs their input. An operator who sends fresh input every turn and never reuses context is burning — their input dwarfs everything else. The same four integers reveal both patterns, and everything in between.
How they relate
Input ────────────────────► the cost of asking
│
▼
Output ◄────────────────── the work produced
│
▼
Cache-write ◄──────────── context built forward (premium)
│
▼
Cache-read ◄──────────── context reused (near-free)
│
└──► back to Input: reuse reduces what you need to send next turnThe cascade is a loop, not a line. Cache-read feeds back into the next turn's input — the more you reuse, the less fresh input you need. That feedback is why leverage compounds: an operator who holds context produces more output per input over time, not less. The four pillars capture the entire loop; the cascade metrics measure its shape.
The 7:2:1 baseline
The Artificial Analysis pricing baseline sets a 7:2:1 ratio for cache-read : cache-write : fresh input. SigRank's Efficiency metric (Y.08) measures how an operator's cascade compares to that baseline - are they above or below the field average for their token mix? It's not a pass/fail; it's a reference point. The baseline comes from published model pricing data, not from SigRank's own sample.
The derivation. The AA baseline uses two ratios. The 7:2:1 pricing ratio (cache-read:cache-write:input) gives the calibration divisor: 4.0 = (7+1)/2. The operating ratio (cache-read:input:output = 3.5:1:0.5, cache-write ~ 0) gives the reference pillars. At those pillars:
I = 1, O = 0.5, R = 3.5, W ~ 0 (R + W + O) / I = (3.5 + 0 + 0.5) / 1 = 4.0 Efficiency = 4.0 / 4.0 = 1.00 (by construction)
The two 4.0s are the same number by design - that is the calibration. Every other operator is measured against this reference point.
The cascade
Υ Yield / SNR / Leverage / Velocity / 10×DEV / Scale / $1M / Efficiency (Y.01–Y.08).
From the four pillars we derive the token cascade — the metrics the board actually ranks on. Each one captures a different facet of how the cascade compounds (or doesn't). Token-only; no word-era proxies.
The headline metric. Leverage × velocity — how much output you produce per unit of fresh input, amplified by how much context you reuse. This is what the board ranks on.
Signal-to-noise ratio. What share of your fresh traffic is actually output? High SNR means most of what moves through you is work, not requests.
Cache reuse per fresh input. The core compounding metric. High leverage means you hold context and reuse it — the cascade is working for you.
Output per fresh input. How much work the model produces for each token you send. Velocity without leverage is fast but expensive; velocity with leverage is the 10× shape.
The amplification exponent. log10 of transmission × commitment × reuse. 10×DEV = 1 means 10× amplification; 2 means 100×. Bound by the telescoping identity — you cannot inflate it independently.
Raw operator scale. log10 of total tokens. A 6 here means ~1M tokens; a 7 means ~10M. Scale is context, not rank — a small operator can out-yield a large one.
Blended USD per 1M tokens. The wallet pillar. Lower is better. An operator with high leverage and velocity spends less per unit of work — efficiency at the bank level.
Efficiency vs the AA 7:2:1 baseline. Above 1.0 means your cascade beats the field average for your token mix; below 1.0 means you are under it. Not a pass/fail — a reference point.
Composition shorthand: leverage:1:velocity. Shows the shape of your cascade at a glance — are you cache-heavy, output-heavy, or balanced?
The telescoping identity
The cascade has three stages — transmission (O/I), commitment (Create/O), and reuse (Read/Create). Their product must equal cache_read / input exactly, because the intermediate terms cancel:
(O/I) × (Create/O) × (Read/Create) = Read/Input
So 10^(10xDEV) = Leverage, by identity — not by fit. An operator cannot inflate their amplification exponent independently of their leverage; the two are bound by algebra. This is Test 3 in the verification suite — it catches any fabricated row where the numbers don't actually compose.
Three operating dimensions, seven analytical views
SigRank is not seven independent measurements. It is a coordinate system for AI operating behavior. Three structural ratios describe the actual operating state. Four analytical transformations interpret that state. One narrative representation communicates it in natural language.
The mathematical dependence between these views is not a defect. A speedometer and an odometer depend on the same underlying motion while answering different questions. SNR (S = V/(1+V)) places the unbounded velocity ratio onto a 0-1 scale for comparison. 10xDEV (D = log10(L)) makes differences between 10x, 100x, and 1000x leverage legible. Yield (Y = L x V) measures the interaction between reuse and output - both must survive for Yield to be high. The dependence is the architecture.
One operating state. Seven analytical views.
Same Yield, different machine
Yield gives coupled strength. Operating Ratio reveals how that strength was constructed. Two operators can produce the same Yield through completely different operating structures:
100 : 1 : 2
Cache-dominant. 100x leverage, 2x velocity. Yield = 200. This operator reuses enormous amounts of cached context and produces modest output per input token.
20 : 1 : 10
Output-dominant. 20x leverage, 10x velocity. Yield = 200. This operator produces substantial output per input token with moderate cache reuse.
Both produce Yield 200. But one is a cache compounding machine and the other is an output generation machine. Yield alone hides that distinction. Operating Ratio reveals it immediately. This is why the system shows several dependent metrics together - each answers a different question about the same operating state.
Yield is an AND-gate: if reuse is zero OR output is zero, Yield is zero. High reuse cannot compensate for producing nothing. High output cannot compensate for preserving nothing.
A worked read (MOSES)
One operator, four pillars, the full cascade derived step by step. How the numbers compose.
A worked read: MOSES
One operator, four pillars, the full cascade. This is how the numbers compose - from raw integers to every derived metric.
Input = 1,251,211 Output = 11,296,121 Cache-write = 128,196,310 Cache-read = 2,555,179,769 Total = 2,695,923,411
Leverage = R/I = 2,042x Velocity = O/I = 9.03 Yield = L*V = 18,436.98 SNR = O/(O+I) = 0.900 10xDEV = log10(L) = 3.31 Efficiency = (R+W+O)/I/4.0 = 538 Scale V = log10(total) = 9.43 Op Ratio = 2042:1:9.03
How to read it. The operator sends 1.25M fresh tokens and reuses 2.56B from cache - a 2,042x leverage ratio. They produce 11.3M output tokens on that 1.25M input - a 9.03 velocity. Yield is the product: 18,436.98. The cascade compounds: cache-read dwarfs input by three orders of magnitude, and output is 9x the fresh input. This is the 10xer shape.
The telescoping check. Transmission (O/I) = 9.03. Commitment (W/O) = 11.35. Reuse (R/W) = 19.93. Product = 9.03 x 11.35 x 19.93 = 2,042 = Leverage. The identity holds - the derived metrics compose exactly.
Archetype and class. Construction = W/R = 0.050 (active context building). Leverage = 2042 (far above the P80 gate of 74.6). Velocity = 9.03 (far above the P80 gate of 0.34). All three axes elevated - this is the CONVERGENT archetype. Class: 2.7B total tokens places this operator in the ARCH+ experience tier.
The signature describes the structure of this workflow - extreme cache reuse, high output velocity, active context construction. It does not describe whether the work was correct, original, or valuable. It says: this is how the operator works the tools.
Proof
How we know the numbers are real - verification tests, integrity checks, the calibration story, and the tools SigRank reads alongside.
What is proven, what is verified, what is open
Three levels: algebraically proven (composition), operationally verified (telemetry + integrity), still under evaluation (quality/hiring/reasoning).
What is proven, what is verified, what is open
SigRank is precise about what it can and cannot claim. Three levels:
- Derived metrics agree with the four pillars (every metric is a deterministic function of I, O, R, W).
- Y = L x V (Yield = Leverage x Velocity, by construction).
- 10^(10xDEV) = L (telescoping identity: intermediate terms cancel).
- Efficiency = (R + W + O) / I / 4.0 (deterministic from pillars).
- Source telemetry is read locally (the agent reads session logs, not prompts).
- Snapshots are ed25519-signed on device and verified server-side.
- Server recomputes all derived metrics from the four raw pillars (no client-supplied derived values are trusted).
- Plausibility checks: range checks, cross-field ratios, cadence bounds.
- Benford's Law runs as an aggregate backstop.
- Contamination detection catches observer-inflated tooling.
- Whether a cascade predicts work quality.
- Whether a cascade predicts hiring performance.
- Whether a cascade predicts better reasoning or outcomes.
The signature describes the structure of the measured workflow. It does not judge whether the work was correct, original, useful, or valuable.
The four degrees of leverage
AA 7:2:1 baseline → wild field median → power users → top eval; the 10xDEV log read + full provenance.
The Four Degrees of Leverage
Read it as a token cascade: Cache : Input : Output. The AA baseline sits at 3.5 : 1 : 0.50 — the modeled average AI user. The median operator on the all-time board sits at 20 : 1 : 0.10 — the typical operator, the 50th percentile of everyone measured. The median of the top 100 lands at 242 : 1 : 1.04, output traded for cache. The top operator on the live board is 553 : 1 : 1.70: every input returns multiple outputs on a deep cache. Four degrees of leverage, each a real skill, and the distance between them learnable. The last three columns are measured live from the all-time board.
Sources: the AA baseline is a static modeled reference (7:2:1 cache-read : cache-write : input ratio from Artificial Analysis pricing data). The other three columns are measured live from the all-time board (auto-pulled at render). Human Center of Mass = median of all real operators; Power users = median of the top 100 by yield; Top Evals = the single leading operator. 130 outliers separated (see the field analysis). All derived from canonical four-pillar token telemetry. Token counts only. Read the full analysis.
| Metric | AA baseline§ | Human Center of Mass* | Power users† | Top Evals to date‡ |
|---|---|---|---|---|
| Υ Yield | 1.75 | 1.91 | 239.61 | 941.23 |
| SNR | 0.33 | 0.09 | 0.51 | 0.63 |
| Velocity (O/I) | 0.50 | 0.10 | 1.04 | 1.70 |
| Leverage (CR/I) | 3.5× | 20.4× | 241.6× | 553.2× |
| 10xDEV (log₁₀) | 0.54 | 1.31 | 2.38 | 2.74 |
| Efficiency (vs AA 4.0) | 1.00 | 5.26 | 62.83 | 141.90 |
| Operating Ratio (C:I:O) | 3.5 : 1 : 0.50 | 20 : 1 : 0.10 | 242 : 1 : 1.04 | 553 : 1 : 1.70 |
10xDEV read on the log anchor
10xDEV is an exponent, not a multiplier: each whole point is a 10× jump in real cascade amplification (linear = 10^10xDEV).
| Degree | 10xDEV | Linear amplification (10^x) |
|---|---|---|
| AA baseline (7:2:1 modeled reference) | 0.54 | 3.5× |
| Human Center of Mass (median, all human operators)* | 1.31 | 20.4× |
| Power-user median (top 100) | 2.38 | 241.6× |
| Top operator to date | 2.74 | 553.2× |
- Top operator vs AA baseline: +2.20 decades = ~158× more amplification
- Top operator vs median operator: +1.43 decades = ~27× more
- Top operator vs top-100 median: +0.36 decades = ~2× more
10xDEV is an anchor: the telescoping identity (10^10xDEV = cache_read/input) locks the exponent to leverage, so it can't be inflated independently; it has to be earned through the full cascade. Gaining two full points is ~2 orders of magnitude of real amplification, which is why it moves slowly and means a lot.
Sources & provenance
AA baseline (7:2:1 modeled reference) · static
The Artificial Analysis pricing baseline sets a 7:2:1 ratio for cache-read : cache-write : fresh input. This is a modeled reference point, not live data — it represents the “average AI user” operating ratio of 3.5:1:0.5 (cache-read : input : output). Efficiency is 1.00 by definition: all other operators are measured against this. Source: Artificial Analysis pricing data.
Top operator to date · measured live
The top real operator on the live SigRank all-time board (auto-pulled at render via the same operatorTotal path the board uses). Derived from canonical four-pillar token telemetry (input / output / cache_create / cache_read). Token counts only, no prompt content. Source: signalaf.com/board/all.
Power users (top 100 median) · measured live
The median of the top 100 real operators on the all-time board, ranked by Υ Yield. Median, not mean: the top 100 is right-skewed (the top 5 have yields 10-100× higher than the rest), so the median is the honest “typical elite performer” — the operator ranked ~50th out of the top 100. Source: signalaf.com/board/all.
Average users (all operators median) · measured live
The median of ALL real operators on the all-time board, with the 130 outliers separated (they're not deleted — they get their own category — but they don't set the median). Median, not mean: the board is heavily right-skewed (a single IGNITER-class operator with 9 quadrillion input tokens pulls the mean yield to 427 vs the median of 2.5 — a 170× spread). The median is the exact 50th percentile, immune to any outlier no matter how extreme. The trimmed mean (drop 5% each end) still lands at 17.6 vs 2.5 — still pulled by the upper-middle. Median is the cleanest cut. The gap between this column and the AA baseline is the selection effect: real operators who install a token scanner are cache-heavy (leverage ~20× vs AA's 3.5×) but output-light (velocity ~0.09 vs AA's 0.50) — net yield is close to the modeled average, but the composition is very different. Source: signalaf.com/board/all.
Why median, not mean
Token-cascade metrics are not normally distributed. They follow a power law: a few operators compound signal at extreme rates while the long tail burns tokens. The mean is dragged toward the extremes; the median sits at the honest middle. For the “typical operator” column, the median answers “what does the operator at the 50th percentile look like?” — which is the question the chart asks. A mean would answer “what would you get if you pooled everyone's tokens and divided evenly?” — which is a different question, and not a useful one when the distribution is this skewed.
Metric definitions
SNR = O/(I+O) · Velocity = O/I · Leverage = cache_read/I · 10xDEV = log₁₀(transmission × commitment × reuse) · Efficiency = (cache+O)/I ÷ 4.0 (AA baseline 4.0 = (7+1)/2) · Υ = (cache_read × O) / I² · Operating Ratio = cache : input=1 : output. Telescoping identity: (O/I)(C_create/O)(C_read/C_create) = cache_read/input, so 10^10xDEV = Leverage.
§ AA baseline: the Artificial Analysis 7:2:1 modeled reference (3.5:1:0.5 operating ratio). Static — not live data. Efficiency = 1.00 by definition.
* Human Center of Mass: median of all real operators on the all-time board, computed live at render. Excludes staged seeds, The Field, retired/anonymized rows, and the 130 outliers (113 extreme humans + 17 flagged flagged operators) that would skew the median. See the field analysis for the full outlier separation methodology.
† Power users: median of the top 100 real operators by Υ Yield on the all-time board, computed live at render.
‡ Top Evals to date: the single top real operator on the all-time board, computed live at render.
All signal is monitored. All drift is noted. · SigRank · MO§ES™ · Ello Cello LLC · Token counts only, never prompt content.
Verification & integrity tests
How we know the numbers are real — Benford (with its honest failure + fix), the outlier control, the telescoping lock, content-free verification, the threat model.
Verification & Integrity Tests
SigRank ranks operators on token telemetry. The obvious question: how do you know the numbers aren't fabricated, gamed, or bot-generated? Every result here comes from a real run on real data — and where a test failed its first form, we show that too, because a test that can't fail isn't a test.
Why these tests exist
The cascade thesis says operator token usage is a multiplicative process — each stage compounds on the last. Multiplicative processes leave statistical fingerprints that fabricated or mechanical data don't reproduce. To fake a high rank, a forger would have to simultaneously fake the right first-digit distribution, the right internal arithmetic, the right concentration, and the right human activity schedule — in one self-consistent file. Each test closes one of those escape routes.
Test 1 — Benford's Law (first-digit conformity)
If session totals come from a genuine multiplicative work process, their leading digits should follow Benford's Law — P(first digit = d) = log₁₀(1 + 1/d). The theory was never fitted to digits; it predicts this as a side effect. Pre-registered kill condition (declared before seeing data): Nigrini MAD > 0.015 = nonconformity.
First result — the registered prediction FAILED:
| Set | n | MAD | Verdict |
|---|---|---|---|
| All agents | 544 | 0.01604 | NONCONFORM |
| Claude only | 487 | 0.01896 | NONCONFORM |
| Codex only | 51 | 0.01793 | NONCONFORM |
Raw session totals did not conform. We report this plainly — the first prediction was falsified. But the failure was diagnostic: digit 1 was under-represented, 5 and 9 over-represented — the textbook signature of lower-bound truncation. The cause is mechanical: every coding session begins with ~20–23k tokens of cached system prompt — an additive constant on top of the multiplicative process — which starves the leading-1 bucket and breaks Benford.
The fix confirmed the mechanism:
| Approach | n | MAD | Verdict |
|---|---|---|---|
| All sessions (raw) | 544 | 0.01604 | NONCONFORM |
| Sessions > 10× floor | 269 | 0.03193 | NONCONFORM |
| Floor-subtracted (value − 22k) | 532 | 0.01109 | ACCEPTABLE |
Subtracting the measured floor — removing the additive constant and leaving the multiplicative remainder — recovers conformity. Subsetting does not fix it; subtraction does. Synthetic simulation reproduced the whole story (pure multiplicative conforms at 0.00974; +22k floor breaks it to 0.03253, matching the data; floor-subtracted recovers to 0.00787). The mechanism reproduces in synthesis — it's not a story told after the fact.
The defensible claim: the multiplicative cascade is Benford-conforming once the measured additive system-prompt floor is removed. The raw version is falsified and we say so; the floor-corrected version holds and is mechanistically motivated — a stronger result than naive conformity. The test had teeth, fired, and revealed a real artifact (the floor) that is now itself a tracked quantity.
Test 2 — the bot control (Hermes)
A natural-conformity claim is only meaningful if something fails it. Among the sessions was a set of 5 automated probe runs (“hermes”): totals 4208, 4152, 4115, 4222, 4258. Every first digit was 4. Zero digit diversity — a fixed-size mechanical probe, exactly the non-Benford signature a bot produces. This is the control that gives Test 1 meaning: the method distinguishes a multiplicative human process from a constant-size machine process.
Test 3 — the telescoping identity (internal-consistency lock)
The cascade has three stages — transmission (O/I), commitment (Create/O), and reuse (Read/Create). Their product must equal cache_read/input exactly, because the intermediate terms cancel:
(O/I) × (Create/O) × (Read/Create) = Read/Input
So 10^(10xDEV) = Leverage, by identity — not by fit. An operator cannot inflate their amplification exponent independently of their leverage; the two are bound by algebra. A fabricated row with a high 10xDEV but the wrong Read/Input ratio fails the identity and is detectable. We recompute this on every operator from the raw four pillars; it holds for every legitimate row.
Test 4 — content-free verification (the privacy license)
A separate experiment (EXP-007) established that conserved structure is detectable without reading content: across negation-paraphrase pairs, surface overlap was zero (Jaccard 0.00) while semantic equivalence was complete (NLI 1.00) — “You must not smoke” and “No smoking” converge to one kernel. The consequence: a statistical witness (token counts) is a legitimate instrument for a conservation-driven process. The no-content-access design is not a privacy compromise we tolerate — it is the architecture this result predicts. We rank the four integers; we never see what you typed.
Test 5 — the threat model (failure taxonomy → countermeasures)
| Gaming attempt | Countermeasure |
|---|---|
| Score inflation / single-metric overclaim | Composite scoring; no single metric escalates rank |
| Fake convergence on pre-processed numbers | Server recomputes everything from the RAW payload |
| High leverage with inverted meaning (idle re-read) | Convergence + concentration-band check |
| Merging metrics to blur a weak one | Components stay separately binding |
What's still being hardened (stated honestly)
- Cadence (Test 6, in development): human activity is bursty with heavy tails (Barabási, Nature 435, 207, 2005) and carries 1/f timing noise (Gilden, Science, 1995); machines are periodic or Poisson. Session timestamps already carry the data for a timing-domain humanity test. Not yet deployed.
- Data provenance note: the Benford figures above were computed on a 544-session sample transcribed by hand from session JSON. They are real and reproducible from that sample, but canonical published numbers should be regenerated from source telemetry. We flag this rather than hide it.
Sources
- Benford's Law: Nigrini, M. (2012), Benford's Law: Applications for Forensic Accounting, Auditing, and Fraud Detection.
- Human burst dynamics: Barabási, A.-L. (2005), “The origin of bursts and heavy tails in human dynamics,” Nature 435, 207.
- 1/f cognitive noise: Gilden, D. et al. (1995), Science 267, 1837.
- AA pricing baseline (7:2:1): Artificial Analysis, Language Model Benchmarking Methodology.
- All token-telemetry results: computed from canonical four-pillar session data. Methods and scripts are reproducible; raw transcripts are not published (privacy).
Token counts only — never prompt content. Tests are run, not asserted.
Signature drift — the tune meter
Shape-not-magnitude drift from an operator’s calibrated signature; the contamination constraint. (Internals proprietary.)
Signature Drift — the tune meter
Every operator has a signature: the characteristic shape of their token cascade — the proportions between output, cache-write, and cache-read, anchored to input. Signature drift measures how far a stretch of work has moved from that shape. Zero drift = locked in tune; rising drift = the cascade is desyncing from the operator's own calibrated peak. It's a measure of shape, not magnitude — the same log family as 10xDEV.
Shape, not size
Drift is computed in log-space on purpose. Working twice as hard across the board (every axis doubled) is still in tune — the shape is unchanged — so it reads as zero drift. Going off on a single axis (lots of cache-write, no reuse) breaks the shape and reads as real drift. Naive similarity measures get this backwards: one axis can dominate the vector and mask a badly desynced cascade as a false “high.” The log-shape read fixes that — no single component can dominate, and being 0.5× or 2× off counts equally. The exact formulation, thresholds, and per-operator calibration are SigRank proprietary internals.
Where it runs — three time-scales
One drift number per session — a live session-level “tune meter,” updating as the session total moves. Contamination-free, no live hook required.
Drift on the change between successive polls — a rolling time-series. This is where drift becomes a cadence instrument (the timing / burstiness layer). Flagged as a windowed estimate.
True per-turn drift — a UX tune-meter. Requires per-turn granularity the source must expose, and only ever as a strictly passive reader.
Sequence: session drift (now, safe) → window-delta drift (the cadence research) → true per-turn micro (passive-only, gated on granularity).
The contamination constraint (non-negotiable)
Any live observer that prompts generates the tokens it measures. We learned this directly: a memory observer that auto-prompts (low-input / high-output) inflated a real operator's output by ~25% — visible openly on the live board as the inflated-vs-clean pair (rows 2 and 3). So every SigRank instrument that touches a live session is read-only against telemetry and emits no prompt — no auto-memory, no keep-alive, no self-query. Verified-passive, or it re-contaminates every operator running it. This is a hard requirement, not a caution — and it is the moat: the instrument that doesn't disturb what it measures.
The drift instrument and the SigRank local agent are governed by the same rule — see the local agent (MCP). The agent is how drift is read live, and the constraint is why it can be trusted.
All signal is monitored. All drift is noted. · Token counts only — never prompt content.
Measured alongside
Tip of the hat to the token tools SigRank reads alongside / builds on — ccusage, tokscale, token-dashboard.
Measured alongside
SigRank doesn't measure tokens in a vacuum — it builds on a small ecosystem of token-usage tools, and ranks the architecture of the cascade on top of what they count. Credit where it's due:
Independent project — not affiliated with or endorsed by the tools above; names belong to their authors. Token counts only.
Standing on shoulders
The idea that an operator deserves a stat screen isn't new — it's just never been applied to AI. Every competitive game gives you one: K/D, accuracy, rank, a Hall of Fame. BlitzStars.com, built by sockrobber, showed what a real player stat board looks like for World of Tanks: Blitz — live stats, historical progression, clan rankings, a record of who actually runs the field. Not just “how much you played” but how well you played — the shape of your performance, tracked over time.
That design principle — measure the operator, not the tool — is what SigRank brings to AI coding. The game is different; the idea is the same. Credit where it's due.
blitzstars.com ↗How we got here — refining the index
Why we lead with the ordinal rank + reader-matched framing, and treat the raw Υ multiplier with care. The honest calibration story.
Read the full write-up on the index-refinement page ↗.
Transmitters
The eight experience tiers (ARCH+ down to IGNITER) plus the TRANSMITTER peak badge - 24 stages total, assigned by total tokens accumulated.
The experience ladder
8 tiers x 3 sub-stages = 24 stages, assigned by total tokens. Plus the TRANSMITTER peak badge.
The experience ladder
8 tiers + TRANSMITTER badgeEight experience tiers from ARCH+ down to IGNITER, each split into three sub-stages (I/II/III) - 24 stages total. Plus the TRANSMITTER peak badge, a temporary state any tier can earn during a high-frequency, high-resonance window. Class is assigned from total tokens accumulated - not compression, not yield, not SIGNA. It tracks how much real work the operator has put in, not how efficient that work is.
What the classes measure
Class tier is a single-axis read: total tokens accumulated. The more real token flow an operator has logged, the higher their tier. It is a qualification ladder, not a quality ranking - a high-tier operator is not necessarily more efficient than a low-tier one. A small operator can out-yield a large one; class tracks volume, yield tracks efficiency.
The TRANSMITTER badge is separate. It is a temporary peak state that any tier can earn during a window where the operator hits both high frequency (token throughput) and high resonance (SIGNA RATE, a composite signal-quality score currently under recalibration). The badge lapses when frequency or resonance drops. It is not a permanent class - it is a windowed peak.
Eight tiers. One ladder.
Your class is identity. Your rank is position. Class is assigned from total tokens — eight tiers, each split into three sub-stages. TRANSMITTER is a temporary peak badge, not a permanent class.
How you move between classes
Class is not a lifetime label. It is recomputed every scoring window (7d / 30d / 90d / all-time). The more tokens you log in a window, the higher your tier for that window. An operator who stops working will see their class drift down as the window rolls forward.
Class tracks volume (how much real work you have done). Yield tracks efficiency (how well you compound that work). They are independent: a high-volume operator can have low yield, and a low-volume operator can have high yield. The board ranks on yield; the class ladder tracks experience.
24-stage distribution data
Population statistics for every stage: token floor/ceiling, operator count, distribution bars. From the HCM cut.
24-stage distribution
Canonical classifier applied to all 1,627 eligible operators. Stage populations follow Option C target shares (not equal-population): each base tier has a different target percentage, then divides approximately into thirds (III, II, I). Observed min/max are empirical ranges within each stage, not classifier thresholds.
| Stage | Observed min | Observed max | Operators | Distribution |
|---|---|---|---|---|
| ARCH+ I | 9025.91T | 9025.91T | 1 | |
| ARCH+ II | 7.07T | 7.07T | 2 | |
| ARCH+ III | 1.19T | 1.19T | 1 | |
| ARCH I | 186.21B | 897.10B | 25 | |
| ARCH II | 98.54B | 182.62B | 27 | |
| ARCH III | 68.77B | 98.25B | 27 | |
| POWER I | 39.96B | 68.66B | 82 | |
| POWER II | 26.96B | 39.82B | 81 | |
| POWER III | 19.14B | 26.53B | 81 | |
| BASE I | 13.96B | 19.09B | 109 | |
| BASE II | 10.19B | 13.89B | 108 | |
| BASE III | 7.75B | 10.18B | 108 | |
| SEEKER I | 5.45B | 7.74B | 123 | |
| SEEKER II | 4.01B | 5.44B | 122 | |
| SEEKER III | 2.96B | 4.00B | 121 | |
| REFINER I | 2.36B | 2.96B | 82 | |
| REFINER II | 1.85B | 2.35B | 81 | |
| REFINER III | 1.33B | 1.84B | 81 | |
| BEARER I | 984M | 1.33B | 68 | |
| BEARER II | 715M | 984M | 68 | |
| BEARER III | 432M | 713M | 67 | |
| IGNITER I | 216M | 431M | 55 | |
| IGNITER II | 89M | 216M | 54 | |
| IGNITER III | 123K | 87M | 53 |
Observed min/max are empirical token ranges within each stage under the canonical classifier (experience_ladder.json). Stage populations differ by design — each base tier has a different target share (Option C). TRANSMITTER is not shown here — it is a peak badge, not a ladder stage.
Build Archetypes
The 10 composition types across 4 families - how operators work, not how much. Separate axis from the experience ladder.
The 10 build archetypes
Convergence, Generation, Reuse Depth, Active Construction. Classified from leverage, velocity, and construction ratios.
The 10 build archetypes
composition classifierEvery operator lands in exactly one build archetype - a composition classifier that describes how they operate, not how much. This is a separate axis from the experience ladder. An ARCH+ can be INPUT-BOUND (deep experience but currently burning fresh input). An IGNITER can be an AMPLIFIER (new but already compounding cache). Archetype describes shape. Class describes qualification. Rank describes position.
The three dimensions
Archetypes are classified from three derived ratios of the four token pillars:
Classification precedence
First match wins. The classifier checks in this order:
- 1. CONVERGENT - P80+ on all 3 axes (leverage + velocity + construction)
- 2. KINETIC - velocity >= 0.80 (generation breakout)
- 3. Construction branch - construction >= 0.02 (BUILDER / RECURSIVE / AMPLIFIER, split by leverage)
- 4. Reuse depth branch - else (INPUT-BOUND / PRIMING / CONTEXTUAL / DEEP READER / ARCHIVIST, split by leverage)
The four families
All 10 archetypes
Deep reuse, active construction, and high generation rise together. A rare composition where all three operating axes are elevated without the usual tradeoffs.
P80+ on all 3 axes (leverage + velocity + construction)
Generation has broken out. Output approaches or exceeds fresh input, making transmission the defining feature of the composition.
velocity >= 0.80
Fresh input still carries most of the workload. Little prior context is returning, so each cycle depends heavily on new input.
leverage < 5
Reuse is beginning to form. Prior context is returning, but the system has not yet developed deep leverage.
leverage 5-10
Retained context is now materially supporting the workflow. Reuse is established, while active construction remains limited.
leverage 10-15, passive
Strong accumulated context is carrying the workflow. The operator draws deeply from retained context while creating relatively little new context.
leverage 15-23, passive
Extreme reuse of accumulated context. A deep context library carries the system while new construction remains limited.
leverage >= 23, passive
Active context construction has begun. The system is creating material for future reuse while leverage is still developing.
construction >= 0.02, leverage < 30
New context is being built on top of an already substantial reusable base. Construction and reuse are now feeding the same operating loop.
construction >= 0.02, leverage 30-50
Deep reuse and active construction are operating together at scale. Existing context produces new work that expands the context available for future cycles.
construction >= 0.02, leverage >= 50
Archetype vs class tier - two independent axes
The experience ladder (class tier) tracks how much you have operated - total tokens accumulated. The build archetype tracks how you operate - the composition of your cascade. They are independent:
- ARCH+ + INPUT-BOUND - deep experience but currently burning fresh input
- IGNITER + AMPLIFIER - new but already compounding cache at scale
- BASE + CONVERGENT - mid-field with all three axes elevated
Both are recomputed every scoring window (7d / 30d / 90d / all-time). An operator can shift from INPUT-BOUND to AMPLIFIER within a week if their architecture changes - the archetype tracks the live shape, not a lifetime label.
Population statistics
Full dataset: N, %, median yield/leverage/velocity, four-pillar composition, top platform for all 10 archetypes.
Population statistics
From the HCM cut (1,586 operators). Each archetype is a deterministic classification — no clustering, no randomness. Medians are per-archetype; composition is the median four-pillar split.
| Archetype | Family | N | % | Yield | Lev | Vel | CR% | CW% | I% | O% | Platform |
|---|---|---|---|---|---|---|---|---|---|---|---|
| CONVERGENT | Convergence | 104 | 6.6% | 257.30 | 245.3x | 1.049 | 93.1 | 5.8 | 0.38 | 0.46 | anthropic |
| KINETIC | Generation | 113 | 7.1% | 469.35 | 361.5x | 1.520 | 96.5 | 2.9 | 0.27 | 0.43 | anthropic |
| INPUT-BOUND | Reuse Depth | 108 | 6.8% | 0.05 | 2.7x | 0.019 | 72.5 | 0.3 | 26.62 | 0.51 | openai |
| PRIMING | Reuse Depth | 149 | 9.4% | 0.32 | 7.7x | 0.042 | 87.5 | 0.2 | 11.42 | 0.49 | openai |
| CONTEXTUAL | Reuse Depth | 186 | 11.7% | 0.84 | 12.7x | 0.066 | 91.5 | 0.3 | 7.18 | 0.47 | openai |
| DEEP READER | Reuse Depth | 169 | 10.7% | 1.52 | 18.4x | 0.081 | 93.9 | 0.3 | 5.12 | 0.41 | openai |
| ARCHIVIST | Reuse Depth | 186 | 11.7% | 3.54 | 29.8x | 0.124 | 95.5 | 1.1 | 3.19 | 0.35 | openai |
| BUILDER | Active Construction | 278 | 17.5% | 1.12 | 13.7x | 0.077 | 88.8 | 3.0 | 6.51 | 0.50 | anthropic |
| RECURSIVE | Active Construction | 132 | 8.3% | 7.23 | 38.9x | 0.191 | 93.2 | 3.7 | 2.37 | 0.47 | anthropic |
| AMPLIFIER | Active Construction | 161 | 10.2% | 26.53 | 77.2x | 0.329 | 95.3 | 3.2 | 1.22 | 0.38 | anthropic |
CR% = cache-read % of total tokens. CW% = cache-write %. I% = input %. O% = output %. Yield = median Υ. Lev = median leverage (cache_read/input). Vel = median velocity (output/input). Population = 1,586 operators (HCM cut, outliers excluded).
MO§ES™
The governance framework SigRank runs on — the Conservation Law of Commitment, the evidence, and the stack of products built on top.
Commitment theory + founding
The theory behind MO§ES™ + the founding-of-the-board story (owner-authored).
SigRank runs on MO§ES™ — the Modus Operandi §ignal Scaling Expansion System. A governance framework built on a published conservation law for language. This section covers where it came from, what the law says, what the evidence shows, how governance works, who it's for, and what we're building on top of it.
Where this came from
The founder studied sociology and history at SUNY Geneseo, UB, and University of Hawaii at Hilo. Ran Pacific Northwest operations for Invisible Children. Held board seats at KEDS (2006–2008) and Horizon Health Services (2012–2018). Different world, but the same question underneath: how do you keep commitment intact when it passes through a lot of hands?
Then DJMP Inc. — a Buffalo contracting operation, started in 2011, taken from zero to $1M/yr with a team of 40. Projects ranging $10k–$500k. Real operations, real governance, real consequences when things drift.
Running governed AI across that operation, something was missing. The leaderboards measured the models. Nobody measured the operator — the person actually steering the AI, making the calls, deciding what to keep and what to cut. The augmentation layer was invisible. So the founder built a way to measure it, found a conservation law underneath it, published the law, patented the enforcement architecture, and ran it against the field. That's where SigRank and MO§ES™ came from — not from a market thesis, from an operational gap.
The Conservation Law of Commitment
C(T(S)) ≈ C(S) with enforcement; C(T(S)) < C(S) without it.
In plain terms: when you transform a piece of language — compress it, translate it, summarize it, rewrite it — the commitment content (the obligations, prohibitions, and modal constraints: “shall,” “must not,” “unless,” “is entitled to”) either survives or it doesn't. With an enforcement gate in the transformation pipeline, it survives. Without one, it decays. This isn't a guideline or a best practice — it's a measurable property of language under compression, and it's falsifiable.
The law is published under CC-BY-4.0 (DOI: 10.5281/zenodo.20029607). The enforcement architecture (MO§ES™) is patent-pending. The law itself is open.
What the evidence shows
Seven experiments (EXP-001 through EXP-007) tested the law on a 20-signal canonical corpus, running 10 recursive iterations each, using bidirectional NLI entailment and Jaccard surface stability as oracles. Three results worth pulling out:
- EXP-003: 13 of 20 signals held NLI bidirectional entailment = 1.00 across all 10 iterations under the gate. That's invariance under recursion, not a tautology.
- EXP-006: Only 2 of 4 paper claims survived self-referential recursion. The harness fails when commitment structure isn't robust — which is the point. The law is falsifiable and the experiments can break it.
- EXP-007: An NP-negation probe separated semantic commitment from lexical surface form. Jaccard degraded while NLI held — the commitment survived even when the surface words changed.
Separately, a 5-phase architecture stress test measured 80–85% structural coherence across a four-module system. Standard probability says four modules at 80% standalone viability should produce ~41% series-system viability (0.8×0.8×0.8×0.8 = 0.4096). The governance layer inverted that.
Full experimental record: DOI: 10.5281/zenodo.19105225
Governance in the action path
Most approaches to AI governance sit outside the model — firewalls that drop packets after the logic has already corrupted, sandboxes that box an agent that still hallucinates inside the box, post-hoc audits that tell you how you were breached after the damage is done. Every one of them patches after the fact.
MO§ES™ doesn't build a better cage. It governs from inside the loop — in the execution path, not before it, not after it. The enforcement gate sits where the transformation happens. Commitment that passes through the gate survives. Commitment that doesn't, doesn't. The conservation law is what makes this a property of the system rather than a policy someone has to remember to follow.
The practical difference: a violation doesn't kill the workflow. The loop realigns to its original parameters and steers back. The agent stays fluid, bound to intent, instead of dying in a dead end or looping indefinitely inside a sandbox that only secures the perimeter.
Who this is for
SigRank measures the operator, not the model. If you're the person steering the AI — deciding what to keep, what to cut, what to ask next — the board is about you. A few groups who get something specific out of it:
- Builders and developers — see how your AI-assisted workflow actually performs. The token cascade shows whether you're burning tokens or compounding them. Compare against the field instead of guessing.
- Creators and writers — measure augmentation efficiency, not just output volume. The cascade reveals whether the workflow is reusing context or repeatedly starting fresh. The four pillars separate signal from noise.
- Students and researchers — benchmark your AI collaboration patterns against established operators. See what efficient operator-AI interaction looks like, with real numbers behind it.
- Enterprise teams — a verifiable workflow signal that can supplement work samples and outcomes for training and tooling decisions. The board is a measured surface, not a self-reported one. Signed snapshots mean the numbers are verifiable.
In the SIGNOMY layer, agents carry provenance and build trust. SigRank is where that provenance starts — the operator's measured record becomes portable.
What we're building on it
The law is the substrate. MO§ES™ is the enforcement architecture. On top of that, a stack of products — each one a different surface for the same gate:
- AQUA — application workflow tooling with reusable submission memory. Answer banks, submission memory, application filling. The workflow layer and the first wedge.
- SigRank — the leaderboard you're looking at. AI operator efficiency, measured by token cascade, verified by signed snapshots. The intelligence layer.
- KA§§A — voice AI runtime that uses commitment kernel caching to cut redundant NLU work in multi-agent flows. In practice: 50s → 6.5s per 5-turn call.
- SIGNOMY (signomy.xyz) — a governed agent marketplace where agents register, build trust, take missions, and carry provenance. The marketplace becomes a constitutional economy rather than a listing board. The top layer — where everything below it becomes operational behavior.
The goal is straightforward: make governance a property of the execution path, not a policy document someone reads once. If the law holds — and the evidence says it does — then commitment survives transformation when the gate is present. Every product above is a different surface for the same gate.
How this connects to the board
Every snapshot on the SigRank leaderboard is ed25519-signed on the operator's device and verified server-side. Token counts only — no message content is ever read or stored. The commitment being conserved is the integrity of the measurement itself: what the operator measured is what the board records, with no drift in between.
The governance layer maps directly to how the board works: signed operator identity, token counts only, leaderboard ranking, platform-agnostic collection, ed25519 verification, and a public board with open data. The leaderboard works because the data passed through the gate — not because someone reviewed it after the fact.
More at mos2es.com · benchmarks