Proof from real systems
See what the current finance examples demonstrate and how to evaluate a Twin against your own approved results.
A Twin should be judged against the business result it is meant to support, not against how convincing an answer sounds.
The current public proof comes from bounded work in real modern and legacy finance environments. Representative figures protect confidentiality; the measured outcomes below are stated separately.
A reviewed profit and loss result
The Twin produced a profit and loss view from reviewed business definitions and calculations. Finance checked it line by line against its approved ground truth:
- 9 of 9 lines matched;
- the measured variance was £0.00; and
- the definition, calculation version, and governed evidence references remained available for inspection.
This demonstrates that one reviewed finance product reproduced its agreed ground truth for the tested result. It does not claim that every future period, question, connector, or Twin product is automatically accurate.
Modern and legacy evidence together
The Twin is also working with evidence from Xero and a legacy SunSystems ledger. The source systems remain authoritative. The Twin provides the reviewed definitions, relationships, and calculations that make their records useful through approved AI without requiring a wholesale system migration.
The important proof is not simply that both systems can be queried. It is that:
- the intended accounts and organisation scope are explicit;
- the business calculation is reviewed;
- the tested result is compared with an approved reference;
- the exact version used can be identified; and
- unsupported questions fail rather than switching silently to another interpretation.
How to evaluate your first result
Agree a small acceptance set before activation:
| Check | Example |
|---|---|
| Expected result | A monthly total or workflow state with a known approved answer |
| Definition | The version, exclusions, and business owner are explicit |
| Edge case | A credit note, cancelled order, intercompany item, or other known exception |
| Unsupported question | A period, entity, or measure the approved context cannot support |
| Evidence | The completed route identifies the published version and governed evidence references |
| Freshness | A source observation time or watermark is checked where the configured interface exposes one |
Run the acceptance set against the exact version intended for use. If the definition, source data, or calculation changes, treat the new result as a new version to review and evaluate.
Proof remains scoped
A successful test is evidence for the product version, source state, and questions that were actually evaluated. It is not a promise about unrelated products or arbitrary questions.
What happens next
Real user demand provides the next evidence. Repeated unsupported questions may show that another source, definition, relationship, or process should be proposed. Material changes return through review before a new version is activated.
See Understand a Twin answer for the evidence a completed query returns, or Build your first Twin for the full journey.