The PROVE TDI platform
See how one decision holds together.
Start with your organisation’s needs. Connect product evidence to those requirements. Compare the options, record human approval and keep the reasons in your Decision Ledger.
The examples below explain the method. They are not live product screens, customer records or vendor recommendations.
- 1
Define the need
Agree what matters to your organisation.
- 2
Test the evidence
Compare options. Keep the gaps visible.
- 3
Make the decision
Record the trade-offs and human approval.
- 4
Review the result
Compare what happened with what you expected.
Compare the fit. Not the sales presentation.
For this occupancy decision, the organisation needs a booking-system connection and a workable deployment. The same requirements apply to every option, including those on the original shortlist.
| Our requirement | Product A | Product B | Product C |
|---|---|---|---|
| Connect to our booking system | API documented; fit untested | Supplier claim only | Evidence not supplied |
| Deploy within our operating constraints | Deployment plan to review | Site survey required | Dependency unresolved |
A shortlist is not a verdict. These questions inform human review, not an automatic winner.
Open the evidence behind an answer.
Product A has API documentation. That does not settle whether it will work with the organisation’s booking system. The source, scope and unresolved question stay visible.
Evidence can be relevant without being sufficient. Conflicting or missing information remains a reason to investigate, not a reason to invent certainty.
What is documented
An API exists.
In this example, the supplier provides an API guide.
What that does not establish
It works with our booking system.
Compatibility with our version and required data still needs testing.
Follow the requirement to the decision
- Requirement
- Share occupancy data with our existing booking system.
- Source and scope
- Illustrative supplier API documentation, not an independent compatibility test. In a real decision, the source, version and retrieval date remain attached.
- Open question
- Can the required data move between the specific systems under our operating conditions?
- Next action and authority
- Ask for a scoped integration test. The accountable reviewer assesses the result; the authorised person decides whether the requirement is satisfied.
Missing evidence is not proof of failure. Documentation is not automatic verification.
Approval is a human decision. The record should outlast it.
The Decision Ledger connects requirements, alternatives, sources, assumptions, risks, rationale, revisions and approvals. AI assists the work; accountable people retain judgement and authority.
A Proof Report communicates the decision. The Decision Ledger preserves its context and connects expected outcomes with later review.
Illustrative Decision Ledger · Not a customer record
The reasoning stays with the decision.
What we need
The booking-system connection, agreed requirements and responsible stakeholders.
Why we think it fits
Options considered, source evidence, assumptions, gaps and the reasons for each trade-off.
Who can approve
Human review and approval remain explicit. In this example, approval is still pending.
What changed
Later evidence, revisions and reasons remain connected instead of losing the original context.
Expected result
Occupancy data reaches the booking system reliably.
Actual result
Not yet measured. Review after implementation.
Put your own decision in context.
Start a seven-day decision trial. Final governed outputs are paid. Commercial relationships never determine evidence strength, ranking or recommendation.
Read the governance principles or see an example Proof Report.