A site decision-support system for a project team

Consider a 20-person architecture and project team delivering a commercial refurbishment.

The project is live on site. The client wants quick answers. Contractors send RFIs and photos. The design team updates drawings. Engineers comment on constraints. The project manager tracks programme risk. Decisions move through meetings, email, site reports, and formal registers.

The team does not need software to make design judgments for them. They need a better way to prepare the context around those judgments.

This is where Proximity could be tailored as a site decision-support system.

The system's job is to connect the records around each site question so architects, engineers, project managers, and clients can review with current evidence. It should not approve design changes, certify work, instruct contractors, or decide professional opinion.

The Workflow

The workflow is weekly site decision review.

The team wants a reliable view of:

• Open RFIs and who owns the response.
• Relevant drawing revisions and model references.
• Site photos and observations.
• Inspection notes or snagging items.
• Client decisions and constraints.
• Programme or cost impact.
• Approvals still needed before action.

The current failure mode is familiar. A contractor question references an old drawing. A site photo shows a condition that is not in the formal record. A client preference was discussed in a meeting but not linked to the RFI. A design response is drafted before the team has checked structural, cost, or approval implications.

Proximity would create infrastructure around this workflow by tying the evidence together.

What Proximity Models

For this deployment, Proximity would model the site question as the core object.

Approved sources might include:

• Drawings and drawing registers.
• BIM or model metadata where available.
• RFIs and responses.
• Site photos and observations.
• Meeting notes.
• Inspection and snagging records.
• Programme milestones.
• Change logs.
• Client decision logs.
• Approval registers.

The system would structure this into project context:

• Site question, location, discipline, and owner.
• Relevant drawing, revision, and status.
• Source photo, date, author, and location.
• Related RFI, change, inspection, or meeting note.
• Required reviewers.
• Open questions and missing evidence.
• Decision status: prepared, under review, approved by humans, or closed.

ISO 19650 is useful background because it frames built-asset information management as a lifecycle discipline for exchanging, recording, versioning, and organising information. ISO's launch note on BIM also stresses collaborative information management, not merely modelling. For Proximity, the lesson is simple: AI support needs the project information environment, not isolated fragments.

What The System Prepares

Before the site decision review, Proximity could prepare a packet for each open question.

The packet might include:

• A short description of the issue.
• The current drawing or model reference.
• Related photos and observations.
• RFI thread summary.
• Client or consultant comments.
• Programme or cost notes if available.
• Missing evidence.
• Required human reviewers.
• Draft response options clearly marked for review.

The system could also prepare a decision queue:

• Ready for design-team review.
• Needs engineer input.
• Needs client confirmation.
• Needs cost review.
• Needs formal approval before contractor instruction.
• Missing current drawing reference.

The value is not that Proximity knows the design answer. The value is that it helps the team see what the answer depends on.

The Centre for Digital Built Britain's Gemini Principles describe digital twins through purpose, trust, and function. In this article, the practical "twin" is not a perfect replica of the asset. It is a connected project state that lets professionals review a site question with current evidence and clear boundaries.

What Remains Human

Professional judgment remains human.

Proximity must not decide design intent, approve a change, certify work, instruct a contractor, accept a site condition, sign off compliance, or communicate a final professional opinion. Those responsibilities remain with the architect, engineer, project manager, client, certifier, or other named professional.

Humans remain responsible for:

• Design judgment.
• Technical review.
• Client advice.
• Certification.
• Contractor instructions.
• Approval of changes.
• Final wording of responses.
• Professional liability and accountability.

The system prepares context. People decide.

This boundary matters because built environment work involves real assets, contracts, safety, cost, and responsibility. NIST's AI Risk Management Framework treats trustworthy AI as a governance problem involving roles, responsibilities, and risk management. That is the right posture here: the workflow should make responsibility clearer, not blur it.

Pilot Shape

A practical pilot would focus on one active project and one recurring review: RFIs affecting design coordination.

The first phase would map sources and define which registers are authoritative. The second phase would create site-question packets for a subset of RFIs. The third phase would use Proximity in the weekly review and tune the missing-evidence flags.

Success signals include:

• Faster preparation for site decision meetings.
• Fewer responses drafted against stale drawings.
• Clearer ownership of each open question.
• Better visibility of client decisions affecting site work.
• More consistent evidence packets before professional review.
• Reduced meeting time spent reconstructing context.