Built, not switched on
Eleven modules with no production caller. Here they are by name.
This is the part of the site we would remove if we were selling harder. It is here because the characteristic dishonesty of a technical product page is to describe a green test suite as a working feature, and this codebase has eleven places where that temptation exists.
Every module below is written, is covered by tests, and is imported by nothing outside its own siblings and its own test files. None is reachable from any API route. That was checked the same way for each one, and it is a source-level claim: the only files importing them are their own siblings and their own tests, and none is imported anywhere under the application tree.
The single most important sentence on this site
Nothing in production writes a pay run.
Five payroll tables exist in the database with row-level security on them. The module that would create a payroll run is in the table below. So nothing in production writes a pay run — which means the employee self-service views and the quarterly return read correctly-wired tables that have no producer. They are built. They are walled. They will return an honest empty result until a run writer exists.
There is a second absence with the same shape, and it is not in the table because it is not a module — it is a missing write path. The payroll surfaces persist nothing. The wired calculation routes say so in their own header, in those words. The self-service lane goes one step further: its repository exposes five read methods and no write method at all, so a W-4, a direct-deposit election or an address submitted by an employee is validated, masked, audited and returned, and then it is gone.
Read the rest of this site with that in mind. Everything on it is arithmetic and access control, both of which are real. None of it is storage.
The eleven
What each one does, and why it is not reachable.
The middle column is what the module actually does — these are not stubs, and several of them are the most carefully written code in the category. The right column is the honest reason it does not run, said without spin.
| Module | What it does | Why it is not reachable |
|---|---|---|
| Payroll run workflow | The whole run lifecycle — assemble, review, approve, post, disburse, void — plus the register content hash the four-eyes approval binds to. | Nothing under apps/ imports it. This is the module that would write a pay run, and its absence is why the pay tables have no producer. |
| W-2 / W-3 / SSA EFW2 e-file | Builds the W-2 and W-3 figures and the fixed-width EFW2 records the Social Security Administration accepts, and verifies them. | No production caller. The three-way reconcile (which IS reachable) proves a filing set agrees; this module, which would produce the actual file, is not wired. |
| Form 940 FUTA and the annual 941 set | The federal unemployment return and the full-year 941 assembly. | No production caller. The single-quarter 941 build is reachable; these two siblings are not. |
| Run reversal and off-cycle runs | Builds a reversing run and assembles an off-cycle run. | No production caller. It reverses a run that nothing can currently create. |
| Payroll audit hash-chain ledger | Appends run-lifecycle events to an append-only hash chain and verifies the chain end to end. | No production caller. The self-service change lane computes its own chain event on each request, but nothing stores it and its verifier has no production caller either, so neither chain is a working audit log today. |
| General-ledger posting and labor distribution | Builds and posts the payroll accrual entry and distributes labor cost across accounts. | No production caller. Its gate suite proves the entry balances; nothing calls it. |
| Year-to-date accumulator | Applies YTD postings idempotently, tracks wage-base caps and the elective-deferral headroom, and builds reversal postings. | No production caller. The FICA engine takes YTD wages as a supplied input instead. |
| SME-signed tax-table registry | Holds effective-dated, signed withholding tables and resolves the one that applies, holding on no table, an ambiguous overlap, an unsigned table or a malformed one. | No production caller yet. The withholding engines take a supplied table directly. The registry is the framework that would govern them. |
| Payroll AI corridor | The grounding wall for an assistant that answers questions about pay: self lane filtered to the viewer's own rows, and SSN, bank routing, account number, direct deposit and tax id never admitted to the grounding set at all — not even for an HR administrator. | No production caller. There is no assistant wired to payroll data, which is the safest possible state for it to be in. |
| Timesheet to earnings | Converts timesheet entries into earning lines. | No production caller. Its siblings in the same file (the run preview, hourly and salary earning helpers) are reachable; this one is not. |
| Onboarding workflow | The new-hire onboarding task model. | No production caller. The hiring decision and the persisted employee record are reachable; the onboarding sequence between them is not. |
How “no production caller” was established
The check, stated so you can repeat it.
“Not reachable” is a claim about an import graph, and a claim about an import graph is worth exactly as much as the search that produced it. So here is the one that produced this table, in enough detail to be repeated or refuted.
For each module: find every file that imports it, and classify. A module qualifies for this table when the only importers are its own siblings in the same package and its own test files — that is, nothing under the application tree imports it, so no registered route can reach it however many layers of indirection you follow.
The same discipline applied to the write path, and this is the part worth copying if you audit your own systems. The question “does anything store a pay run” was answered by searching for insert and update statements against the pay-stub, pay-run and year-to-date tables across the whole application and package tree. The search returned exactly one file, and it is an integration test that seeds its own fixture rows. The positive control is the point: the same pattern DOES match inside that test, which proves the search can match — so the zero everywhere else is a demonstrated absence rather than a broken query. A search that returns nothing everywhere, including where the thing exists, has told you nothing at all.
Two honest bounds on the method itself. It is a source-level claim: it says nothing about a deployment where somebody has wired a caller we cannot see. And it is a claim about today: if one of these modules gets a caller, this table shrinks, and the page changes rather than the table quietly staying up.
They are not eleven independent gaps
One missing module accounts for most of this table.
Read the eleven as a list and they look like eleven separate pieces of unfinished work. They are not. Most of the table is downstream of a single absence, and saying which one is more useful than any individual row.
The payroll run workflow is the keystone. It is the module that would assemble, review, approve, post and void a run — and therefore the module that would WRITE a pay run. Nothing under the application tree imports it. Five payroll tables sit in the database with row-level security on them and no producer, because the producer is this module.
Follow the consequences out. Run reversal and off-cycle runs reverses a run that nothing can currently create. The year-to-date accumulator applies postings from runs that are not posted. General-ledger posting and labor distribution posts an accrual for a run that does not exist. The audit hash-chain ledger appends run-lifecycle events for a lifecycle nothing enters. And the two surfaces that ARE reachable but return nothing — employee self-service and the quarterly 941 — read the tables this module would fill.
So the honest shape of the gap is not “eleven things are missing.” It is: one keystone module is unwired, four modules in this table are its immediate dependents, and two working surfaces are starved by it. The remaining rows are genuinely independent — the e-file builder, the FUTA return and the annual 941 set, the signed tax-table registry, the AI grounding corridor, the timesheet converter and the onboarding sequence — and each has its own reason on the row.
We say it this way because a list of eleven invites the reader to guess at how much work is left, and the guess is usually wrong in one direction or the other. The structure is more informative than the count, and it is also more falsifiable: if the keystone lands and this table does not shrink, we were wrong about the shape and the page will say so.
Twelve gates, sixty-two tests
What a passing suite proves, and what it cannot.
Twelve gate suites cover the payroll engines and they run green: sixty-two tests across twelve files, run before this page was written. That number is a measurement rather than a target, and it is the only measurement quoted anywhere on this site.
The bound matters as much as the result. A green suite proves a function computes the right answer. It says nothing whatever about whether anything calls that function. Five of the twelve exercise a module from the table above — and because the two lists sit in different sections on the home page, that has only ever been stated as a count. Here it is as a list.
| Gate | What it proves | The module it exercises |
|---|---|---|
| Gate 07 · GL balance | The payroll accrual entry balances. | → General-ledger posting and labor distribution — no production caller |
| Gate 08 · YTD idempotency and caps | Re-applying a posting changes nothing; wage-base caps hold. | → Year-to-date accumulator — no production caller |
| Gate 10 · Audit hash-chain | A back-dated edit breaks the chain and is detected. | → Payroll audit hash-chain ledger — no production caller |
| Gate 11 · Run-workflow lifecycle | The run states advance only in the legal order. | → Payroll run workflow — no production caller |
| Gate 12 · Reversal round-trip | A reversal returns the register to its prior position exactly. | → Run reversal and off-cycle runs — no production caller |
Gate 10 is the sharpest example in the set. It proves that a back-dated edit breaks a hash chain and reports the index where it broke. The arithmetic is genuinely correct. And nothing in production keeps a chain for it to protect: the change lane computes an event per request and stores none of them, the verifier that would walk a chain has no production caller, and the chain position arrives as a request parameter defaulting to genesis, so there is no server-held head. Tamper-evidence is a property of a stored chain. We do not store one, so we do not claim one.
The other seven
The gates that exercise something a handler actually calls.
These seven test modules that a registered API handler reaches. That is a stronger position than the five above, and it is still only a statement about the arithmetic — it says nothing about whether the surface has been run against a production database.
Why publish this at all
Because the alternative is that you find out in a pilot.
A page like this costs something. It is the section a buyer screenshots. We publish it because the failure mode it prevents is much worse than the objection it raises: a green test suite described as a working feature is a claim that survives a demo, survives procurement, and fails in week two of a pilot, at which point the thing that is damaged is not the feature.
It is also the only way the rest of the site means anything. If we did not name the eleven, then “the engines are built and covered” would be a sentence you would have to take on trust. With the eleven named, it is a sentence you can check — the ones we claim are reachable are claimed by file name, and the ones that are not are listed above by name.
If you are looking for the part of this product that is finished rather than proven, it is the hiring and HR records lane: job postings, applications, employee records, staff credentials and leave all have real persistence behind them, through the canonical repository. It is described on the engines page, and it is the one lane in this whole category that writes.
Where to go next
The rest of this site.
Every page here is its own argument rather than a restatement of the home page. If you would rather ask a person, the address below reaches one.