{"criteria_id":"token-efficiency/v1","criteria_revision":"1.2.0","criteria_changelog":"1.0.0 (2026-11-03): initial banking — shares rounded to 3 decimals. 1.1.0 (2026-11-03, correction wave): shares rounded DOWN to the nearest multiple of 0.5 at every total — derivability protection for small totals, after the QC-2 counterexample (QC2-REPORT.md §2(iv), 2026-11-03) showed 3-decimal shares can pin a unique exact total for a small catalogue. 1.2.0 (2026-11-03, correction wave 2): the floor-to-0.5 grid is kept and a runtime derivability self-check is added — a whole's shares are withheld (null, reason shares_withheld) when the whole's counts lie in the withholding class of the candidate box computed from its own part byte lengths under kind-aware β (attacker model v2), after QC-3 (QC3-REPORT.md, 2026-11-03) measured β_schema(2)=2 (negative-integer schemas) and produced three exact-recovery triples against the grid alone.","family":"token-efficiency","op":"split-profile","ops_not_offered":["budget","catalogue","audit"],"corpus":{"id":"split-profile-corpus/v1","sha256":"406a8aa9409716b50a4ad73dbf634cf0e6e0ff39b99a06db577bac0287acafc5","token_figures_status":"PINNED-REAL-TOKENIZER"},"corpus_pin_definition":"The corpus pin is the SHA-256 of the corpus's canonical serialization (the corpus object excluding its sha256 field), computed and verifiable by the published harness (harness.mjs). Expected shares inside corpus cases are hand-derived from the criteria text with an independent script driving the pinned tokenizer module directly (not the engine's code path), and pinned against the real tokenizer named in the criteria (cl100k_base, gpt-tokenizer 4.1.0).","tokenizer":{"id":"cl100k_base/gpt-tokenizer@4.1.0/data-sha256:223921b76ee99bde995b7ff738513eef100fb51d18c93597a113bcffe865b2a7/source-sha256:7354993a4b8e2d0351562811a67ea2cf6fa4966164df2925c83b63d8d802f005","stub":false,"real":true,"encoding":"cl100k_base","implementation":"gpt-tokenizer","version":"4.1.0","data_sha256":"223921b76ee99bde995b7ff738513eef100fb51d18c93597a113bcffe865b2a7","source_sha256":"7354993a4b8e2d0351562811a67ea2cf6fa4966164df2925c83b63d8d802f005","status":"pinned — cl100k_base via gpt-tokenizer 4.1.0 (MIT), pins in the fleet TOKENIZER DECISION RECORD (Q-04 build); special-token spellings in submitted text are counted as ordinary text (empty allowed-special set).","role_in_this_op":"This op reports shares, not counts: every share is a ratio of exact counts under this tokenizer. The tokenizer is named here because the scope statement counts exactly under the tokenizer named in this criteria document."},"price":{"usdc_units_per_call":20000,"label":"$0.02","basis":"per catalogue"},"free_tier":{"per_day":100,"min_interval_ms":5000,"on_exhaustion":"402"},"input_contract":{"body":"One JSON request body: { catalogue, caller? (free pre-check only) }. The catalogue is a JSON array of tool entries, or an object carrying a tools array of the same form.","catalogue":"Each tool entry must be a JSON object. name and description, when present, must be strings; inputSchema, when present, may be any JSON value. Anything else is a malformed free refusal naming the rule.","caps":{"tools":200,"body_bytes":262144},"over_cap":"More than 200 tools, or a request body over 262,144 bytes, is a free pre-gate refusal naming the cap. No partial or truncated profile exists in this family.","zero_tools":"A catalogue with zero tools is a free refusal (not assessable).","ignored_inputs":"The fields sessions_per_day, daily_ceiling_tokens and calls_per_day are not accepted for any computation in this op. If submitted they are ignored entirely — not echoed with any figure, never used; the report for a catalogue submitted with them is identical to the report for the same catalogue submitted without them."},"serialisation_rule":"A catalogue is a JSON array of tool entries, or an object carrying a `tools` array of the same form. Each tool entry must be a JSON object; `name` and `description`, when present, must be strings (present-but-non-string = malformed, free refusal naming the rule); `inputSchema`, when present, may be any JSON value. Anything else = malformed free refusal. Part strings, per tool: name part = JSON.stringify(name) when name is a string, else the empty string; description part = JSON.stringify(description) when a string, else empty; schema part = JSON.stringify(inputSchema) — keys in submitted (parse) order, no whitespace — when inputSchema is present, else empty. Absent field = zero-length part, never an invented default. Part counts = cl100k_base token counts of the part strings under the fleet tokenizer (empty allowed-special set, per the tokenizer decision record). Parts are encoded SEPARATELY; no concatenation, no delimiters. A tool's definition-token count FOR THIS OP = name count + description count + schema count (the criteria state this definition on their face). Catalogue total = sum over tools of tool totals = sum of the three catalogue sub-count totals. Shares: sub-count ÷ total, rounded DOWN to the nearest multiple of 0.5 — a share is published as 0, 0.5, or 1: the largest multiple of 0.5 not exceeding the unrounded share; a zero sub-count publishes exactly 0, and a sub-count equal to the total publishes exactly 1. This one grid applies at every total, to catalogue shares and per-tool shares alike. Derivability self-check (criteria revision 1.2.0): before a whole's shares are published, the engine recomputes from that whole's own part byte lengths the candidate box a submitter could hold — for each part, the counts d whose measured minimum byte length β(d) does not exceed the part's actual byte length (string parts: β(0)=0, β(1)=2, β(2)=3, β(c)=c for c≥3; schema parts: β(0)=0, β(c)=c for c≥1; an absent part is fixed at 0 and a present part at 1 or more) — and withholds the whole's shares (all three null, reason `shares_withheld`) exactly when the whole's true counts lie in the box's withholding class. That class is: every candidate triple of the box whose floored shares admit no other feasible candidate in the box; plus, when exactly one such triple exists and the box holds other candidates, every candidate that shares the floored shares of the lexicographically smallest candidate outside that set — so a withholding class in a box of two or more candidates is never a single triple. The only triples that can ever be box-unique are the seven published in §4 of the criteria document (the derivability proof under attacker model v2 is published with the build package, verify-rounding2.mjs). Decisions on unrounded values. R-2 rows in submitted order, each carrying `index` (0-based) and `name` (string or null). Edge rules: a tool with total 0 → all three shares null, reason `empty_definition`. Catalogue total 0 → R-1 shares null, reason `empty_catalogue`. Zero tools → free refusal (not assessable). Tools with absent inputSchema are NEVER grouped (absence is not an identity); two tools whose schema parts are byte-identical strings form a group ({} == {} groups). Schemas differing only in key order are NOT identical (submitted-order serialisation).","rounding":"Every share is rounded DOWN to the nearest multiple of 0.5: the published share is the largest multiple of 0.5 not exceeding the unrounded share, so every published share is 0, 0.5, or 1 (a zero sub-count publishes exactly 0; a sub-count equal to the whole publishes exactly 1). The same grid applies at every total, to the catalogue shares (R-1) and to each tool's shares against its own total (R-2) alike. Every decision is made on the unrounded value. The three published shares of one whole sum to at most 1: each published share understates its unrounded share by less than 0.5, so a whole whose parts are each below half publishes 0 for every part. Derivability self-check (revision 1.2.0): before a whole's shares are published, the engine recomputes the candidate box from the whole's own part byte lengths under the measured β table (string parts β(0)=0, β(1)=2, β(2)=3, β(c)=c for c≥3; schema parts β(0)=0, β(c)=c for c≥1) and withholds the whole's shares — all three null, reason shares_withheld — exactly when the true counts lie in the box's withholding class: the box-unique candidates, extended when there is exactly one by the whole share-class of the lexicographically smallest other candidate, so the class is never a single triple in a multi-candidate box; a whole whose candidate box holds exactly one candidate is likewise withheld. The seven triples that can ever be box-unique are [0,1,1], [0,1,2], [1,0,1], [1,0,2], [1,1,0], [1,1,1], [1,1,2] (name, description, schema). Revision history: 1.0.0 rounded to 3 decimals; QC-2 (QC2-REPORT.md §2(iv)) demonstrated exact recovery of a small catalogue's counts from its 3-decimal shares ([94, 40, 13], total 147; [60, 39, 28], total 127), and 1.1.0 answered with the floor-to-0.5 grid alone; QC-3 (QC3-REPORT.md) then showed the grid alone still admits exact recovery for [0, 1, 2], [1, 0, 2] and [1, 1, 2] under the correct kind-aware β (β_schema(2)=2, via negative-integer schemas), and 1.2.0 adds the self-check. The exhaustive derivability proof under attacker model v2 is published with the build package (verify-rounding2.mjs).","verdict_grammar":{"line":"TOOL-CATALOGUE SPLIT PROFILE — tools: N — schema-identity groups: G — <check-end UTC>","vocabulary":"No other verdict vocabulary exists for this op. The line carries the tool count N (a fact the caller supplied by submitting the catalogue) and the schema-identity group count G. It carries no token figure, no band, and no grade."},"blocks":[{"id":"R-1","name":"catalogue-wide split shares","text":"name_share, description_share, schema_share: each catalogue sub-count total divided by the catalogue total, rounded as published. If the catalogue total is 0, all three shares are null with reason empty_catalogue. If the derivability self-check withholds the catalogue's shares, all three shares are null with reason shares_withheld."},{"id":"R-2","name":"per-tool split shares","text":"One row per tool, in submitted order (ordering is not a ranking), each carrying index (0-based), name (string or null), and name_share / description_share / schema_share: each of the tool's three sub-counts divided by that tool's total. A missing field is a zero sub-count and a 0 share, never null. A tool whose total is 0 reports all three shares as null with reason empty_definition. If the derivability self-check withholds the tool's shares, all three are null with reason shares_withheld. No per-tool total, no per-tool sub-count, and no per-tool share of the catalogue appears anywhere."},{"id":"R-3","name":"schema-identity groups","text":"Two or more tools form a schema-identity group when their schema part strings are byte-identical. Tools with absent inputSchema are never grouped (absence is not an identity). Outputs: for each group, a group index, the tool names in the group (submitted order), the tool indices, and the number of tools in the group; plus the total group count G (also in the verdict line). No schema content, no schema token count, and no schema character count is reported.","caveat":"Identity is judged under the published serialisation (keys in submitted order); two schemas that differ only in key order are NOT identical under this rule — the rule is stricter than sorted-key equivalence, and says so on its face."}],"free_precheck":"The free pre-check (POST /precheck) returns assessability ONLY: the common signed fields; whether the submitted catalogue is in-contract (or the free refusal naming the cap/malformation); and per-block assessability lines — R-1/R-2 ASSESSABLE (zero tools is a refusal), R-3 ASSESSABLE when at least two tools carry a schema, else NOT-ASSESSABLE with the reason: fewer than two tools carry a schema. It returns no tool count, no share, no group existence, and none of the tool-ergonomics/v1 pre-check counts. Free allowance: 100 per day per caller wallet, minimum interval 5,000 ms, 402 on exhaustion.","custody":{"construction":"In-memory processing within a single request lifetime; nothing about a submission persists, on any path including errors and timeouts. No hash of a submitted catalogue or of any tool in it appears anywhere.","ledger_closed_fields":["payer wallet","timestamp/day","price (USDC units) with the CAD fair-market-value block (rate, rate date, basis, cad_pending, refund)","payment tx id + Solana fee (lamports)","criteria version","verdict line","tool count","schema-identity group count","block assessability outcomes (R-1/R-2/R-3)","house flag"],"ledger_note":"The ledger list above is closed: adding a field is a criteria/handling version change and re-runs the canary. The ledger NEVER carries any token total, sub-count, character count, share, or band id. It also carries no input byte size: the request body's byte size is a byte count of submitted content, and byte counts of content are excluded from every retained surface of this op (the safer reading of the reconciliation's character/byte-count exclusion); the judgement is recorded in the build registry. The payment-inclusion line's shorter ledger sentence is the buyer-facing summary of this same list.","errors":"Error handling is closed-form: static strings plus numeric facts only (lengths against caps, counts of tools, rule ids). No error path interpolates any part of a catalogue beyond the rule it names. No token or character count of submitted content appears in any error."},"forbidden":"Schema-level forbidden content in every surface of this op (report, pre-check, errors, ledger, metrics): no absolute token count of any tool, any sub-count, or the catalogue, at any precision; no character or byte count of any content; no per-tool share of the catalogue; no top-k concentration figure; no composite score or grade; no judgement vocabulary (never bloated, wasteful, inefficient, bad design, redundant); no claim about whether a tool is worth its tokens; no usage claim (a catalogue alone cannot show which tools are ever called); no quoted catalogue content beyond tool names; no estimate-comparison figure of any kind; no projection figure, verdict, or band of any kind.","scope_statement":"The `split-profile` op states how one submitted MCP tool catalogue's definition-token count is composed, and nothing else. Counted exactly under the tokenizer named in this criteria document, it reports the shares of that count carried by tool names, descriptions, and parameter schemas — for the catalogue as a whole and inside each tool — and the groups of two or more tools whose parameter-schema serialisations are byte-identical under this criteria document's published serialisation (keys in submitted order; schemas differing only in key order are not identical under this rule). It reports no definition-token count for any tool or for the catalogue, and no character count. It makes no projection, and no comparison against any estimate. Per-tool and total definition-token figures for a submitted manifest — stated as estimates under the 4-characters-per-token method — are the province of the tool-ergonomics/v1 audit, which also grades description discrimination, parameter specification, and naming hygiene; this op grades nothing, produces no score or grade, and makes no claim about any tool's design, usefulness, worth, or frequency of use.","schema_identity_caveat":"Identity is judged under the published serialisation (keys in submitted order); two schemas that differ only in key order are NOT identical under this rule — the rule is stricter than sorted-key equivalence, and says so on its face.","full_preload_note":"Shares are proportions of the catalogue's definition-token count as submitted; the report grades the catalogue as submitted, not any client's loading behaviour, and makes no claim about how often any tool is called.","disclosure_sentence":"Submitting a catalogue to any third party, this service included, gives its contents to a new holder however briefly; the check is processed in memory only and never stored, but it does not undo the disclosure.","honesty_line":"The counts underlying this profile are exact under the published tokenizer; another model's tokenizer will count the same text differently, and no figure in this report is a promised bill reduction on any specific provider.","retention":"Submitted catalogues are processed in memory only and are never stored — not in KV, not in logs, not in the payments ledger, not in metrics, and not in error records. No catalogue content, no fragment of it, and no hash of any submitted value is recorded anywhere. Reports carry shares, schema-identity groups, and tool names only. The payments ledger records only the closed field list published in the criteria. Because nothing is kept, a paid retry re-sends the catalogue.","payment_includes":"$0.02 per tool-catalogue split-profile check. The fee is per catalogue: each catalogue you submit is charged at $0.02. The payment includes: one submitted MCP tool catalogue (up to 200 tools, request body up to 262,144 bytes), returned as one signed report giving — for the catalogue as a whole and for each tool, by tool name — the shares of its definition-token count carried by its name, its description, and its parameter schema, counted exactly under the tokenizer named in the report and stated as shares only (the report contains no token count for any tool or for the catalogue, and no character count); and the groups of two or more tools whose parameter-schema serialisations are byte-identical under the published serialisation. A free pre-check returns the assessability of each part of the report only — no shares and no duplication result. The report states proportions and duplication of schemas only; it does not grade any tool's design, usefulness, or worth, and it makes no claim about how often any tool is called. Submitted catalogues are processed in memory only and are never stored; the payments ledger records only the payer, the time, the price, and the verdict line.","kill_line":"Kill line (Q-03R, under Mauricio's 2026-11-03 build-bank-hold doctrine): build, bank, and hold; judged at the fleet's periodic reviews. There is NO demand kill line for this item. Day-0 = first outside paid settle (accounting only; house proofs never count). Tripwires, all stop-and-review: (1) refunds >5% in any 30-day window; (2) free use >10x paid use; (3) a wrong share/group from undisclosed stale or partial data (the counting error enters the corpus first as a regression case, corrected rules publish as a new criteria version, the corpus re-passes QC-1 at 100% before serving resumes; issued reports are never amended); (4) the Q-03 projection tripwire is satisfied BY CONSTRUCTION — no projection exists in this op and no input is accepted for one; (5) custody: any surface carrying submitted catalogue content beyond tool names; (6) double-count: any underlying count double-counting a tool or span; (7) DERIVABILITY: any figure in a served report or pre-check found to permit recovery of a per-tool exact count or the exact catalogue total by trivial arithmetic (alone or combined with Ergonomics' published method and free pre-check total) — the offending figure class is removed or the op stops until a new criteria version restores the result.","never":"This op never reports a token count or a character count for any tool or for the catalogue; never compares any count against an estimate; never projects any load and never accepts a volume or a ceiling for any computation; never grades any tool's design, usefulness, or worth; never ranks tools; never retains submitted material beyond the request lifetime.","service":"split-profile","version":"1.2.0","endpoints":{"criteria":"GET /criteria (free)","precheck":"POST /precheck (free, assessability only: no shares, no group existence, no counts)","check":"POST /check (paid, $0.02 per catalogue: signed split-profile report)","metrics":"GET /metrics","not_offered":"POST /budget, POST /catalogue and POST /audit answer NOT COVERED — those ops are not built or offered by this worker. This worker serves op split-profile only."}}