Why Site Questions Lose Their Decision Context
Why RFIs, observations, decisions, and instructions lose meaning as they move between the site, design team, meetings, email, and formal project records.
TLDR
- A site question gathers context in photographs, conversations, drawings, observations, and constraints, then loses that context when it becomes a formal RFI or instruction.
- Better registers and information discipline solve many failures.
- Connected context becomes useful when teams need to preserve the path from observation to question, decision, authority, and downstream action across several systems.
A formal record can be less informative than the conversation
A site question often begins with a practical observation. A contractor sees that the installed condition differs from the drawing. A photograph is shared in a message. Someone recalls an earlier client discussion. An architect checks a revision. An engineer explains a constraint on a call.
By the time the issue becomes a formal RFI, much of that context has been compressed into a short question. When the answer returns, it may be separated from the photograph, the exact location, the drawing revision, and the assumptions discussed in the meantime.
The project has gained a record and lost part of the reasoning needed to use it.
Workflow signals
Inputs
Proximity models
State
System prepares
Briefs + packets
Human decides
Approve / edit
Pilot learning
Corrections -> rules / examples / checks
Site information changes meaning as it moves
An observation is not an instruction. A design comment is not an approval. A meeting agreement may express intent without satisfying the project's formal authority. A marked-up photograph can explain a condition without defining the contractual response.
These distinctions are familiar to experienced project teams. The difficulty is preserving them when information crosses informal and formal channels. Fast-moving work depends on calls, messages, photographs, and meetings. Accountable delivery depends on controlled drawings, RFIs, instructions, approvals, and registers.
Treating one channel as illegitimate is unrealistic. Treating them all as equivalent is dangerous.
ISO 19650 provides a framework for managing information across the built-asset lifecycle, and openBIM promotes interoperable processes across platforms and stakeholders (ISO). Those foundations help control information. The operating challenge is connecting the live question to the formal record without confusing discussion, evidence, and authority.
The issue is a chain, not a document
A useful site-question record connects several things:
- The original observation, location, date, and reporter.
- Photographs, model locations, drawing revisions, specifications, and earlier related questions.
- The question that requires a decision and why it affects the work.
- Comments from relevant disciplines and unresolved disagreements.
- The authorised decision or instruction.
- Downstream acknowledgements, actions, and later evidence of completion.
No single item is the complete truth. The photograph may be current but ambiguous. The drawing may be controlled but not reflect the discovered condition. The instruction may be authoritative but depend on a later coordinated revision.
The practical outcome is fewer repeated questions and less abortive work. When the chain is visible, reviewers spend less time reconstructing what happened, site teams receive an answer they can apply, and managers can locate delay at the missing decision rather than in a generic “open RFI” count.
Better process may be enough
A project does not necessarily need another system.
If RFIs lack location or drawing references, improve the submission template and train the team. If responses remain in email, reinforce the formal workflow. If current drawings are hard to find, fix common-data-environment permissions, naming, and issue discipline. If meetings generate decisions without owners, strengthen the action and instruction process.
A focused review packet can solve a recurring meeting problem without modelling the entire project. Search and indexing help when approved evidence exists but is dispersed. A targeted integration may connect a stable RFI system to the document environment.
A business ontology earns its place when observation, location, asset, document, revision, question, response, decision, instruction, authority, and action must be connected across tools and organisations. Each relationship should retain its source, timestamp, permission, and provenance. Existing project systems remain authoritative for their records.
The point is not to create one giant project database. It is to give a defined decision a connected evidence trail and make conflicts visible before someone acts on the wrong interpretation.
The edge cases are questions of authority
A contractor may need immediate direction to make an area safe while the permanent solution remains under design. A verbal discussion may prevent delay but still require formal confirmation. A site photograph may show a condition after work has moved on. A revised drawing may solve the RFI but not reach the subcontractor performing the work.
These cases matter because speed and control pull in different directions. If every answer waits for a perfect record, work stalls. If an informal comment is treated as a final instruction, the project creates commercial and technical risk.
A connected view should show the current practical position and the formal state separately. It can make clear that a temporary action was communicated, a design response is under review, or an instruction has been issued but not acknowledged.
Repeated corrections become useful evidence. They may show that locations are described inconsistently, a role boundary is unclear, site events are entered too late, or the formal workflow does not match how decisions are actually made.
Interfaces should follow the moment of work
Site teams need concise, location-specific actions that work on a phone or tablet. Designers need the current information, design intent, and cross-discipline constraints. Project managers need ownership, ageing, programme effect, and formal status. Clients need decisions and implications at the right level of detail.
These views should share the same underlying relationships without giving every role the same access or language. Training should use real site questions, including ambiguous photographs, superseded information, provisional positions, and urgent safety actions.
People need to know how to correct a link, challenge a status, and identify the authoritative instruction. Trust grows when the system reflects the difference between “this was discussed” and “this is approved.” The NIST AI Risk Management Framework offers a useful general reference for managing context, performance, and risk throughout the life of such a system 3.
Human authority remains visible
Architects, engineers, project managers, clients, contractors, certifiers, and statutory authorities retain the decisions assigned to them. The system can prepare context, identify missing review, and route the next action. It does not convert an observation into a professional opinion or a meeting note into an instruction.
That boundary is not a limitation around the edge of the system. It is part of the information model. A decision is useful only when the evidence and the authority behind it are visible.
Measure fewer reconstruction loops
Useful measures include RFI preparation and review time, repeated requests for information already provided, questions reopened because context was missing, actions based on superseded information, and delay between a decision and downstream acknowledgement.
The desired result is straightforward: site teams receive clearer answers, reviewers spend less time rebuilding the situation, and formal control supports the pace of the work instead of arriving after it.
The guardrail is authority: faster context must not turn an observation into an instruction or make superseded evidence look current. If reconstruction loops do not fall, or downstream action based on stale information increases, the connected approach has failed its purpose.
Sources
/ Start
Start with one business outcome. Expand from there.
Begin with a focused review rhythm, workflow, or team where better operating context would immediately change the quality of preparation and judgment.