ATLAS

From fragmented project information to validated engineering knowledge.

Comment

Inspiration

I am a civil engineer working directly with construction operations and geotechnical projects.

Atlas did not start as a software idea. It started as a problem I kept facing at work.

At one point, I was involved in managing twelve projects at the same time while also coordinating a specialist geotechnical team. I could keep the projects under control, but doing so required a large amount of manual work: daily reports, spreadsheets, production records, costs, measurements, equipment, logistics and monthly results.

The information existed, but it was spread everywhere.

A large part of a construction company’s knowledge remains stored on company servers, inside folders organised according to the preferences of each project manager. One project may have a very detailed structure, while another depends on a few spreadsheets, emails and the personal memory of the people involved.

When a project manager changes or a project ends, much of the context becomes difficult to recover.

On many projects, it is also difficult to answer a basic question, item by item in the Bill of Quantities:

  • How much was actually produced?
  • How much labour was used?
  • Which equipment was required?
  • How much material was consumed?
  • What was the real cost?
  • Did the item generate or lose margin?

This level of control is often developed only when a project starts losing money, when the expected margin is low, or when an engineer needs to investigate a specific problem. By that time, part of the information may already be incomplete.

The problem is not that construction companies have no data. They have a lot of data. The problem is that it is dispersed, formatted differently from project to project and rarely connected in a way that preserves the complete story.

There is another reality I see regularly on construction projects.

The most active shared working environment between the contractor’s site management and the supervision team is often a WhatsApp group.

I have nothing against WhatsApp. It is fast, familiar and useful on site. Photos can be shared immediately, questions can be answered quickly, and operational changes can be communicated while the work is taking place.

The problem is what happens afterwards.

Photographs, voice messages, instructions, informal approvals and changes agreed on site become mixed with hundreds or thousands of messages. When the project finishes, the group becomes inactive, and almost nobody exports and organises the complete conversation.

The information may still exist on someone’s phone, but it no longer functions as usable project knowledge.

This led me to a simple question:

What if a construction project could preserve not only its documents, but also the context, evidence, decisions and lessons behind them?

That question became Atlas.

What it does

Atlas is an early working prototype of a governed engineering knowledge and decision workflow.

Its long-term vision is to become a knowledge and intelligence layer for the complete construction lifecycle, connecting owners, contractors, designers and supervision teams without forcing them to replace the systems they already use.

The existing systems remain the official sources.

Atlas adds the missing context between them.

It connects:

  • project documents;
  • activities and Bill of Quantities items;
  • daily production;
  • labour and equipment;
  • costs;
  • measurements;
  • evidence;
  • conflicts and missing information;
  • human decisions;
  • validated lessons.

The first implementation is deliberately focused on contractor-side operational control. Construction sites generate information every day, results can be checked quickly, and the value of better control can be measured directly.

The current prototype demonstrates one complete workflow:

project data → evidence → reconciliation → conflict detection → human validation → decision brief → validated lesson

The main demonstration is based on a real construction case that was manually converted into controlled demonstration data.

The workflow reconciles work executed during April 2026 with cost records and a later measurement record. It identifies four components with an internal reconciliation value of €44,135.73.

This amount is not additional revenue, savings or recovered value. It is an internal reconciliation of work executed in April and later included in a May measurement record. The prototype preserves the calculation’s origin, exclusions, limitations and validation status.

A second version of the case contains a deliberate evidence conflict. Atlas can still perform the calculation, but it blocks approval until the conflict is resolved.

This reflects an important principle:

AI can assist the analysis, but professional decisions remain human and evidence-based.

The longer-term ambition is broader.

Construction projects are already multi-organisation environments, but collaboration is often based on compressed archives, email attachments, messaging groups and disconnected folders.

A revised drawing may be sent by email, but if someone forgets to download it or place it in the correct folder, the site team may continue using an outdated version.

The owner may visit the site with the designer and agree on a change, but if nobody formally records it, the contractor, designer and supervision team may later hold different versions of what was decided.

Atlas aims to create a shared and governed project context where each participant contributes and validates the information related to their own responsibility.

How we built it

I first used GPT-5.6 to turn my practical construction experience into a structured product model.

This included defining:

  • the project workflows;
  • the information model;
  • the responsibilities of specialised agents;
  • evidence and validation rules;
  • the distinction between facts, calculations, assumptions and recommendations;
  • the human-review process;
  • the path from project records to reusable knowledge.

Codex was then used to turn these concepts into executable components.

The prototype includes:

  • a reusable Atlas Skill;
  • structured JSON schemas;
  • an evidence register;
  • sample project data;
  • a deterministic validation and reconciliation engine;
  • a command-line workflow;
  • automated tests;
  • conflict-detection rules;
  • approval-blocking rules;
  • human validation states;
  • an audit record;
  • a generated decision brief;
  • a validated lesson output.

Codex and GPT-5.6 had different but complementary roles:

  • Codex helped build, modify and test the executable workflow.
  • GPT-5.6 helped structure the engineering reasoning, interpret the evidence and support the professional review experience.

The current prototype does not require a custom language model or API credits.

ChatGPT provides the reasoning and interaction environment, while the Atlas Skill, schemas and deterministic tools provide the engineering structure, rules and validation steps.

Atlas is currently being developed and tested through:

  • four engineering and construction case studies;
  • one live project being followed operationally;
  • one working evidence and decision workflow.

The four case studies explore different parts of the future product:

  • evidence and internal financial reconciliation;
  • project closeout and document continuity;
  • daily operational control across several work fronts;
  • geotechnical estimating and execution knowledge.

Challenges we ran into

The biggest challenge was not generating ideas. It was deciding what not to build.

Atlas has a broad vision, but for this Build Week I had to reduce it to something that could be built and demonstrated honestly.

Instead of presenting a complete construction platform that does not yet exist, I focused on proving one narrow workflow from beginning to end.

Another challenge was maintaining engineering rigour.

It is easy for an AI system to produce a confident answer. In engineering, however, a confident answer without evidence, provenance or professional validation may create more risk than value.

The prototype therefore had to keep a clear distinction between:

  • original source records;
  • extracted facts;
  • calculations;
  • assumptions;
  • conflicts;
  • recommendations;
  • approved human decisions.

The system also had to continue calculating when possible while still blocking approval when material evidence was missing or contradictory.

A further challenge was defining what “centralising information” should mean.

Atlas should not simply copy every file from every system into another database. Existing ERP, BIM, planning and document-management systems may remain authoritative.

The objective is to centralise the project context, relationships, provenance and ability to retrieve information while respecting responsibilities and permissions.

Accomplishments that we're proud of

I am proud that Atlas moved from a broad concept to a small but executable workflow.

The prototype can:

  • validate structured project information;
  • reconcile production, costs and measurements;
  • link results to evidence;
  • identify missing or conflicting information;
  • prevent approval when a blocking issue exists;
  • record a human decision;
  • generate an auditable decision brief;
  • convert an approved result into a reusable lesson.

I am also proud that the prototype is honest about its current maturity.

It is not presented as a complete platform, a production-ready multi-user system or an autonomous engineering agent.

It is an early working prototype that proves one important path:

fragmented project information can be transformed into traceable analysis, human-validated decisions and reusable engineering knowledge.

The project also established a wider architecture for:

  • the ADO, focused on construction operations;
  • the AGO, focused on geotechnical estimating and execution knowledge;
  • Atlas BI, focused on evidence-linked operational and management indicators;
  • a governed Knowledge Base covering projects, activities, costs, decisions and lessons.

What we learned

The main lesson was that the construction industry probably does not need another isolated application.

It already has many applications.

What is missing is a layer that connects project information while preserving:

  • where it came from;
  • what it relates to;
  • who is responsible for it;
  • whether it has been validated;
  • what decision was made;
  • what can safely be reused.

I also learned that communication is not the same as knowledge preservation.

An instruction may have been sent by email or WhatsApp. A photograph may have been shared. A decision may have been discussed during a site visit.

But unless that information is connected to the relevant activity, drawing, participant, date, evidence and approval status, the project has communicated without properly capturing its knowledge.

Another important lesson is that a productivity value is not useful by itself.

To improve a future estimate, the value must remain connected to its context:

  • project type;
  • ground conditions;
  • geometry;
  • equipment;
  • team composition;
  • access;
  • weather;
  • constraints;
  • source evidence;
  • validation status.

This creates a continuous learning cycle:

estimate → execute → measure → validate → learn → improve the next estimate

The ADO can capture what happened during execution. The AGO can later use that governed knowledge to improve productivity assumptions, team composition, equipment selection, risk allowances, programme durations and future budgets.

What's next for ATLAS

The immediate next step is to turn the current contractor-side prototype into a persistent project workspace.

The priorities are:

  • automated ingestion of Excel files and project documents;
  • a persistent project registry and evidence database;
  • structured daily capture of production, labour, equipment and costs;
  • item-by-item comparison between the Bill of Quantities, budget, production and actual cost;
  • collaborative workflows for logistics, equipment, procurement, safety and quality;
  • dashboards through Atlas BI;
  • integration between execution data and future estimating through AGO.

The next stage is multi-user operation inside the contractor organisation.

The objective is for each participant to contribute and validate the information related to their own responsibility, instead of depending on one project manager to collect, download and reorganise everything manually.

A later stage is multi-organisation collaboration between:

  • contractors;
  • owners;
  • supervision teams;
  • designers;
  • subcontractors;
  • laboratories;
  • suppliers.

This does not mean giving everyone access to all project information.

Access must remain controlled by organisation, role, project, responsibility and information type.

The long-term objective is to replace fragmented exchanges of compressed folders, email attachments and temporary messaging groups with a shared, governed project context.

A drawing revision, site instruction, design clarification or agreed change should not depend on one person remembering to download an attachment or update a folder.

It should become a traceable project record linked to:

  • the relevant document;
  • the activity affected;
  • the responsible participants;
  • the date;
  • its approval status;
  • the operational and commercial impact;
  • the evidence supporting the decision.

Atlas is still an early-stage prototype and requires further technical development, product validation and incubation before it can become a production-ready platform.

However, the work completed so far has helped validate both the underlying problem and the proposed direction. The first executable workflow shows that fragmented project information can be transformed into traceable analysis, governed decisions and reusable engineering knowledge.

I am now looking for the right environment and partners to help Atlas grow: technical collaborators, construction and engineering organisations willing to support real-world pilots, and an incubator or strategic partner capable of helping turn the current prototype into a scalable product.

The vision is ambitious, but the next step is practical: continue testing Atlas on real projects, improve it with future users and build each capability from evidence rather than assumptions.

Projects end. Engineering knowledge should not.

Built With

Share this project:

Updates