By the myPitLab team · Last updated 8 July 2026 · 9 min read
TL;DR
- PAS128 utility survey work needs a structured survey report — not a Word doc stitched from last year's template with find-and-replace on the client name
- UK clients expect methodology, PAS 128 accuracy, survey extent, geo-photos, asset tables, limitations and recommendations in a consistent order
- Limitation text must come from governed rules (standing water, reinforced concrete, access restrictions) — not improvised paragraphs that drift between surveyors
- Reports should aggregate structured field data; AI may assist wording but must never invent asset counts, depths or utility locations
- myPitLab Field Survey Report pulls from live project data; MySafeOps offers a dedicated survey report generator when reporting is your starting point
Key takeaways
- PAS128 is a detection standard; the survey report is how you prove what was done, what was found and what was not possible on site
- Method statement and report limitations must align with RAMS — contradictory documents trigger client queries and rework
- Geo-photos with location context beat camera-roll appendices that nobody can tie to coordinates
- Survey extent and boundary narrative should match KML/KMZ and DXF deliverables — same project, same scope
- Issue reports from approved project data after office QA, not from draft field sync
In this article
- What a PAS128 survey report actually is
- Why Word templates fail framework QA
- Sections UK clients expect in 2026
- Limitations, methodology and PAS 128 accuracy
- Geo-photos, boundaries and asset tables
- RAMS, reports and deliverable alignment
- myPitLab vs MySafeOps for survey reports
- How to evaluate survey report software
- Frequently asked questions
Introduction
You won the PAS128 detection job. The field team completed EML and GPR passes. MH validation chambers are logged. Geo-photos are on the server. The client is waiting for the survey report — the document that ties methodology, findings, limitations and recommendations into something their framework reviewer can sign off.
Too many UK firms still produce that report by opening a Word template from 2019, copying sections from the last similar job, and hoping the limitation paragraphs still match site conditions. It works until it does not: wrong client logo, methodology that references equipment you did not use, limitations that contradict the RAMS, asset counts that do not match the CAD pack.
In 2026, framework clients expect structured, repeatable survey reports generated from project data — with human review before issue, not manual re-keying from field notes.
myPitLab Field Survey Report aggregates project assets, geo-photos, weather, CAD context and limitation rules into an editable HTML report. MySafeOps provides a dedicated survey report generator for teams focused on safety documentation and client report packs. This guide explains what UK delivery leads should demand — whichever platform you use.
What a PAS128 survey report actually is
PAS 128 defines how buried utilities are detected and classified in the UK. The survey report is your formal deliverable describing:
- What the client asked for (scope and project requirements)
- How you performed the work (methodology, equipment, PAS 128 accuracy class)
- Where you worked (site description, survey extent, boundary)
- What you found (utility records, trial holes, MH/IC validation, geo-photos)
- What you could not confirm (limitations — access, weather, reinforced concrete, standing water)
- What the client should do next (recommendations)
The report is not the CAD file, the KML or the RAMS — but it must reference and align with them. A principal contractor receiving your pack should see one coherent story across PDF report, GIS handover, CAD and RAMS.
Why Word templates fail framework QA
Word-based reporting breaks at scale for the same reasons Word RAMS does:
| Problem | Client impact |
|---|---|
| Copy-paste methodology | Describes GPR grid you did not run |
| Manual limitation paragraphs | Missing standing-water caveat on a wet day |
| Asset tables re-typed from Excel | Counts disagree with CAD |
| Geo-photos in a ZIP appendix | No link to coordinates in the report |
| No version control | "Which report matches revision C of the CAD?" |
Digital survey reports should aggregate structured project data, apply organisation limitation rules, and let humans edit before issue — same pattern as modern RAMS generation.
Sections UK clients expect in 2026
A credible PAS128-oriented report structure includes most of the following (order may vary by client template):
| Section | Purpose |
|---|---|
| Report information | Client, project ref, dates, surveyor, revision |
| Foreword / executive summary | High-level outcome for non-technical readers |
| Project requirements | PO scope, accuracy class, deliverables list |
| PAS 128 accuracy | Detection intervals, confidence levels per utility type |
| Methodology | EML, GPR, TS, CCTV, MH validation — what was actually used |
| Site description & weather | Conditions that affect findings and limitations |
| Survey extent & boundary | Map context, KML/KMZ alignment |
| Findings / utility records | Structured asset and detection results |
| Geo-photos / site photos | Captioned, located, tied to project |
| MH/IC validation | Chamber records cross-referencing field inspections |
| CAD summary | TFR/EOT counts when DXF supplied — structured only |
| Limitations | Rule-driven disclaimer text |
| Recommendations | Next steps, further works, monitoring |
| Photo appendix | Reference table linking photos to report sections |
Missing limitations or survey extent is a common framework rejection — not because the field work was wrong, but because the report does not prove scope.
Limitations, methodology and PAS 128 accuracy
Limitations protect you and inform the client. They must be:
- Consistent — same standing-water wording on every job where it applies
- Traceable — ticked from site conditions, not invented in the office
- Aligned with RAMS — if RAMS says confined space entry was not performed, the report limitation must match
A rules engine (organisation-level limitation keys → generated text) beats free typing. Surveyors tick conditions on site; the report expands governed paragraphs. Humans edit before issue.
PAS 128 accuracy section should reflect what was contracted and delivered — not generic boilerplate. If the PO specified Quality Level D for foul sewers and B for power, the report states both and ties methodology to each.
💡 Structured data → client-ready report myPitLab Field Survey Report aggregates project data, limitation rules and geo-photos. MySafeOps survey report generator for teams starting with documentation workflows. myPitLab → · MySafeOps →
Geo-photos, boundaries and asset tables
Geo-photos are evidence, not decoration. UK clients increasingly expect (see our geo-photo capture guide):
- Location context (coordinates or map inset)
- Caption tying photo to trial pit, surface feature or chamber ID
- Inclusion flags — only approved photos in the issued report
Photos from the camera roll without asset linkage fail audit when a client asks "which MH is this?"
Survey extent should match the boundary you issued in KML/KMZ and the area described in RAMS. Drift between "we surveyed the northern half" in the report and a KML covering the full site causes coordination disputes.
Asset tables must come from the database — manhole counts, utility records, trial pit results — not manual Excel after the fact. When AI assists executive summary wording, it must use only provided data; missing data yields explicit "no data recorded" statements, not invented figures.
RAMS, reports and deliverable alignment
Three documents, one project truth:
| Document | Role |
|---|---|
| RAMS | How work was performed safely |
| Survey report | What was found, limited and recommended |
| CAD / GIS | Spatial deliverables for designers and asset teams |
Misalignment examples that cost rework:
- RAMS lists UAV work; report methodology does not mention it
- Report limitations cite heavy rain; weather line says dry conditions
- Report asset count differs from DXF export by twelve chambers
Generate RAMS and report from the same project record where possible. On myPitLab, Field RAMS and Field Survey Report share project context. On MySafeOps, RAMS and survey report generator are designed to issue together for documentation-led workflows.
myPitLab vs MySafeOps for survey reports
| myPitLab | MySafeOps | |
|---|---|---|
| Report source | Live field project — MH/IC, geo-photos, CAD upload, weather | Survey report generator from project documentation context |
| Best for | Firms delivering PAS128 + MH validation end-to-end | Teams prioritising report + RAMS packs first |
| Field capture | Core product — offline, QA, publish | Not the primary focus |
| Limitations | Organisation rules engine | Governed report sections |
| Client delivery | Portal, PDF, DXF, KML from same platform | Report and RAMS issue and share |
| Typical path | Field → QA → report → multi-format delivery | RAMS + report → expand to full field ops later |
Choose myPitLab when the survey report must pull asset tables and geo-photos directly from inspections your team captured on site.
Choose MySafeOps when your bottleneck is producing defensible PAS128-style report packs and RAMS quickly — before you replace the whole field stack.
How to evaluate survey report software
| Criterion | Pass | Fail |
|---|---|---|
| PAS128-oriented sections | Accuracy, methodology, extent built-in | Generic "survey report" with no PAS context |
| Limitation rules | Org-level, rule-driven text | Free-text only |
| Data aggregation | Pulls from project DB | Manual paste from Excel |
| AI usage | Writing assist only; no invented facts | AI generates asset counts |
| Geo-photos | Located, captioned, selectable | ZIP appendix |
| Section order | Reorderable; custom HTML blocks | Fixed PDF template |
| RAMS alignment | Same project / org context | Separate silo |
| Issue workflow | Draft → review → final | Export to Word to "finish" |
Run a pilot report on a completed project and time: generate → senior review → client-ready PDF.
Frequently asked questions
Is PAS128 the same as the survey report? No. PAS 128 is the detection specification. The survey report is your project deliverable describing how you applied it and what you found.
Can AI write the whole PAS128 report? AI can assist executive summary and narrative sections when grounded in structured data. Factual content — counts, depths, coordinates — must come from field records. Never issue AI text that was not reviewed by a competent person.
What if the client supplies their own report template? Good platforms allow custom HTML sections or export structured content for merge. Avoid re-typing into client Word templates when your system already holds the data.
How does the report relate to the client portal? On myPitLab, issued reports sit beside portal access for maps, 3D and downloads — see client portal delivery.
Should limitations match RAMS wording exactly? They should not contradict. Exact wording may differ — RAMS is safety-focused; report limitations are technical scope — but standing water, access restrictions and scope exclusions must align.
Summary
PAS128 survey report delivery in 2026 is a structured, data-driven process. UK clients expect methodology, accuracy, extent, geo-photos, limitations and recommendations in a professional pack that matches CAD, GIS and RAMS — not a recycled Word document.
Next steps: Review your last framework submission — did limitation text match site conditions? Browse all insights, start a free myPitLab trial, or explore MySafeOps for survey report and RAMS generation.
