Data-Centric Design Became the Bigger Idea

I was drawn to blockchain because it promised a shared history of what happened and when. I was drawn to AI because it could find patterns and generate useful language from large amounts of information.

The deeper I went, the more I realized that both technologies depended on a less visible question:

Is the data designed well enough to keep its meaning as it moves?

That question pulled me toward data-centric design.

Construction information loses context between systems

Construction teams create schedules, models, contracts, invoices, submittals, meeting notes, issue logs, and field reports.

Each record may be useful in its own system. The difficulty appears when people need to connect them.

Does the contractor named in one record match the organization in another? Is an "approved" item approved for fabrication, payment, installation, or closeout? Does the date describe a plan, a commitment, or an event that already happened?

Moving the values without their meaning creates another copy of the problem.

Ontologies make meaning explicit

An ontology describes the types of things in a domain and the relationships between them.

For a simple payment example, the model might define:

• a contractor;
• an invoice;
• an obligation;
• an amount;
• a due date;
• the relationship between the contractor and invoice.

The value is not the vocabulary alone. The value is the shared meaning that software and people can inspect.

Web standards such as RDF, the Resource Description Framework, represent information as statements connecting a subject, a property, and a value. OWL, the Web Ontology Language, can express classes, relationships, and constraints around that graph.

These tools can help systems exchange meaning without forcing every participant into one database.

A semantic model does not settle the business rule

Suppose a graph states that Contractor A has an obligation represented by Invoice 1 and records an amount and due date.

Software can query and connect those statements. It still needs business rules to answer:

• Which record is authoritative?
• Was the invoice approved?
• Are there retainage or disputed amounts?
• Did the contract change?
• Who may see the information?
• Which person accepts the calculation?

An ontology can make the concepts and relationships visible. It does not create contractual truth or assure compliance.

Design around questions people need to answer

Data-centric work can become too abstract if it begins with a universal model of the entire project.

A better starting point is one recurring question.

For example: What is preventing this work package from being ready?

Then identify the required entities and relationships:

• the work package;
• required information;
• procurement items;
• predecessor work;
• responsible parties;
• open constraints;
• source records;
• current status and review date.

The model earns its keep if it helps people answer the question across systems without losing where the information came from.

The data layer outlives the tool

Blockchain and AI will continue to change. Platforms will change too.

The project's need to preserve meaning, provenance, access, and responsibility will remain.

That is why data-centric design became the bigger idea for me. It asks us to design the information before we ask a new tool to automate it.

If you want to test the approach, choose one project question that currently requires people to reconcile several systems. Map the things, relationships, sources, and decision owner. Then decide which technology, if any, helps that information move with less loss of meaning.

Editorial disclosure: This adaptation and its representative image were developed with AI-assisted editorial and visual production, then reviewed and approved by Marcus Turner.