Specifications co-written by language models — what goes into a technical description before a person reads it

The mechanism

A designer, a general contractor’s bid department or a contracting authority asks an assistant for a draft description: of a heat pump, a ventilation installation, a facade cladding system or a building control system. The draft contains parameters, classes, references to standards and often a manufacturer’s product as the reference product, with the addition “or equivalent”. The author of the document corrects what they notice, and the rest may stay.

What the model treated as the default becomes the starting point. If the model knows a product’s parameters wrongly, confuses standards or attributes a product to the wrong manufacturer, the error has a chance of passing into a document that contractors, suppliers and contracting authorities then read.

What this means for the three parties

Contracting authority and designer. The risk is twofold: incorrect standards and classes that only surface during execution, and clauses that unwittingly narrow the choice to a single manufacturer. Under EU public procurement rules, technical specifications may not refer to a specific manufacturer without allowing equivalent solutions, or otherwise restrict competition. A draft that suggests one brand as the reference product therefore needs particular care. Responsibility for the content of the document lies with its author, whatever the tool.

Manufacturer. Models describe products on the basis of what they have found in public sources. A manufacturer may discover that in draft specifications its products have outdated parameters, are attributed to a competitor or do not appear in the category in which they actually compete. This is not about a place in the specification; it is about making sure that what the model says about the product is true.

Market. We are not aware of any public, systematic measurement of how AI assistants influence the content of specifications. Without measurement, the contracting authority does not know where its clauses come from, and the manufacturer does not know how it is being described.

What we do not know

We are not aware of public data on how often designers, general contractors and contracting authorities begin a description from an assistant’s draft, and we do not give estimates. Nor do we know to what extent drafts differ between assistants and languages, or whether companies that models know better appear more often as the reference product in descriptions. These are research questions, not facts, and we treat them as such.

What a company can do

• Contracting authority: check the standards, classes and parameters in a description prepared with the help of an assistant; make sure that naming a product as the reference product does not narrow the choice and that the document allows equivalent solutions.
• Designer: treat an assistant’s draft as working material, not as a source; verify it against manufacturers’ documentation and the practice’s own standards, because responsibility for the design does not pass to the tool.
• Manufacturer: check what language models say about its products, parameters and category; correct errors in the documents that models read: technical data sheets, product descriptions, declarations and expert publications.

The Foundation’s role

The Foundation researches this phenomenon and educates all parties. We measure what language models put into draft specifications: which product serves as the reference and how often, which parameters models treat as the default, where clauses that narrow the choice appear, errors in standards and classes, and differences between assistants and language versions. We organise the results into an error register, we correct errors at source, and we provide a content map showing companies what is worth completing.

We carry out the measurement as part of brand research in language models. The same organisation of names and data that allows a model to describe a product correctly is the essence of semantic transformation, that is, organising a company’s names, processes and data so that people, language models and board reports understand them the same way.