Quality control and delivery acceptance.

Our quality workflow separates production checks, technical review and delivery validation. The project scope defines the tests, review coverage and evidence your team receives.

THE ACCEPTANCE PRINCIPLE
A requirement needs a check method and a decision rule.

A clean visual result is not evidence of positional accuracy. Acceptance needs the right checks for the intended use and the source data available.

THREE REVIEW STAGES

Check the work.
Then check the handover.

Reviewer assignments and the extent of independent review are agreed in the project scope. Client acceptance follows the reported results and any explicitly accepted exceptions.

01 / PRODUCTION QC

Check against the baseline

Compare classes, feature interpretation, geometry and attributes with the accepted pilot. Flag missing coverage and questions that need a client decision.

OUTPUT: CHECK RECORD & ISSUE LOG
02 / TECHNICAL REVIEW

Test the agreed criteria

Run applicable validation rules and inspect the agreed sample or coverage. Separate format defects, interpretation errors and source limitations.

OUTPUT: RESULTS & REVIEW COVERAGE
03 / DELIVERY VALIDATION

Confirm usable files

Reconcile the manifest, versions and coordinate references. Open representative outputs in the target software and report unresolved items before handover.

OUTPUT: VERSIONED DELIVERY PACKAGE
CONTROL FRAMEWORK

Six controls your reviewers can follow.

01

Requirement-to-check matrix

Connect each required class, layer, attribute, tolerance and file format to a check method, responsible reviewer and acceptance rule. Record the specification version.

02

Approved pilot baseline

Review typical work and difficult cases together. Keep the accepted files and interpretation decisions as the reference for later batches.

03

Repeatable validation

Check applicable headers, reference systems, schema, required fields and file counts across the package. Record the tool, rule set and results so checks can be repeated.

04

Defined visual review

State which areas receive complete inspection and which are sampled. Record sample size, selection method, coverage and limitations rather than describing a sample as a full audit.

05

Location-based issue register

Give each issue an identifier, tile or feature reference, severity, evidence and owner. Track corrected, accepted-with-exception and unresolved cases separately.

06

Versioned acceptance package

Provide a file manifest, reference-system notes, check summary, known limitations and revision log as agreed. Corrected files identify the version they replace.

ACCURACY & LIMITATIONS

Passing file checks does not establish survey accuracy.

Schema validation, class counts and visual review answer different questions from absolute positional accuracy. An accuracy assessment needs suitable independent reference observations and a defined assessment method. If those inputs are unavailable, the report should say accuracy was not assessed.

For projects using the USGS Lidar Base Specification, checkpoints must be independent of acquisition calibration control. The applicable contract determines the required assessment and reporting. Read the USGS processing and accuracy requirements ↗︎

Corrections follow an agreed review window and resubmission process. New requirements are recorded as scope changes; unresolved source limitations remain visible for the client’s decision.

SPECIFICATIONS, NOT BADGES

Agree the version.
Define the evidence.

A standard only applies when it is included in the project requirements. File-format compliance, data quality and fitness for a particular design use are separate decisions. These references do not imply certification, endorsement or blanket compliance.

USGS Lidar Base Specification ↗︎ASPRS LAS 1.4 R15 specification ↗︎OGC CityGML versions and schemas ↗︎Client CAD template and software versionClient feature catalogue and tolerance rulesAgreed review coverage and acceptance plan
PLAN YOUR REVIEW

Define acceptance before production.

Bring a representative sample, the intended use and the specification you need to satisfy. We can scope the checks and identify missing inputs.

Discuss a production pilot ↗︎