✓ Verified by Track AI ROI

How Track AI ROI verification works

What the mark means when you see it on a consultancy's published track record or a proof report.

What Track AI ROI is

Track AI ROI is an independent measurement layer for AI consulting. Consultancies run their client implementations through the platform: each engagement commits to a measurable goal up front, the platform meters what is actually delivered, and the client confirms the outcomes. The pages carrying the mark are generated from that record.

Where the numbers come from

Platform-metered Usage, adoption and cost figures are pulled directly from AI provider APIs (Anthropic, OpenAI, Google, Microsoft) through credentials held by the platform. The consultancy has no field in which to type these numbers.
Client-confirmed Financial outcomes count only after the client company's own administrator confirms them. A consultancy's unconfirmed claims stay pending and are excluded from every figure that carries the mark.
Frozen commitments The baseline an implementation is measured from, and the expected value beside it, are frozen when the engagement is committed. Neither can be edited afterward, and verdicts are immutable once computed. Every month is measured from the original baseline, and the expected value shown beside it is the original forecast, never a revised one.

How a verdict is decided

Each verdict (methodology kf-verdict-v7) weighs what an implementation returned against everything it cost, month by month from go-live. It never judges against the goal the implementation set itself, so an easy goal cannot make proof easier. The expected value is a forecast, shown beside each month's figure and never scored.

Benefits are recorded as separate lines in four tiers: cash released (a budget line that fell), cost avoided (a planned cost that did not happen), capacity (measured time saved), and wider benefits, which are recorded but never given a money value. Costs are counted in full: one-time set-up, recurring licences and usage, a fair share of shared subscriptions, and the time people spend checking and redoing the output.

Every line carries an evidence grade: obtained directly from an independent source (E1); a client system of record with tested controls (E2); a document or instrument such as an invoice reference, a timer or system-logged runs (E3); an estimate, or a figure confirmed one way only (E4); and self-report (E5). Cash is a recorded amount, not an estimate: once a client admin has confirmed it, it counts in full at every grade, and its grade is shown beside it. A client admin's own entry counts as self-attested; this departs from the methodology's rule that no money figure rests on self-report alone, by choice, so that a client's own savings are not hidden for want of paperwork. Measured time saved is an estimate and counts at a disclosed share set by its design and evidence: 100% for a controlled comparison on tested records, 90% or 70% for weaker designs, 50% on an estimate, and nothing on self-report. Costs count in full at what was recorded, never discounted and never marked up. Each carries its evidence grade.

Measured time saved is estimated from recorded runs before and after, task by task (a Hodges–Lehmann shift with a 90% Mann–Whitney interval), and needs at least 5 timed or system-logged runs after go-live per task. Typed runs are reported in hours but count toward nothing. It is demonstrated only when the whole interval is above zero and the estimate reaches the minimum effect declared at commit: the committed reduction, never below 10%. Its money value is hours times the loaded hourly rate frozen at commit (from the labour rates on file: a role, department or account default; never from an individual's wage, since the rate can be read back from the value) times the share of saved time counted as value, 50% unless redeployment is recorded. That value is capacity, not cash: it is shown beside cash and never added to it.

The verdict reads one of six states. Paying off: confirmed cash covers the cost. Capacity gain, no cash yet: time saved is demonstrated, cash does not yet cover cost. Not demonstrated: measured, but nothing passes. Net negative: each month after the ramp loses money even at the upper bound of time saved. Not yet measurable: in the ramp (3 months by default), or while the evidence is short, for at most 3 periods after the ramp. Unsupported: the record is incomplete. Proven is Paying off with the cash held to the six-month checkpoint, at least half the involved people using it, and the baseline confirmed. A consultancy's record is shown as the distribution of these verdicts across every implementation it committed, never as a win rate or a delivered percentage.

Every figure is rebuilt from the raw record each time, nothing is projected forward, and each verdict states the periods it covers and nothing about later ones. The parameters for which no standard exists are published in a register with their values and nearest precedents, and are shown on every proof report. A verdict is a consulting computation by Track AI ROI and expresses no assurance; assurance, if any, comes from an independent practitioner.

Every commitment also records an expected value: what the implementation was forecast to save each month when it was set up, frozen at commit beside the baseline. It is shown beside each month's measured figure so a reader can see whether the result was the size that justified the build. It is never scored: the verdict weighs evidence against cost, and a forecast reached or missed changes nothing in it.

How time figures are obtained

Every time figure on a proof report carries an evidence tier and the sample behind it, so a reader can tell a measurement from an estimate:

measured from system timestampsA run's duration taken from the client's own system (ticket opened to closed, document created to sent). Nobody was asked.
timed as it happenedThe person doing the task pressed Start and Stop on a live timer while doing it.
typed from memory, run by runThe person doing the task typed how long a specific run took, after the fact.
declared from workflow stepsMinutes per step entered once when the workflow was documented, summed. An estimate, counter-signed but not measured.
typed once at setupA single per-run figure entered at setup.

A measured baseline is the median person-time of at least 5 recorded runs by 2 different people (or 8 runs when exactly one person is assigned to the step, which the evidence says), frozen at commit. One recorded run per step is enough to commit; a baseline short of the floor is labelled a thin sample wherever it appears and keeps maturing from new runs until go-live or 28 days after commit, each update a new record on the chain; person-time counts everyone involved in a run. A sampled period outcome is the median of the after-runs recorded in that period, counted only once every linked task has at least 3 of them; a period that later drops below that floor is withdrawn, not left standing. After-runs are solicited by the platform from runs it metered, on a schedule the client did not choose, and each report says how many were solicited versus volunteered.

How runs are counted

Time saved is the per-run saving multiplied by the number of runs, so every surface that shows it also says how the runs were counted:

runs counted by the implementationThe implementation reports each completed run to the platform itself (a signed event per run). Every metered day has counted runs.
runs partly counted, partly estimatedSome days were counted directly and the rest estimated from provider usage; the report says what share was counted.
runs estimated from the provider's request countsNothing was counted directly; runs are the provider's own request counts divided by the calls each run makes.
runs estimated from a typed tokens-per-run figureNothing was counted directly, and the provider reports tokens but not requests, so runs are tokens divided by a tokens-per-run figure someone typed at setup. The figure is shown beside the count; hours saved scale with it.
runs unknown: tokens only, nothing to convert them withTokens were metered but nothing converts them to runs; the run floor cannot be met and no time saved is claimed.

A run is never counted twice: a day with counted runs takes only the count, never the provider estimate on top of it.

Outcomes measured on the work

Some implementations cannot be timed: the people use a tool nobody can instrument, or they stop recording runs. For those, the outcome is measured on the work itself, from the system it lands in (a ticketing tool, a CRM, a document store), as either cycle time per item (elapsed, from the system of record) or items completed per person per period. Every item carries its start and completion times and who did it; nobody is asked anything. This is a different kind of figure from person-time, elapsed time includes waiting, and it is never compared with a timed baseline or turned into hours saved.

A work-level baseline is the same statistic over at least 20 completed items by 2 people before the implementation went live, frozen at commit. A period's figure rests on the items completed by the involved users in that period (5 or more reads as measured, fewer as a thin sample). Because cycle time and throughput also move with staffing, season and the mix of work, the proof report also shows, for reference, the same change for people in the company who did the same work without the tool over the measurement window, counting a month only when that group had at least 2 people in it (otherwise it says "trend only" and why). The reference figure is shown so a reader can judge the difference; it does not adjust the verdict, which judges the involved users' own change against the minimum effect declared at commit. Changes on the work are elapsed time or throughput, not person-time, so they are never given a money value. An item the client's system or an admin withdraws leaves every figure, with the reason kept beside it; nothing is ever edited in place.

Records may also arrive as a file export from the system they live in. An import goes through the same intake and the same checks as a connected source: the platform's assistant proposes which column is which from the column names and a sample of rows, a person approves the mapping and sees the preview before anything is written, and every stored record carries that person's name, the file and the approved mapping as its source. The assistant never writes a figure; it only proposes a mapping, and every proposal is logged with its cost and whether it was accepted as proposed or corrected. A system that sends events to a webhook is held the same way: its first events are kept, not written, until a person has approved the mapping, and an event that no longer fits the mapping is kept for a person rather than written wrong.

All-or-nothing publishing

A published track record shows every committed implementation with its verdict: paying off, net negative, not yet measurable, abandoned. There is no mechanism in the system for excluding an engagement, so a strong page cannot be the result of curation.

Anonymity and consent

Client companies are never named unless they explicitly consent, and that consent is revocable at any time. Everything else appears as anonymized cohort snapshots (implementation type, industry, company size). An industry or company size is named, on a row or in a list, only when at least five client companies in the record share it, so no client can be singled out by it.

What the consultancy cannot do

Who checks the record

Every change to a workspace is appended to a hash-chained log, one chain per company and one per firm, and every verdict and committed goal is fingerprinted onto it. The platform re-verifies every chain and every fingerprint automatically each day and records each check; a failure alerts the operators the same day and is shown here until it is resolved. The most recent check ran on 2026-11-03 (UTC) and found a problem in 0 chains and 1 fingerprint; the operators were alerted and are investigating.

What verification does not mean

The mark verifies measurement, not suitability. It is not an endorsement, a rating, or a ranking; Track AI ROI does not rank consultancies, and no amount of spend changes what a page shows. Whether a firm's record fits your situation is your judgment to make; the mark's job is to guarantee the record is real.