Corrections from an outside audit of the product, its public documents and its interfaces. A request for contract 1 now gets contract 1, the public interfaces have one catalog, the software bill of materials lists every package the website installs, the command line reads infrastructure files more exactly, and the published documents that had drifted from the service were brought back into line.
What changed
Contract 1 of the Trust Profile response, requested with the Trooth-Contract header or ?contract=1, was answered with contract 2 and a warning, which does not keep a pinned meaning; it is now answered with contract 1 itself, and any fact two sources disagree about is left out and named rather than resolved. The API Versioning Policy says so. The public interfaces (the REST application programming interface, or API, the Model Context Protocol (MCP) server, the subscription endpoints, the command line and the badge) are listed in one catalog at /interfaces.json, and section 2 of the API Terms now incorporates it and says which public endpoints store something rather than only read. The software bill of materials at /sbom.json listed the website's direct dependencies only; it now lists all 852 packages its lockfile resolves, direct and transitive, each with its integrity hash, whether it ships with the site, and the dependency graph, and it says how to tie it to the commit a deployment serves. Each Worker's bill now carries its dependency graph too. The webhook guide and reference now say which signature to check on which channel, and the samples verify the one that signs a timestamp. A reading's counts now name the checks that were not as expected, and a check the reader could not reach is reported as not read rather than as a finding. Code samples keep their language and line breaks when a page is read as Markdown, and tables in legal documents render as tables. The connector disclosures name the least permission each connector's one request needs, the Retention Schedule says which document controls and lists the hourly continuity series separately, the site's structured data and several descriptions no longer say more is signed than is, and the HTTP Strict Transport Security (HSTS) statements give each host's own duration. The downloadable trust documents were corrected where they had drifted: the account service's 35-day backup, the per-host HSTS durations, the bill of materials, and the count of controls in place, and the archive now carries a manifest of what it holds. The command line, trooth 0.5.1, no longer treats metadata keys as infrastructure settings, keeps each module's encryption settings to itself, reads every Kubernetes document form and list, counts a credential literal once and finds one hidden by a later reassignment in a Dockerfile.
Why it changed
An audit of September 28, 2026 compared what Trooth says in its pages, documents and machine-readable files with what the service and the command line actually do, and listed where they disagreed.
Who is affected
- Affected: Developers who request contract 1 of the Trust Profile response, who verify webhooks, or who run trooth lint in a pipeline; and anyone relying on Trooth's published documents. Nothing a signed-in company sees in its workspace changed.
- Availability: Public. No account needed.
- Release stage: Available.
- Areas: API, CLI, Webhooks, Legal, Platform, Trust Profiles.
What to do
No action required. Nothing to do. A client that requests contract 1 now receives contract 1's shape instead of contract 2 with a warning; one that does not ask is unaffected. trooth lint 0.5.1 can report fewer credential findings than 0.5.0 where 0.5.0 counted metadata or a repeated value, and more where 0.5.0 missed a reassigned one.
Dates
- Announced: September 28, 2026, the day this entry was written. Entries are never backdated.
- Released: September 28, 2026.
What this does not fix
Some of the audit's findings need work on api.trooth.co or a decision by the founder and are not in this release: where each company fact came from, recorded per fact; a signed reading that names the interpretation it was read under; badge freshness per category; multi-factor recovery codes; and the retention exceptions and continuity powers the audit asked to narrow.