Use Cases · Commercial & Change Control
Every change tested against the record, including the ones nobody formally logged.
Every change and value engineering decision is tested against the live requirement register before it is signed off.
- What it undoes, named up front, before the design is redrawn
- Informal instructions caught, found in correspondence and raised as variations
- Every position a requirement held, so drift is visible rather than discovered
- Value engineering review
- Change order prevention
- Bid review
- Insurance claim checking
Variation register · stage 4Week 34
Cladding build-up revisedVO-014 · client instruction
£84,200
Agreed
Riser relocation, levels 3 to 7VO-018 · design development
£31,600
Agreed
Reception finish upgradedAsked for in the week 22 meeting
Not priced
Unlogged
Second stair pressurisation addedClient email, 4 Jun
Not priced
Unlogged
Plant deck acoustic screenDesign team memo, 19 Jul
Not priced
Unlogged
Work instructed, delivered, and never charged for
3 changesCurrent practice
A change is priced against the contract, not against what the design already committed to.
Cost and programme are assessed. What is rarely assessed is which settled requirements the change quietly undoes, because that would mean holding every requirement, its history and its evidence in one place. So the consequence is discovered later, in a clash, a validation turn-back, or a claim.
- Impact is judged after the design is redrawn, so effort is committed before the consequence is known
- A requirement agreed months ago can be undone without anyone noticing it was agreed
- Changes requested informally are never raised, so the work is delivered unpaid
- When it is disputed, the sequence has to be reconstructed from correspondence
One value engineering decision, followed through
Decision taken22 weeks to discovery
With Tektome
Test the consequence before you commit the signoff.
A proposed change is evaluated against the live requirement register and its history before anything is modelled. What it touches, what it undoes and what it puts at risk are stated up front, so the decision is taken with the consequence visible rather than priced and discovered. Whichever way it goes, the reasoning is on the record for whoever answers for it later.
Proposed, not yet modelled
Substitute the cladding build-up. What does it reach?
14
Requirements touchedAcross facade, acoustics and fire
2
Settled requirements undoneAcoustic separation, cavity barrier spacing
3
Deliverables affectedFacade spec, fire strategy, acoustic report
The decision, taken knowingly
Three routes, priced against consequence.
Whichever is chosen, the reasoning is written down against the requirements it affects. No modelling effort was spent to find this out.
What you get
Every output carries its evidence.
Change detection from correspondence
Meeting notes, emails, reports and memos are scanned for changes the client or the team has asked for, and any that were never raised against the Employer's Requirements or the brief are flagged. The instruction that arrived in a sentence rather than a form is still an instruction.
Why it mattersAn informal change that is built and never priced is margin given away. It is also the hardest kind to recover once the job has moved on.
Correspondence scanned · week 34
Minutes
Cladding build-up revised
VO-014
Minutes
Reception finish upgraded
Unlogged
Second stair pressurisation added
Unlogged
Report
Riser relocation confirmed
VO-018
Memo
Plant deck acoustic screen
Unlogged
Three instructions found in writing that never became a variation, each with the document and date that carries it.
Impact visible before anything is modelled
A proposed change is run against the register first, so its effect on the design and the requirements is known before drawing effort is committed. Testing a change costs a question rather than a week.
Why it mattersThe point of maximum influence over a change is before the team has invested in making it work.
Proposed change · requirements reached
ProposedCladding build-up substituted
- Requirements touched
- Includes a settled one undone
Value engineering checked against settled requirements
Each saving is set against what it breaks. Where a proposal undoes something already settled, that is flagged at the point of decision rather than found in a later review, so the saving and its exposure are weighed together.
Why it mattersA saving that reappears as rework was never a saving. It was a deferred cost with a worse exchange rate.
Value engineering schedule · reviewed
Standardised door ironmongery
£19,400
Clear
Cladding build-up substituted
£112,000
Breaks 2
Reduced ceiling void, level 2
£27,800
Clear
Single stair pressurisation
£64,500
Breaks 1
Requirement drift, tracked
A settled requirement cannot be quietly undone. Every value it has held is kept with the decision and the person behind it, so when a later change moves it back, that is visible as a reversal of something agreed rather than as a fresh position.
Why it mattersDrift is not one decision. It is a sequence of small ones, each defensible on its own, which together undo what was agreed.
Acoustic separation, party wall type B
04 Mar
45 dB
Client brief §4.2
19 Jun
45 dB
Settled · acoustician
12 Aug
41 dB
VE, no reference
The August change did not cite the June decision, and would not have known it existed. The register does.
The record a dispute actually turns on
What changed, when, who asked for it, what it affected and what was decided, all linked. Ask for the position on any change in plain language and get the bundle back, drawn from the live record rather than assembled from an archive under time pressure.
IncludingChange and variation reports, value engineering schedules, client-facing packs and claim bundles, generated from your own templates across drawings, models and documents alike.
VO-014 · assembled from the record
Assembled as the work happened, not written up afterwards. Ask in plain language for any other cut of it.
Value
What the work produces, and the value it returns.
33.4%
disputed costs as a share of contract budget
HKA CRUX, 8th annual report, to July 2025
5–40%
cost overrun attributable to design changes, depending on when in the programme they land
Design Changes in Construction Projects, ResearchGate · range across the studies reviewed
9.83%
of project value lost to avoidable error, with 77% of it by value traced to inadequate planning
CITB / GIRI Productivity Commission, April 2026 · measured across 25 live UK projects worth £942.5m
Why Tektome
Drift is caught while it is a decision, not once it is a claim.
A change log records that something changed. It holds no requirements, so it cannot tell you what the change undid, and it only contains what somebody remembered to enter. Change here is validated against the live register and its history, which is what makes drift visible at the moment it happens rather than at the moment it costs.
| On this | A change log |  |
|---|---|---|
| What it records | The changes somebody entered | Change validated against the register that governs it |
| Informal instructions | Contains only what was raised, so one never appears | Scans correspondence, so an unlogged instruction is surfaced and priced |
| What a change undid | Holds no requirements, so it cannot say | Names the settled requirements it breaks, at the point of decision |
| When impact is priced | After the design has been redrawn | Before modelling effort is committed to it |
| Drift | Keeps no history, so a reversal reads as a fresh decision | Every position a requirement has held is kept, so drift has a record |
Who this is relevant to
The change is the same.
Whether it was ever priced is not.
An instruction that arrives in a sentence is still an instruction. Built and never raised, it is margin given away on a job that had none to spare. That is a commercial exposure, not an administrative one.
Commercial and finance
Commercial Director · Finance DirectorGeneral Counsel · Company Secretary
Variations that get priced
Instructions found in correspondence and raised as variations, rather than delivered inside a scope that never covered them.
Contracts and claims
Contracts Manager · Claims leadWhoever answers the claim
Evidence, not reconstruction
What changed, when, who asked and what it affected, linked at the time, so a dispute is answered from the record rather than an archive.
Design leadership
Technical Director · Head of Design ManagementHead of Technical Excellence
Consequence before commitment
The settled requirements a proposal would undo, named before the team spends weeks making the change work.
Client and development
Development DirectorClient side
Savings that hold
Value engineering weighed against the requirements it breaks, so a saving is not simply a cost moved further down the programme.
In the project team
Architect · Engineer · Quantity surveyor. Ask what a proposed change reaches and which settled positions it reverses, without assembling the answer by hand.
Next step
Interested to learn more?
A 30-minute session: a deeper look at the platform, and a conversation about the change and value engineering decisions your firm is carrying. Nothing to set up, no project data needed.
- A change tested against the register before it is signed off
- A walkthrough on a project we have prepared
- Live Q&A with our engineering team
Book a 30-minute intro
Your request is in.
We'll be in touch shortly to find a time that works.