▸ proof · attestation · published June 2, 2026 · v2.0.0
No field-operations incumbent lets you independently check its claims. STEADYWRK does. Every public number — the 90% completion rate, the <2hr target quote target, the 3% human-override rate — reads from one canonical source, and the build breaks if any page shows a figure that drifts from it.
That is consistency and anti-drift you can re-check — not an independent audit. The eval figures are self-reported and estimated from our own production telemetry. The honest, harder flex is below: every metric’s exact provenance, the gates that enforce it, and the public ledger of what we retracted.
curl https://steadywrk.app/api/health▸ the provenance ledger
Each row is a number we publish, the exact key path it reads from in apps/web/src/data/canonical-metrics.ts, the build gate that backstops it, and a live, no-auth surface where you can re-pull it. Consistency comes first from architecture — nothing is hand-typed; every surface imports the same constant, so the prose and the data cannot diverge. The gate is the second line: it fails the build if a retired claim ever reappears.
| Metric | Published value | Canonical source (key path) | Build gate | Verify live |
|---|---|---|---|---|
| Completion rate | 90% | CANONICAL_METRICS.formatted.completionRatePct | verify:metrics | /api/public/dispatch-metrics |
| Quote turnaround | <2hr target | CANONICAL_METRICS.formatted.quoteTurnaround | verify:metrics | /proof |
| Coverage | Multi-State | CANONICAL_METRICS.formatted.activeStates | verify:metrics | /api/public/dispatch-metrics |
| Contractor network | Vetted contractor network | CANONICAL_METRICS.formatted.activeProviders | verify:metrics | /proof |
| AI agents in production | 12 AI agents | CANONICAL_METRICS.formatted.aiAgents | verify:metrics | /proof/autonomous-operations |
| Production posture | Active production | CANONICAL_METRICS.formatted.jobsDispatched30d | verify:metrics + audit:opsec | /api/public/dispatch-metrics |
| Customer tier | Enterprise FM portfolios — names withheld by mutual NDA | CANONICAL_METRICS.formatted.customerTier | verify:metrics + audit:opsec | /proof |
| Human-override rate | 3% | CANONICAL_METRICS.evals.humanOverrideRate | verify:metrics | /evals |
| NTE variance | ±9% | CANONICAL_METRICS.evals.nteVariance | verify:metrics | /evals |
| Dispatch latency (p50 / p95) | 340ms / 890ms | CANONICAL_METRICS.evals.dispatchLatencyP50 / .dispatchLatencyP95 | verify:metrics | /evals |
| Canonical registry version | v2.0.0 | CANONICAL_METRICS_VERSION | verify:metrics | /api/health |
▸ the integrity machinery
The ledger above is only as good as what enforces it. These are the real, named checks in the repository. Three are wired into the deploy gate and fail the build; one is an advisory pre-ship sweep. We mark which is which rather than imply they all block a release.
$ npm run verify:metricsScans every public-surface file and fails the build if any retired (struck) claim appears anywhere outside the canonical registry. This is what makes a retraction stick — once a claim is struck, the gate blocks it from reappearing on any page.
source: scripts/verify-metrics.ts
$ npm run audit:opsecSweeps public pages and components for operationally-sensitive pre-images — partner brand names, retired counts, internal phrasing — and fails the build on any high-severity (P0) or blocklisted hit.
source: scripts/audit-opsec.ts
$ npm run ops:claim-guardAn advisory sweep over source and built output for unprovable compliance and vendor-relationship strings, plus private-repo links. Run as a pre-ship review check rather than wired into the deploy gate.
source: scripts/ops/public-claim-guard.mjs
$ npm run phase:gateThe composite deploy gate: typecheck, lint, build, verify:metrics, audit:opsec, a live /api/health probe, and a deploy-drift check that the shipped commit matches main. Every passing phase writes an append-only receipt.
source: scripts/phase-gate.sh
▸ audit receipts
When the composite gate passes, the build pipeline writes an append-only receipt — the phase, the timestamp, the gate result, the build hash, and the registry version it ran against. The receipts are regenerated on every deploy and the public subset is listed in full on the audit log.
▸ the retraction ledger
The hardest trust signal a vendor can give is the one it walked back. Each claim below is a number STEADYWRK once published and then decided it could not stand behind on a verbatim-liftable page. They are retired, struck, and blocked by the build gate from reappearing — shown here only to account for them. 13 forbidden claims are enforced in total; 6 numeric retractions are annotated below.
A specific work-order count was operationally sensitive and reverse-engineerable.
Same dispatched-volume figure under a second phrasing — retired with the first.
A precise network-size count we would not stand behind on a verbatim-liftable page.
A reach figure that implied a verified roster we cannot independently attest.
A customer-footprint claim that named a scale we could not evidence per account.
A market-size figure with no first-party source — a borrowed number, not our own.
▸ roadmap · cryptographic attestation
Today the receipts are append-only and build-stamped — tamper-evident by deploy history, not by signature. The next step is a detached cryptographic signature over each receipt, verifiable by any third party against a published key, so trust does not rest on us alone.
pending · requires a dedicated signing key
Signing is intentionally not enabled in this build. It needs a dedicated signing key held outside the repository; no key is committed and no signature is faked. When the key is provisioned, each receipt will carry a verifiable signature and this section will document the verification command — the same “check it yourself” standard as the rest of this page.
▸ methodology
One source. Every public metric reads from a single canonical registry (apps/web/src/data/canonical-metrics.ts, v2.0.0). The same registry feeds this page, the live /evals dashboard, and the public JSON endpoints — so the prose and the data cannot disagree.
Consistency, not certification.What is verifiable here is that every number traces to one source and the build breaks on drift. The eval figures are self-reported and estimated from STEADYWRK’s production telemetry — not an independently audited third-party benchmark. We publish the discipline honestly; we do not claim an auditor signed off on the values.
Dated and versioned. This page is current as of June 2, 2026. When a metric’s definition changes, the registry version (v2.0.0) changes with it, so a citation can pin exactly what it cited.
Source is private; surfaces are public. The repository is private, so source files are named here as paths, not links. What is public and re-checkable are the live surfaces: the audit log, the health probe, and the evals endpoint.
companion proof surfaces
▸ questions, answered
Every public metric reads from a single canonical registry (apps/web/src/data/canonical-metrics.ts, v2.0.0). A build gate, verify:metrics, fails the deploy if any page shows a number that does not match the registry, or hardcodes one instead of importing it. The same registry feeds the live, no-auth surfaces — /api/public/dispatch-metrics, /evals, and /api/health — so the marketing copy and the live JSON cannot disagree. That is consistency and anti-drift you can re-check yourself, not a number you have to take on faith.
No. The eval figures are self-reported and estimated from STEADYWRK’s own production telemetry (the registry marks them estimated). What is independently checkable is the integrity machinery: that every published number traces to one source, that the build breaks on drift, and that retracted claims are logged publicly. The flex is the discipline, stated honestly — not an auditor’s stamp.
STEADYWRK keeps a public ledger of claims it has retired — earlier numbers it decided it could not stand behind on a verbatim-liftable page, each shown with the date it was struck and the qualitative posture published in its place. 13 forbidden claims are enforced by the build gate; 6 numeric ones are annotated on this page. A vendor that publishes what it walked back is telling you what its other numbers are worth.
No. A retired claim is rendered struck-through and labelled retired, never as a live assertion, and the build gate (verify:metrics) blocks every retired string from appearing anywhere else on the site. The ledger exists to show the discipline, not to re-state the claim.
Not yet. The audit receipts are append-only and carry the build hash, gate result, and registry version, and the build pipeline regenerates them on every deploy. Cryptographic signing — a detached signature over each receipt that a third party could verify against a published key — is a planned hardening step that requires a dedicated signing key. It is flagged here rather than faked; no key is committed.