One CCTP per trade from the DPGF with a ChatGPT plugin

Install the ChatGPT plugin: Trade specifications from the bill of quantities →

A practice is preparing the tender package for a small office fit-out, a fictional project used here as an example. The DPGF is ready: three trades (drylining, internal joinery, painting), an extra painting line as an option not activated, a lump sum for "shared protection and cleaning" with no trade assigned, and a grand total. The CCTPs still have to be written. The temptation is familiar: reopen the CCTP from a similar job and swap the names. Three weeks later, the DPGF moves to its next revision, the new notes only mention drylining, and nobody can tell whether painting was removed or simply forgotten.

This article introduces the ChatGPT plugin "Trade specifications from the bill of quantities", an Educasium resource for architects and project managers. It does not go back over how to write a CCTP article, already covered in our ChatGPT method for CCTP by trade, but over what the plugin adds: inventorying every DPGF line, producing one file per trade, keeping common conditions in a single register, preserving the memory of requirements across revisions, following the practice's Word template and organizing human reviews by scope.

Contents

1. Start from the DPGF, not from a blank page
2. One file per trade, common conditions kept once
3. The file that remembers every requirement
4. The practice's Word template and human reviews
5. Using the plugin step by step
6. Skill or plugin: what changes
7. Installing the plugin in Codex
8. When this plugin is not enough
9. Training to produce written documents with AI
10. Frequently asked questions

Start from the DPGF, not from a blank page

In many practices, the DPGF (décomposition du prix global et forfaitaire, the French lump-sum price breakdown that works as a bill of quantities) exists before the CCTP (cahier des clauses techniques particulières, the technical specification for each lot, meaning each trade package) or progresses alongside it. The plugin treats this direction of work as a normal path: inventory of every line, proposed mapping to articles, draft, then human review. The DPGF outlines the scope but rarely holds all the technical content: the plugin reads it as a source, and the original is never modified.

Every line is counted

Quantities and prices stay in a mapping appendix; they do not enter the CCTP without a decision on their status. Coverage is checked both ways: items without an article, articles without an item and possible duplicates are listed one by one.

What the DPGF does not say

A description reading "internal partition 72 mm thick" gives a sourced thickness, but nothing about fire rating, acoustics or installation. The plugin carries the value over with its source and leaves the rest as [À PRÉCISER : objet], meaning "to be specified". Nor does it infer a construction system from a unit price.

One file per trade, common conditions kept once

By default, the plugin produces a separate file for each trade, named after the project, the trade code and the revision, without asking you to confirm the split. A single multi-trade document is only prepared on explicit request. A trade identified with no known work still gets its draft, which flags the gap instead of inventing articles.

Conditions are kept in a single register with three scopes: general technical provisions for all trades, project-specific conditions, and conditions specific to each trade. They come from the documents actually read, because the DPGF alone does not define shared obligations. Each CCTP includes the common conditions that concern it with the same identifier, version and text: they are editions of the register, not separately edited copies. If your template requires a separate common document, the plugin produces it and each trade refers to it. No automatic priority is given to a specific condition over a general one: contradictions are surfaced for a decision.

In the example provided, the junction between the drylining partition and the joinery door set remains an open interface: who handles the reveals and sealing has not been decided. It appears in both trades, without being silently handed to either.

The file that remembers every requirement

This is the clearest difference from one-off drafting. The plugin keeps a master file and a consolidated lots.json for the whole project: articles, requirements, sources, interfaces, open points, decisions, history and issued packages. The trade CCTPs are editions of it. At the next revision, four rules prevent the confusion described above:

• An omission is not a deletion: an article missing from the new notes keeps its last requirement, flagged as not updated.
• A removal must be explicit and sourced: the article and its number stay in the history, and that number is never reused.
• A contradiction is not settled silently: both values are kept and the clause stays [À PRÉCISER].
• A new version never replaces an earlier issue, which stays frozen with its files.

An index of editions links each file to its articles, conditions, sources and reviews. It is neither a database nor a software lock, but a documentary inventory you can read.

The practice's Word template and human reviews

The practice's template (styles, numbering, headers, sections, vocabulary) is an input just like the DPGF. With suitable document tools, the plugin starts from a copy of the template, keeps its styles and checks how the final pages render. It separates presentation changes from content changes and does not carry over technical facts from the older project used as a model. Without a template, it delivers a provisional draft without claiming fidelity.

The plugin prepares; it validates nothing. Four reviews stay pending until a real decision is documented:

1. H1, scope and mapping of the items.
2. H2, requirements and decisions.
3. H3, consistency between DPGF, CCTP, drawings and template.
4. H4, version and release of the exact files.

Approving the drylining trade does not approve joinery or the whole project. When a source changes, the affected reviews go back to "to be reviewed".

Using the plugin step by step

Step 1: Gather the documents. The DPGF (Excel or CSV), your technical notes per trade, the practice's Word template and, if you have one, a reference CCTP identified as such.

Step 2: Write the request. For example: "From this DPGF, prepare a separate Word CCTP for each trade, following our template. Provide the consolidated pivot file and the points to decide per trade." The plugin works in French, so you can also write the request in French.

Step 3: Review the inventory. Is every line counted, is the lump sum with no trade still there, is the option kept apart from the base?

Step 4: Decide open points per trade, stating the scope of each decision.

Step 5: Check each file: articles from that trade only, common conditions present, template style followed, unknowns visible.

Step 6: Revise without starting over, providing the new DPGF or new notes together with the previous master file.

Skill or plugin: what changes

The skill remains useful for quickly drafting a single trade from the drawings. The plugin takes over when the DPGF structures the project and the CCTPs live through several revisions.

Installing the plugin in Codex

The plugin installs in Codex, OpenAI's agent that you can use with a ChatGPT account. The download is reserved for participants in Educasium training courses, on the plugin page. Download the ZIP and unzip it into a stable folder on your computer. In a terminal, run codex plugin marketplace add "path/to/the-folder" with the unzipped folder, then codex plugin add archi-cctp@educasium-cctp. Then open a new Codex session. The ZIP includes fictional examples (a per-trade request, a DPGF in CSV, technical notes) so you can test the path before a real project.

When this plugin is not enough

• No paid standards library: an unverified reference stays "to be checked".
• No built-in Word generator: DOCX export depends on the tools available; without them, a TXT or Markdown draft is delivered with the lots.json, and the limit is stated.
• The CCAP (cahier des clauses administratives particulières, the administrative specification) is a separate document, prepared only on request, with no invented amounts or deadlines.
• No technical validation: the CCTP remains a draft until your reviews are done.
• Nothing is sent to contractors: release and signature remain human actions.
• Revit is not required, but there is no IFC reader or geometry engine. Documents are written in French, as a French DCE (tender package) requires.

Training to produce written documents with AI

A plugin structures the work, but it does not replace a command of the DPGF, CCTP, review and release chain. Our Architectural Management with AI training covers these paths using your own documents, with the checkpoints to keep in place within the practice.

Frequently asked questions

What happens if my new notes no longer mention an article?

The article is not deleted. The plugin treats an omission as a carry-over: the article keeps its last known requirement and is flagged as not updated, to show it was not reviewed. If it really has to leave the CCTP, an explicit, sourced removal is needed. The article then leaves the active edition but stays in the master file's history with its number, which is never reassigned. An incomplete note therefore never makes a requirement disappear silently.

Can I get a single CCTP covering all trades?

Yes, if you ask for it explicitly. By default, the plugin produces one file per trade, because that is how consulted contractors usually read their scope and because reviews can then be carried out trade by trade. Separate chapters inside one file are not treated as files per trade. In both cases, the master file and the consolidated lots.json stay the same: they serve as the reference for the editions.

Do the DPGF quantities and prices appear in the CCTP?

Not by default. Quantities, unit prices and amounts stay in the mapping appendix, with their original values and their reference in the DPGF. The CCTP may repeat a location as source data, but a quantity only goes in once you decide its status. The plugin does not itself classify a take-off as contractual or indicative, and it infers no hierarchy between DPGF, CCTP and drawings from their names or dates.

Do I need a Revit or BIM model to use the plugin?

No. The plugin works from a DPGF, technical notes and the documents you provide; sufficient notes are already enough to structure the CCTPs. Extraction from Revit is only considered on request, with a connector that is actually available. When a new drawing revision arrives, the plugin opens an impact review and keeps the previous reference, without changing a clause before comparing.

To go further, our ChatGPT method for CCTP by trade details how to draft a trade from the drawings and project description, and our ChatGPT method for DPGF breakdown by trade revisits the price breakdown this plugin starts from.

Funding may be available depending on your eligibility (OPCO, FIF PL). Qualiopi-certified training provider. To set up this DPGF-to-CCTP path in your practice as part of our Architectural Management with AI training, contact Educasium and specify your status (employee, self-employed, business owner) and your goal. You will find the download and the installation tutorial on the dedicated ChatGPT plugin page.