Week 15 · lesson
Stakeholder Report Review
A technical report fails when the reader cannot tell which statement is observation, which is measurement, which is interpretation, and which is recommendation.
The map may be correct and the report can still mislead the stakeholder.
The fictional report
A facilities report contains this paragraph:
The drone survey proves the northeast roof has exactly 18.437 m² of storm damage. The 3D model confirms the roof is structurally unsafe and should be repaired immediately.
That is a lot of confidence packed into two sentences.
Now compare it with the evidence packet:
- orthomosaic and point cloud reconstructed successfully;
- visible roof-surface discoloration exists;
- polygon annotation was drawn by a student analyst;
- checkpoint coverage is weak near the northeast roof;
- no structural engineering measurement was performed;
- source imagery shows only exterior visible condition.
The report overclaims badly.
Separate the claim types
Observation
A visibly different roof region appears in the northeast zone of the supplied imagery.
Measurement
The annotated polygon measures approximately X m² in the current mapped model.
Measurement requires validated scale/geometry and appropriate precision.
Interpretation
The region may be consistent with visible storm-related damage.
Interpretation needs context and should not become stronger than the source evidence.
Recommendation
A qualified facilities professional should inspect the area directly.
Recommendation is an action based on the evidence and its limitations.
These four sentence types should not blur together.
A drone image cannot diagnose what it cannot observe
A roof image may reveal:
- displaced material;
- visible debris;
- staining;
- missing shingles;
- surface deformation visible from the camera angle.
It cannot automatically establish:
- internal structural integrity;
- moisture hidden beneath materials;
- exact cause of damage;
- code compliance;
- engineering safety rating.
Those claims require different expertise and evidence.
The strongest report knows when to stop.
Make limitations visible near the claim
Do not hide the important limitation three pages later.
If a measurement near the project edge has weaker checkpoint coverage, say so next to the measurement.
If an annotation is analyst interpretation, label it.
If the dataset was designed for visual inspection rather than survey-grade measurement, state the intended use prominently.
Stakeholders often skim. The report design should make misuse harder.
Use source traceability
Every important finding should be traceable to evidence.
A compact system can use IDs:
Finding F-03
→ Orthomosaic zone NE-2
→ source images IMG_071–IMG_078
→ annotation A-04
→ checkpoint review Q-02
→ limitation L-03
Now another reviewer can reconstruct how the conclusion was formed.
A screenshot pasted into a slide with no source path is much weaker.
Worked rewrite
Original:
The drone survey proves the northeast roof has exactly 18.437 m² of storm damage and the roof is structurally unsafe.
Rewritten:
The supplied orthomosaic shows a visibly abnormal region in the northeast roof zone. A student-drawn polygon measures approximately 18 m² in the current model; however, checkpoint coverage is limited near that project edge, so the value should be treated as an estimate rather than high-precision area evidence. The imagery does not establish internal structural condition. Direct inspection by the appropriate facilities professional is recommended.
The rewrite is less dramatic and much more useful.
Report the quality of evidence, not your confidence level
Avoid:
We are 95% confident this is damage.
unless a defined statistical process actually supports that number.
Instead report evidence properties:
- image coverage strong/weak;
- checkpoint distribution;
- measurement error evidence;
- annotation source;
- surface obstruction;
- missing viewpoints;
- unresolved interpretation.
Confidence should come from the process, not personality.
Stakeholders need action thresholds
A report becomes more useful when it distinguishes:
- informational finding — useful context, no immediate action;
- review finding — needs human/qualified inspection;
- mission-data defect — recapture or reprocess before interpretation;
- unsupported claim — should be removed from the report.
Do not turn every colored annotation into an emergency.
Build a stakeholder report review
Take a supplied report draft and mark each major sentence:
OBS— observation;MEAS— measurement;INT— interpretation;REC— recommendation.
Then check:
| Question | Result |
|---|---|
| Can every measurement trace to validation evidence? | |
| Are annotations identified as analyst-added? | |
| Is precision consistent with demonstrated accuracy? | |
| Are weak coverage areas disclosed? | |
| Does the report claim expertise the dataset does not have? | |
| Can stakeholder action be justified from the evidence? |
Rewrite at least three weak sentences.
Presentation quality is not evidence quality
A clean layout, 3D animation, company logo, color gradient, and professional typography can make a report easier to read.
They cannot strengthen the underlying measurement.
This matters because polished visualization increases persuasive power. Weak evidence presented beautifully can be more dangerous than weak evidence presented badly.
A technical communicator has to prevent design quality from impersonating measurement quality.
Your final report disposition
Choose:
- ready for stakeholder review;
- revise claims/limitations;
- revise evidence package;
- not suitable for the intended decision.
Defend the disposition with two specific report defects or strengths.
Unit 5 conclusion
Weeks 13–15 built the complete mapping evidence chain:
geometry → capture quality → reference/control → reconstruction → validation → product → stakeholder claim.
If the claim gets stronger at the end than the evidence was at the beginning, the project has failed even if the map is gorgeous.