Where review happens
The submission chain is the app → the Fieldwork API → the Lucia Booking Engine → the admin’s Maintenance Inbox, first proven end to end on 2026-08-10 (Wave 4 landed — enable replies, FILD-58). A manually filed issue travels the same chain as a chat-born one.
The Fieldwork App can display server-returned state for an issue it submitted. It does not own
the Maintenance Inbox, approve money, dispatch a vendor, schedule work, or decide that work is
complete.
Questions and replies after submission
A submitted item has one durable thread shared by the reporting employee and the authorized operator. It is separate from the draft conversation that produced the item. The employee sees operator replies on the submitted item and can answer there; the operator sees the combined chronology in the Maintenance Inbox.- Sent means the reply was accepted for delivery; Seen means the other party’s seen cursor has reached it.
- Amber Needs your reply state appears in Submitted, in the drawer count, and as a badge on the hamburger menu button, with an in-app notice on open when replies are waiting.
- Dismissed items keep their history visible but lock the employee composer.
- V1 sends only while online. A failed attempt remains truthfully not sent; there is no offline queue or push-notification-to-the-phone claim.
- Lucia does not draft, rewrite, or participate in these V1 messages.
- Every thread begins with the employee’s submission. An owner-started conversation with no issue behind it is Planned, not built (FILD-167, 2026-09-09).
- The email leg of the employee-facing maintenance thread rides Postmark; Postmark carries nothing else. Guest-facing mail is a different family on Resend and never reaches Fieldwork.
What the employee contributes
A reviewed Fieldwork submission can carry:- the observed maintenance or housekeeping problem;
- the property area and grounded description;
- employee-reported severity and guest impact;
- uploaded photos;
- an employee-reported assignee suggestion or estimate; and
- an explicit request for owner approval, when the employee chose that control.
What an owner or operator can trust
Use the canonical Maintenance Inbox record and its evidence, then record only what actually happened:- Approval requires an explicit authorized decision.
- Estimated cost remains separate from approved or incurred cost.
- Assignment requires a real assignment, not merely a suggested name.
- Scheduled requires a real date or confirmed slot.
- Completed and verified require their own evidence.
Reaching a record on the operator side
On the Linear record as of 2026-09-10, two admin changes concern how an operator lands on a Fieldwork submission: the operator push notification’s link now opens the Maintenance page on the referenced record (Push deep-link lands unfocused, LUCI-167, marked Completed 2026-09-10), and each maintenance record carries its own copyable link (Each maintenance record carries its link, LUCI-246, Finalizing). This page reports their record state only; it does not certify either on a served admin build.Approval and money boundary
Fieldwork’s approval and money contract is implemented across the App, API, and Engine, but the August 19 messaging round trip does not certify every approval or money action end to end. The message thread must not be treated as approval, assignment, scheduling, spend, or completion.When an owner or operator needs to act, use the Maintenance Inbox available in the target
environment and verify its actual state there. Do not treat this page or source identity as proof
that a particular approval, cost, reply, or verification control is deployed for every property.
Verification basis
Verified on September 10, 2026 against the evidence named in this page’s metadata,
including the founder-recorded Maintenance Inbox-to-phone round trip of 2026-08-19. That proof
covers the message loop, not every operator control or property. Admin-side items above are
dated by their Linear records, not by a served build.