PropTech: The Data Dilemma

In a Constructrr recording published in March 2021, I hosted Paul Doherty, Anthony Day, and Lindsay Nguyen for a conversation about built-environment data, privacy, security, provenance, and digital legacy. The products, roles, and pandemic examples in PropTech: The Data Dilemma belong to that moment. The central question still matters: before a team adds another platform, who decides what the data means, whether it can be trusted, who may use it, and when that permission ends?

More data does not mean better decisions

Data work can look productive while an incorrect source moves through reports, reviews, and decisions. Paul Doherty described teams repeating a save-as workflow and producing polished visual information from an incorrect input. His blunt summary was, “I can be very productive with the wrong information.”

That observation connects the episode's wide-ranging topics. The panel moved from inconsistent naming and expanding data stores to health-status credentials, security permissions, sustainability sensors, virtual representations, and posthumous data. The use cases changed, but each depended on decisions that software could not settle by itself: purpose, ownership, source quality, access, consent, custody, expiration, and review.

The dilemma is not a shortage of data. It is a shortage of visible governance around the data a workflow already depends on.

Five principles for trustworthy project data

Shared language comes before shared infrastructure

Paul called out nomenclature, taxonomy, and ontology as a problem inside his organization and across global partners working on large urban projects. He used a water analogy to describe data changing state across a lifecycle rather than sitting as a static file or piece of plumbing.

The analogy matters less than the operating need beneath it. If two project partners use the same word for different things, or different words for the same thing, a common platform can move the disagreement faster without resolving it. Before integration, a team needs representative definitions, an owner for each critical term, and a way to handle exceptions when project context does not fit the standard.

Trust starts at capture and continues through every handoff

Anthony Day argued that sustainability information could not become trustworthy merely because it was recorded in a secure system. In his 2021 example, confidence also depended on whether a sensor was calibrated and whether the data could be altered before a regulator or financier reviewed it. The example locates the right review point: upstream of the dashboard.

Source integrity is only the beginning. A useful evidence chain also needs to show who transformed the data, which rule was applied, where a human reviewed the output, and what happens when the source is incomplete or contradictory. A trusted destination cannot repair an invisible break in the journey.

Access should match the decision, not the appetite to collect

The episode's most time-bound example concerned workplace health credentials during the pandemic. Anthony described a verification flow intended to return a limited result without copying the underlying personal information into the verifier's system. He also acknowledged that blockchain was one possible architecture rather than the only one. Lindsay Nguyen described access in similarly bounded terms: different entities carried different risks, and permission could vary by user, purpose, and time.

The 2021 health-pass design is not a model to carry forward unchanged. Its more durable question is narrower: what is the minimum information required for this decision, and why would the recipient retain anything more? That question gives privacy, operations, and user experience a shared place to start.

Architecture does not remove accountability

Near the end of the conversation, Lindsay considered a professional data custodian: a group capable of protecting information and carrying out a person's wishes. She immediately named the tradeoff. Central custody could add capability while moving the system away from a decentralized model, and different situations might justify different architectures.

That tension is more useful than a universal answer. Centralized and distributed systems arrange control differently. Neither choice decides which user should have access, for what purpose, for how long, or who should hold the information. Those decisions have to be made and kept visible.

The lifecycle can outlast the original project

The panel's discussion of digital legacy was speculative, but it exposed a neglected handoff. Participants asked what should happen to personal data, credentials, devices, and virtual representations after death, who could authorize access, and whether a family could even find what had been distributed across platforms and systems. Analogies to wills, donor cards, intellectual property, and bank custody helped them frame the problem without resolving it.

For project teams, the nearer version of that question is simple: what happens to information when the project, contract, system, or accountable person ends? Retention and deletion are not administrative cleanup if later decisions still rely on the record.

Start with one decision, not another platform

One practical way to make governance concrete is to attach it to a recurring workflow. Before choosing a new tool, map one decision and create a minimum governance card.

1. Purpose: What decision will this information support?
2. Trusted source: Where does it originate, and what makes that source representative enough?
3. Accountable owner: Who can approve a definition, resolve a conflict, or stop use?
4. Transformation: What changes between capture and decision, including automation and human review?
5. Access: Who needs which field, for what purpose, and for how long?
6. Exception: What happens when the source is late, missing, disputed, or outside the expected range?
7. Disposition: When is the information retained, transferred, archived, or deleted?
8. Review: What evidence would require the team to correct the information or stop using it?

This card will not solve enterprise governance. It can help the team decide whether technology belongs next, or whether the workflow still needs an owner, a shared definition, or a review rule.

The governance questions outlast the 2021 examples

Those products, roles, and pandemic examples belong to 2021. The operating questions reach beyond those examples: purpose, ownership, access, retention, review, and the response when information proves wrong.

Some ideas in the conversation were explicitly speculative, including the proposed market for posthumous data. They are useful here as stress tests. If information outlives a project, contract, platform, or person, who remains accountable for it, and what authority should that person have?

Try this on one broken data handoff

Take one recurring handoff where the team argues about whose number, status, model, or document is correct. Do not begin with the platform. Ask:

What decision fails when this handoff fails, and where is the earliest point the team can see the evidence become untrustworthy?

Then complete the governance card for that one flow. Mark every field that lacks an owner, every transformation no one reviews, and every permission with no end condition. Choose one gap to test. This keeps the review tied to a handoff the team can observe.