01
Live
The signal carries how fresh it is and refreshes on a cadence tied to your actual operational state. Green today is not green last quarter. A buyer sees where you stand now, not where you stood at the last audit.
In build · Design partners welcome
A signed compliance PDF is a photograph of a moment that has already passed. trust.json is a live signal: proof that a vendor's posture is current right now, that the other side can verify for themselves, and that tells the truth the moment something slips.
The problem
Vendor trust runs on artifacts built for an annual rhythm: the SOC 2 report, the vendor trust center, the attestation PDF. Each answers one question, "were you compliant at audit time," and each is out of date before the ink dries.
When a buyer asks what your posture looks like this week, no artifact answers. And in the near future where software and AI agents evaluate each other in milliseconds, nobody in the loop can open a PDF at all. Here is what is missing:
trust.json makes each of those a property of the signal itself: current, checkable, and honest, at the moment the other side needs to decide.
What it is
01
The signal carries how fresh it is and refreshes on a cadence tied to your actual operational state. Green today is not green last quarter. A buyer sees where you stand now, not where you stood at the last audit.
02
The recipient checks the signal themselves, with cryptography, not a phone call and not a leap of faith. Either it proves what it claims or it does not. Trust becomes a decision the other side can make on its own.
03
When something is wrong, the signal says so, with scope, instead of showing a stale green badge. It is built so that quietly hiding a problem is the one thing you cannot do.
Think of it as the compliance equivalent of the lock in your browser: a small, standing proof that rides along, checked automatically, that you never think about until it turns red. The mental model most people already have for a secure connection, applied to whether a vendor is safe to rely on right now.
Who it's for
The teams that publish a trust posture buyers depend on, the teams that assess vendors at a volume that has outgrown spreadsheets, and the systems that will soon make these calls without a human in the loop at all.
You re-prove the same posture to every buyer, and every proof is stale by the next deal. Publish it once, live, and let buyers verify it for themselves instead of putting you through the same review each time.
You inherit a folder of PDFs and a scoring dashboard that disagrees with them. Get a current, checkable signal of where a vendor actually stands, instead of a point-in-time attestation you have to trust on faith.
Your software already talks to other software, and soon it will have to decide inline whether a counterparty is safe to transact with. A PDF cannot ride along on an API response. A small, verifiable proof can.
Why us
Trust is the product
The deliverable is a trust decision anyone can make for themselves, not a document they have to take on faith. The whole point is to stop asking the other side to trust you, and start letting them check.
Read the principleHumans always decide
The vendor publishes the signal. You set the policy for what a given posture warrants: proceed, flag, or hold. The protocol reports the truth; the decision about what to do with it stays yours.
Read the principleShow your work
Every claim is checkable at the source, cryptographically, the moment it matters. Not a badge you hope is accurate, a proof you can verify. Trust without traceability isn't trust.
Read the principleDesign partners
trust.json is in build. If you publish a trust posture buyers rely on, or you assess vendors at a volume that has outgrown spreadsheets and PDFs, we want you in the room while the protocol is still taking shape.