Designing the QA pack acceptance criteria for your project

The QA pack article covered what should be in a pack. The reading residuals article covered how to interpret the most important page in one. This article is the procurement-side companion: how to write acceptance criteria into a contract so a QA pack can be objectively accepted or rejected, rather than negotiated after the fact.

It pairs with the procurement checklist and the reading proposals article as the contract-level companion to those brief-level pieces.

Contents vs acceptance criteria

Most QA-pack specifications stop at what should be included: metadata, residuals, classification quality, density map, sign-off. That's necessary; it isn't sufficient.

Contents answer: did the operator include this section? Acceptance criteria answer: did the section meet a defined threshold?

A pack can be complete in contents and unacceptable in results. A residuals page is present (contents pass) but reports RMSE of 80 mm against a 20 mm spec (criteria fail). A classification audit is included (contents pass) but shows 35% manual-correction rate on what should have been automated work (criteria warn).

Without acceptance criteria, the buyer's only contractual options at delivery are accept or initiate a dispute. With acceptance criteria, the conversation moves to specific clauses with specific remediation paths.

The six acceptance criteria worth pinning down

Six items where contractual thresholds eliminate post-delivery ambiguity:

1. Residual RMSE threshold + worst-case threshold

What to specify. Not just the RMSE target but the worst- case checkpoint residual that's tolerable.

Example clause.

"Acceptance: RMSE vertical at independent control checkpoints shall not exceed 22 mm aggregate, with no individual checkpoint residual exceeding 60 mm. Where any individual residual exceeds 45 mm, the operator shall investigate and document the cause in the QA pack."

Why the worst-case matters. RMSE alone hides outliers. Specifying both prevents a capture with 18 mm RMSE and a single 250 mm outlier from passing.

2. Cover-class stratification

What to specify. Residuals stratified by cover class with per-class thresholds.

Example clause.

"Residuals shall be reported stratified by cover class (bare, sparse, moderate, dense). Per-class RMSE thresholds: bare ≤22 mm, sparse ≤30 mm, moderate ≤45 mm, dense ≤80 mm. Any class breach to be documented with affected area, surface conditions and recommendation."

Why per-class thresholds matter. Aggregate RMSE can hide significant variance under canopy. Stratified thresholds ensure the dense-canopy areas the design will actually rely on meet a defensible spec.

3. Strip alignment residual threshold

What to specify. Post-alignment overlap discrepancy threshold per strip pair.

Example clause.

"Post-alignment overlap RMSE shall not exceed 20 mm per strip pair. Strip pairs exceeding 35 mm to be documented in the QA pack with remediation action. Per-strip transformations applied during alignment shall be documented in the QA pack (translations, rotations)."

Why this matters. Catches over-fitting issues per the strip alignment article and ensures the operator shows their work rather than burying significant transformations.

4. Classification accuracy threshold

What to specify. Class population sanity check + manual- audit confusion matrix threshold.

Example clause.

"Classification quality shall include: per-class point population in the QA pack; manual-audit confusion matrix from a randomly-sampled 200 points reviewed by hand; per- class precision and recall. Ground class precision shall exceed 98%, recall shall exceed 95%."

Why this matters. Quantifies classification quality beyond visual inspection. The audit sample doubles as a sanity check that the manual review actually happened.

5. Density coverage threshold

What to specify. Project-area percentage that must meet target density, and minimum acceptable per-cell density.

Example clause.

"Achieved point density at 1 m grid: at minimum 95% of cells within project boundary shall meet ground-classified target density of 60 pt/m²; no cell shall be below 25 pt/m² ground-classified. Density coverage map at 1 m grid to be included in QA pack."

Why this matters. Prevents the case where average density is fine but specific zones are sparse. Forces the operator to maintain density across the whole project, not just where it was easy.

6. Documentation completeness checklist

What to specify. Explicit list of QA pack sections with sign-off requirements.

Example clause.

"QA pack shall include all of the following, signed off by a reviewer independent of the processing team:

1. Project metadata header (project ID, dates, contributor)
2. Capture parameters (sensor, altitude, flight conditions)
3. Trajectory quality (PPK solution, covariance plot, base RINEX reference)
4. Strip alignment results (pre/post overlap residuals)
5. Independent control checkpoint residuals (per item 1, 2)
6. Classification quality (per item 4)
7. Density coverage map (per item 5)
8. Surface model QA (resolution, interpolation, hydro- enforcement breaklines)
9. Deliverable manifest
10. Sign-off block (named reviewer, date, role)"

Why this matters. A QA pack missing a section can't be objectively rejected without specific clauses requiring it. This list turns the QA pack into a checklist.

The accept / conditional / reject framework

Contracts benefit from three-tier acceptance language rather than binary pass/fail:

Clean accept. All six criteria met within threshold. No documented exceptions. Sign-off block complete. Payment proceeds per contract terms.

Conditional accept. Some criteria met within threshold; others within an extended tolerance band documented with explanation. Payment proceeds with documented exceptions noted; remediation either not required (the variance is acceptable in context) or scheduled separately.

Reject pending remediation. One or more criteria breached significantly. Payment held pending agreed remediation. The remediation path is pre-defined by criterion.

Example contract language for the three-tier framework:

"Deliverable acceptance: the QA pack will be evaluated against the six criteria above. Outcomes:

• Clean accept: all six thresholds met. Payment proceeds.
• Conditional accept: up to two criteria within 50% of threshold breach. Documented in delivery letter. Payment proceeds with noted exceptions.
• Reject pending remediation: any criterion exceeding 50% of threshold or more than two criteria in breach. Remediation path per attached schedule."

The three-tier framing avoids the all-or-nothing problem where minor exceptions trigger disproportionate dispute.

Pre-agreed remediation paths

For each criterion, the contract should specify what happens when it fails:

Residual RMSE breach. Operator investigates root cause; re-processes from archive if cause is processing; partial or full re-fly if cause is capture. Cost responsibility per attached schedule (typically operator-borne if breach exceeds 50% of threshold).

Cover-class breach. Operator documents affected area; either accepts the limitation in delivery, or schedules targeted re-fly of affected area. Cost responsibility per schedule.

Strip alignment breach. Operator re-runs alignment with adjusted parameters. If unable to bring within threshold, investigate boresight calibration ( the boresight article covers the root cause).

Classification accuracy breach. Operator runs additional manual review on misclassified areas; re-issues classified cloud with documented changes.

Density coverage breach. Operator documents affected cells; partial re-fly of low-density areas if material to deliverable; otherwise accept with documented limitation.

Documentation completeness breach. Operator adds missing sections from existing project records. Re-sign by independent reviewer.

Pre-agreed remediation paths convert "the delivery isn't acceptable" into "the delivery requires the following remediation per contract schedule X". Much more actionable.

The role of contract law vs operator goodwill

Without acceptance criteria, post-delivery friction depends on operator goodwill — most reputable operators will work to resolve issues anyway, but the buyer has no contractual basis for insisting.

With acceptance criteria:

• Specific clauses provide the legal basis for rejection
• Pre-agreed remediation paths reduce dispute over what should happen
• Cost responsibility is documented per failure mode
• Time limits on remediation can be specified
• Programme work has clear continuation thresholds

The intent isn't to be adversarial — most projects never invoke the rejection clauses. The intent is to make the acceptance process specific and objective so both parties share the same understanding of what's required.

Common acceptance-criteria mistakes

Three patterns in marginal contracts:

Writing vague criteria. "QA pack shall be acceptable to the purchaser" — gives the buyer veto without specificity. Reputable operators reasonably push back on this kind of language. The fix is to specify the threshold rather than delegate the judgement.

Setting unrealistic thresholds. Specifying ±10 mm RMSE under dense canopy is achievable with very expensive capture and a re-fly contingency budget; quoting against it inadvertently signals a project that may not be feasible at budget. Use realistic thresholds per the accuracy article.

Not including the underlying metric. "RMSE ≤20 mm" without specifying it's at independent checkpoints, vertical, against AHD — leaves operators free to report against a different measure. The clause needs to specify what the threshold is measured against, not just the number.

Forgetting documentation criteria. Specifying accuracy thresholds without specifying documentation requirements produces deliveries that meet the numbers but can't be verified. Both kinds of criteria are needed.

Programme-level acceptance criteria

For multi-cycle programmes (per the annual programmes article), acceptance criteria typically have both per-cycle and programme-aggregate components:

Per-cycle. Same six criteria above, applied to each capture.

Aggregate / trend-based. Across cycles, does the operator maintain consistency? Are residuals stable cycle-over-cycle or drifting? Is processing pipeline version stable?

Programme contracts benefit from trend-based criteria because they catch quality drift that per-cycle criteria miss. Example aggregate criterion:

"Aggregate cycle-over-cycle: residual RMSE shall not drift by more than 20% between consecutive cycles. Drift exceeding threshold to trigger root-cause investigation per attached schedule."

TL;DR

Acceptance criteria are the contractual companion to the QA pack contents specification. Without them, the buyer has no specific basis to accept or reject a delivery; with them, the process is objective and remediation paths are pre-agreed.

Six criteria worth specifying:

1. Residual RMSE + worst-case threshold
2. Cover-class stratification with per-class thresholds
3. Strip alignment residual threshold
4. Classification accuracy threshold (precision + recall)
5. Density coverage threshold (% of cells, minimum per-cell)
6. Documentation completeness checklist + independent sign-off

Three-tier acceptance framework (clean accept / conditional / reject pending remediation) avoids the all-or-nothing dispute trigger that binary frameworks create.

Pre-agreed remediation paths per criterion convert delivery problems from disputes into contractual processes. Most projects never invoke them; specifying them changes the dynamic before they're needed.

For programme work, add cycle-over-cycle trend criteria to catch drift that per-cycle criteria miss.