A model can finish processing before the job is finished.
The software has a fairly narrow definition of success: it reached the end without crashing and wrote some files. The person opening those files has a different question. Can I use this for the thing I asked you for?
This month, we put more of that second question into writing. We revised Atlas’s offering scope around three visual outputs, each with an explicit purpose and a way to check the handoff. The revised services and scope are now reflected on this website.
The interesting part is what counts as finished.
Three different reasons to look at a place
“Capture my property” sounds like a brief. It still leaves most of the job undecided.
Someone might want an aerial overview they can label and share. Someone else might want to explore a building in 3D. A third person might need dated images that let them look back at how a site appeared before work started.
Those requests can involve the same aircraft and the same property. They ask different things of the result.
Our revised scope gives them separate names.
Property Overview is an aerial view with visual labels and annotations, a browser view, and a printable overview. The check is straightforward: does it represent the agreed capture area, are the labels reviewed, do the files open, and have we identified what is obscured?
Atlas Worlds is a visual 3D reconstruction you can explore in a browser. The agreed views need to load on the devices named in the scope. Capture gaps and visible reconstruction artifacts need to be disclosed.
Site Record is dated aerial imagery with comparable views over time. The dates and coverage need to be recorded, the comparison views paired, and differences in conditions or visibility explained.
That last detail matters. A tree with leaves and a tree without leaves can give you two very different views of the same ground. Before interpreting a difference, you need to know what each capture actually shows.
The workstation is a forgiving audience
A reconstruction can look excellent on the machine that made it. That machine already has the files, the software, and an operator who knows where to look.
The recipient may have a phone.
That makes “opens on the agreed device” a delivery requirement. So are the less photogenic details: which files are included, how long viewer access lasts, what revisions are covered, and when delivery is due.
Our scope document now requires those details in each quote.
There is no dramatic screenshot of a clearly stated retention period. We will have to survive without one.
What the view can support
We also narrowed what belongs in these visual scopes.
They exclude boundaries, setbacks, measured siting, contours, volumes, design, safety determinations, and certification. Requests involving those outputs need a separate scope review. The licensing and delivery arrangement for measured services remains unresolved.
A sharper image does not resolve that arrangement. Neither does a confident sentence underneath it.
For a visual overview, the useful question might be: can everyone looking at this understand which building or access route we are discussing? For a site record: can we find the right date and compare the agreed views? For a browser reconstruction: can the recipient explore the parts of the place we agreed to show?
Each is a worthwhile result with a specific limit. Naming that limit belongs in the agreement before capture.
Write the ending first
Our July field note was about planning the flight around the output. September adds the next question: how will we know the output is ready to hand over?
That answer needs to exist before processing starts.
It tells us what to capture, what to check, what to disclose, and what to ask when a request is still vague. It also gives the recipient something more useful than our assurance that the model looks good.
The processing bar can tell us when the computer is finished.
The scope should tell both of us when the job is.