The Opportunity
Construction documentation is still largely manual. Bridge projects generate enormous volumes of documentation - technical drawings, regulatory data, material specifications, external datasets - and every project depends on that information being complete, consistent, and timely. Without automation, collecting and structuring it for each engagement became a recurring bottleneck before any analysis, design, or reporting could begin.
Manual, multi-source documentation
Bridge projects pulled data from multiple sources: Word and PDF reports, Excel files, technical drawings, BIM/IFC models, and external databases such as Eurostat, weather APIs, and OECD datasets. Collecting and aligning this information was a manual, error-prone process that delayed downstream work and had to be repeated for every new project.
Critical information locked in images and BIM
Key structural details lived in technical drawings and BIM files rather than text: pillar counts, segment lengths, geometric layouts, hierarchical component relationships. Engineers were re-measuring and re-entering this information manually, introducing risk exactly where precision and traceability matter most, and making it difficult to reuse knowledge across projects.
Limited technical maturity and integration readiness
The internal platform used a strict hierarchical data model with immature, poorly documented APIs. Any attempt to automate extraction, document generation, or model building had to work around incomplete documentation and ad hoc integrations. This created a consistent “integration tax” on every new tool and made it hard to connect AI outputs reliably to existing systems.
The Solution
The work focused on building a single document intelligence layer that could sit on top of existing systems and handle the full spectrum of construction data while remaining compatible with the client’s hierarchical data model.
The first step was to automate extraction from the sources that teams touched every day: reports, spreadsheets, PDFs, and external datasets. Instead of copying values manually into internal structures, documents are now ingested, parsed, and mapped directly into the platform’s data model. External sources such as weather and regulatory statistics are pulled through APIs and normalised into the same structure, so project documentation can be generated from a consistent, reusable base.
From there, the same extraction logic was extended to visual inputs. Technical drawings that previously required manual measurement - bridge layouts, pillar configurations, segment dimensions - are processed through a visual pipeline that reads structural elements from images and converts them into structured fields. Visual and textual data end up in the same place, which means a single project view can combine both without extra manual work.
BIM files, which had been treated as separate, specialist artefacts, became part of the same ecosystem. A backend service reads IFC hierarchies, translates parameters into the internal data structure, and can write BIM files back from stored data when models or documentation change. Instead of redoing mappings for every project variation, a semi-automated mapping layer handles new parameters and structures as they appear.
On top of this foundation, a self-service environment was introduced for non-technical users. Engineers and project managers can assemble models, using predefined templates that plug directly into the structured data already available in the platform. They no longer need to start from raw files or wait for a data team to prepare every dataset.
Across all of this, the main constraint was integration. The hierarchical data model and incomplete API documentation meant every connection required careful mapping, testing, and iteration. The solution was designed with that reality in mind: modular components, clear interfaces, and a focus on making each new data source or model plug into the same backbone rather than creating yet another silo.
The Impact
Construction is an industry where the data already exists but remains inaccessible in practice because the tooling to move it reliably into a usable form hasn’t been built. Most teams absorb that cost as manual work, spread across projects, invisibly compounding delivery risk.
What BERD now has is an extraction and integration layer that covers the main document types their bridge projects depend on, all connected to a single internal data structure:
- Immediate gains come from time and accuracy: less manual transcription, fewer inconsistencies, and faster access to project-ready data.
- Longer-term value comes from starting each project with structured, validated information rather than spending the first phase of every engagement collecting it.
As technical maturity grows, the architecture is in place to go further:_ more data sources, more models, and more of the documentation process running without manual intervention.
