Know the outcome happened.
Your system says something happened. IndeProof independently checks whether it actually did.
The expensive failures are the ones your system says succeeded.
A lead that never reached the CRM, an order that never reached fulfillment — while every dashboard showed green. When the reporting system grades its own work, the costliest failures are invisible. Independent evidence is how the uncertainty gets resolved.
One system makes a claim.
A second source tests it.
A lead created, an order fulfilled, a record written — IndeProof checks a genuinely independent source and returns an evidence-backed verdict and closeout report.
Instrument One is the system making the claim. Instrument Two is the independent source used to test it.
Independently verifies that a contracted business outcome actually happened — under a pre-agreed Outcome Contract.
Systems grading their own work agree with themselves. Proof requires an instrument that could disagree.
An outcome classification on every claim, and a closeout report backed by preserved evidence.
Submit one workflow for qualification — an answer comes before any pilot, payment, or access.
Watch one claim become a verdict.
The operational sequence behind every classification — from the moment a claim fires to the moment a proof artifact is recorded.
—
Self-reported completion is testimony. Corroboration is evidence.
Dashboards, logs, and status pages are produced by the system being judged. Self-reported completion repeats the original claim — it does not test it. A source controlled by the claiming system cannot provide structural independence; verification requires a source capable of disagreeing with the claim, read by a verifier with a separate identity and appropriately scoped access.
So IndeProof is built to be the instrument your system does not control, reading a source it cannot edit.
Before anything counts, an Outcome Contract is frozen: the exact outcome, the independent proof source, the precise matching rule, the deadline, and the settlement rules (settlement: a quiet period after the deadline, so a result must hold, not merely appear). Then every claim is checked against that source with separate, least-privilege, read-only access.
Example Outcome Contract
When a qualifying form submission is accepted, verify that exactly one contact carrying the matching event identifier appears in the designated CRM within five minutes. Otherwise issue the applicable evidence-backed verdict.
Not legal boilerplate — the precise precommitted rule governing what will be checked and how it will be judged. See this contract frozen inside the sample closeout report →
The two channels on this page work the same way: statements on the left, verifiable specifics alongside. They meet only at a resolved outcome.
One pattern: a claim, an independent record, a window.
IndeProof fits outcomes that leave a deterministic record in a system the claiming side does not control. The proven, contract-specified example:
- Originating claim
- The producing system asserts "lead created" and issues a unique event identifier.
- Independent proof source
- The CRM itself, read by a separate verifier identity with read-only contact access.
- Bounded outcome
- Exactly one contact record carrying the exact identifier.
- Window
- 300 seconds, inclusive, plus a settlement period in which the record must remain the same singleton.
Two adjacent patterns the same contract model fits — shown as patterns, not as deliveries already performed:
- Originating claim
- The commerce system asserts a paid order was handed to fulfillment.
- Independent proof source
- The fulfillment provider's records, read independently of the ordering system.
- Bounded outcome
- Exactly one fulfillment record matching the order identifier.
- Window
- An agreed deadline from order confirmation, with settlement — fixed in the contract before counting.
- Originating claim
- A support workflow asserts a refund or cancellation was executed.
- Independent proof source
- The payment processor's or billing system's record, read with separate credentials.
- Bounded outcome
- Exactly one refund/cancellation transaction matching the case identifier.
- Window
- An agreed deadline from the workflow's assertion, with settlement — fixed in the contract before counting.
Examples, not customer implementations. Where no genuinely independent proof source exists, IndeProof does not apply.
Four outcome classifications. No fifth option.
Every contracted business outcome resolves to exactly one of four classifications. No "probably fine," no silent retry, no optimistic rounding.
Exactly one matching record appeared in the independent proof source inside the contracted window and remained stable through settlement.
The intended outcome was late, missing, or did not match the contract's exact identity rule. Late is failure — lateness is not forgiven.
Proof was unavailable, contradictory, malformed, or duplicated. The ambiguity is preserved exactly as found — never rounded up to success.
Only events explicitly flagged as internal tests are excluded from the totals — and each exclusion is itself recorded.
A separate layer: the evidence-integrity audit
Distinct from outcome classification, every preserved evidence artifact can later be independently recomputed. That audit answers a different question — not what happened to the outcome, but does the evidence itself still hold — and it returns its own result: PASS, FAIL, UNCERTAIN, or UNAVAILABLE. UNAVAILABLE there is an evidence condition, not an outcome: when proof for a business outcome cannot be observed, the outcome classification is simply Uncertain.
You do not receive a dashboard. You receive a case file.
The intended pilot closeout deliverable, demonstrated with controlled synthetic data: the frozen contract, the claims, what the independent source would show, every classification, and every honest exclusion — backed by sequenced, tamper-evident evidence artifacts (each record carries a fingerprint of its payload and links to the one before it, so alteration shows).
A report you could hand to your CFO and your engineers on the same afternoon.
Closeout report — Lead Assurance pilot (internal, controlled)
DOC IP-CO-SAMPLE-001 · rev 1 · all identifiers synthetic- Frozen Outcome Contract
- Exactly one CRM contact carrying the exact event identifier, within 300 seconds inclusive.
- Scope
- Planned internal controlled pilot; isolated test account; no customer or production data.
- Independent proof source
- The CRM, read by a separate verifier identity (read-only contact access).
- Sample count
- 250 synthetic events over 10 operating days — the protocol’s planned allocation, shown illustratively.
- Verification window
- 300 s inclusive + 300 s settlement; re-audits at +5 and +30 minutes.
- Evidence references
- Specifies sequenced, integrity-tagged artifacts per event; digests only, never tokens. Illustrative here.
- Exclusions
- 10 scenarios explicitly flagged internal-test — the protocol records each exclusion.
- Uncertainty
- 30 scenarios settle uncertain (proof unavailable or duplicated) and stay uncertain.
- Evidence-integrity audit
- PASS — illustrative; a separate audit layer that, in a delivered report, records whether every preserved artifact independently recomputes intact.
What the pilot produces
When the internal pilot executes, its verified results will be published here — and nowhere before that.
IndeProof does not publish numbers it cannot prove.
Before you submit a workflow
What can IndeProof verify?
A bounded business outcome that leaves a deterministic record in a system the claiming side does not control — like a lead reaching a CRM, an order reaching fulfillment, or a refund reaching the processor. Methodology & limitations →
What makes a proof source genuinely independent?
The claiming system cannot write to it, edit it, or share credentials with the verifier reading it. It must be capable of disagreeing with the claim.
Is IndeProof another monitoring or alerting tool?
No. Monitoring watches signals a system emits about itself. IndeProof checks a contracted outcome against an independent record and issues one of four evidence-backed classifications.
What is an Outcome Contract?
The precise rule — outcome, proof source, matching rule, deadline, settlement, exclusions, classification behavior — frozen before anything counts. See the example above.
Does sending an email begin a pilot?
No. It begins a qualification conversation only. It authorizes no pilot, no payment, and no system access; neither party is committed.
Do I need to send credentials or customer data?
Never. Qualification needs only a plain-language description of the outcome, the claiming system, a possible proof source, and the approximate time window.
How is a pilot priced?
Pilots are fixed-scope and fixed-fee, agreed in writing before anything runs, with no automatic renewal. There is no public price list — the fee is quoted after qualification.
What do I receive at closeout?
A closeout report — the frozen contract, every classification, every exclusion — backed by preserved, tamper-evident evidence. See the sample report →
Submit one workflow for qualification.
One workflow, and the business outcome it is supposed to produce. You receive a qualification answer before any pilot, payment, or system access.
Pick the workflow whose reported success nothing independent confirms. We will tell you honestly whether its outcome is valuable, testable, and independently provable — or why IndeProof does not apply.
Qualification is a conversation, not a pilot — nothing is authorized and nothing is owed before written agreement.
Do not send credentials, API keys, tokens, personal data, or confidential evidence. Qualification never requires them.