How this kit is checked

The parity run

The arithmetic is written three times. engine/qot_engine.py is Python, works in Decimal, and has no third-party dependencies. The workbook's Excel formulas are the second. The offline spot check is the third, in JavaScript. Three implementations are worth nothing on their own, so one script drives all three from the same inputs and compares them to the same answers.

What that establishes is agreement. Not independence. The next section is about the difference, because it is the whole of the difference between a check and a reassurance.

The test suite holds 90 cases. An internal verification build of the workbook loads every one of them as data, and build/verify_with_libreoffice.py reads that file twice. First with no recalculation at all: the cached results the file carries, which is what a webmail preview or a phone viewer puts on the screen. Then again with every formula recomputed from scratch, which is what Excel does on open. Both readings have to land on the engine's own Decimal, and the build fails if either does not.

The recalculation is the part that needs saying plainly, because it is easy to fake by accident. LibreOffice opens an .xlsx and, left alone, reports whatever results the file already claims its formulas come to. It does not recompute them. So the tool writes a throwaway user profile with OOXMLRecalcMode forced to always and converts the file inside that profile. Without that setting the run would be the workbook agreeing with itself, and it would pass.

Every exception rule the workbook implements fires on exactly the cases the engine fires it on. The Checks summary cell recalculates to zero. Three Checks rows are not zero and are not supposed to be: CK-11 reads 2, CK-20 reads 1 and CK-24 reads 1, all three advisory and all three counting zero toward the summary. The verification file carries those cases because they contain the errors those rules describe, and a check the self-test cannot satisfy is a check somebody eventually switches off. On the shipped sample only CK-20 is non-zero; on the empty customer file none of them is.

“The workbook implements” is doing work in that sentence, so here is the size of it. The Exception Log lists 53 rules. 44 are live in the workbook and are the ones the parity run proves. Eight are engine only: the engine raises them and this file does not. One more, E-405, is raised by neither half, and it is below. Every one of the eight is marked engine only on the sheet, carries a Guards column saying whether it protects a number or is advisory, and prints a plain statement of what its absence costs you. But its In scope and Self-test counts read n/a, because nothing here fires it. Four of the eight still show severity E and blocks output, which is the severity the rule carries in the engine; read the statement, not the severity.

That paragraph used to be something we counted by hand, which is how it came to be wrong. Since 11 September 2026 every code either half of the kit can raise (95 of them) is accounted for in the builder's own source, as a rule here, a row on the Checks sheet, or a deliberate engine-only declaration carrying its reason. The build fails if one is not. Engine-only is a decision somebody made and signed, never an absence a check happened to tolerate.

Three rules have come off that list in the last three builds rather than staying disclosed on it: E-505 on 9 September 2026, E-102 on 10 September and E-205 on 11 September. The rule that decided each, and that we will keep applying, is this: the workbook must never silently substitute a value you did not provide. A substitution you cannot see is a wrong number. Validating a figure you typed is a lower bar, because it is on the screen in front of you.

We then ran that test deliberately against all twelve, rather than waiting to find a fourth after launch. The method was not reading the code: each condition was typed into the shipped workbook the way a licensee would type it, recalculated through LibreOffice, and the Box 12 cell read. Two of the twelve were built. One was not, and it is the one this page owes you. The rest substitute nothing: they validate a figure you typed, are impossible here by construction, or are already intercepted by a live blocking rule, and in two cases the workbook is stricter than the engine and refuses where the engine quietly defaults.

E-205 failed that test and was published here as open on 10 September, before it had a fix. It was built on 11 September. The engine refuses to report for an employee whose status row is missing a field it needs, and the offline spot check has done the same since it was written; the workbook was the only half without it. A blank Pay basis produced a figure with no rule firing at all. That is the plainest version of this defect anywhere in the product, plainer than the one below, which at least said something while saying the wrong thing.

E-502 is the only one of them whose absence can still cost you a number, and it stays engine-only for this edition on the rule above: it bounds a section 207(j) or 207(k) premium you entered and can read, rather than one this file made up. Where that cell is left blank, both halves fall back to the same figure: the premium on your own pay lines.

And the sweep is now a gate rather than an afternoon. Three defects of one kind were found here one at a time, each by a reader. The method that missed all three for a month was reading formulas; the method that found them was typing the condition into the built workbook and recalculating it. That is now the fifteenth thing every build has to pass: every input where the engine refuses to report because something is missing is typed into the shipped file, recalculated, and required to come back blocked and with no figure — blocked as well as empty, because a number that quietly does not appear is its own kind of wrong. A control employee with nothing missing has to come back with a figure, so a workbook that refused everything could not pass. Add a blocking rule to the engine and the gate fails until somebody says what this file does about it.

It found two more things the moment it first ran, neither of which anyone had reported. E-202, a qualified amount with no pay date, which the engine blocks, could not fire at all, because it tested the pay year against zero and the year of an empty date is 1900. The week produced no figure and said nothing about why. And E-405, a rule listed on the Exception Log as engine-only, turned out to be raised by neither half: it is impossible by construction in both, which is a fine answer, but not the one the sheet was giving. Both are fixed, and both are here because a gate that only ever confirms what you already believed is not a gate.

Three of the twelve rows are shown; the run prints all twelve. The other thirteen engine blocking rules are declared in the same file as not a missing input, each carrying the reason it is not one: a duplicate, a value out of range, a scope refusal. The gate fails if a blocking rule is neither probed nor declared, and that is the part meant to outlast us: the next blocking rule somebody adds to the engine breaks the build until somebody has said what this file does about it.

The verification build carries 118,305 formula cells. 111,201 ship carrying their real computed result; the remaining 7,104 are formulas whose result is an empty string, a row that does not apply or a column that stays blank until you fill it, so there is nothing to cache. Of the cached results, 4,589 are checked against the engine: every cell it holds a Decimal for.

The spot check is driven the same way, through its own page in headless Chromium. It is a single-employee, single-workweek tool, so it cannot express every case. It matches on the 65 it can, to the cent, including the severity codes raised and the eligibility verdict. The 25 it cannot are each printed with the reason: a deferred bonus spanning a quarter, a second employee on the same file, a pay date in the following tax year. None is quietly dropped. That run also counts the page's network requests after load. There are none.

Why agreement is not enough

Implementations that share a misreading of the specification agree with each other and are still wrong. Comparing them cannot find it. The thing each is being measured against is the others, and they are all reading the same sentence the same wrong way.

That is not a hypothetical, and the example is ours. Section 4.2 of the calculation spec said the includable straight-time figure includes TIPC lines, meaning the tip-credit memo lines. All three implementations read it that way, so all three agreed. The reading is wrong: 29 CFR 531.59(b) allows the credit only for hours worked in an occupation in which the employee qualifies as a tipped employee, so a tipped employee whose whole week was worked in the non-tipped job correctly has no such line at all. The check built on that sentence fired at error severity on weeks that were computed correctly, and stayed silent on the dual-job week where the premium really had been taken on the cash wage alone. Every parity run was green the entire time. It was found by someone reading the regulation.

So the published examples do work the parity run cannot do. They are arithmetic we did not write, published by the agencies whose rules the kit implements, with the answer printed beside the facts.

The last row is not a published example and this page will not call it one. 29 CFR 531.60 publishes no worked example. It states a rule: a tipped employee's regular rate includes the tip credit the employer takes, capped at the section 6(a)(1) minimum wage less the cash wage paid. The $2.13 cash wage is printed verbatim in 531.59 and 531.60. The $5.12 credit is printed in no statute or regulation. It is that formula's own product, given the $7.25 minimum wage at 29 USC 206(a)(1)(C). Apply the rule and the regular rate is $7.25, not $2.13, and ten overtime hours carry $36.25 of qualified premium. Computing that premium on the cash wage instead is the most common error in this category. The derivation is recorded as assumption A12 in params/ty2026.json, and the rules PDF labels the figure derived rather than published.

One penny of disagreement

29 CFR 778.114(b)(1) illustrates the fluctuating workweek: a $600 salary, and a second week of 44 hours. The regulation's own arithmetic rounds that week's regular rate to $13.64 before halving it, and prints a premium of $27.28. At full precision the rate is 600 divided by 44, which is $13.636363…, and the premium is $27.27.

The engine never rounds the regular rate. On those facts it computes $27.27 and reports $27.28, because the $27.28 the employer paid falls inside the $0.05 operational tolerance the kit ships with, and a premium inside the band is the figure taken. Set the tolerance to zero and the reported figure is $27.27. So the kit arrives at the regulation's number at the shipped setting without computing it, the two readings are a penny apart underneath, and this page will not say the kit reproduces 778.114(b)(1) to the penny — nor will any other page we publish, because that is a claim a careful reader would take apart with a calculator in about a minute. It is accurate for FS-2026-13 Q16 and for 29 CFR 778.110, which reproduce exactly. It is not accurate here.

What changed on 8 September 2026 is not the number. It is what the kit says about the employer who paid $27.28.

Until then, the two figures were reconciled through the operational tolerance: $0.05 per component, so the paid figure fell inside the band and governed. A review pass went looking for where that stops working, and found it. The regular rate is never rounded is the kit's rule, not the regulation's. 29 CFR 778.109 defines the rate as a division and says nothing about precision. Its neighbors round: 778.113(a) prints a $375 salary for a 40-hour week as $9.38 an hour, not $9.375, and all three of the 778.114(b) illustrations compute the premium on a rate rounded to the cent. In the third of them the rate rounds down — $700 over 48 hours is $14.583…, printed as $14.58 — and the premium the regulation prints, $58.32, is a cent below the exact half-time amount of $58.33.

An employer whose payroll rounds the rate to the cent is therefore doing what DOL's own published illustrations do, and its premium is lawful. The kit was calling that an exception. At a $0.00 tolerance, which is a permitted setting, it flagged all three 778.114(b) illustrations — and the third one, where the regulation's premium is a cent short of full precision, as a possible FLSA underpayment. Above that, the tolerance held only because the gap is small: it grows with overtime hours, and from a 59-hour week up it clears $0.05 and the flags come back. On a grid of weekly salaries from $290 to $2,000 and weeks of 41 to 80 hours there are 9,353 combinations where a payroll following the regulation lands outside the band.

All 9,353 are now clean. The engine carries a second figure beside the requirement: the same premium computed on the rate rounded half-up to the cent. Where the premium paid matches it, the week is recognized as compliant on its own row (I-705 in the engine, check C-48, rule I-C48 in the workbook) instead of drawing a shortfall warning or a non-FLSA excess. The tolerance was not widened; the same band is applied to a second lawful requirement, and the tolerance goes back to doing only the job it was documented for. Assumption A14 in params/ty2026.json records the whole of it, with the regulation's four illustrations and their arithmetic in both directions.

The reported figure did not move. That was the constraint the fix was written under, and it is asserted rather than promised. On the rows this path touches (the ones outside the operational tolerance, where the flag used to be raised), the kit reports min(required, paid) measured on the unrounded requirement, which is the smaller of the two lawful readings and the amount FS-2026-13 Q16 calls minimally necessary. Inside the tolerance nothing about the reported figure changed either: there the premium paid is the figure taken, which is why the 778.114(b)(1) week above reports $27.28 and not $27.27. Every weekly figure across a quarter of a million salary-and-hours-and-premium combinations, at three tolerance settings, is identical to what the engine reported before the change. Only the flag is different. A reader who follows the regulation is no longer told they overpaid.

The workweek you told it about, which it was throwing away

Status History has a column headed Workweek starts, and under it the words “overrides the employer default”. Until 10 September 2026 nothing in the workbook read that column. Its only appearance in the whole builder was its own definition. Every workweek was built on the employer-wide value from Client Setup, and what a licensee typed on the status row was discarded without a word. The employer-level Workweek start time beside it had no name to be read by at all.

It does not take an unusual payroll to bite. One status row saying WED against a Client Setup default of SUN is enough, and which way it breaks depends only on which day the weeks you entered happen to start. If they start Wednesday, as they would, the engine computes the figure and the workbook raised an error against a perfectly valid week and blocked. If they start Sunday, the engine blocks and the workbook reports. Neither is a number worth having. The start day decides which hours fall in which workweek, and therefore how much overtime is in each.

It is honored now, with a start-time column beside it so this file can express exactly what the engine can. And with the definition finally visible, E-102 can do its job: where an employee's workweek definition changes during the year, 29 CFR 778.301-.302 requires the overlap week to be computed on both definitions and the employee paid whichever is more. Neither half of the kit performs that computation, so the employee is blocked rather than reported on whichever definition happened to win. Two live self-test cases hold it: T50a, a genuine Wednesday workweek, which the workbook wrongly blocked before this release, and T50b, the mid-year change, which it now blocks correctly.

The build refused to produce a file the moment T50a was added, before a line of the fix was written. That is the parity run earning its keep: a case that pins the engine's answer turns a silent disagreement into a failed build.

The one where disclosure was not enough

E-505 is the rule for a tipped employee with no applicable minimum wage on file. A tipped employee's credit is normally sized to bring the regular rate to exactly the governing minimum, so a rate sitting on the federal $7.25 while the employer computed its own overtime premium on a higher rate is evidence that a higher state minimum governs and was never entered. It is not proof — the other reading is a voluntary premium, which FS-2026-13 Q16 says does not qualify at all — and 29 CFR 778.109 makes the regular rate remuneration divided by hours worked, so the missing input cannot be recovered from what was paid. The engine withholds the week rather than guess.

Until 9 September 2026 the workbook did the opposite, and this page did not say so. It substituted the federal minimum for the blank cell and reported a figure computed on it. On DOL's own Field Operations Handbook scenario 4 — 45 hours, cash wage $3.35, credit $3.90, premium paid $25.00 — it reported $18.13 where the answer with the $10.00 state minimum on file is $25.00, and logged the $6.88 difference under I-703.

It was disclosed. The Exception Log carried an E-505 row saying, in as many words, that leaving the cell blank would understate the premium. That was judged enough, and it was not. We typed the scenario into the shipped file and recalculated it: every Checks row came back zero, the summary cell zero, the employee not blocked, Box 12 reading $18.13. Exactly one rule fired on the data: I-703, severity information. Its message said the excess was “state, CBA, double-time or voluntary pay”. That is not a missing signal. It is a confident statement of the wrong cause, on a row a reader has every reason to believe. A disclosure that lives only in a static row nobody has a reason to open is not a disclosure, and the file's own standard (an error row that is not an error teaches you to ignore error rows) cuts the same way in the other direction.

So the rule is built. The workbook now blocks that employee, reports no Box 12 figure, and shows the rate the premium implies as a hint for filling the cell in. Nothing is computed on that hint, in either half of the kit. Two live self-test cases hold it: T49a is DOL's scenario with the cell blank and must be withheld, T49b is the same week with $10.00 on file and must produce DOL's $25.00. The parity run proves E-505 fires on the first and on nothing else. A blocking rule with no sibling proving it stays quiet is a rule nobody can tell is too wide, and a rule that suppresses a figure for an employee who should have had one is a worse failure than the one it fixes.

I-703 is reworded in the same release, everywhere it appears. It now states what the figures show — the premium paid exceeds what section 7 required on the regular rate computed here — and names the inputs that could produce that, including a regular rate that came out too low. It no longer tells you the employer chose to overpay. It could not know that.

The source evidence

Every constant in params/ty2026.json carries a citation, and params/SOURCES.md logs the documents behind those citations with the host each came from and the date. It is a retrieval log, not a complete index: the Department of Labor's Field Operations Handbook is cited in the constants file and has no row in it at all. A list like that is worth very little on its own, so each URL in it has to carry a capture row in params/source-evidence.tsv: the SHA-256 of the bytes the server returned, how many bytes there were, the status, the UTC timestamp, and a literal span from the document that had to be present in those bytes for the fetch to count. tools/verify_sources.py fails the build if a cited URL has no such row. It needs no network and runs in under a second, so it can sit in front of every release.

Why there is a probe at all

Because of that row, and the day it nearly did not exist.

26 USC 225 is the section this entire product rests on. It was originally fetched from the URL form used for every one of its sibling sections, the one ending &num=0&edition=prelim. On 7 September 2026 that form returned HTTP 200 for section 225 and served the site's edition-picker furniture with no statutory text in it at all: 73 KB of page, and not one word of the law. Eight sibling sections fetched through the identical pattern returned their full text. curl exited 0. The status was 200. The response was long. Every check that asks whether the fetch worked passed, and the source line for the most important section in the kit was resting on a page that did not contain it.

It was caught by reading the fetched bytes. The fix is in the manifest above: a status code is not evidence, and a probe is. A row whose probe span is absent from the bytes is a failed fetch whatever the server said. The f=treesort form of the URL does return the section, that is the form the manifest records, and the span it must carry is 225(b)'s own dollar limit.

One thing to be straight about, since a reader may go and check. Re-fetched while this page was being written, the old sibling-pattern URL does return section 225: three requests, 153,451 to 153,551 bytes each, the probe span present in all three. The empty response is not reproducible on demand. That is the case for the probe rather than against it. A gate that only catches failures you can summon back on request is a gate that catches nothing, and the next one of these will not be a page of the wrong kind. It will be the right kind of page carrying the wrong edition.

What a re-fetch does and does not prove

Re-run the online check and most of the 59 fetched rows come back byte-identical, hash and all. Some do not, and the count moves every time it is run: on 9 September 2026, when the log held 39 fetched rows, it was 27 identical and 12 changed; on 12 September, from the same captures, 24 and 15; and on 20 September, against the 59, 41 and 18. None of those rows has changed. uscode.house.gov and dol.gov build a page per request, so the byte count drifts by a few dozen and the hash goes with it, and the longer ago a row was captured the more likely it has drifted. The number below is one dated run, not a figure you should expect to reproduce. What holds on all 59, on every run, is the probe.

So a reader can re-fetch any of the 59 and confirm it still says what we quoted from it. A reader should not expect every hash to match, and the only column worth reading as a pass or a failure is probe gone, which is zero. We would rather print the drift than let a matching hash be assumed. It is a check on the documents. It is not a claim that any individual constant was read off a retained copy of that particular fetch, and it is not a claim about editions: a probe can tell you a document of the right kind was at that URL, and it cannot tell a revised fact sheet from the one we read. That limit is finding F7 below and it is still open.

The sixtieth row, which is not a fetch

Ohio's 2026 minimum wage is $11.00, and $5.50 for tipped employees, for businesses with annual gross receipts over $405,000. Those figures drive sample SMP-03, an Ohio server, so they steer a worked example a buyer reads and they owe the same evidence as any constant. The build machine cannot fetch them. Its network policy refuses com.ohio.gov outright, answering the connection with a 403 before any bytes exist to hash.

The row is written anyway, and it says on its face what it is. Its sha256 is a dash. Its http field reads attested and so does probe_found, and a note records who read the document, when, what it said, and why no fetch was possible from here. Every run of the gate prints the attested rows in a block of their own, by name, so the weaker grade cannot be counted in with the stronger one.

The difference matters and it is not a formality. A capture row is bytes somebody else can pull down and hash for themselves. An attested row is a person's word, with the reason attached. Two Department of Labor tables that this machine can reach carry the same Ohio figures and are captured in the normal way, which corroborates everything except the 1 January 2026 effective date. That date rests on the state's own release and on nothing else, and now you know it.

The review that was run against us

Before the edition was cut, the kit went through an adversarial review. The reviewer read the specification and the primary sources, rebuilt every artifact from a bare container, and then tried to break it. The engagement was report-only: nothing in engine/, params/ or the build was changed by the review itself, and the six tests that captured its findings were merged into the repository failing, on purpose, so that no fix could be waved through without them going green on their own terms.

Its verdict, in its own words: the build holds; the law does not, in two places. Both were found by reading 29 CFR 778.5, the Department of Labor's Field Operations Handbook and FS-2026-13 Q18. Neither could have been found by comparing implementations, which is the argument of the second section of this page arriving with a bill attached.

The first: a tipped employee in any state whose minimum wage exceeds $7.25 was understated or refused a figure altogether. 778.5 says the FLSA regular rate cannot be lower than a higher applicable minimum, and the kit computed on $7.25. At a $10.00 state minimum that is a 27.5% understatement of code TT, and it reached a sample the kit ships: SMP-03 is an Ohio server citing 778.5 as its governing rule and then computing as though Ohio were a federal-minimum state. The second: comp time. FS-2026-13 Q18 states the qualified amount as the hours times the applicable rate divided by three, and the kit divided by the accrual rate, which is a 25% difference at a 2.0 accrual for a state or local government client with such an agreement.

The first is fixed. The second is half fixed, and the half that is not is the more useful thing to publish. Q18's own worked example fixes the accrual at one and one-half hours and names no other rate, and at 1.5 the FAQ's divisor and the kit's are the same arithmetic, so the FAQ is not authority for the case where they differ. The kit kept its reading. What it did not have, and now does, is assumption A13 recording the divergence in writing, with FS-2026-13's own reliance language, and I-905 printing the FAQ's figure beside the kit's on the exception log. A buyer following the IRS's published formula gets both numbers and can decide.

Two of the review's six tests no longer assert what the review asserted, and that is the sentence in this section most worth reading skeptically, so here is what changed and why. Where no applicable minimum wage is on file, the review asked the engine to infer the governing rate from the premium the employer chose to pay. It does not, because 29 CFR 778.109 makes the regular rate remuneration divided by hours worked — a computed fact, with the governing minimum wage an input to that division and never an output of it — and FS-2026-13 Q16 settles what an over-payment means: an employer who pays double time on a $20.00 rate has still had only $100.00 required of it. The engine now withholds that week under E-505 and names the implied rate as a hint, instead of reporting a figure that rests on a fact the file does not carry. The other changed test is the comp-time divisor above. Both arguments are written into the test docstrings, so they are read by anyone who runs the suite.

One finding is open and printed above as open: F7, the limit of what a capture hash can prove about a document's edition. F9 is not a defect but a bounded design choice, printed as one. Publishing them costs us something. It is still the cheapest way to tell you what kind of document this is.

F8 and F10 were open when this page was first published, and were closed on 8 September 2026 by a second review pass that read the sections behind them in full. Both are worth reading as a pair, because they went opposite ways. F8 found the kit being stricter than the regulation and flagging lawful payrolls: fixed, by accepting the regulation's own arithmetic as a second lawful requirement, with the reported figure held fixed and asserted so. F10's C-22 found the kit asserting a state rule it could not source: it warned about daily overtime above eight hours in a week, and the two halves of the kit did not even test the same condition. Eight hours is the daily threshold in some of the four states the check was written for and not in others, and each of the four attaches conditions to its daily rule that a payroll register does not carry. Nothing was narrowed or re-derived from second-hand text: every Colorado and Nevada primary source is unreachable from the build container, so the check was removed, its id retired, and state daily overtime recorded as out of scope for this edition. A check that cannot be sourced is worse than no check.

Check it yourself

The spot check is live and free, at tieoutpress.com/spot-check.html. One employee, one workweek, about two minutes, nothing to fill in first and no form anywhere on it. It is the third implementation described at the top of this page, so the 65 cases in the parity run are 65 cases of it agreeing with the engine you would be buying. Put FS-2026-13 Q16's facts into it and see whether $100.00 comes back.

If you build or configure payroll software. Everything the kit computes can be compared with from the free files, and an implementer is welcome to do that. Four of the five published examples are in the table under "Why agreement is not enough," each with its source in the first column. The fifth, 29 CFR 778.114(b)(1), is worked through under "One penny of disagreement." The twelve worked answers and their key are on the kit's page, downloadable with no email wall. The spot check takes one employee and one workweek at a time. Where your figure differs from ours, write to support@tieoutpress.com with FIGURE CHECK at the start of the subject line, the workweek's inputs with invented names and amounts, and both figures; those messages are read first. A difference is a finding about a reading of the rule, and it is answered by pointing at the source. This page records what the kit computes and how that was checked. It says nothing about what any vendor's software does: no vendor's output has been compared here, and nothing on this site tests or ranks a payroll product.

What the kit is, what it costs and what its license permits are set out on the kit's own page. The TY2026 edition has been released, the workbook is at 1.0.2 under the tag ty2026-v1.0.2, and the store is open: any of the three licenses can be bought from the price table on that page. Version 1.0.2 changes no figure. It packs the license and a README into every download and moves the paid download's constants file to params/ty2026.json. It also rewrites the About sheet's sentence on the parity run to the counts the parity run above reports, where it said all 90 cases were compared to the cent. The workbook's Version sheet records each. This page exists so that you can decide whether the method is any good before you buy.