Which data?
Period, instruments, frequency, provenance, quality status and, where relevant, licensing or usage conditions.
DOCUMENTATION
A result becomes reviewable only when its path of origin remains visible.
Documentation is not an appendix written at the end of the project. It is part of the system. For each material finding, six things should remain traceable: which data were used, which rules applied, which version produced the result, under which conditions the test ran, which claim limitations follow and which use/disclosure status applies to the data and result.
DOCUMENTATION
A reader should be able to understand how a statement was produced.
A robust result requires more than the number itself: data state, calculation and decision rules, system version, test conditions and known limitations all matter. The documentation is intended to make that chain visible from the published finding back to its underlying basis.
SIX QUESTIONS
What a reader should be able to establish for every important claim
Which rules?
Decision rules, parameters, filters, execution assumptions and risk logic must belong to a defined rule state.
Which version?
A rule change creates a new state. Results from different versions should not be silently combined.
Which test?
Test period, control group, comparison path, cost assumptions and other conditions determine what the number actually means.
Which limitation?
Every finding should state what has not yet been tested – such as intraday ordering, costs, new data or isolated APS impact.
Which rights / which clearance?
Data source, licence class and disclosure status determine whether a result can only be used internally, shown publicly, or reproduced/disclosed to a third party.
EXAMPLE
From a published statement back to the test basis
The evidence page, for example, states the scope of the Version 1 test matrix. That number alone would be of little value. The documentation chain gives it meaning: 94 real instruments were evaluated with 60 oscillators under the same basic logic, producing 5,640 systematically executed individual tests.
The context also states that these tests share market, data and formula families and therefore must not be treated as 5,640 independent scientific experiments. Those details prevent a correct number from producing an incorrect conclusion.
Published statement5,640 systematically executed individual tests
↓Definition94 real instruments × 60 oscillators
↓Data & test stateVersion 1 · historical daily data 2009–2025
↓Limitationbroad test matrix · not 5,640 independent experiments
STATUS, NOT A LABEL
Not everything is described with the same word “validated”.
A historical comparison, a documented test and an independent replication are different evidence states. The site therefore uses visible status labels.
Documented
The statement can be traced in the current source or test base.
Historical finding
The number or observation exists, but is not presented as universal performance evidence.
Revalidation required
The finding is intended to be reproduced or isolated under Version 2 conditions.
Planned
The function or test belongs to the target architecture but is not yet a finished component.
DOCUMENTATION AS PART OF THE PRODUCT
Domain knowledge, code and evidence should describe the same version.
A future user or acquirer should not find contradictory system states in marketing material, source code and manuals. The long-term objective is a coherent chain of domain documentation, technical architecture, test records, user help and version history.
Domain documentation
What the rules mean, why they exist and which market or risk situation they represent.
Technical documentation
How modules, data models, interfaces, error handling and operating conditions are implemented.
Test & audit records
Which version was run when, against which data, and whether the expected reference state was reproduced. New data and result states should retain at least data_source, license_class, dataset_fingerprint, run_id, publication_clearance and third_party_disclosure.
Help & explanation
Contextual assistance for users – ultimately in German and English and ideally available inside the product.
AI & DOCUMENTATION
AI may support documentation, but it must not invent an unreviewed new system state.
Generative AI can search large knowledge bases, structure text, formulate explanations and assist quality assurance. Precisely because it can do so, it needs explicit sources, versions and approval rules. AI-generated wording is not a new domain standard until it has been checked against the documented system logic.
✓Source-groundedMaterial domain claims are tied back to existing documentation and test states.
✓Editorially reviewedPublished content is not copied from an AI draft without review.
✓Version-consistentNew wording must not silently change the underlying system state.
REVIEW
The evidence page applies this principle to concrete metrics.
FROM DOCUMENTATION TO EVIDENCE
The Evidence Map shows how this documentation principle is applied to public statements.
For every core claim it makes the metric, current support, methodological limitation and next validation step visible.
Public evidence trail
A number should not merely be readable. A reviewer should be able to see why it appears on the website and which test would change its status.
View Evidence Map →