Claim Boundaries
This page exists so that the limits of our claims are stated directly rather than left to be inferred from careful phrasing elsewhere.
What we claim
- Provenance is preserved from source through to a ledger draft as a design that the implemented layers follow, with each layer's actual reach labeled.
- Unsupported items are not hidden. They are left in explicit terminal states.
- The system is designed so that omission candidates, duplicate candidates, unsupported items, and review-required items can be found and traced back to source evidence.
- A specific revision's commitment and current-use state can be verified — as a design; see the status note below.
What we do not claim
- That we guarantee the authenticity of source documents, the identity of a user, tax accuracy, or legal effect.
- That we provide automated filing, tax authority approval, or a substitute for a tax professional.
- That we collect more data, or are generally more accurate, than any other service.
- That direct experience with another service constitutes an evaluation of its overall quality.
- That GIWA certifies the accuracy of a report's contents.
- That a challenge mechanism is deployed in V1.
What "provable" means here
When this documentation says a result is provable, it means that the source coordinate, the extraction result, the transformation and interpretation grounds, the policy and version applied, and the result revision can be traced again.
It does not mean the source document is genuine, that the tax treatment is correct, that the result has legal effect, or that any authority has approved it.
The status of each claim
Several claims above describe the design, and their implementation status differs by layer. The distinction is carried throughout the site by the status labels:
| Claim | Where it holds today |
|---|---|
| Provenance preserved | Implemented from Observations back to execution evidence; Planned forward to a ledger draft |
| Unsupported items left in explicit states | Implemented in the JIT and schema layers |
| Omissions and duplicates findable by a reviewer | Implemented as stored outcomes; Not verified as a usable interface |
| Revision commitment verifiable externally | Not verified — no contract or transaction exists |
On comparison with other services
This documentation makes no comparative performance claims about other services.
There is a general observation worth stating, because it defines the problem this project addresses: automated integration alone does not establish collection completeness. Providers say so themselves — terms of service for this category of product commonly note that collected transaction data can vary with exchange API policy changes, and place responsibility on the user to provide and verify information without omission or duplication.
That is a statement about the boundary of the problem, not about any particular service's quality. We have not run a controlled comparison, and until we do, phrases like "faster", "more accurate", or "fewer omissions" are not used. How we intend to establish such claims is set out in the Evaluation Plan.
Writing rules for this documentation
These rules govern edits to this site. They are also recorded in AGENTS.md.
- Use completed-tense statements only where base-branch code and a runnable verification exist.
- Distinguish the existence of a schema, migration, or client from the existence of a compute runtime.
- Distinguish mock and fixture tests from live provider, live database, and end-to-end verification.
- Prefer GitHub code and execution results over issue-tracker status.
- Mark anything unimplemented as Roadmap, Planned, or Target architecture.
- Describe GIWA as product vision until a real contract, transaction, and Explorer verification exist.
- Do not claim tax calculation accuracy, filing accuracy, legal effect, or government approval.
- Attach a status label to every capability claim.
- Do not make comparative claims about competing services.