Consider four interoperability changes to support structured construction product data (d-KoP, CPR White Paper, MIH)

[JHil1ier]

Why this matters

Three MHCLG-linked reforms are converging on the same underlying question: how should structured construction product data be created, identified, shared and reused across the built environment?

Those reforms are the Construction Products Reform White Paper, the industry-led Manufacturers' Information Hub and the MMC digital Kit of Parts (d-KOP). Around them sit wider standards and frameworks, including the EU Digital Product Passport regime, GS1 GTIN, BSI PAS 8700 and the MMC Definition Framework.

We think the planning application data specification is likely to become one of the most visible downstream consumers of this emerging product-data ecosystem. What you are trying to create does not need to host product data. Nor should it become a vehicle for product-level prescription; that sits more naturally with Building Regulations, the Building Safety Regulator's Gateway 2 process and the procurement and assurance stack. But the planning specification would benefit if it offered clean attachment points, enabling structured product data to move through the planning process without losing its identity, provenance or connection to the asset element it describes.

Practically we'd advocate for keeping the planning spec lean while making it interoperable and more specifically considering four targeted changes, which would make a material difference.

What the current specification already gets right

The current specification already leaves the door open to structured data. All 23 application schemas allow additional properties. The file component accepts arbitrary MIME types and base64 content. Documents are classified against the planning-requirement codelist rather than being constrained by file format.

The issue is whether it arrives as usable, identifiable data or as a technically valid but semantically anonymous file.

Four proposed changes

1. Promote IFC and Uniclass references to structured fields

The building-element-type codelist already includes IFC equivalence in prose, for example by noting that an item refers to the same thing as IfcWall. But machine mapping should not depend on reading a notes column.

Adding ifc-class and uniclass-reference as first-class fields would make the codelist machine-readable without prescribing a particular product schema. It would also give downstream product-data systems a common reference point.

This is a Tier 1 change: a CSV edit to data/codelist/building-element-type.csv, plus one schema field. A populated file could be supplied as a spec: pull request.

2. Give structured product attachments a semantic slot

At present, there is no obvious document type for a structured product schedule, MMC component dataset, or Gateway 2 product evidence pack. A d-KoP JSON file can be uploaded today, but it lands in a generic category and loses much of its practical meaning.

Adding two or three entries to the planning-requirement codelist, or creating a parallel document-format codelist, would allow LPA case-management systems to recognise and route these attachments correctly.

This is also a Tier 1 change: a small number of additional codelist rows.

3. Make material descriptions conditional where structured data is provided

The existing-materials and proposed-materials fields are currently required strings. That means an applicant who attaches a structured record for a wall, roof or other element still has to manually repeat the same information in prose.

A better approach would be to require those strings only where no structured product record has been attached. Prose remains available as the fallback, but unnecessary duplication is avoided.

This is a Tier 2 change because it requires a validation-rule decision and a view on conditional cardinality at component level.

4. Address the codelist granularity gap

The current 17-entry building-element-type codelist mixes broad categories, such as walls and roofs, with more specific listed building consent entries, such as chimneys and rainwater goods.

External schemas are often more granular. For example, the d-KoP distinguishes between External Wall, Internal Wall, Party Wall and Partition. Truss is treated as its own Part, but has no direct entry in the current codelist.

If a structured product record cannot map cleanly to the planning codelist, the attachment may pass validation while still failing semantically. There are two possible routes: introduce parent-child relationships, or add an other-type field alongside the codelist value.

This is a Tier 2 change because it requires a schema model decision.

The connection points

Attachment point in the planning spec	Carries which kind of d-KoP content	Current friction
building-element-type codelist value on each building-element	Identifies which d-KoP Part this row corresponds to	Granularity mismatch; no machine cross-reference to IFC or Uniclass
existing-materials and proposed-materials	Prose summary of materials	Required even when a structured record is attached
building-element component (extensible via allow-additional-properties)	Optional reference to a d-KoP record (Part ref + version + URL)	No formal field; relies on applicant convention
supporting-document with typed document-types	The d-KoP JSON file itself	No codelist entry for structured product schedules
mime-type on the file component	Format declaration for the upload	Free string; no recognised MIME type registered
submission-details, site-location	Project identification fields used by both schemas	Already aligned in substance

Four of the six attachment points already work in principle. Two create avoidable friction. The proposed changes are therefore not a request to expand the spec into a product-data platform but instead to enable interoperability.

The decision stage

Materials conditions are routine, particularly in conservation areas. The decision-stage specification is still at working-draft stage, so there is an opportunity to align it with the same interoperability logic. The same design choices above will determine whether discharge of conditions can be evidenced through structured attachments, or whether it remains a manual document-review process. Camden's decision-notice work in [issue #330] looks like the right place to thread this through.

Questions back

1. Are you comfortable with the framing: interoperability hooks, not hosted product fields?
2. Is there appetite to promote ifc-class and uniclass-reference to first-class fields on the building-element-type codelist?
3. What is the preferred route for declaring the format and purpose of a structured-data attachment?
4. Is there precedent in the specification for required-if-another-field-is-absent validation rules?
5. Are the Construction Products Reform and digital planning teams actively coordinating on the product-data implications of Chapter 7 of the White Paper?
6. Would a spec: pull request adding populated IFC and Uniclass fields to the building-element-type codelist be useful?

What we can offer

Akerlof contributed to the original d-KoP work and is active in the Industrialised Decarbonisation Construction Challenge (IDCC). We can act directly with the digital planning team and carry this case upstream into the parallel reforms. The simplest first step would be a populated CSV draft for the building-element-type codelist, ready as a spec: pull request for the team to review.