Field notes for project teamsEvidence before assertion
Stellarnoodlenesscn
Evidence practice / 04

REVIEW THE EXCEPTIONS

An evidence gap is not a failure to report. It is a clear signal that the claim needs another view, another record, a qualified statement or a human decision.

Exception note

Make the uncertainty actionable.

Progress tracking systems can surface missing captures, changed conditions, inconsistent locations and unexpected visual differences. Those signals should create a review task—not a silent downgrade, automatic completion or unexplained percentage.

Write down what is uncertain, why it matters, who owns the next check and what would resolve it. Keep an unresolved item visible until an authorized reviewer closes it.

Exception checklist

Use this checklist alongside project procedures. It is a prompt for review, not an automatic acceptance or rejection rule.

CAPTURE
  • Is the expected image missing, late or unreadable?
  • Did the viewpoint, direction, lighting or framing change?
  • Is the work obscured by temporary materials or access limits?
  • Does the image show the intended location and scope boundary?
RECORDS
  • Does the image location conflict with its metadata or field note?
  • Is the drawing revision current and applicable?
  • Are programme status and inspection records inconsistent?
  • Is a required test, delivery record or sign-off unavailable?
INTERPRETATION
  • Could a visible change have another explanation?
  • Is image classification uncertain or unsupported by context?
  • Does the image omit concealed or quality-critical conditions?
  • Would the claim imply acceptance beyond what is recorded?
ACTION
  • Name an owner and an expected follow-up.
  • Request a safe, targeted view or required project record.
  • Qualify the statement or defer it pending review.
  • Document the resolution and who made the decision.
From flag to decision

DO NOT LET AN ALERT BECOME A VERDICT

A discrepancy alert can help a team direct attention. It does not establish non-compliance, defect, delay or completion. Verify the source and context before drawing a conclusion.

Return to milestone review →

Make exceptions specific

A useful exception describes the evidence issue without overstating its meaning. “Expected west elevation view for Zone C is absent from the 14 June capture set” is actionable. “Zone C is behind” may not be. The first identifies a missing item and a place; the second turns a missing view into a schedule conclusion without sufficient basis. Where possible, include the capture point, milestone, date, source record and consequence for the assessment.

Classify the issue in language the team understands: missing, unreadable, location mismatch, revision mismatch, obstructed, changed viewpoint, conflicting record, uncertain detection or human sign-off pending. Do not create dozens of labels that differ only slightly. A concise reason helps the owner decide whether to recapture, correct metadata, locate a controlled document, inspect the work or qualify the report.

Distinguish kinds of uncertainty

Some uncertainty is about the data: the timestamp may be wrong, a file may be duplicated or a drawing revision may be unclear. Some is about coverage: the relevant area is outside the image, blocked or captured from a different angle. Some is about interpretation: a model or reviewer cannot distinguish materials, stages or temporary work. Other uncertainty is procedural: the right inspection, test or authorization is pending. These situations need different responses. A new image can help coverage, but it cannot resolve every quality or acceptance question.

Record uncertainty in proportion to its impact. A minor blur outside the claimed boundary may not affect an assessment; an obstruction over a critical connection may. Explain the relationship to the milestone definition and route significant questions to the person with the required project knowledge or authority. Do not convert confidence scores into unsupported claims about work complete.

Assign and close the follow-up

Every actionable exception needs an owner, a next step and a status. The owner may need to capture a view, confirm an identifier, retrieve an inspection entry, resolve a scope revision or ask an authorized reviewer to visit the work. Set a sensible due point related to the reporting cycle rather than leaving an open task without context. If the issue cannot be resolved before a report, state the limitation and its effect on the claim.

When an item is resolved, preserve both the original flag and the resolution. Record who reviewed it, what new evidence or explanation was considered and whether the milestone statement changed. If the original detection was a false alarm, note why. This helps improve capture instructions and data matching while avoiding a misleading history in which the system appears never to have been uncertain.

Use trends carefully

Repeated exceptions can reveal process friction: a viewpoint may be inaccessible, metadata capture may be inconsistent or several records may use different zone names. Teams can use those patterns to improve their routines. But a high count of flags is not itself proof of poor progress, and a low count is not proof of complete evidence. The pattern needs to be interpreted alongside scope, capture coverage and project context.

Be cautious when comparing teams or contractors using raw exception totals. Projects differ in size, complexity, safety constraints and capture frequency. If metrics are used internally, define what is counted, state the limitations and avoid using an automated signal as a substitute for fair, contextual review. Give affected people a way to correct inaccurate data.

Protect people and sensitive site information

Images may include workers, visitors, neighboring properties, access controls or commercially sensitive layouts. Follow project policies for capture, access, storage, retention and sharing. Restrict exceptions and evidence packs to people who need them. Apply the project’s process if material requires masking or removal, and preserve an appropriate record of any derivative used for review. Avoid broad distribution simply because an automated tool flagged an image.

The central principle is practical: a flag tells the team where the evidence chain needs attention. It does not announce what the work means. Keep the claim, source imagery, project records and reviewer decision connected, and make open questions visible until someone with the right context resolves them.

All diagrams and sample checks on this page are illustrative, not actual project records.