Building handover should transfer decisions, not just documents

Design proposal | Logic Foundry | October 11, 2026. This article proposes a way to review operational handover. The examples are fictional, and the evaluation described below has not been conducted by Logic Foundry.

1. The question behind the document

Imagine a facilities team taking responsibility for a refurbished office building. The team receives drawings, equipment schedules, training materials and control descriptions. A month later, a manager asks why a particular operating schedule was chosen. The files describe what the system does, but the team cannot find the discussion that explains the compromise behind it.

This is a fictional example of a useful handover question: can the receiving team reconstruct the reasoning behind an important operating decision without relying on whoever happens to remember it? A complete collection of files and an understandable decision are different things. Our proposal is to test both.

2. A small record with a specific purpose

Alongside the usual project deliverables, consider a short decision record for a limited set of consequential choices. Begin with the operational question, the area or equipment affected, and the person responsible for accepting the decision. Link the record to the supporting document and its version rather than copying the entire document into another system.

The next part describes the chosen approach and the alternatives considered. Record the constraint that mattered, such as access for maintenance, occupied working hours, an existing equipment interface or an agreed budget boundary. Separate a verified site observation from a planning assumption. Where someone accepted a compromise, preserve its scope and the authority under which it was accepted.

Finish with the evidence used to accept the outcome, unresolved questions, and a reason to revisit the decision. A change in occupancy, replacement of connected equipment or a recurring operator complaint might be a review trigger. These are examples to adapt, not universal acceptance criteria.

3. Acceptance is not the same as certainty

A handover record should make an unresolved issue visible without quietly converting it into an accepted result. For example, a fictional team might have reviewed a sequence under one operating condition while a different condition remains unobserved. The record would say what was checked, what remains open and who owns the next review. It would not describe the unobserved condition as proven.

Similarly, naming an owner is not evidence that the owner has agreed to the action. A proposed workflow would distinguish an assigned responsibility from an acknowledged responsibility, and would retain the date and reason for closing an open question. The receiving operator should be able to challenge an assumption without having to rewrite the original project history.

This record would supplement formal commissioning, professional judgement, contractual deliverables and applicable procedures. It would not replace them or grant a new person permission to change controls. The purpose is to make reasoning easier to find, not to create an alternative approval authority.

4. Make the record useful to the next team

Different people need different entry points. A property manager may begin with a tenant impact, a technician with an asset, and a designer with a system description. A proposed information model would connect those entry points to the same decision and supporting evidence. It would also distinguish an earlier accepted arrangement from a later approved change.

A simple folder or register can be enough for an initial trial. Start with a few decisions that the receiving team expects to question again. If maintaining the register requires duplicating every project document, the design is probably too broad. If it contains only a list of filenames, it may be too thin to help someone understand the tradeoff.

Access and ownership need attention as well. Project files can contain sensitive operational or commercial information. A practical implementation would use the organisation's existing access rules, keep a clear authoritative copy, and avoid putting unnecessary sensitive details into widely shared summaries.

5. A tabletop evaluation readers could try

Choose one completed, non-sensitive project example and three decisions that affected the receiving team. Use existing records only. Ask someone who was not involved in the project to explain the question, the selected approach, the reason for it and the remaining uncertainty. Do not change live equipment or control settings for this exercise.

Record which answers were supported by a specific document, which required an interview and which remained unknown. Then prepare the proposed short records and ask a different reviewer to attempt the same reconstruction. Note confusing language, broken references, conflicting versions and questions the record still cannot answer.

The hypothesis is that a concise record of reasoning could make a handover easier to interpret. The exercise may also show that the real problem is missing evidence, unclear authority or inadequate training. A small tabletop comparison cannot establish long-term reliability, cost savings or operational performance. Treat its results as feedback on the information design.

6. Where the proposal can fail

A record can become misleading if it outlives the arrangement it describes. It can become performative if every field is filled but nobody checks the supporting evidence. It can become a bottleneck if a team must wait for a lengthy narrative before dealing with an urgent issue. Limit the scope, identify who maintains it and make the current status explicit.

Two discussion prompts can help refine the idea: Which operating decision in your last handover depended most on someone's memory? What change would make that decision worth reviewing, and who would notice it? Designers, integrators, equipment providers and operators may give different answers. That difference is useful material for a handover discussion.

CORE-FM currently supports properties, assets, work orders, preventive maintenance and sensor monitoring. Logic Foundry's confirmed research into digital twins, BMS API integrations and future reporting and decision tools includes the broader question of how operational context can support understandable decisions. The handover record described here is a design proposal, not a claim of a shipped feature, tested integration or completed experiment.