AI Office Field: from site reports to accepted work and documents

By the end of the day, a site sends photographs, voice messages and a brief “done”. The supervisor has notes, the office has a spreadsheet, and the estimate uses different work descriptions. Establishing what was actually completed, checked and accepted requires another round of calls and manual reconciliation.

AI Office Field is a proposed additional AI Office module for construction, installation and building operations. Its purpose is to connect assignments, employee reports, review and document preparation. This article describes a development and pilot concept. A finished Field mobile module is not currently part of the product.

Consider an office fit-out. A crew installs equipment, finishes conceal some work, two items need correction, and additional work is agreed verbally. A week later, someone must reconstruct quantities, explain deviations and establish which items can enter the customer's documents.

The gaps appear between events. A photograph has no estimate item attached. “Done” does not establish acceptance. Presence on site does not explain how much time went into installation, waiting for materials or correcting defects. Even a well-organised file archive cannot connect these facts on its own.

A useful workflow links contract or service request → assignment → report → review → accepted quantity → documents and management records. AI can help transfer information between stages while preserving its source and status.

Products already address this market. PlanRadar, for example, describes document management, reporting and schedules across construction and building operations. A site photo report is not a new product category. Field's proposed role is to connect field data to the wider AI Office workflow for tasks, documents and approvals. PlanRadar · Construction and real estate management platform ↗

In the proposed scenario, an employee opens a phone assignment showing the site, zone, work item, unit, target and current instruction. “Install profiled sheeting on the warehouse west façade, item 24, shift target 40 m²” is more useful than “continue the façade”.

The assignment should include the relevant drawing and version. In maintenance, it might show a QR-tagged asset, room, service procedure and fault history. The employee needs to know both the object and the expected outcome.

Starting and finishing require a short action. The employee adds photos and records a message: “Installed 42 square metres; four need rework; we need more fasteners tomorrow.” AI suggests a draft quantity, defect note and material requirement. The employee checks those fields before submission.

Numbers and units deserve particular care. Linear metres must not silently become square metres, and a voice transcription is not a verified measurement. An unclear value should prompt clarification. Manual entry remains necessary when recognition fails or the model is unavailable.

The supervisor receives the assignment, report, photographs, claimed quantity and blockers together. They can accept everything, accept part or return the work with a reason. This review turns an employee's report into a confirmed fact for internal records.

Take an illustrative work item totalling 200 m². Before today's shift, 80 m² had been accepted. The crew reports another 42 m², but the supervisor accepts only 38 m² because 4 m² require rework.

Progress based on internal acceptance is 118 / 200 = 59%. The remaining 82 m² include the four awaiting rework. Those four cannot count as both accepted and outstanding. Once corrected, their acceptance adds only 4 m², rather than counting the original report again.

This requires separate reported, accepted and returned quantities, a link between a resubmission and its original report, and a history of decisions. Correcting an accepted record should create a new version requiring review. Silently editing the past undermines the cumulative total.

A useful report distinguishes what was claimed, what was checked and what was accepted. One “completed” field cannot represent all three states.

Internal supervisor acceptance also does not establish customer acceptance or permission to issue a payment document. Subsequent steps depend on the contract and the agreed document workflow.

A photo can show an installation detail, a defect or work before it is concealed. To remain useful a month later, it needs an assignment and zone, an author, an upload time, a description and a link to the review decision. For concealed work, the required views and capture stage should be defined in advance; a responsible specialist assesses whether the evidence is sufficient.

An ordinary photograph does not guarantee an accurate area, length or installation-quality assessment. In the basic scenario, a person enters quantities or supplies an agreed measurement. Computer vision could be explored separately for a narrow task with known scale and capture conditions, with errors evaluated on real sites.

Location is another contextual signal. Android allows users to grant approximate rather than precise location. A map point therefore cannot establish presence in a particular room with certainty. Android Developers · Request location permissions ↗

For Field, a reasonable design would collect location at agreed events, such as starting an assignment, and show its available accuracy. Floors, rooms, building axes or asset QR codes may be more useful inside a large complex. If location is unavailable, the report should flag that for review without discarding the work record.

Employees should understand the collection purpose, see relevant records and have a correction process. Retention, access and the basis for processing need to be defined before a pilot. Hidden continuous tracking and automatic accusations based on a single location mark are outside the proposed scenario.

Start and finish events can populate a draft timesheet. The interval may also contain a break, travel, waiting for access or a forgotten clock-out. The company defines paid-time rules and corrections; a button press does not itself calculate payroll.

Accepted quantities can feed work registers and document drafts. Each item should retain its work reference, period, supporting evidence and responsible reviewer. A specialist checks the contents, details, applicable format and approval route before a document is issued.

Employees and subcontractor crews may have different accounting and payment rules. Combining them into one automatic “earned” field would undermine accuracy. The accounting model comes first, followed by calculation rules and then document preparation.

Useful project states include reported by the worker, accepted internally, included in a draft document, agreed with the customer and passed for settlement. The register then shows exactly where processing has stopped without implying automatic formal acceptance.

A familiar request on site is “move three more lights”. In the Field concept, that becomes a separate change request with a description, initiator, location, photos, estimated quantity and effect on current assignments. AI may help organise the information, but an authorised person must approve a change to the baseline estimate.

Estimate and assignment versions should remain available. Otherwise, it becomes difficult to explain why scope and cost increased. Work accepted internally but missing from customer documents is especially useful to surface: it warrants a documentation check, not automatic revenue recognition.

A fastener shortage should become a specific requirement: which item, how many, for which assignment and by when. After review, it can feed a procurement task. If the delivery date is unknown, the system should expose that uncertainty rather than invent a precise completion forecast.

Plan-versus-actual tracking needs comparable measures: accepted versus planned quantities, confirmed versus estimated time, and actual versus specified materials. A deviation needs an explanation, such as changed scope, rework, a late delivery or a poor estimate. A red percentage alone does not support a decision.

The baseline schedule, current forecast and approved revised plan should remain distinct. A later forecast must not rewrite the original commitment. Historical records can eventually improve estimates for similar work, provided conditions, crew composition, units and data quality are considered.

Basements, plant rooms and remote sites may lack a stable connection. Employees need access to previously downloaded assignments and must be able to save reports and photos locally for later transfer. Flutter's documentation describes offline-first patterns using local and remote data with explicit synchronisation logic. This is an architectural reference, not a selected Field technology. Flutter · Offline-first support ↗

Users need three separate states: saved on the phone, received by the server and accepted by the reviewer. If photos are still uploading, the interface should say so. Sending the text alone must not make the entire report appear delivered.

Retrying after a connection failure must not create a second shift or count accepted work twice. Stable identifiers, duplicate detection and conflict handling are necessary. If an assignment changed while the phone was offline, the employee should see the difference and follow an agreed update process.

A mobile web form could be an initial prototype, but identical background uploading cannot be promised across phones. MDN marks the Background Synchronization API as having limited browser availability. Behaviour after closing the app, locking the screen and restoring connectivity needs testing on the intended devices. MDN · Background Synchronization API ↗

An office-based AI station does not remove the distance to the site. During an outage, management sees the last received data with its update time. Local work may continue, while a current consolidated view must wait for synchronisation and review.

The proposed architecture uses the shared AI Office core for users, tasks, documents, permissions and approvals. Field adds site-specific records: zones, work items, shifts, reports and quantity decisions. A photograph then remains part of an assignment and its workflow rather than becoming another detached archive file.

An executive assistant could answer “What is blocking this stage?” or “Which quantities await review?” with original reports, task owners and data freshness. Procurement receives a confirmed requirement; document workflows receive accepted items. These connections still need implementation and validation. A shared core does not mean that every integration already exists.

If a company already uses construction or maintenance software, its API or export should be assessed first. Reliable integration needs stable identifiers, statuses, original attachments and change history. A final PDF may help a person while remaining insufficient for dependable automated quantity exchange.

Responsibilities should be explicit:

• Software rules calculate quantities and time, enforce permissions and versions, detect duplicates and validate status transitions.
• AI transcribes speech, suggests report fields, retrieves instructions with sources and helps explain deviations.
• People confirm inputs, accept quality and quantities, approve changes and authorise documents.

The basic assignment-to-acceptance workflow should remain available when the language model is unavailable. An AI response must not independently close a defect, alter an estimate or replace a qualified specialist's decision about safe work.

In a local-first scenario, primary documents and processing can remain in company infrastructure. An external model is used only for agreed tasks and data. The phone nevertheless becomes another storage location for assignments, photographs and unfinished reports.

Device protection, local cache scope, backups and recovery therefore need attention before a pilot. Revoking server access does not immediately erase data from a lost phone that remains offline. Mobile technology and local access expiry should account for that limitation.

Workers should see the assignments they need, supervisors their own areas, and office staff the information their roles permit. A future customer or investor portal should expose only separately approved material. Internal calculations, employee data and unrelated projects must not become accessible simply because progress photographs are shared.

The same principle applies across a property's lifecycle. Construction centres on quantities and intermediate acceptance. After handover, the focus shifts to assets, service requests, preventive maintenance and fault-resolution history.

A ventilation installer needs the task linked to an assembly and drawing. A service engineer needs equipment history and a maintenance record. A property manager needs recurring-fault explanations and outstanding issues. Cleaning, grounds maintenance and furniture installation can also use short reports with clear review criteria, although forms and units will differ.

Later development could explore QR-based tool issue and return, warranty history, concealed-work evidence and crew scheduling that considers qualifications and material availability. Each direction needs its own rules and validation. An initial pilot is better scoped to construction or building-services maintenance and a few recurring work types.

A practical starting point is one process, a small team and a defined outcome. Two sites and three work types could test assignment delivery, photo reporting, partial acceptance and transfer of accepted quantities into a register. These are illustrative pilot boundaries, not a declared product capacity.

First, establish a reliable manual workflow. Then add voice entry and check whether it reduces completion time without increasing errors. Schedule prediction and image-based measurement can be considered once suitable evaluation data exists.

Useful pilot measures include report preparation time, delay until acceptance, timesheet corrections, reports missing required evidence, synchronisation errors and office processing time. Compare equivalent workflows before and after deployment, including time spent reviewing AI suggestions.

An illustrative calculation helps size the opportunity. If six supervisors each save 20 minutes over 22 working days, that is 44 hours per month. Saving another 45 minutes of office processing per day adds 16.5 hours, for a total of 60.5 hours if the assumptions hold. This is not a measured AI Office Field result or an automatic payroll saving.

We see AI Office Field as an option for development and a pilot that connects site work to the company's tasks, knowledge and documents. An example assignment, current report and acceptance rules are enough to start a discussion. Together, they can define the first workflow and a way to test whether it produces a clearer, more timely account of completed work.