COMPANY / ABOUT
About InfraDock
InfraDock turns the spreadsheets and documents construction and infrastructure teams already send into a dashboard that traces back to its source rows, and a question box that answers in plain English with page-level citations.
What we are building
Infrastructure and construction firms run their projects on two piles of paper. Spreadsheets arrive every week or month from sites and plants. Documents — contracts, tenders, claims, correspondence — run to thousands of pages. Both hold the answers management needs, and neither can be queried.
InfraDock turns the first pile into a dashboard that traces back to the exact row it came from, and the second into a question box that answers in plain English with page-level citations. Two halves of one platform, for the same team.
Consolidating the spreadsheets
Every site names its columns differently: Units Produced, Qty Made, and Output (nos) all mean the same thing. Row labels drift, so Line-2, Line 2, and L2 turn out to be one production line. One file reports in units while another notes figures in thousands above the header. Subtotal rows sit mixed in with real data, and last month gets restated because a number was wrong.
Files are read as they arrive. Consolidation, unit handling, and the rollups from lines to plants to project happen on upload, and any figure on the dashboard opens onto the file, the row, and the submission that produced it. Baselines stay versioned, so what was originally committed survives every revision. When a site restates a period, the original submission stays on record and the affected periods recompute — including later ones, where figures are cumulative.
Interrogating the record
A single project generates an EPC agreement, amendments, claim submissions, correspondence from the Authority Engineer, bank guarantees, completion certificates, and survey reports. Thousands of pages, many of them scans rather than text. Ask a question in plain English and the answer comes back with the document, the page, and the passage it rests on.
Scanned pages are read with OCR, so a photographed page is as searchable as a typed one. That matters, because the oldest and most contractually important papers in an archive are usually the photocopies. A question with several parts is broken down first, passages are retrieved and re-ranked for relevance, and only then is an answer composed — rather than one similarity lookup and hope.
Evidence, not a black box
A useful answer should not be something you have to take on trust. Every answer names the source pages it rests on, and every figure records the observations that produced it. In a contractual or arbitration setting, an answer nobody can point to in the document is worth nothing, so the citation is part of the answer rather than a decoration on it. Asking where a number came from should be a click, not an investigation.
Where the system stops and asks
Nothing is computed while any part of a file is not understood. If one row in two hundred cannot be confidently matched, the whole upload waits in the review queue and the dashboard keeps showing the number from yesterday rather than a guess from today. That is a deliberate choice: for a team making commercial decisions, a number that might be wrong is worse than a number that is a day old.
The same rule fences in the model. When it reads a column header and decides what it means, it chooses from a list written for that project rather than inventing a category, and an unrecognised column becomes an explicit not-known that follows the rule the team set — logged, queued for a person, or rejected outright. When two reports disagree about the same thing, that surfaces as a question rather than a quietly blended figure on a chart.
Configured, not rebuilt
Construction vocabulary is not hard-coded. A hierarchy of plants and lines, or of project, work packages, and activities; the metrics that matter; the rule for which report wins when two disagree; the shape of the dashboard — all of it is configuration. Setting up a new project means configuration plus a small adapter for the physical shape of the files, not a new system, and none of it asks for an ERP rollout, a workflow overhaul, or a retraining programme.
Who we build for
Construction leads the work: the document types, project logic, and reporting rhythm we design around come from construction projects. Inside a firm the work lands with four people — the project head who needs the question of whether the project is on track answered today rather than in three days, the planning team consolidating dozens of site spreadsheets by hand every month, the contracts and claims team hunting through a long agreement for the clause that governs a delay, and the site and plant managers who would rather not be chased for a resubmission because their file broke the report.
Manufacturing teams work with the same kinds of files and are supported as a secondary audience, configured the same way rather than through a separate product.
What this is not
Not a business intelligence tool. The value is not the chart. It is that the numbers were consolidated from messy sources without a person doing it by hand, and that each one is auditable back to a spreadsheet row.
Not a general chatbot. Answers come from the documents of one project, and when something is not in them, the correct answer is that it is not in them.
Not a template enforcer. We do not solve the spreadsheet problem by making every site fill in our form. Adapting to the file you already send is the product.
Not an autopilot. Where the system is unsure it stops and asks a person. That is a feature we sell, not a limitation we apologise for.
Talk to us
The fastest route is the enquiry form — we use it to arrange a walkthrough against your own document types.