The super walks the building with a 360 camera on their hard hat, and by the time they are back in the trailer the capture has been processed into a progress map, what is installed, what changed since last week, and which activities are drifting behind the baseline. Turning that capture into the weekly progress report the PM and owner read used to mean a human reconciling photos against the schedule by hand; now the AI drafts it. But this is the lesson where the computer-vision discipline from Level 1 meets the language-drafting discipline, because the report is built on vision data that is right about ninety percent and a narrative that will confidently state whatever it is fed, which is exactly how the infamous "slab in progress" report happened. This lesson shows you how to produce the weekly progress report fast while catching the vision misreads before they reach the owner.

The Two Engines in One Report, and Where Each Fails

The weekly progress report from a 360 capture runs on two of the four engines stacked together, which is what makes it both powerful and a specific trap. The computer-vision engine reads the capture and determines what is installed, what changed, and what is behind, the progress data. The generative-AI engine takes that progress data and writes the narrative report, the prose the PM and owner read. Each engine has its Level 1 failure mode, and in this report they compound: the vision is right about ninety percent and misses or misreads the unusual conditions, and the narrative will confidently state whatever the vision data says, so a vision misread becomes a confidently-stated false claim in the report.

This is exactly the mechanism of the "slab in progress" failure from the jobsite lesson: the vision engine misread a finished slab as in-progress, and the narrative engine confidently reported it as in-progress, and because the report read authoritatively, it went to the owner as fact. The two engines stacked means the verification has to address both: you check the vision data for the misreads, especially in the conditions where vision is weak, and you check the narrative for confident statements built on those misreads, because the narrative inherits the vision's errors and presents them with unwarranted confidence. The report is fast because both engines are fast; it is dangerous for the same reason, and the verification is what stands between the stacked speed and a confident false report to the owner.

Baseline Drift Detection: The Genuine Analytical Value

One capability in this workflow is truly valuable and worth understanding: baseline drift detection, where the AI compares the captured progress against the schedule baseline and flags the activities falling behind, for instance the activities more than seven days behind their early start. This is the computer-vision progress data meeting the schedule, and it turns the capture into an early-warning system: instead of the super manually noticing which activities are slipping, the AI surfaces the drift automatically by comparing what the capture shows is built against what the baseline said should be built by now.

The drift detection is valuable because it is the leading indicator a super needs, the same role as the slip detection in the look-ahead lesson, but grounded in visual evidence of actual installed work rather than self-reported progress, which makes it harder to game and more objective. An activity flagged as seven days behind early start, with the photo evidence showing what is actually installed, is a concrete, evidence-backed early warning the super can act on. The posture is the predictive-attention one: the drift flag surfaces where to look, and the super verifies the flag against reality and decides what it means, because the drift detection inherits the vision's ninety-percent accuracy, so a flagged drift might be a real slip or a vision misread of the progress, and a real slip might be missed where the vision is weak. The drift detection is a strong early-warning tool precisely because it is evidence-backed, and it is still a candidate the super verifies, not a verdict, because the evidence is read by a ninety-percent engine.

Baseline drift detection turns the capture into an early-warning system grounded in visual evidence of actual installed work, harder to game than self-reported progress. But it inherits the vision's ninety percent, so a flagged drift is a candidate the super verifies against reality, not a verdict.

The Verification: Catching the Misreads Before the Owner

The verification on this report is the computer-vision discipline from Level 1 applied with the jobsite lesson's hard-won lesson, and it targets the specific places the vision fails. You review the AI's progress callouts against what you, the super who walked the building, actually know is there, hunting specifically for the misreads in the conditions where vision is weak: the half-finished trades that do not look like the finished training examples, the occluded work, the unusual conditions, the transitional states like a slab that is finished but reads as in-progress. The super's walk-through knowledge is the ground truth, and the verification is checking the AI's report against that knowledge before it goes out.

The two failure directions both matter here. A false positive, the AI reporting something as installed or complete that is not, would overstate progress to the owner, which is its own problem if the owner relies on it for a pay application. A false negative or misread, the AI reporting a finished condition as incomplete or missing a real drift, would understate progress or miss a slip the super needed to flag. So the verification confirms the report's progress claims against the super's knowledge, corrects the misreads, and documents the corrections, because a progress report to the owner is a record the owner relies on, and a confident vision misread in it is exactly the "slab in progress" failure that destroys the super's credibility when the owner notices. The report is the super's report, drafted by AI from vision data, verified by the super against what they know is actually built, which is the division that keeps the speed and stops the misread.

Why the Owner Report Is a Credibility Document

The weekly progress report deserves particular care because it is a credibility document, the regular communication that shapes the owner's trust in the super and the team, so an error in it costs more than the specific mistake. When a super sends a report that says a slab is in-progress and the owner walks the site and sees it finished, or sees a trade reported as on-site that demobilized Friday, the cost is not just the wrong fact; it is the owner's trust in every future report, because now the owner reads every report wondering what else is wrong. The report's value depends on the owner trusting it, and a confident AI misread that the owner catches undermines exactly that trust.

This is why the verification is not optional polish but the thing that protects the report's entire purpose. A fast report that the owner cannot trust is worse than a slower report the owner relies on, because the report exists to inform and reassure the owner, and a report that does that wrongly does the opposite. The discipline is that the speed of the AI-drafted report is captured only when the super's verification makes it trustworthy, so the super uses the recovered time not to send more reports faster but to ensure the report that goes out is accurate, because the owner relationship the report builds is worth more than the minutes the AI saved. The AI drafts the report from the capture; the super's verification is what makes it a report the owner can trust, and that trust is the report's actual value, which the verification protects and a confident misread would destroy.

The Photo Evidence and Why It Changes the Report

A distinctive strength of the capture-based report is that every progress claim can be backed by photo evidence from the capture, which changes the report from assertion to documentation and is worth using deliberately. When the report says a trade is behind, it can show the photo of what is actually installed in that area, so the owner is not asked to take the super's word but is shown the evidence, which makes the report more credible and more useful, and which also creates a time-stamped visual record that is valuable later if the progress becomes disputed. The photo evidence is the capture's unique contribution: a written progress report asserts, while a capture-backed report documents.

This photo-backing also disciplines the report in a useful way, because a progress claim that has to be backed by a photo is a claim the super can check against the photo, which is part of the verification: does the photo actually show what the callout claims? A callout that says complete with a photo showing incomplete work is a misread the photo itself exposes, so the photo evidence is both the report's credibility feature and a verification aid, letting the super confirm each callout against its own evidence. The discipline is to use the photo evidence as both, presenting it to the owner for credibility and using it to verify the callout, because a callout backed by a photo that contradicts it is worse than no photo, so the verification confirms the photo supports the claim, turning the evidence from a credibility feature into a verified one. The report that documents with verified photo evidence is far stronger than one that merely asserts, which is the capture's real advantage when the evidence is checked.

Observed Progress vs. Self-Reported Progress

There is a deeper shift the capture-based report represents, worth naming because it changes the reliability of progress reporting: it moves progress from self-reported to observed. Traditional progress reporting relies on trades and supers reporting what they completed, which is subject to optimism, pressure to show progress, and honest error, so reported progress can drift from actual progress in ways that surface late. A capture-based report grounds the progress in what the camera actually saw installed, which is observed rather than reported, and observed progress is harder to inflate because the evidence is the installed work itself.

This matters because observed progress is more objective and more reliable for the decisions that depend on it, the schedule status, the pay application, the owner's understanding of where the project really is, and grounding those in observation rather than self-report reduces the optimism and error that self-reporting carries. But the observation is the ninety-percent vision engine, so observed does not mean infallible, it means grounded in evidence that itself must be read correctly, which is why the super's verification of the vision's reading remains essential, the human confirming that the camera's observation was interpreted right. The shift from self-reported to observed progress is a genuine improvement in reliability, harder to game and more objective, and it is bounded by the vision's accuracy, so the super's verification is what completes the shift, turning the camera's observation into verified observed progress rather than merely a different source of potentially-misread data. Observed-and-verified progress is the reliable basis the report should rest on, which is the capture plus the super's check together.

The Applied Problem: Produce the Report and Catch the Misreads

Here is the exercise. Take a real or representative OpenSpace capture, generate the AI weekly progress report mapped to your look-ahead with baseline drift detection, and produce the report a super would actually send to the PM and owner, identifying the two callouts the AI got wrong and documenting the verification override. Run the workflow: the capture is processed into progress data, the AI maps it to the look-ahead and flags the drift and slip with photo evidence and drafts the report; you review the report against your walk-through knowledge, hunting the misreads in the weak-vision conditions; and you correct the errors and document the overrides before the report goes out.

Produce two things. First, the corrected weekly progress report, mapped to the look-ahead with the verified drift flags and photo evidence, in the form the super would actually send to the PM and owner. Second, the verification override record: the two (or more) callouts the AI got wrong, what it claimed, what is actually true from your walk-through, and the correction, because that record is both your verification evidence and a log of where the vision tends to misread on this project, which sharpens future verification. The two-callout target is deliberate: on a real capture you will find misreads, and finding them is the point, because the super who finds two misreads before the report goes out is the super who does not send the "slab in progress" report.

The deliverable is the verified report and the override record, and the lasting product is a weekly-report workflow that captures the speed of AI-drafted progress reporting while the super's verification catches the vision misreads before they reach the owner and erode trust. This is the field-reporting core of the chapter, and it combines two of the level's threads: the computer-vision discipline of verifying the ninety-percent vision data and the language discipline of catching confident false statements, both applied to a credibility document. The super who masters this sends accurate, evidence-backed progress reports fast, building owner trust rather than risking it, achieved because the AI drafted from the capture and the super verified against what they walked, which is the only way the stacked speed of vision plus narrative is safe to send to an owner.

Key Takeaways

• The weekly progress report stacks two engines: computer vision reads the capture for progress, and generative AI writes the narrative. Their failures compound, the vision is right about ninety percent and the narrative confidently states whatever the vision says, which is exactly the "slab in progress" mechanism.
• Baseline drift detection is the genuine analytical value: comparing captured progress against the schedule baseline and flagging activities behind (for instance more than seven days behind early start) turns the capture into an early-warning system grounded in visual evidence of actual installed work, harder to game than self-reported progress.
• The drift flag inherits the vision's ninety percent, so it is a candidate the super verifies against reality, not a verdict; a flagged drift might be a real slip or a misread, and a real slip might be missed where vision is weak.
• The verification targets the weak-vision conditions, half-finished trades, occluded work, transitional states like a finished slab reading as in-progress, checking the AI's progress callouts against the super's walk-through ground truth. Both directions matter: false positives overstate progress, misreads understate it or miss a slip.
• The report is a credibility document: an error the owner catches costs not just the wrong fact but the owner's trust in every future report. A fast report the owner cannot trust is worse than a slower one they rely on, so the verification protects the report's entire purpose.
• The super uses the AI's recovered time not to send more reports faster but to make the report that goes out accurate, because the owner trust the report builds is worth more than the minutes saved.
• The artifact: generate the AI weekly report from a real capture with baseline drift detection, produce the report the super would send to the PM and owner, identify the two callouts the AI got wrong, and document the verification override, which also logs where the vision tends to misread on this project.