If you build in this category — a compliance or GRC platform, an LLM or MCP gateway, an agent-security or observability product — the buying page answers the wrong questions. This page answers yours. It is the human-readable twin of the peer section in llms.txt, which your AI can read directly.
Last updated: 2026-08-03 · [email protected] · Louie Lu on LinkedIn
Proofpane is a runtime governance layer for AI tools with three planes: runtime control (policy gates and DLP that run before the irreversible step — before the model receives the prompt, before the tool call executes), an evidence plane (a hash-chained tamper-evident audit record, exported as Ed25519-signed packs an auditor verifies offline, with no vendor account), and an authorization root (human approvals as cryptographically signed events, terminating in a key the customer holds). The layer is built and measurable; there is no customer deployment yet, and the current priority is collaboration with an established platform rather than a pilot queue. This page exists to make that conversation efficient.
Not features — positions, each with an implementation behind it, each of which would take time to re-derive:
The part a website cannot be copied from, and the most useful thing a peer can read here:
Each of those is a different position on the same decision. The model published in The Chain of Custody exists to make the positions nameable. A platform that already owns the customer relationship and the compliance surface, and does not own the enforcement path, is looking at a layer — not a competitor.
Evaluators — human and AI — consistently score Proofpane high on architecture and honesty, and lower on enterprise maturity. That reading is correct, and the attribution matters: every named maturity gap (SOC 2, third-party pen test, signed installers, case studies, reference calls) traces to one variable — no first enterprise deployment yet — not to the architecture. Each is a procurement-stage artifact with a named unlock. The design-gap column, so far, is empty.
What is in place ahead of demand, each verifiable: ≈1,800 governed calls/second measured across three nodes with the audit chain still verify-valid; a verified PostgreSQL backend; 4,500+ test functions behind CI; 335 controls pre-mapped across five frameworks; a governed self-evolution loop. The public recordings show a laptop, a menu-bar tray and a hardware key — the mechanism at single-operator scale — because the product's real form, a layer inside somebody else's platform and estate, cannot be demonstrated on its own.
What collaboration looks like. For a platform considering this, the missing customer is the part you already have. You bring the customer relationship and the compliance surface; this layer brings the enforcement path and the evidence it generates — runtime gates, the offline-verifiable record, and the customer-held authorization root — plus the published model that names where each of us sits.
How to evaluate it without a call: read the two papers below, have your AI read llms.txt, download the sample Evidence Pack and verify it offline, open the demo org (no signup). Then write to [email protected].
A published capability claim about this product was withdrawn after it turned out to be true, on the reasoning that being correct in advance is luck, not evidence; the incident and the wrong prediction inside it were published rather than buried, and the publish-time gate was then hardened until it blocked the founder himself. That record is the argument, and it is checkable: the write-up.
Questions a peer evaluation needs answered that aren't on this page? Email — the answer will be added here.