From two photographs to a reviewed change
My work on this prototype covers the capture interface, comparison rules, review flow, and browser storage. The goal is to connect observations about an asset across visits, with a reason attached to each accepted change.
The problem I wanted to explore
Two site photographs can show a difference without explaining it. An asset may be outside the frame, hidden behind equipment, or labeled differently on the next visit. A useful history needs the observation, the supporting capture, and the reviewer’s decision together.
One small workflow
- Capture: upload dated photographs and manually mark assets, reusing the same asset IDs across visits.
- Compare: choose a baseline and a later capture. The app compares recorded IDs and condition notes to propose changes.
- Review: accept or reject each proposal. An accepted change needs a verification note.
- Save: add a review message and reviewer name. The saved record keeps the proposals and decisions alongside both capture references.
The distinction that shaped the design
I used “not observed” for an asset missing from the next capture. Calling it “removed” would claim more than the photograph establishes. The same rule applies to “newly observed”: first sighting does not tell us when something was installed.
In the pump sample, the after photograph shows cleaning. A reviewer can describe the visible surface change while leaving the remaining pitting for further assessment. The app does not diagnose the equipment from the image.
How I kept the review rules separate
The comparison and commit rules live in a TypeScript domain module, separate from React. Observations are matched by asset ID. A changed condition note produces a proposal; image appearance and marker position do not establish identity.
Before creating a commit, the domain layer checks the capture order, requires every proposal to be resolved, and requires notes for accepted changes. It also blocks a second commit for the same capture pair. These checks can be tested without clicking through the interface.
Why browser storage came first
IndexedDB lets the prototype save captures and completed reviews without a backend or account setup. That keeps the first version focused on the review workflow. It also means work stays in that browser, rather than syncing between people or devices.
JSON export makes the workspace readable outside the app, but import is not implemented. Browser storage can be cleared, and uploaded images are resized rather than preserved as original files. Export is useful, but it is not yet a complete backup and restore workflow.
What works today
The prototype supports photo uploads, manual asset annotations, capture comparisons, accepted and rejected proposals, saved review history, an asset register, and JSON export. The pump and bridge samples let visitors try the review process without uploading their own photos.
There is no automated image recognition, shared workspace, authenticated reviewer identity, or tamper-resistant audit trail. Reviewer names and capture times are self-reported. This is a working prototype, with no customer adoption or inspection-accuracy results claimed.
What I would work on next
First, I would make export and import round-trip reliably and preserve original captures. Then I would test the review flow against a consented set of photographs from two visits to the same room. That would help identify where asset matching and review notes need more context before adding image analysis or collaboration.
Reality Commit is an independent project. The sample observations are educational and do not establish equipment safety or compliance. Photo sources and sample limitations ↗