Skip to main content
DoneThat

AI Adoption GuidePropertyOccupy

Move-In Condition Documentation

Computer vision processes move-in inspection photos to produce a structured defect report with annotated images, creating a defensible baseline for deposit dispute resolution.

Property processAcquireLeaseOccupyMaintainBillRenewVacateDispose

By Don, DoneThat’s AI coach · updated

Why move-in photos rarely become a usable baseline

A security deposit dispute is won or lost on what the unit looked like on day one. Most portfolios already collect that evidence: a stack of phone photos from the walkthrough, sometimes a checklist, sometimes a tenant signature on a PDF. Months later, when a resident contests carpet wear or a cracked tile, the file is often a folder of unlabelled JPEGs. Nobody can say which wall, which room, or whether the mark was already there.

The gap is not photography. It is structure. Photos without room, surface, defect type, and severity do not travel well into a ledger, a work order, or a tribunal pack. Staff who were not on the original walk cannot reconstruct a defensible baseline from a camera roll.

Computer vision can turn those photos into a draft defect report with bounding boxes and a room-by-room list. That draft is not the legal baseline. A named staff member still reviews, corrects, and signs it. Until that signature exists, the unit does not have a documented starting condition, only raw images.

What the vision pipeline extracts from a walkthrough

The input is the inspection photo set: typically one sequence per unit, captured during the move-in appointment. Each image should be tied to a unit identifier and, where the capture app supports it, a room label or a walkthrough order. The model does not invent rooms that the photos do not support.

For each readable image the pipeline proposes:

  • Room or area (kitchen, bathroom, bedroom, hallway, exterior door)
  • Surface or fixture (wall, floor, ceiling, cabinet, appliance, glazing)
  • Defect class (scuff, stain, crack, chip, hole, moisture mark, missing hardware, unclean area)
  • Rough severity (cosmetic, functional, safety)
  • A bounding box or polygon on the image
  • A short plain-language caption

The output is a structured record, not a paragraph of prose. Each proposed finding carries a photo reference so a reviewer can jump from the list to the annotated frame. Duplicate shots of the same mark are collapsed where overlap is obvious. Remaining duplicates stay in the draft for staff to drop.

The model does not score fair wear and tear as a legal conclusion. It describes what is visible. Wear versus damage is a staff and policy decision, recorded after review. Captions should stay observational ("linear scuff on hallway paint, approximately door-handle height") rather than accusatory.

Related occupancy tools sit beside this workflow. A 24/7 Tenant Query Agent can later point a resident to the signed baseline when they ask what was logged at handover. Space Utilization Analytics and an ESG & Energy Consumption Monitor answer different occupy-stage questions. They do not replace condition evidence.

How staff review and sign the draft report

Human-in-the-loop is the operating rule. The model drafts the defect report. Property staff still own the baseline.

Reviewers work from a split view: annotated images on one side, the finding list on the other. Typical edits are:

  • Merge two boxes that mark the same scratch
  • Reassign a room when the photo sequence was out of order
  • Downgrade or drop a false positive (a shadow read as a stain, a rug pattern read as damage)
  • Add a finding the model missed, using the same photo
  • Attach a note the tenant raised on site ("pre-existing chip, tenant agrees")

Only after those edits does a staff member sign. Signature means a person, a timestamp, and the unit identifier. The signed package is the baseline: the structured list plus the annotated images as they stood at sign-off. Later model runs do not silently rewrite a signed record.

If the tenant also signs, that is a separate acknowledgement on the same package. The vision draft never stands in for either signature. A supervisor may sample a share of signed files for missed defects or over-annotation. Sampling is quality control on the human step, not a second model pass that alters history.

When the system returns nothing

Empty output is the correct result when the inspection cannot be evidenced.

Return no findings, and do not fabricate a clean-unit report, when:

  • No inspection photos are attached to the unit's move-in event
  • Every image fails readability checks (too dark, motion blur, extreme close-up with no context, corrupt file, or frames that cannot be tied to the unit)
  • The capture is a single unreadable thumbnail or a screenshot of a document rather than photographs of the space

A "no defects detected" result is allowed only when photos are present, readable, and the reviewer agrees the frames show the claimed rooms. That is a signed negative finding, not an empty payload. Empty means we cannot document condition from this input. Staff then reshoot or complete a manual report. The system should surface the reason (missing set versus unreadable set) so the appointment can be recovered the same day.

Do not infer condition from older listings photos, marketing shoots, or the previous tenancy's move-out pack. Those archives can be linked as context. They are not this tenancy's move-in baseline.

Partial sets need the same honesty. If three rooms are photographed clearly and two are not, the draft covers only the readable rooms. The record should state which rooms have no usable frames rather than imply a whole-unit inspection.

Using the baseline at move-out and in disputes

At notice, staff run the same photo protocol. The move-out set is compared to the signed move-in package, not to the unsigned draft. Comparison is finding-to-finding where rooms and surfaces align: new marks, enlarged marks, and marks that match the baseline.

The comparison report is again a draft. Staff decide charge versus wear, apply house rules, and produce the deposit statement. The annotated move-in images are the exhibit that shows the starting point. The annotated move-out images show the end point. A dispute pack that leads with those two signed sets is easier to defend than a narrative written from memory.

Keep the chain of custody complete: who captured, who reviewed, who signed, which photo IDs were in the signed set. If a photo was excluded at review, leave that exclusion in the audit trail. When a resident asks for the condition file, send the signed package, not a regenerated model output.

Work orders that close move-in defects (a missing smoke-alarm battery, a broken blind) should reference the finding ID. Completing the job does not erase the baseline. It adds a dated repair note so move-out comparison does not treat a fixed item as if it were still broken, or treat a new break as if it were the original one.

What to keep in the property record

Store the signed structured report, the annotated image files (or lossless overlays plus originals), the reviewer identity, and the empty-output events. Empty-output events matter: they explain why a unit has no vision baseline and whether a reshoot happened.

Do not store a second, "improved" model version on top of a signed baseline. Retrain the detector for future walkthroughs. Historical signatures stay frozen. Retention should follow the same schedule as other deposit evidence for the tenancy, including enough time after move-out for dispute windows to close.

Process design is simple: photos in, draft out, human sign-off, freeze. When photos are missing or unreadable, the draft is empty and the file says so. That is the quality outcome for occupy-stage condition documentation: a baseline a manager can stand behind, not a camera roll hoping someone remembers the kitchen wall.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first