The question that kills these systems is always the same one, and it always comes from the expert, not the engineer: “Where did this date come from?”<\/p>\n\n\n\n
You have a screen showing a beautiful chronology. Two hundred events, colour-coded by discipline, cross-referenced against the programme. The delay expert points at row 47, the one that says the piling rig arrived late, and asks which document that came from, who produced it, what page, and whether the other side has seen it. If the answer involves anyone opening a folder and searching, the platform has already failed. Not technically. Evidentially. A chronology nobody can trace back to a produced document is a nice picture, and a nice picture is worth nothing in an adjudication.<\/p>\n\n\n\n
That is the constraint that shapes everything else. A construction dispute intelligence platform is not a search engine with a construction theme on it. It is a provenance system that happens to do search. Get that ordering wrong and you build something impressive that no expert will sign their name to.<\/p>\n\n\n\n
This post walks through the architecture layer by layer: intake and chain of custody, normalization, the schedule data plane, the chronology model that joins the two, retrieval, and the tightly bounded generation layer on top. For each one I’ll say what it prevents, because that is the only reason any of these layers exist.<\/p>\n\n\n\n
Strip away the vocabulary and the job is narrow. Take a pile of heterogeneous records from a capital project, some of them structured and some of them scanned faxes, and let a small number of expensive humans answer three questions quickly and defensibly:<\/p>\n\n\n\n
The third one is not a nice-to-have. Both of the industry references people actually argue from lean on it. The Society of Construction Law Delay and Disruption Protocol raised record keeping to a core principle in its second edition and stopped expressing a preference between retrospective delay analysis methods, on the reasoning that the records you have largely determine the method available to you. AACE International’s Recommended Practice 29R-03 codifies forensic schedule analysis into a taxonomy of Method Implementation Protocols, and its minimum implementation protocols are essentially statements about which source schedules you must be able to produce. Both documents are, underneath, about evidence handling. So is your architecture.<\/p>\n\n\n\n
Everything upstream of this layer is somebody else’s mess. Site photos on a phone, a shared drive nobody pruned since mobilization, an Aconex export, a hard drive that arrived in an envelope. Your job at intake is to make an irreversible statement about what you received and when, before anyone touches it.<\/p>\n\n\n\n
Hash every file on arrival and store the hash next to the object, not in a spreadsheet. SHA-256 over the raw bytes, computed before any conversion, deduplication or renaming. The hash becomes the document’s identity for the rest of its life.<\/p>\n\n\n\n
# Build an arrival manifest before anything else runs\nfind .\/ACME-INTAKE-001 -type f -print0 \n | xargs -0 sha256sum > manifest-ACME-INTAKE-001.txt\n\n# Re-verify later, after the files have moved through processing\nsha256sum -c manifest-ACME-INTAKE-001.txt<\/code><\/pre>\n\n\n\nThen put the originals somewhere they cannot be quietly edited. On AWS, S3 Object Lock in compliance mode with a retention period is the blunt instrument: once set, the object version cannot be overwritten or deleted by anyone, including the root account, until retention expires. Governance mode is the softer variant, where a specifically permissioned principal can lift the lock, which is fine for internal working copies and wrong for originals. If you are self-hosting on a Contabo or InterServer box because the client will not put project data in a hyperscaler, the equivalent discipline is a write-once staging volume plus an append-only manifest log, and you accept that you are relying on process rather than on the storage layer refusing the write.<\/p>\n\n\n\n
The manifest is the product<\/h3>\n\n\n\n
If the matter is already in formal disclosure, you will be handed productions rather than raw folders, and those arrive as load files. A Concordance DAT carries one row per document with fields like BegBates, EndBates, Custodian, BegAttach, EndAttach and an MD5 hash. An Opticon OPT carries one row per page, mapping Bates numbers to image paths. The delimiters are deliberately weird characters that real text rarely contains, and different tools disagree about the exact code points, so parse defensively and log what you detected rather than assuming.<\/p>\n\n\n\n
The failure mode here is quiet and expensive. Variable-width Bates numbers sort lexically instead of numerically, so ABC10 lands between ABC1 and ABC2, attachment ranges resolve to the wrong parents, and a family of documents silently splits. Nobody notices until an expert cites a covering email whose attachment, in your system, belongs to a different letter. Pad to fixed width on ingest and reconcile every BegAttach range against the documents you actually loaded.<\/p>\n\n\n\n
Layer two: normalization, and the OCR tax nobody budgets for<\/h2>\n\n\n\n
Construction corpora are the worst kind of mixed. Native Office files with clean text, born-digital PDFs, scanned site instructions with a signature and a coffee ring, photographs of whiteboards, and drawings where the only text that matters is inside a title block in the bottom right corner.<\/p>\n\n\n\n
Route by what the file actually is, not by extension. For a PDF, try text extraction first; if the extracted layer is empty or nearly empty, it is a scan and needs OCR. Tesseract via OCRmyPDF is the cheap path and it is genuinely good on clean typed pages. It degrades badly on handwriting, on stamps, and on anything skewed, which describes most site paperwork. A managed service such as Amazon Textract handles tables and forms better and returns geometry for every detected block, which matters more than accuracy alone.<\/p>\n\n\n\n
Geometry is the part teams skip and then rebuild six months later. If you store only the extracted string, you can prove a phrase exists somewhere in a document. If you store the page number and the bounding box, you can put a highlight on the exact line in the viewer, and the expert can confirm it in two seconds instead of reading eleven pages. That difference is the difference between a tool people use and a tool people abandon.<\/p>\n\n\n\n
Keep the OCR text separate from the original in storage, and record which engine and which settings produced it. When a disputed reading of a handwritten date turns up, and it will, you want to be able to say exactly how that character was produced.<\/p>\n\n\n\n
Layer three: the schedule plane is a separate data model<\/h2>\n\n\n\n
This is where most teams underestimate the work. Programme data is not documents. It is a graph, versioned, with a calendar attached, and it needs its own tables, its own ingest path and its own validation.<\/p>\n\n\n\n
Primavera P6 exports as XER, a tab-delimited text format with a table-per-section layout, or as P6 XML. Either way you are pulling out projects, the WBS tree, activities, logic links and calendars. In XER these live in sections including PROJECT, PROJWBS, TASK, TASKPRED and CALENDAR. Parsing it by hand is a bad use of a week; PyP6Xer is an open source Python parser that will get you to objects quickly.<\/p>\n\n\n\n
from xerparser.reader import Reader\n\nxer = Reader(\"update-14.xer\")\n\nfor project in xer.projects:\n print(project.proj_short_name)\n for activity in project.activities:\n print(activity.task_code, activity.task_name)<\/code><\/pre>\n\n\n\nTwo things bite immediately. First, several duration and float fields in XER are stored in hours rather than days, which you can see in the column names themselves. If you load them straight into a “days” column because the numbers looked plausible on a five-day calendar, every float figure downstream is wrong by a factor that varies with the calendar. Check your own export before you trust any mapping, including this one.<\/p>\n\n\n\n
Second, activity IDs are not stable across a project’s life. Activities get renumbered, split, deleted and re-added between updates. If your schema keys on the activity ID alone, two updates will silently merge activities that were never the same work. Key on a composite of schedule version plus activity ID, and maintain a separate mapping table for identity across versions that a human can correct. That table is boring, it is not automatable, and it is the difference between a windows analysis that holds together and one that quietly compares apples to a different orchard.<\/p>\n\n\n\n
Store every update as an immutable snapshot with its data date. Never mutate a loaded schedule. The whole point of the layer is that you can reconstruct exactly what the programme said on a given day, which is precisely what a time slice or windows method needs.<\/p>\n\n\n\n
Layer four: the chronology is the join, and the join is the hard part<\/h2>\n\n\n\n
Documents on one side, schedule snapshots on the other. The product is the thing in the middle: an event, with a date, a description, a set of supporting document references, and a set of affected activities.<\/p>\n\n\n\n
Model it explicitly. An event is not a document and it is not an activity. One letter can create three events. One event can be evidenced by nine documents and a photograph. The relationship is many-to-many in both directions and every attempt I have seen to flatten it ends with someone maintaining a spreadsheet on the side.<\/p>\n\n\n\n
-- Every assertion resolves to a page and a box on that page\nCREATE TABLE evidence_ref (\n id BIGSERIAL PRIMARY KEY,\n event_id BIGINT NOT NULL REFERENCES event(id),\n document_id UUID NOT NULL REFERENCES document(id),\n page_number INT NOT NULL,\n bbox JSONB, -- normalized coordinates from OCR\n quoted_text TEXT NOT NULL,\n asserted_by TEXT NOT NULL, -- 'analyst' or 'model'\n confirmed_by TEXT, -- NULL until a human confirms\n confirmed_at TIMESTAMPTZ\n);<\/code><\/pre>\n\n\n\nThose last three columns are the ones that matter. They encode the difference between something the machine proposed and something a person stands behind. Report generation reads only rows where confirmed_by<\/code> is set. Everything else is a suggestion queue. This is not a compliance box; it is the mechanism by which an expert can put their name on the output, and it needs to exist in the schema rather than in a workflow convention that erodes under deadline.<\/p>\n\n\n\nLayer five: retrieval that finds document numbers, not just meaning<\/h2>\n\n\n\n
Pure vector search is the wrong default for this corpus, and it fails in a way that looks like success. Embeddings are good at meaning and bad at tokens. Ask for “RFI 0442” and a dense retriever will cheerfully hand you eleven chunks about requests for information, none of which is RFI 0442, because the identifier got smeared into its semantic neighbourhood. Construction disputes run on identifiers: RFI numbers, variation order references, drawing revisions, activity IDs, Bates ranges.<\/p>\n\n\n\n
Run lexical and semantic retrieval in parallel and fuse the rankings. PostgreSQL with the pgvector extension does both without adding infrastructure: an HNSW index over the embedding column, a GIN index over a generated tsvector column, and reciprocal rank fusion to merge the two candidate lists.<\/p>\n\n\n\n
CREATE EXTENSION IF NOT EXISTS vector;\n\nCREATE TABLE chunk (\n id BIGSERIAL PRIMARY KEY,\n document_id UUID NOT NULL,\n page_number INT NOT NULL,\n body TEXT NOT NULL,\n body_tsv tsvector GENERATED ALWAYS AS\n (to_tsvector('english', body)) STORED,\n embedding vector(1536)\n);\n\nCREATE INDEX chunk_tsv_idx ON chunk USING gin (body_tsv);\nCREATE INDEX chunk_hnsw_idx ON chunk USING hnsw (embedding vector_cosine_ops);<\/code><\/pre>\n\n\n\nOver-fetch from each side and trim after fusion rather than pulling the final count from each; more candidates give the fusion step something to work with. Add a trigram index if your corpus has OCR noise, because “RFI 0442” and “RFl 0442” are the same document to a human and different tokens to Postgres.<\/p>\n\n\n\n
Filter hard on metadata before ranking. Matter, custodian, date range, privilege status. A retrieval layer that can return a privileged document into a shared workspace is a liability, not a feature.<\/p>\n\n\n\n
Layer six: generation, bounded hard<\/h2>\n\n\n\n
Language models are useful here and the useful jobs are smaller than the demos suggest: proposing candidate events from a batch of correspondence, drafting neutral one-line summaries, clustering near-duplicate records, suggesting which activities an event might touch. Every one of those is a proposal that lands in a review queue.<\/p>\n\n\n\n
The reason to be strict is not squeamishness. Stanford’s RegLab and HAI ran a preregistered evaluation of commercial legal research tools built on retrieval-augmented generation, with expert-scored answers, and found hallucination rates in the range of roughly 17 to 33 percent depending on the product, against vendor marketing that had claimed hallucination-free citations. The vendors disputed the characterization. The finding that should worry you more than the headline number is the failure mode underneath it: a citation that exists, is quoted accurately, and does not stand for what the answer says it stands for. Retrieval reduces fabrication. It does not produce correct reasoning about what a document means, and misgrounding is far harder to spot than an invented reference.<\/p>\n\n\n\n
So bound it. Generation writes to the proposal table, never to the report. Every generated assertion carries the chunk IDs it was built from, and the UI shows the source page beside the claim by default rather than behind a click. If a proposed event has no evidence reference, it does not enter the queue at all.<\/p>\n\n\n\n
Tenancy, privilege, and the thing that ends the engagement<\/h2>\n\n\n\n
Matters do not share data. Ever. Not “logically separated by a WHERE clause that we always remember to add”. The cheapest defensible pattern is a database per matter, or at minimum a schema per matter with connection-level scoping, so that a missing predicate produces an empty result rather than another client’s correspondence.<\/p>\n\n\n\n
Two more that get discovered late. Privilege state is per document per matter and it changes; model it as a versioned attribute with an audit trail, not a boolean someone flipped. And plan the exit at the start: matters end, retention clocks expire, and someone has to certify destruction. That means knowing every copy you made, including OCR text, thumbnails, embeddings and backups. Tools like the O&O Software utilities have a place at the endpoint end of that job; the platform side is a deletion manifest that enumerates derived artifacts per document, written at ingest rather than reconstructed under pressure.<\/p>\n\n\n\n
If experts are working from home, from site cabins, or from three countries, the access path is part of the design. A managed VPN such as NordVPN or Surfshark on the client side plus network-level allowlisting on the platform side is a pragmatic combination, and it is worth writing into the engagement documentation so nobody improvises with a personal Dropbox at eleven at night.<\/p>\n\n\n\n
Where these platforms break in practice<\/h2>\n\n\n\n\n- Chronology dates drift from document dates.<\/strong> Usually a timezone or a date-format collision: a scanned form read as DD\/MM, an email header parsed as UTC, a schedule data date stored as a naive timestamp. Store the raw string you extracted alongside the parsed value and show both in the review UI.<\/li>\n\n\n\n
- Float figures look wrong by a constant factor.<\/strong> Hours versus days in the schedule import. Check against the same activity opened in P6 before you debug anything else.<\/li>\n\n\n\n
- Retrieval misses a document everyone knows exists.<\/strong> Either it was never OCR’d because the PDF had a thin text layer that passed your emptiness check, or the identifier is only in the title block of a drawing. Log extraction character counts per page and alert on suspiciously low ones.<\/li>\n\n\n\n
- Two activities merged across updates.<\/strong> Composite keying was not applied, or an activity was renumbered. Diff activity code sets between consecutive snapshots and surface additions and deletions as a report the planner reviews.<\/li>\n\n\n\n
- Document families split.<\/strong> Bates padding or an unreconciled attachment range from the load file. Re-run the family reconciliation and count orphaned attachments.<\/li>\n<\/ul>\n\n\n\n
Common mistakes<\/h2>\n\n\n\n\n- Treating the schedule as documents. It is a graph with versions, and shoehorning it into the document store costs you every analysis you actually wanted.<\/li>\n\n\n\n
- Storing extracted text without page and coordinate provenance. Cheap now, a full reprocessing run later.<\/li>\n\n\n\n
- Vector-only retrieval. Looks great in a demo built from prose, falls over on the first RFI number.<\/li>\n\n\n\n
- Letting model output reach a deliverable without a recorded human confirmation.<\/li>\n\n\n\n
- Mutating loaded schedules to “fix” them. Fix on the way in, or hold the correction as an annotation. Never edit the snapshot.<\/li>\n\n\n\n
- Deferring the deletion story to the end of the matter, when the derived artifacts are already scattered.<\/li>\n<\/ul>\n\n\n\n
Best practices for building a construction dispute intelligence platform<\/h2>\n\n\n\n\n- Hash at the door, lock the originals, and never process in place.<\/li>\n\n\n\n
- Make every derived artifact point back to a document ID, a page and a region.<\/li>\n\n\n\n
- Give schedules their own immutable, version-keyed store with the data date as a first-class field.<\/li>\n\n\n\n
- Model events separately from both documents and activities, with many-to-many links in each direction.<\/li>\n\n\n\n
- Run hybrid retrieval and fuse the rankings; filter on matter and privilege before you rank.<\/li>\n\n\n\n
- Keep generation in a proposal queue with confirmation recorded in the schema.<\/li>\n\n\n\n
- Isolate matters at the database or schema boundary, not in application code.<\/li>\n\n\n\n
- Instrument ingest as seriously as you would a production pipeline. Grafana over your extraction counts and OCR queue depth will tell you a corpus is going wrong days before an analyst does.<\/li>\n<\/ul>\n\n\n\n
Frequently asked questions<\/h2>\n\n\n\nDo I need a dedicated vector database for this?<\/h3>\n\n\n\n
Almost certainly not. Matter corpora are large in gigabytes and small in chunk count compared to consumer-scale search. PostgreSQL with pgvector keeps the embeddings in the same transaction as the provenance rows, which means you cannot end up with a chunk whose document record was rolled back. That consistency is worth more here than the last few milliseconds of query latency.<\/p>\n\n\n\n
Should the platform pick a delay analysis method?<\/h3>\n\n\n\n
No. That choice belongs to the expert and depends on the contract, the forum, the records available and the timing of the analysis. What the platform should do is make it obvious which methods the record set can support, by reporting what you actually have: how many schedule updates, at what intervals, with what data dates, and how complete the contemporaneous correspondence is around each window.<\/p>\n\n\n\n
XER or P6 XML for schedule ingest?<\/h3>\n\n\n\n
Accept both, because you will be sent both. XER is what planners export by habit and it is easy to parse with existing libraries. P6 XML is more explicit about structure and less prone to encoding surprises. Whichever arrives, keep the original file, hashed, alongside the parsed rows.<\/p>\n\n\n\n
How much of the review can realistically be automated?<\/h3>\n\n\n\n
The ranking and the grouping, most of it. The judgement, none of it. Automation that reduces a hundred thousand documents to a few thousand worth reading is enormously valuable and uncontroversial. Automation that decides what a letter means is where you inherit risk you cannot price.<\/p>\n\n\n\n
Can I build this on top of a common data environment we already have?<\/h3>\n\n\n\n
Partly. A CDE such as Aconex is a good source of records and a poor system of record for a dispute, because access changes, exports are point-in-time, and the retention rules belong to the project rather than to the matter. Pull from it, hash what you pulled, and hold your own copy under your own lock.<\/p>\n\n\n\n
What does this cost to run?<\/h3>\n\n\n\n
The shape of the bill is more useful than a number. OCR and embedding are one-time per document and scale with page count, so a scan-heavy corpus costs multiples of a born-digital one. Storage is small and constant. Retrieval is negligible. Generation scales with how much you push through it, which is another argument for narrow, queued use rather than a chat box over the whole corpus.<\/p>\n\n\n\n
Is a general eDiscovery platform not enough?<\/h3>\n\n\n\n
For document review, often yes, and they are considerably better at productions and privilege logging than anything you will build in a quarter. What they do not have is the schedule plane. The value of a construction-specific build is the join between correspondence and programme versions, so a sensible architecture frequently uses an established review platform for documents and adds the schedule and chronology layers alongside it.<\/p>\n\n\n\n
The one thing worth remembering<\/h2>\n\n\n\n
A construction dispute intelligence platform earns its place by making provenance cheap. Search, clustering and summarization are commodity capabilities now; anyone can bolt them onto a corpus in a fortnight. What is hard, and what decides whether an expert will rely on the output, is that every date, every event and every sentence in the eventual report resolves in one click to a specific page of a specific produced document, with a record of who confirmed it.<\/p>\n\n\n\n
Build the provenance spine first. Hash at intake, keep coordinates, version the schedules, model events as their own thing, and keep the model on the proposal side of a human confirmation. The clever features are easy to add afterwards. Retrofitting evidence handling into a system that was designed as a search tool is a rebuild, and it always arrives at the worst possible moment, which is about three weeks before a hearing.<\/p>\n\n\n\n
\n\n\n\nNeed help building or fixing this?<\/h2>\n\n\n\n
I work on the infrastructure side of exactly this problem: getting messy project records into a system where every claim is traceable. Things I can help with:<\/p>\n\n\n\n
\n- Designing the intake and chain-of-custody layer, including hashing, immutable storage, and load file parsing that survives odd delimiters and inconsistent Bates padding.<\/li>\n\n\n\n
- Building the schedule ingest path for XER and P6 XML, with version-keyed snapshots and an activity identity map that holds across updates.<\/li>\n\n\n\n
- Standing up hybrid retrieval on PostgreSQL and pgvector, including page-level and coordinate-level provenance so highlights land on the right line.<\/li>\n\n\n\n
- Setting up the OCR and normalization pipeline, with routing rules, quality checks, and alerting on pages that extracted suspiciously little text.<\/li>\n\n\n\n
- Matter isolation, privilege state modelling, audit logging, and a deletion manifest you can act on at the end of the engagement.<\/li>\n\n\n\n
- Reviewing an existing platform and telling you plainly where the provenance chain breaks.<\/li>\n<\/ul>\n\n\n\n
If you have something concrete, send it over: an XER export, a sample DAT and OPT pair, a page count breakdown of your corpus, or the schema you are currently working from. It is much easier to say something useful about a real file than about a description of one.<\/p>\n\n\n\n