Technology should make project decisions easier to examine

Start with the information problem

A development can have a current drawing in one place, an older unit mix in a presentation and a financing model built around a third version. Each file may look reasonable on its own. The risk lies in decisions being made from incompatible information.

The technology approach we are exploring starts by connecting those records. A project fact should retain its source, date, version and status. An approved specification, a working assumption and a market benchmark should remain distinguishable as the plan evolves.

Connect physical progress with financial consequence

A revised delivery date can affect installation, inspections, first occupancy, interest carry and the cash available at refinancing. A slower leasing pace can change stabilization and funding needs even when construction finishes on time. Examining each item in a separate file makes the dependencies harder to see.

The approach we are exploring would connect drawings, scope, commitments, schedule, market assumptions and financing in a shared project view. The aim is to expose disagreements and unresolved assumptions, with their evidence and responsible reviewer. It would support a decision; it would not turn an incomplete record into an approved fact.

Consider a hypothetical delivery change. A useful workflow would flag the affected milestones, identify the assumptions requiring recalculation and route the issue to the people responsible. Reproducible financial calculations and reviewed scenarios would show the potential cash consequence. An AI-generated narrative alone would not establish either the revised schedule or the funding requirement.

Make a changed assumption visible

Consider a hypothetical building redesign. Reducing the number of homes may lower some costs while changing rental income, approvals, parking, factory scope and financing needs. Updating only the construction budget leaves the rest of the decision incomplete.

A useful workflow would surface the affected assumptions, preserve the previous version and show what has been checked. It would also flag an unresolved dependency rather than silently supplying a market average as an approved project fact. The goal is faster access to reliable context, with uncertainty visible.

Give automation a bounded job

Potential uses include comparing document versions, extracting fields for review, organizing source evidence and identifying inconsistent assumptions. Reproducible calculations should remain distinguishable from generated explanations. A fluent summary is not confirmation that the underlying value is correct.

NIST’s generative-AI profile recommends verifying sources and citations and preserving provenance and oversight. Those principles support a proposed workflow with human review at consequential decisions; they do not certify a tool or eliminate errors.

Evidence: [1]

Measure the decision as well as the task

Drafting faster is useful, but the exposure around a development decision can be larger than the labor cost of preparing it. Late discovery of an incorrect financing assumption, an unpriced scope change or an unsupported leasing pace can alter cash needs. That is our strategic reason for examining coordination across functions.

A pilot would need evidence that relevant changes were caught sooner, calculations remained reproducible and reviewers could resolve issues more reliably. Avoided losses cannot simply be attributed to software. We have not established a quantified benefit or a deployed platform through this proposed approach.

Evaluate the workflow before claiming the benefit

We would assess a pilot by correction rates, missing facts, review effort and whether another person can reproduce the decision from its evidence. More software activity is not itself a better outcome. A workflow that saves drafting time but increases verification work may not improve execution.

Access also needs to reflect the audience. Public research, investor material and internal commercial records serve different purposes. Connecting information should not mean publishing private assumptions or treating permission to read as permission to share.

This article describes an approach in exploration. It does not announce a named product, an existing deployment, a proprietary capability or a quantified saving. The strategic question is whether connected information can help a senior team notice and resolve consequential changes earlier.