From pre-handover inspection to as-built file: a ChatGPT plugin

Install the ChatGPT plugin: Handover, snag list and as-built file →

A fictional example. Three weeks after the OPR (opérations préalables à la réception, the pre-handover inspection) at "Résidence des Tilleuls", an architect opens their inbox. The joiner writes that the office door that was rubbing the floor "has been fixed". The plumber sends a file called "DOE final.pdf". In the practice's shared spreadsheet, a colleague has already marked the door snag as "cleared", the corridor paint touch-up has vanished from the list and the ground-floor plan has changed revision. Nobody knows any more what has been repaired, inspected or actually cleared.

This article presents the ChatGPT plugin "Handover, snag list and as-built file" offered by Educasium. It does not repeat our articles on the acceptance record or snag tracking: it explains what the plugin adds, namely keeping the whole AOR chain (assistance aux opérations de réception, the handover stage of a French architect's assignment) in one cumulative register, from preparing the OPR to reviewing the DOE (dossier des ouvrages exécutés, the as-built file).

Contents

1. What the plugin covers: the whole AOR chain in one register
2. Acceptance remains the client's act
3. Before handover: gathering the items and documents
4. After handover: snags updated without erasing anything
5. The as-built file reviewed requirement by requirement
6. Using the plugin step by step
7. Skill or plugin: what is the difference?
8. Installing the plugin in Codex
9. When this plugin is not enough
10. Training in architectural management with AI
11. Frequently asked questions

What the plugin covers: the whole AOR chain in one register

The plugin follows four stages of the same project:

• Before handover: the list of items to inspect and documents to gather, without announcing any decision.
• Documented decision: a review of the acceptance documents provided and, only on request, a draft PV (procès-verbal, the acceptance record) reflecting the scope and date actually established.
• After handover: cumulative snag updates, with evidence of clearance (levée des réserves) and the history kept.
• As-built file: the inventory of documents received, reading them and comparing them with what the contract actually requires.

The common thread is a dated, versioned JSON register: each version adds sourced events without rewriting earlier ones. Reports, lists per contractor, re-inspections and changes between versions are simply dated views of it.

Acceptance remains the client's act

Under article 1792-6 of the French Civil Code, réception is the act by which the maître d'ouvrage (the client) accepts the works, with or without reservations; the legal framework, warranties and drafting of the PV are covered in our articles on the acceptance record with Claude and with ChatGPT. The plugin applies a simple rule: it keeps apart the inspection date, the date of the acceptance document, the effective date and the clearance date, calculates no warranty from a site visit, writes "acceptance not established in the documents" when no document is provided, and never classifies an acceptance as tacit, partial or court-ordered on its own.

Before handover: gathering the items and documents

The plugin can start from the register kept during construction (see our site meeting reports with ChatGPT), or from existing records and spreadsheets.

A site item is not yet a snag

Open items become candidates to inspect. They only become "confirmed snags" with a source documenting their inclusion in the acceptance document. Each snag gets its own ID but keeps the ID of the original site item and its history, with an explicit correspondence table. Closing a site item does not prove that a snag has been cleared, and the plugin does not change the site register: it flags the update to be made.

Located, sourced snag records

Each record carries building, level, room, trade, plan with revision and marker, media actually available, and the people responsible for the repair and for the inspection, with the source of that assignment. A plan revision does not automatically move a marker: the previous revision is kept and the realignment is flagged "to check". Without a position or photo provided, the plugin invents no pin; a vague finding stays marked [À COMPLÉTER] (to be completed).

After handover: snags updated without erasing anything

This is what resolves the opening scenario: the plugin adds events to the latest verified version of the register, without overwriting earlier ones, and keeps apart three facts that are often blended together:

The repair workflow (to do, in progress, reported done, to inspect, satisfactory inspection, rework requested) stays separate from the evidence of clearance: a confirmed snag without documented clearance stays active, and a missing clearance date stays empty rather than borrowing the report's date.

An item missing from the new notes is not deleted: it is carried over with its last known status and the note "not updated". A reopened snag keeps the same ID and the earlier clearance in its history.

The as-built file reviewed requirement by requirement

The expected inventory is built from the CCTP (technical specification), the CCAP (special administrative conditions) and the requirements actually consulted, not from a universal list. Each requirement is linked to its trade, to a piece of equipment where relevant, to the person responsible for submitting it and to a reviewer.

Statuses are deliberately precise: missing, received not read, read to be checked, documented discrepancy, approved within the demonstrated scope, justified as not applicable. Received does not mean approved: a file named "DOE final" proves neither that it is complete nor that it is accurate. An approval requires a precise criterion, an author, a date and a source.

Every submission is kept. A corrected resubmission must be re-read: it does not inherit the earlier approval, does not erase the previous comments and does not automatically close the corrective action.

The plugin also tracks the submission workflow: in preparation, to submit, submitted, under review, returned for corrections, to resubmit, documented review. This workflow describes the organisation, not the outcome: a documented review may conclude that there are discrepancies. If a section required by the contract is missing, the document cannot be presented as ready to submit under that requirement, but a submission already made is still recorded as a fact.

Using the plugin step by step

Step 1: Frame the file and provide the sources. Project, type of contract, scope and assignment, then the site register if there is one, OPR findings with labelled photos, the CCTP, the CCAP and the decisions actually communicated.

Step 2: Prepare the OPR. Ask for the list of items and documents, separating findings, proposals and decisions.

Step 3: Record the decision. Have the signed PV reviewed to qualify the confirmed snags, or ask for a draft for the right person to approve.

Step 4: Update at each re-inspection. Always provide the latest version of the register first, then the new documents, and check the view of changes.

Step 5: Review the as-built file. Attach the documents submitted per trade and ask for the inventory, reasoned comments and the documents to be corrected.

Skill or plugin: what is the difference?

The ChatGPT skills presented in our other articles each handle one document: the acceptance record with its initial register, or the snag tracking workbook. They are used in a ChatGPT project to which the instructions are attached. The plugin is installed in Codex and covers the whole stage with a single register convention, from continuity with the site follow-up to the as-built file. For a one-off acceptance record, the skill is enough; to follow a project through to the end, the plugin saves you from rebuilding the history at every step.

Installing the plugin in Codex

The download is reserved for participants in Educasium training courses, from the plugin page. Unzip the ZIP into a stable folder that you will not move or rename. In a terminal, add that folder as a catalogue with codex plugin marketplace add "path/to/the/folder", then install the plugin with codex plugin add archi-reception@educasium-reception. Then open a new Codex session. The INSTALLATION.md file in the ZIP repeats these commands.

When this plugin is not enough

• No signing or sending: nothing is signed, sent or notified without an explicit instruction.
• No mobile capture: it works from the notes, photos and documents you provide.
• No direct connection to field apps: it can read an export you provide, but it is neither an automatic importer nor a sync.
• A label is not evidence: a "Verified" or "Closed" status in an export does not demonstrate clearance.
• CSV files are only views: they do not replace the history in the JSON register, which you need to keep and reuse.

Training in architectural management with AI

A plugin structures the work; it does not replace the method. Our Architectural Management with AI training covers site follow-up, handover and keeping reliable registers with ChatGPT, using cases close to your own practice.

Frequently asked questions

Can the plugin declare acceptance on my behalf?

No. Acceptance is the client's act. The plugin prepares the list of items and documents before the inspection, reviews the acceptance documents you provide and, if you ask, drafts a PV with the signature fields left blank. As long as no decision is documented, it states "acceptance not established in the documents" and calculates no warranty date. Nor does it conclude that a tacit acceptance has occurred: it sets out the facts and leaves the legal qualification to the competent people.

Why is "fixed" not enough to clear a snag?

Because that word often covers three different facts: the contractor reports a repair, an on-site inspection confirms the work, and clearance is then formalised within the framework set by the contract. The plugin records each of these events separately, with its source and its author. A confirmed snag therefore stays active until its clearance is documented. This separation avoids discovering, in the middle of a disagreement, that no document proves what the spreadsheet showed.

What happens if a plan changes revision between two visits?

The marker stays attached to the plan and revision on which it was placed. The plugin does not move it to the new revision: it records the current documented revision and flags a realignment "to check", without converting or inventing coordinates. You keep the original location, which is valuable when a room has been redrawn between the OPR and the re-inspection, and you know which markers need checking on site.

Does an as-built document submitted a second time keep the approval of the first version?

No. Each submission is kept with its file, revision and date, and an approval only covers the submission and the criteria actually examined. When the contractor sends a corrected version, the plugin asks for a fresh reading of the relevant criteria, keeps the previous comments and leaves the corrective action open until it is confirmed. A documented review is not an overall approval of the as-built file and never closes a physical snag.

Upstream, our method for site meeting reports with ChatGPT feeds the register; see also our articles on the acceptance record and snag tracking, with ChatGPT or with Claude, if you prefer to work document by document.

Funding may be available depending on your eligibility (OPCO, FIF PL). Qualiopi-certified training organisation. To structure your handovers, snag clearance and as-built file reviews with AI as part of our Architectural Management with AI training, contact Educasium and tell us your status and your goal. You will find the download and the installation tutorial on the dedicated ChatGPT plugin page.