Product promise parity
Does your software actually behave the way your website says it does?
Your marketing site, privacy policy, pricing page, security statement and AI disclosures all make promises. Your code, your dependencies, your providers and your configuration change every week. PromiseParity checks whether those two things still agree — and shows you the evidence either way.
Truth drift
Statements like these are made once and then left behind by six months of shipping. Nobody lied. The software simply moved.
- “We do not train AI models on customer data.”
- “Documents are deleted after 24 hours.”
- “We only use Anthropic.”
- “Only listed subprocessors receive customer data.”
- “That feature is included on the Enterprise plan.”
- “AI-generated content is disclosed.”
The question PromiseParity asks about every one of them: you said this — what proves it is still true?
Claims should have evidence
PromiseParity is built around one chain. A claim comes from a source. A source is checked against technical evidence. Evidence produces a verification with a stated method and confidence. Every result keeps its history, so you can see not just what is true today but when it changed.
- 01ClaimAvailable
- 02SourceAvailable
- 03EvidencePhase 4
- 04VerificationPhase 5
- 05ResultPhase 5
- 06HistoryPhase 7
Evidence is deterministic wherever it can be — manifests, lockfiles, imports, configuration, schema, routes. Where a judgement is required, it is labelled as a judgement rather than promoted into a fact. A tool that cries wolf about a dependency it does not understand is worse than no tool at all.
What exists today
PromiseParity is early. Right now the product is its foundation: GitHub sign-in, organizations, roles and an audit trail. Claim registration, repository evidence and continuous verification are being built in that order, and this page will say so until they ship.
Keep your product and its promises in parity.