You can write offline what you assert about your own work; you must be online to touch anyone else's record. That one sentence decides everything below, so there is no per-feature offline policy to keep in sync.
It moves the graph; it does not go into a photo feed. That is the line between what this product is and commodity daily-logs, and it is why capture is an action from a decision rather than a door of its own.
Two people photographing the same wall both produce valid records, and a late-syncing photo is never wrong, only late. That is the whole reason this set is writable offline — not a bet on sync quality, but a fact about the kind of thing it is.
Show the result, not the process. The photographs are there, the tick is ticked, and a quiet ring says the copy on the server has not caught up. A pending list would make him manage a transfer he has no way to help with.
Both are kept against Ridgeline with the time and where you were. When you are back we will ask you once what they are evidence of.
Capture into a cold cache anyway, and capture must be wired to a decision. Offline against an unread job both cannot hold. Held, not filed is the resolution: refusing loses what he came for, filing blind builds the photo feed the product exists not to be, and holding costs one question later, when somebody can actually answer it.
We do not have this one yet — it exists and you are offline — against that is not here, which means it does not exist. Telling a man standing on a job site that his job does not exist is the worst sentence in the state vocabulary.
The window delivery
Ana confirmed it by text at 7:12am
Rock in the trench
CO-2, sent Friday
Something else
Say what, and it files against that
Two photographs from 9:04am, at Ridgeline. They stay here until you say what they are, and nothing removes them.
It does not mean it disappears. An unanswered question about a photograph is a small untidiness; a photograph that vanished because nobody classified it is the thing a builder would never trust the product with again, and there is no recovering from that once.
The sentence means the app cannot do this for you — because it genuinely cannot. It does not know what he photographed, it will not guess, and it says so in his own terms rather than with a badge.
With the as-of line stated once at the top and never per card. Everything he can look at, he can look at; everything that touches somebody else's record waits, and the offline bar says which is which in one sentence rather than by graying out fourteen buttons.
You can write offline what you assert about your own work. You must be online to touch anyone else's record.
Writable: the builder's site capture — photos, checklists, notes — and the homeowner's inspiration capture, which is the same kind of thing seen from the other app. The homeowner's photo is not an exception being carved out; it is an observation, and the rule admits it for the same reason it admits his.
Read-only: everything else, on both sides. Deciding, signing, approving and answering all need current state to be safe. A signature queued against a change order that was superseded while he was in a basement is exactly the lie the freeze rule exists to prevent.
The internal capture-to-verify backstop as a workflow. Capture as an act is settled here and on 23-builder-money; capture as a verification system is deferred, and it is one of the places the source research reworks its own earlier answer.
What is here works with no signal. Most of it is what you have opened; the sheets you kept are here because you asked for them.
Not opened on this phone. There is nothing stored for either of them, and they will be here the moment you are back on signal and look.
There is no download button here. Opening a job is what puts it here, and the phone decides when to let go of it. A sheet you kept is the one thing you hold on purpose, and you stop keeping it from the sheet itself.
The obvious version has a download toggle per job, and it is wrong twice over: it is one more thing to maintain before driving somewhere with no signal, and it makes forgetting to tick a box the reason the binder was not there. Opening a job is the only gesture, and it is one somebody already makes.
A list of what is present answers the wrong half of the question. The reason to open this screen is almost always a specific job somebody is about to drive to, so the ones with nothing stored have to appear by name — a job that is simply missing from the list reads as a job that does not exist.
AE1 built 40 frame 6’s Save to my phone, and a sheet somebody chose to keep is neither of the two things this frame was drawn to report. So it gets its own row — and the screen head and the closing callout both said something that stopped being true the day it shipped. “Not what you have chosen to keep” and “no way to clear this” are corrected above rather than left standing, and Q238 is the ruling. The report still has no control on it: the release lives beside the save, on the sheet.
Frames 1 and 2 already establish that capture never depends on signal. Repeating it here is deliberate: this is the one screen where somebody is counting what they have, and that is exactly the moment they will wonder whether they can still record what they see.
Nobody has been told about this tick. Correcting it now costs nothing but a line.
0001_init.sql calls the tick a durable record of somebody standing in a house saying this was done, and POST /ticks is idempotent on (decision_id, item_key) so a retry in a dead zone cannot double it. A DELETE would make the record say the walk never happened, which is a different and less true claim than he ticked it and then said it was wrong. The correction is a second row of the same kind, and it inherits the offline behavior of the first for free.
Nobody has been told about this tick is the whole difference between a correction and a retraction. A tick that has already reached her Now and moved a decision cannot be quietly walked back, and this frame draws the easy case on purpose. What the harder case says is the second half of Q158.
AA3 shipped frame 1's checklist and the checklist cannot undo. No frame drew an un-check, §4 declares no route, and the plan refused to invent one against append-only rows: all three of those were right, and the consequence was that a mistap is a durable assertion with no affordance at all. Q158 asks whether a correcting line is the affordance, or whether a confirm-to-undo before anything syncs is the better answer.