Commercial terms, companion to version 1.0
VELOCITY ATTRIBUTION RULE
Version 1.0. Published for the same reason the dollar rule is published: a cycle-time claim a customer cannot reproduce from their own timestamps is a claim they will eventually stop believing.
Why time gets its own rule, not a paragraph in the dollar one
Organizational latency and decision velocity are not dollars, and they fail differently. A dollar figure can be wrong by amount. A cycle-time figure is usually wrong by which clock started. Most vendors who claim a speed improvement are comparing a stopwatch that starts when their tool acted against a customer's memory of how long things used to take. That is not a measurement, and this estate does not publish things that are not measurements.
The dollar rule solves attribution with confounder deduction, because money has many causes. Time solves a different problem: which two timestamps are being subtracted, and who logged them. Get that right and the arithmetic is almost boring, which is the point. Boring arithmetic is the kind a customer's own analyst can rerun in a spreadsheet during the sales cycle, before a contract exists.
The two metrics, defined precisely
01 Organizational latency
The elapsed time between a discrepancy becoming detectable (the earliest moment the source records, taken together, already contained enough information to show the disagreement) and the discrepancy being resolved (a decision recorded against it, per the EOS decision record). Detectable, not detected: the clock starts when the evidence existed, not when a person happened to look.
02 Decision velocity
The elapsed time between evidence being ready (a Proof Object or reconciliation pack exists, complete, for the object in question) and a decision being recorded against it, by a named authority. This is narrower than organizational latency: it excludes the time spent finding the problem, and measures only the time spent deciding once the evidence was already in hand.
The four gates
Modeled on the dollar rule's six, narrower because there is less to dispute in a timestamp than in an attribution of cause. A measurement that fails any gate is not published, not shown to the customer as a metric, and not used in any aggregate.
Gate 1 Both timestamps come from a system of record
Not from a person's recollection, not from a meeting note. The start timestamp is the earliest source-record timestamp that, combined with the others, already contained the discrepancy. The end timestamp is the decision record's own timestamp. A time claim resting on someone's memory of when they noticed something is not eligible.
Gate 2 A pre-EOS baseline exists from the same customer
The comparison is never against an industry average, a benchmark study, or a number from a different company. It is that customer's own historical cycle time, on their own comparable discrepancies, before EOS was introduced. No baseline, no improvement claim. Not estimated. Absent.
Gate 3 The comparison is like-for-like
A discrepancy resolved in nine days that would previously have needed a quarterly close to surface is not a nine-day improvement over a quarter; it is a different kind of event, and the rule requires it to be excluded rather than flattered. Only discrepancies of comparable materiality and comparable review path are compared.
Gate 4 The customer confirms which clock started
A named person on the customer side agrees where the start timestamp falls. This is the gate that does the most work, and it exists for the same reason Gate 5 exists in the dollar rule: a cycle-time number produced entirely by the party being paid, about how fast that party's own product is, is not evidence on its own.
Worked example
A purchase-order discrepancy exists across two source systems from the moment the second invoice posts. Historically, at this customer, that class of discrepancy surfaced during the monthly close and was decided within the same cycle.
Source B posts, discrepancy now detectable ......... Day 0 Historical baseline, this customer, this class ...... resolved Day 34 (next close) EOS flags the discrepancy, evidence pack complete ... Day 1 Decision recorded, named authority ................... Day 3 ---------- Organizational latency, this instance ................ 3 days, was 34 Decision velocity component (evidence-ready to decided) 2 days Gate 3 check: comparable materiality and review path .. yes, both required sign-off Gate 4 check: customer confirms Day 0 as the correct start
This is a single instance, clearly labeled as one, not a rate. See below for why a single instance is never presented as a percentage.
What exists today
No pre-EOS baseline exists yet, because figures publish from measured deployments only. There is currently no organizational latency figure, no decision velocity figure, and no average of either, for any customer, published or private. The mechanism above is built, gated, and ready to compute a real number the first time a real baseline exists. Until then this page describes the rule, not a result.
The aggregate question: what "average" will mean, before there is one
The request this rule anticipates is a portfolio statistic: average percent improvement across customers. Publishing that honestly, once it exists, requires deciding the method before the first flattering number arrives and creates pressure to choose a favorable one. Decided now, while there is nothing to gain from the decision:
| Choice | Rule |
|---|---|
| Central tendency | Median, not mean. One exceptional case must not carry the average. |
| Disclosure | Every published average states n, the count it was computed from, in the same sentence. |
| Eligibility | Only measurements that passed all four gates are included. A customer's own disputed or ungated figure is excluded, not floored to zero and counted anyway. |
| Reproducibility | Each customer in the set can independently reproduce their own contribution to the average from their own pinned pack. An average no single customer can check their own piece of is not published. |
| Minimum n | An average computed from fewer than five gated customers is not published as an average. It is disclosed as individual, named-count case evidence, or not at all. |
What is published, and what is not
The same question the Guard Standard answers for tooling and the dollar rule answers for fees applies here: publishing the method is the trust signal; publishing the exact internals is a blueprint for a competitor with none of the discipline. The split:
Published, this page
- Both metric definitions, exactly as measured
- All four gates and what each one excludes
- The aggregation rule: median, disclosed n, minimum five, reproducible per-customer
- That a customer can dispute a start timestamp and the dispute path from the dollar rule applies identically here
Held, not published
- Any specific customer's measured latency or velocity, ever, without that customer's consent
- The internal heuristics that classify two discrepancies as "comparable materiality and review path" for Gate 3, since publishing the exact boundary invites shaping a discrepancy to land on the favorable side of it
- Any complexity-adjustment weighting beyond the raw elapsed time, if one is ever introduced, for the same reason a credit model publishes its factors and not its exact coefficients
- Aggregate figures below the five-customer minimum, under any framing
The dispute path
Identical to the dollar rule's, because a second dispute process would just be a second place for the vendor to be trusted on its own word. The customer challenges a start timestamp in writing. The measurement is reproduced from the pinned pack in front of them. If their reasoning moves the start timestamp, the figure is corrected without argument. Nothing is published while a dispute is open.
The commitment
We will not publish a cycle-time figure without a pre-EOS baseline from that same customer. We will not average fewer than five. We will not let one exceptional case set the average. And until a real baseline exists anywhere, this page states a method, not a metric.