01Layer
A validation pipeline
For the COTO TMH-18 (Road Asset Data Electronic Exchange Formats) specification — structural and domain rules over UTF-8 CSV submissions.
Manifesto · v1
What we built, why it exists, and how it works.
TMH18 Validator is a deliberate piece of infrastructure. This page exists so that anyone — engineer, authority, auditor — can read the whole rationale in one sitting before they decide whether to trust a certificate we issued.
What it is
A pipeline, a workflow, a certificate authority.
TMH18 Validator is four things stitched together, in this order. Each one is necessary; none on its own is sufficient.
02Layer
A co-sign workflow
A submitting engineer prepares the dataset; a principal engineer co-signs. Separation of duty is enforced — no signer approves their own submission.
03Layer
A certificate authority
On co-sign, TMH18 Validator hashes the stored file bytes (SHA-256) and issues a public certificate at tmh18.com/verify — re-hashable by any third party without an account.
04Layer
An immutable audit log
Every override, every reviewer comment, every co-sign event is written to an append-only audit log keyed to the submission ID.
Why · first principles
Four claims we are willing to be measured against.
Every product decision — what to build, what to refuse to build — comes back to these. If one of them turns out to be wrong, the platform is wrong.
§1Principle
Trust must be reproducible.
A PDF stamp is a claim. A SHA-256 over the exact bytes a co-signing engineer reviewed is a fact. Anyone — a contractor, an auditor, a court — can re-derive it in seconds.
§2Principle
Standards deserve enforcement.
TMH-18 is a published spec. Submissions that drift from it — bad encoding, non-monotonic chainage, missing temperature correction — should not silently pass into the asset record. The engine makes the spec executable.
§3Principle
Overrides are not loopholes.
A warning override is recorded with the engineer who issued it, the justification, and the timestamp. The certificate carries the full context, not a stripped pass/fail.
§4Principle
The verifier is the product.
The platform is incidental. The third-party verifier — open, no account required, cryptographic — is what makes the certificate worth anything outside our walls.
How it works
Four deterministic steps from raw CSV to a third-party-verifiable hash.
Nothing on this path is a black box. The rule set is published, the override justifications are written to the audit log, and the certificate is verifiable without an account on tmh18.com/verify.
01Step
Submit
Upload the TMH-18 dataset (UTF-8 CSV, up to 1 GB). The ingest schema maps headers — ROAD_NUMBER, SECTION_ID, CHAINAGE, DATE, D0, D200 — to the canonical field set defined in the documentation.
02Step
Validate
The rule engine runs deterministic checks on every row — encoding, required headers, monotonic chainage, deflection-sensor ratio, temperature correction. Warnings can be overridden with a written justification; errors block the co-sign request.
03Step
Co-sign
The submitting engineer requests a co-sign. A principal engineer at the same organisation reviews the overrides, validates the dataset against site context, and signs. The signing event is locked to the file bytes at that moment.
04Step
Certify
TMH18 Validator hashes the bytes (SHA-256), mints a certificate, and publishes it at tmh18.com/verify. Any third party can re-hash their copy of the file and match the certified hash — no login, no API key.
Full rule catalogue, header reference, and verifier semantics: /docs.
Pre-pilot intakeRead the principles.
Read the principles.
Then submit something.
Tell us about your organisation and the survey files you need to check. We review access requests and contact accepted organisations with next steps.
Request access
Application takes about 2 minutes. No payment required during pilot.