constructrr

Article

Submittal Improvement Starts With Shared Rules

A shared data exchange can support submittal coordination, but teams must first agree on states, responsibilities, routing, exceptions, and review.

By Marcus Turner

Published

Three project participants align one submittal packet and its status tabs in a field office.

In 2023, I attended the AEC Integration Summit hosted by the Construction Progress Coalition. My team explored a familiar construction problem: how might we reduce duplicate work in the submittal process while making responsibility and status more visible?

The technology discussion was useful. The more important realization was that a shared platform cannot repair a process the participants have not agreed on.

Before routing can be automated, the team has to define what is being routed, who is responsible for each decision, which status values mean the same thing across systems, and what happens when the normal path breaks.

The real waste is repeated interpretation

Submittal information often moves through several organizations and several systems. Each participant may maintain its own log, naming convention, status, and copy of the record.

The result is not only duplicate data entry. People also spend time reconstructing what another system means.

Does "returned" mean approved, approved as noted, rejected, or simply sent back to the contractor? Which date reflects the designer's decision? Who owns the next action when a package contains several items with different outcomes?

If those meanings are not shared, connecting the systems can move confusion faster.

A common data exchange is a coordination role

At the summit, we explored a Common Data Exchange, or CDX, as a shared layer between the participants' existing systems.

The CDX was not valuable because it promised one more place to store every document. Its possible value was narrower:

  • receive a defined event or record from one system;
  • translate it into agreed project terms;
  • route it to the responsible participant;
  • preserve the source and history;
  • return the resulting status to the parties that need it.

That is a coordination role. It depends on clear project agreements and technical interfaces.

Define the operating rules first

A project considering this pattern should begin with a process conversation, not a cloud architecture.

The owner, contractor, designers, and trade partners may need to agree on:

  • the submittal requirements and responsible roles;
  • the meaning of each status;
  • which system remains authoritative for each fact;
  • the routing and notification rules;
  • how revisions, partial decisions, and exceptions are handled;
  • which information each participant is allowed to access;
  • how the team will resolve conflicting records.

The list is less glamorous than a system diagram. It is also what makes the system diagram useful.

Treat the technology stack as a hypothesis

After the summit, I used AI tools to transcribe the team recap and generate a possible implementation strategy. The output proposed familiar cloud components for identity, structured data, document storage, workflows, APIs, notifications, monitoring, and deployment.

That exercise helped expose the parts of the system. It did not select a platform, prove compatibility, establish security, or validate the workflow against a project contract.

This is an important boundary for AI-assisted design. A model can help a team draft options and identify questions. It should not turn a concept workshop into an approved technical recommendation.

Start with one visible handoff

A practical test does not require rebuilding the full submittal process.

Choose one recurring handoff where duplicate entry or status confusion is visible. Map:

  1. the event that starts the handoff;
  2. the minimum information required;
  3. the source system;
  4. the receiving role;
  5. the allowed status values;
  6. the exception path;
  7. the point where the result is reviewed.

Then decide whether an integration, a shared record, or a simpler process change is the smallest responsible solution.

The central question is not whether construction needs another platform. It is whether the team can make the rules of information exchange clear enough for people and systems to follow.

Editorial disclosure: This adaptation and its representative image were developed with AI-assisted editorial and visual production, then reviewed and approved by Marcus Turner.

Original source material

Continue with the original source.

This companion article is connected to source material outside the Constructrr podcast and video archive.

Open the original source material: Reducing Duplicate Work in Construction