MEng research · Construction lessons learned · NLP

From a project interview to a lesson the next project can use

Construction teams learn a great deal on every project, but most of it stays in people's heads or in post-project interviews that nobody reads again. EngNLP is the research tool behind an MEng thesis: it turns a recorded interview into structured lessons, placed in a construction taxonomy, and rewrites each one as advice that another project can reuse.

Log in
01

The pipeline

six stages, four branches
STAGE 1
Transcribe & review
Audio to verbatim text. A person checks the transcript before anything else runs.
ASRhuman gate
STAGE 2
Resolve narrative
Dialogue rewritten as one narrative of what the interviewee said. Interviewer commentary is dropped.
LLM
STAGE 3
Atomise
The narrative split into atomic statements, each one self-contained fact.
LLM
STAGE 4
Root categorisation
Statements sorted into project information and Event–Cause–Lesson tuples, one tuple per incident.
LLMB-cubed
Stage 5 · four parallel branches
5A Project Information T1
Slot match by cosine similarity; value by named-entity recognition.
5B Originating Event T1 T2 T3
Event type, situation infons by semantic-role labelling, effect severity on an ordinal scale.
5C Root Cause T4
Each cause statement placed in a 639-node tree by a four-method vote.
5D Actionable Lesson T2 T3
Rule frame (do / don't, action, condition), benefit tier, reuse type.
STAGE 6
Generalised lesson
The four branches recombined into one advice sentence another project can reuse.
LLMfaithfulness judge
Fig. 1Stages 1–4 are shared. At Stage 4 each interview forks into four taxonomy branches, which run independently and rejoin at Stage 6. Each stage unlocks only when the one before it has run; the transcript review is the only manual step.
02

The taxonomy

where every statement is placed
Project Information once per interview Event–Cause–Lesson tuple, once per incident (×n) 29 nodes · 12 attributes T1 Project Name · Project Type · Client · Contract Type · Cost · Duration · Start Date · End Date Location · Project Manager · Technology · Project Identifier children expandable, e.g. Project Type → Roads, Water Supply, Housing … Originating Event what happened Root Cause why it happened Actionable Lesson what to do next time Event Type 6 categories T1 Situation Infons R, A, O, l, t T2 Event Effect ΔC ΔT ΔQ ΔS ΔE T3 639 nodes · 13 categories · 3 levels below Root Cause T4 e.g. Design process, Material, Project management, Financial factors, External factors … each cause statement is tagged with its best node Lesson in Context Situation, State, Agent, Deontic, Action, Reasoning T2 Lesson Benefit ΔC ΔT ΔQ ΔS ΔE gains ordinal tiers 1–4 T3 Re-use do / don't / ambiguous, from the deontic operator
T1 Fixed attribute, expandable children. Filled by the best-matching statement; value by named-entity recognition.
T2 Fixed slot. The tuple's statements are distilled to one sentence, then an LLM reads the frame (SRL or rule frame).
T3 Fixed leaf. Value is an ordinal tier chosen by a cross-encoder, or an entity.
T4 Deep tree. Each statement is placed in it by a four-method ensemble vote (Fig. 3).
Fig. 2The taxonomy (704 nodes). Project Information describes the project once; every incident becomes an Event–Cause–Lesson tuple. The four node types T1–T4 differ in how a slot is matched and how its value is read. The taxonomy is shared by all users and edited only by the superadmin.
03

Placing a root cause

Cause statement embedded, 3072-d M1 Flat search nearest node by cosine, across the whole tree M2 Beam search top-down, keeps the best 3 paths per level M3 Upward score propagation children lift parents; per-node relevance α M4 Cross-encoder re-rank re-scores the pooled M1–M3 candidates Majority vote ties broken M1 > M2 > M3 > M4 Parent Gap check promote to the parent when it fits better than the leaf; never into Root Cause itself → Root Cause node + path
Fig. 3How a cause statement is placed in the Root Cause tree. Four methods search the tree independently and vote. Every score is on one scale, similarity = max(0, 1 − cosine distance); the cross-encoder's logits are used only to rank. The ablation on the Evaluation tab scores each method alone against the vote.
04

The output: a generalised lesson

Every tuple ends as one sentence of advice, built from the four branches:

When the situation arises because of its root cause, on this type of project, to improve the benefit, you should / you should not / consider the action.
5B situation 5C cause 5A project type 5D benefit, deontic operator, action
05

How it is evaluated

TIER 1

Model selection

Each of the pipeline's model slots is chosen by comparing candidate models. Transcription is scored by word error rate against a reference transcript. A judge model must come from a different provider from the model it grades.

TIER 2

Per-stage checks

Each stage is scored against a blind expert baseline: element-level precision, recall and F1 with bootstrap 95% intervals, P/R/F1 of the root causes found per tuple (exact and hierarchical), B-cubed for tuple grouping, and a Root Cause ablation of each method.

TIER 3

Pooled result

Element decisions pooled across every interview with a baseline, giving one score per branch with its confidence interval. Stage 6 is judged on faithfulness: every claim in the advice must trace back to the branch outputs.

Pipeline runs Stages 1–3 give the narrative & statements Evaluator labels blind sees the statements and the empty taxonomy, not the output Save → locked the baseline can no longer be edited Reveal & compare pipeline output shown beside the baseline, per element Scored TP FP FN TN → Tier 2 & 3 no pipeline output visible output visible
Fig. 4The three evaluation tiers, and the blind protocol that Tier 2 depends on. Because the evaluator commits to their own labels before seeing the pipeline's, the baseline cannot be anchored on the output it is used to score.
06

Who does what

Userpractitioner
aAdd interview→ bRecord or paste transcript→ cReview transcript→ dRun Stages 2–6→ eShare with evaluators
Evaluatordomain expert
fOpen a shared interview→ gLabel statements & elements blind→ hSave & lock→ iCompare with the pipeline
Superadminresearcher
jMaintain the taxonomy· kSelect models (Tier 1)· lAssign roles· mPool results (Tier 3)
Fig. 5The three roles. Users own their interviews and run the pipeline on them. Evaluators see only the interviews shared with them, and see the pipeline's output only after locking their baseline. The superadmin sees everything and is the only role that edits the taxonomy.

New accounts start with the User role. Evaluator access is granted by the researcher.