Runbook

Trust and security are part of the payroll product.

Runbook has to earn trust twice: by proving the payroll record and by protecting the people, money, tax data, and approvals inside it.

Wrong checks, late raises, tax notices, mid-year switches, garnishments, and worker questions all collapse into the same practical problem: what happened, why did it happen, and what evidence proves it? Large payroll companies prove trust with scale, security programs, guarantees, and support teams. Runbook needs those operational controls too. The product adds something more direct: a payroll run that can explain itself, a proof packet another party can verify, and a live-funds gate that blocks money movement until the security and operating posture is ready.

Accounting team reviewing records before approval
Trust is the combination of secure operations, clean approvals, and evidence that survives questions.

The trust architecture.

Buyers need familiar security signals and a deeper payroll-specific proof model. Runbook should show both plainly.

Protect private dataWorker PII, tax identifiers, pay history, bank instructions, and employer credentials require scoped access and minimum necessary disclosure.
Control approvalsPayroll approval is an event. Agents propose, humans approve, and every approval needs a durable audit trail.
Prove calculationsEvery material number should trace to source facts, rule snapshots, deterministic calculation, and correction history.
Operate live funds safelyProvider rails, key custody, monitoring, incident response, backups, support escalation, insurance, and security review are live-payroll gates.

Current trust controls

These are already part of the product architecture or repo, not marketing hopes.

Live

Deterministic engine

No AI in payroll math. Runs are priced by code and rule snapshots, with tests guarding invariants.

Live

Integer cents

Money is represented as integer cents end to end, with display conversion only at boundaries.

Live

Bitemporal records

Facts carry effective time and recorded time, so corrections can distinguish what was true from when it was learned.

Live

Quittance verifier

Approved runs can be sealed and independently verified by recomputation, not trust in a dashboard.

Live

Rule provenance gate

Real rule values require ratified or explicitly deferred provenance; demo values must remain labeled.

Live

Agent write boundary

Agents propose documents. Humans confirm. The engine validates. The ledger records.

Engine-supported

Blockchain-like audit trail

Append-only entries, chained digests, public verification, and tamper-evident history without putting payroll data on-chain.

Security controls to engineer before live funds.

These are not marketing badges. They are product gates for payroll, filings, bank data, and worker records.

Control areaCustomer signalEngineering / operations obligation
Access controlOnly the right person can view, approve, change, export, or support payroll data.Role-based permissions, least privilege, advisor scopes, support access policy, session controls, periodic access review.
Audit logEvery sensitive action has a who, what, when, why, and source artifact.Immutable event trail for approvals, imports, exports, bank changes, tax settings, support access, agent proposals, and admin actions.
Data protectionPayroll data stays private even when proof is shared.Encryption in transit/at rest, secret management, key custody and rotation, data minimization, export/deletion workflows.
Money movementFunds do not move unless authorization, funding, settlement, and failure paths are controlled.Provider due diligence, funding authorization evidence, returned ACH/reversal workflow, reconciliation, escalation runbook.
ResiliencePayroll should not depend on wishful uptime.Monitoring, alerting, backup/restore drill, disaster recovery plan, status communication, incident response tabletop.
AI and agentsAI cannot silently change payroll or calculate taxes.Proposal-only writes until approved, deterministic gates, refusal taxonomy, delegated-authority design only after legal/security review.

Claims ledger

These public promises are intentionally ambitious. Each one is a build obligation before general availability.

ClaimStatusBuild obligation
Live payrollBuild obligationPayroll rails integration or provider contract, payroll funding, payment evidence, failure handling.
Tax deposits and filingsBuild obligationProvider contract, filing workflows, reconciliation harness, notice and amendment support.
Money movementBuild obligationBank/provider rails, authorization evidence, returned-payment workflows, support escalation.
Worker self-servicePlannedAuthenticated portal, stubs, W-4 changes, notifications, and explanation surfaces.
Security posturePlanned before live fundsKey custody policy, incident runbook, monitoring, backup/restore drill, security review.

The proof artifact

The Quittance is the core trust object: source events, rule snapshot, calculation, accrued liabilities, settlements, canonical digest, signature, and registry status.

Verify a Quittance
checkDocument structurerequired
checkRecomputation from embedded factsrequired
checkPlatform seal and public keyrequired
checkRegistry entry for existencerequired

A blockchain-like audit trail, without putting payroll on-chain.

Runbook's proof model is blockchain-like where it matters: append-only entries, chained digests, public verification, and tamper-evident history. But payroll data stays private. The blockchain is not the ledger; the ledger is Runbook's bitemporal payroll record. Public anchoring is a future optional witness, not the source of truth.