How we prepare and correct our guidance.

Separate the manual, the product and the example

Manual claims should identify the issuing body, document title, edition, date and the applicable section or table. We retain draft status and distinguish legacy references. A source edition used by our library does not establish what every receiving authority has adopted.

Product explanations describe the supported workflow and the evidence a user should inspect. They must not turn a selected check into a claim of complete manual compliance. Original procedures and examples are labelled as working guidance, with their assumptions and limits.

Use the standards and coverage page alongside the receiving authority’s actual requirements.

What “reviewed” means here

A review date records a documented editorial check of the article. Depending on the subject, that check compares wording with the cited source, the current product behaviour or implementation, and reproducible automated tests. It is not a claim that a registered professional engineer personally approved the article.

AI-assisted research, drafting and automated checks are used in this library. Automation can help identify inconsistencies but does not replace professional judgement, field verification or the receiving authority’s acceptance process. We do not invent named authors, reviewers, qualifications or external endorsements.

The organisation byline identifies the publisher responsible for the guidance. If an individual technical review is explicitly credited in future, it must identify a real reviewer, their relevant role and the scope of that review.

Dates describe different events

Published is the first public release supported by our release records. Updated means the content changed substantively. Reviewed means the described editorial check was completed. We do not change these dates simply to make a page appear newer.

Where an older publication date cannot be established, it is omitted. We keep source and release evidence internally. A film can predate its written guide’s latest update; if its advice becomes misleading, we correct or retire it instead of silently changing its transcript.

Worked examples and downloadable records

Our training examples use invented identifiers and values. They are not client survey evidence. Each worked example should state the selected definition, expected result, correction rationale and what was not tested. A passing synthetic fixture is not proof that a complete project or customer template will pass.

We test stated parser and field-check outcomes with the corresponding application functions where possible. We preserve invalid and corrected samples so that the difference is inspectable. These tests do not certify instruments, assessors, measurements or entire TMH manuals.

Completed working templates explain how to record evidence. Unavailable approvals, certificate IDs and reviewer details remain blank; an example must not masquerade as a real approval.

Report an error or request a correction

Email admin@tmh18.co.za with the page URL, the statement in question and the source edition and clause or product result that supports your correction. Do not send confidential survey records or personal information unless an authorised support process requires them.

We assess the reported claim against the evidence, correct material inaccuracies and record substantive changes. When the answer depends on a project-specific profile, we clarify the boundary instead of presenting one interpretation as universal.

Independent publishing and service limits

TMH18 Validator is an independently operated private platform. Mentioning COTO, SANRAL, the Department of Transport or a manual does not imply affiliation or endorsement. A platform certificate records review decisions and file identity; it does not establish measurement accuracy, government certification or complete manual compliance.

Use the working templates or return to the learning library.