A DWG that looks right in a screenshot may still be difficult to use. A useful production brief defines feature meaning, geometry behavior, surface construction and how the receiving team will test the files. The goal is a working design input with known limitations.
Define the intended use and source limits
State whether the output supports planning, preliminary design, asset inventory or another use. Specify required detail and tolerances with the responsible client professional. Processing a point cloud does not by itself certify a survey or create a verified as-built record.
- Provide the source capture date, registration information and available imagery.
- Flag areas with occlusion, sparse returns or uncertain registration.
- Identify field verification and professional sign-off that remain outside production scope.
Supply working templates and versions
Provide the actual CAD template and an accepted example, together with the software and version used for review. Decide whether the output requires editable native objects or exchange geometry. A LandXML export and a native Civil 3D surface should not be treated as the same deliverable.
- Layers, line types, units, symbols, object styles and annotation scale.
- Horizontal and vertical references, local grid transformations and insertion requirements.
- External references, fonts, plot configuration and packaging rules.
- Required native files, exchange files and PDF review sheets.
Write feature capture rules
For each feature, define which physical edge or reference becomes geometry. For example, a curb may require separate top and toe lines instead of one centerline. Decide when geometry must stop at an occlusion and how any inference is marked.
- Choose 2D or 3D representation for each feature type.
- Specify closures, connectivity, minimum feature size and segment behavior.
- Define observed, inferred and field-verification-needed status.
- Resolve inconsistent imagery and point-cloud evidence in the pilot.
Specify surfaces independently of contours
Contours are an output of a surface; smooth contours alone do not demonstrate a usable terrain model. Define the source classes, breaklines, boundary, exclusions, triangle limits and bridge treatment. Review surface behavior where terrain changes quickly or data is missing.
- Include profiles through representative roads, embankments and drainage features.
- Document excluded areas and interpolation across gaps.
- Confirm whether surfaces must rebuild in the target application.
Run an acceptance session in your software
Review a pilot in the receiving application, using the same operations your designers perform. Keep a short issue register with file, feature, expected behavior and observed result. Agree how fixes are checked and how later scope changes affect cost and schedule.
- Open the package and resolve references without missing dependencies.
- Inspect coordinates and spot elevations against the agreed reference.
- Test snaps, object properties, layers, connectivity and surface rebuilds where applicable.
- Plot a representative sheet and check legibility at the intended scale.
- Record limitations and the client’s acceptance decision.
Put the checklist to work
Use the editable templates to record your project requirements and delivery review. Adapt them to the applicable contract and specification.