Property Development, Augmented

Ask a developer running three schemes what keeps them awake and they will rarely say they do not understand development. They understand it perfectly well. What they cannot do is find the one email, from eleven months ago, in which the structural engineer said the party wall detail depended on a survey that was never commissioned.

A modest residential scheme in the UK will generate several thousand discrete pieces of information before practical completion. Planning application documents and consultee responses. A design and access statement, a transport statement, an ecology survey, a daylight and sunlight assessment. Pre-commencement conditions and their discharge correspondence. Tender packs, subcontractor quotes, clarifications, and the six versions of the drawing that only one subcontractor is actually pricing. Site photographs. Delivery notes. Two hundred WhatsApp messages that contain instructions nobody minuted.

None of this is exotic. It is the ordinary substrate of a development business. The problem is that it lives in six systems that do not speak to each other — an email client, a shared drive, a phone camera roll, an accounting package, a messaging app and somebody's head — and the person who most needs it is the person with the least time to look.

Where the money actually leaks

The expensive failures in small development are usually retrieval failures dressed up as something else.

• A site is investigated for six weeks before someone reads the 2016 refusal that identified the same access constraint you have just paid a highways consultant to identify again.
• Two subcontract quotes are compared on headline price when one excludes scaffolding, temporary works and making good, and the exclusion was on page four.
• A variation is instructed verbally on site, delivered, and then disputed nine months later because the only record is a photograph with no caption.
• A funder asks for the evidence behind an appraisal assumption and the answer takes three days to reconstruct, badly.

In each case the expertise existed. Somebody in the chain knew. The information simply did not arrive at the moment of decision in a form that could be acted on.

What AI is actually good at here

Strip away the marketing and current language models do a small number of things unusually well: they read long documents quickly, they summarise with reasonable fidelity when the source is in front of them, they extract structured fields from unstructured text, they compare two documents and surface differences, and they draft. That is a narrow list. It is also, awkwardly, almost exactly the list of tasks eating the week of a development manager.

What AI is bad at, reliably

• Anything requiring current data it was not given. A model does not know your local plan unless you hand it the local plan.
• Arithmetic at scale. It will produce a plausible-looking appraisal with a wrong number in the middle. Calculate in a spreadsheet or a calculator; use the model for commentary.
• Legal, planning, structural and valuation conclusions. It will give you one confidently. It is not qualified, insured, or accountable.
• Knowing when it does not know. Absent explicit instruction, a model fills gaps rather than flagging them.

Every practical technique in this book is built around that split. Use the machine for the reading, the extraction, the comparison and the first draft. Keep the decision, and the record of the decision, with the professional.

Augmentation is a word that has been used to sell almost everything, so it needs a definition tight enough to fail a test.

A workflow is augmenting if a qualified person still makes the decision, still sees the evidence, and would still be able to explain the reasoning without the tool. Anything else is abdication with better graphics.

The liability test

The cleanest practical test is this: if the output were wrong and caused loss, who would be answerable? If the answer is your architect, your solicitor, your engineer or your QS, then that person must remain in the loop, must see the underlying document rather than the summary, and must have signed off in a way that leaves a record. If the answer is nobody, you have built a machine for creating unattributable risk.

Three failure modes

1. Summary drift. The team stops reading the source and starts reading the summary. Six weeks later a decision rests on a paraphrase of a paraphrase. Fix: every summary carries a citation to a page or clause, and any decision above a defined threshold requires the source to be opened.
2. Confidence laundering. A hedged human judgement goes into the model and comes back as clean declarative prose. The uncertainty is deleted by the formatting. Fix: require the model to output an explicit assumptions-and-unknowns block, and never delete it from the circulated version.
3. Silent scope creep. A tool built to compare quotes starts being used to select subcontractors. Fix: write the permitted-use statement into the prompt library entry itself, alongside a short list of prohibited uses.

The shape of a good workflow

Every workflow in this book has the same five parts, and if one is missing the workflow is not finished.

The rest of this book applies that structure across the development lifecycle: SITE for research and planning, BUILD for procurement and delivery, PROVE for evidence. The framework is deliberately boring. Boring survives model upgrades.

Most wasted professional spend in development happens in the first fortnight, on sites that were never going to work. The purpose of a desktop triage is not to decide whether to build. It is to decide whether the site deserves paid professional time.

What you can genuinely get from public sources

• Location fundamentals: local planning authority, ward, region, and administrative boundaries — available free and instantly from the ONS-derived postcode dataset.
• Planning history: the LPA's public planning register, searchable by address or application reference, including refusals and officer reports.
• Appeal decisions: the Planning Inspectorate's appeal decision database, which is where precedent actually lives.
• Policy: the adopted local plan and any neighbourhood plan, plus the LPA's five-year housing land supply position.
• Constraints: conservation areas, listed buildings, flood zones, tree preservation orders, article 4 directions.
• Comparable evidence: Land Registry price-paid data and EPC records for floor areas and condition signals.

None of that requires AI. What AI changes is the time cost of reading it. An officer's report is fourteen pages; a model given the actual PDF will tell you in twenty seconds which policies the case turned on and what the objections were. You then read those sections properly.

The thirty-minute sequence

1. Fix the location. Normalise the postcode, confirm the local planning authority, and note the region. Everything downstream depends on getting the right LPA.
2. Search the planning register for the site and the two neighbouring plots. Refusals on neighbours are frequently more informative than consents on your site.
3. Read the most recent refusal or the most recent consent in full. Not the summary — the decision notice and, if available, the officer report.
4. List the constraints that would change the scheme rather than the cost: flood zone 3, a listed neighbour, an article 4 removing permitted development, a TPO on the only viable access.
5. Pull three comparables and sanity-check your revenue assumption. If the scheme only works at a price nothing nearby has achieved, stop.
6. Run a rough appraisal. Not a valuation — a viability sniff test with a stated contingency and a stated finance cost.
7. Write the question list: the five things a professional now needs to answer before you spend anything else.

Prompting for planning history, safely

The single most useful prompt pattern in site research is extraction with citation. It looks like this, and the constraints matter more than the request:

You are assisting a UK property developer with a desktop appraisal. Using only the attached officer report, list: (1) each planning policy the officer relied on, with the paragraph number; (2) each reason for refusal, quoted verbatim; (3) each matter the officer said was acceptable; (4) anything material you cannot determine from this document. Do not infer, do not use general knowledge of planning policy, and do not offer an opinion on whether a new application would succeed. Mark any item you are unsure of as UNVERIFIED.

Three things are doing the work there: the source is constrained to the attached document, the output is structured, and the model is given an explicit way to say it does not know. Without the third instruction it will invent a paragraph number, and it will look right.

Where this stops

A desktop triage cannot tell you about ground conditions, party wall complexity, drainage capacity, the neighbour who objects to everything, or the difference between what an LPA's policy says and how that LPA behaves. Those are the reasons you instruct professionals. The triage exists to make sure you instruct them on sites worth the fee.

Planning is where developers most want AI to work and where it fails most expensively. The failure is specific and worth understanding, because once you see it the useful applications become obvious.

Retrieval is easy; weight is hard

Given a local plan, a model can find every policy touching on housing density, amenity space, parking standards or design. That is genuine work and it is fast. What it cannot do is tell you how much weight this authority's committee gives Policy H4 when it conflicts with Policy DM12, whether the five-year land supply position tilts the balance, or whether the case officer's recommendation will survive committee. Weight is contextual, political and local. It is not in the text.

The appeal-decision corpus

The Planning Inspectorate publishes appeal decisions in full. They are structured, reasoned, and they tell you what actually persuades an inspector in your authority on your issue. Almost nobody reads them systematically, because reading forty of them takes a week. Reading forty with extraction prompts takes an afternoon, and the output is a pattern you can act on: which arguments succeed here, which fail, and what evidence was decisive.

The workflow is unglamorous. Download the decisions. Feed them one at a time — not in bulk, because bulk invites blending — with a fixed extraction schema: issue, inspector's conclusion, the evidence relied on, and the paragraph. Assemble the extractions into a table yourself. Read the ones that matter in full. The model has done the sorting; you have done the thinking.

Pre-application and consultee responses

Consultee responses are where schemes die quietly. Highways, lead local flood authority, ecology, conservation. They arrive as PDFs, often late, often contradicting each other. A comparison prompt — 'list every requirement each consultee has imposed, flag any two requirements that cannot both be satisfied' — surfaces conflicts that otherwise appear at committee.

Conditions and discharge

A decision notice with twenty-eight conditions is a project plan nobody has written down. Extract each condition into: number, trigger point (pre-commencement, pre-occupation, other), what must be submitted, who prepares it, and lead time. That table is a genuine deliverable, it takes ten minutes with a model and a day without one, and it prevents the single most common cause of delayed starts — discovering a pre-commencement condition after mobilisation.

None of this replaces a planning consultant. It changes what you pay them for: less time reconstructing history, more time on strategy and negotiation.

An appraisal is a structured argument about the future expressed as arithmetic. The arithmetic is simple. The argument is where the money is.

The structure

Gross development value is what the finished scheme sells or lets for. From GDV you deduct build cost, professional fees, statutory and planning costs, contingency, finance, sale costs and the developer's profit requirement. What remains is what the land can bear. That is the residual land value, and it is the number that tells you whether to bid.

Acquisition cost is not the purchase price

Stamp duty land tax in England and Northern Ireland, land transaction tax in Wales and land and buildings transaction tax in Scotland are all banded, and the surcharges — additional property, non-resident, corporate — routinely add a five-figure sum to a small scheme. Add legal fees, survey costs, search fees and any agent's fee on acquisition. Rates change with each fiscal event; check the current rate before you rely on any figure, including one produced by a calculator or a model.

Sensitivity beats precision

The base case is the least interesting output of an appraisal. What matters is the shape of the downside. Move GDV down 5% and 10%. Move build cost up 5% and 10%. Extend the programme by three months and let the finance run. If the scheme survives all four, you have a project. If it only works in the base case, you have a hope.

This is where a model does add value. Give it your completed appraisal, with the numbers already calculated, and ask it to critique the assumptions: which inputs is the result most sensitive to, which assumptions are unevidenced, what has been omitted relative to a standard scheme of this type. That is commentary on arithmetic you control, not arithmetic you delegated.

Returns: which measure, and to whom

• Profit on cost — profit divided by total development cost. The developer's working measure and the one most lenders test.
• Profit on GDV — profit divided by gross development value. Lower number, common in valuation reports; do not compare the two.
• Return on capital employed — profit divided by the equity actually at risk, which with debt is far smaller than total cost.
• Annualised return — ROCE adjusted for the real programme length, including sales period. A 25% return over thirty months is not a 25% return.

None of the above is a valuation. A red book valuation is a regulated professional product, and where lending or a transaction depends on value, that is what is required.

Three quotes for the same package arrive. They are £84,000, £91,500 and £108,000. They are also for three different jobs, and nothing in the documents says so.

This is the most reliably profitable AI workflow in a construction SME, because scope-gap detection is pure document comparison — exactly what models are good at — and the cost of missing a gap is the gap itself, later, as a variation with no competitive tension.

The normalisation workflow

1. Build a scope schedule from your own tender documents first. Not from the quotes. If you extract the schedule from the quotes you inherit their omissions.
2. For each quote, extract against that schedule: included, excluded, not mentioned, and priced provisionally. 'Not mentioned' is a separate category from 'excluded' and it is where disputes come from.
3. Extract the commercial terms separately: payment terms, retention, programme, fixed-price period, fluctuation, insurance levels, warranties, and what happens if the programme moves.
4. Produce the like-for-like table: base price, plus the cost of the items each tenderer excluded, priced at the highest tenderer's figure for that item.
5. Generate the clarification questions — one per gap, addressed to the specific tenderer, quoting their own wording.

Compare the attached three quotations against the attached scope schedule. For each schedule line and each tenderer, state INCLUDED, EXCLUDED, NOT MENTIONED, or PROVISIONAL, and quote the wording you relied on with its page number. Do not calculate totals. Do not recommend a tenderer. List separately every commercial term that differs between tenderers.

Note the two prohibitions. Totals are arithmetic and belong in your spreadsheet. Recommendation is judgement and belongs to your QS or contracts manager, who will weigh things the documents do not contain — whether this subcontractor actually turns up, whether their last job for you ran clean, whether their programme is credible.

Contract interrogation

Standard-form contracts are long and mostly unread by the people operating under them. A model given the executed contract and its amendments can produce a genuinely useful operating summary: notice periods and to whom, the extension-of-time mechanism and its triggers, valuation and payment dates, the payless notice deadline, retention release, and — critically — every clause that has been amended from the standard form.

What must remain with the professional

• Whether an entitlement to time or money exists.
• Whether a notice is valid or served in time.
• Whether to terminate, suspend, or accept a repudiation.
• Any advice on the meaning of a clause in dispute.

Small contractors and developers do not skip project controls because they do not value them. They skip them because the person who would do the reporting is on site solving the problem the report would have described.

Capture before reporting

No amount of automation rescues a business that does not capture. The minimum viable capture set for a small scheme is small: a dated site diary entry, photographs with a one-line caption, a log of instructions given and received, and a running list of open questions. Four things. If they exist, reporting is a formatting problem. If they do not, reporting is fiction.

The practical intervention is usually to move instructions out of messaging apps and into anything with a date and an author. A shared sheet is sufficient. The technology is not the point; attribution and time-stamping are.

The weekly report

Given the week's diary entries, the instruction log, the open-questions list and last week's report, a model will produce a competent draft: progress against programme, work completed, issues arising, decisions needed, and changes to the risk picture. It takes minutes. It is a draft.

Variations and RFIs

A variation register should record, for every change: what changed, who instructed it, when, under which contract mechanism, what it cost, what time effect was claimed, and whether it was agreed. Most small schemes record two of those seven. Extraction from emails and messages can rebuild a register retrospectively — usefully, and painfully, because the gaps become visible.

RFIs are similar: the value is in ageing. An open RFI list sorted by days outstanding, with the discipline responsible, is a one-page document that changes behaviour at a site meeting.

Programme commentary

A model cannot run critical path analysis and should not be asked to. What it can do is compare this week's reported progress against the baseline activities and flag divergence in words — which is what most of your reader base actually needs, because they will not open the Gantt chart.

A cost report that shows what has been paid is a history lesson. The number that governs decisions is committed cost: everything ordered, instructed, or reasonably certain, whether or not an invoice exists.

Building the commitment picture

• Executed subcontract sums, at full value, not at valuation to date.
• Issued purchase orders.
• Instructed variations, at the best current estimate, flagged as estimated.
• Known-but-unpriced changes, listed with a range.
• Remaining contingency, stated as a number rather than assumed.

Assembling that from emails, orders and instruction logs is extraction work. A model will do it in an afternoon for a scheme that has drifted, and the output is a list of things you had forgotten you had committed to.

The variation conversation

The most expensive habit in small construction is agreeing the money for a change and leaving the time effect for later. Later never has the same negotiating position. Four questions, asked at the point of instruction and recorded:

1. What is the change, described precisely enough that a stranger could price it?
2. Under which contract mechanism is it instructed?
3. What is the cost, and is that fixed or estimated?
4. What is the effect on the completion date, including nil if nil?

Forecast to completion

Monthly, in writing: current committed cost, forecast remaining, forecast final cost, movement since last month, and the reason for the movement. Where a model helps is in drafting the reason narrative from the change log — turning a list of variations into two paragraphs a funder can read. Where it does not help is deciding whether your contingency is still adequate. That is a judgement, and it should be recorded as one.

When a scheme is examined — by a funder, an insurer, a JV partner, a purchaser's solicitor, an adjudicator — the question is almost never whether the decision was reasonable. It is whether you can show what you knew when you made it.

The four fields

A decision log entry needs four things and can be written in ninety seconds: what was decided, what information it was based on (with links to the documents), what was uncertain at the time, and who approved it. That is the whole discipline. The reason it is rare is that it feels like overhead in month two and like salvation in month twenty.

Where AI helps, and its limit

Models are good at assembling an evidence pack from an existing archive: find every document referenced in the decision log, extract the relevant passages, build a chronology, and flag references to documents that cannot be located. That last output is the valuable one — a list of things you cited and cannot produce.

Confidentiality and retention

Before any document goes into a third-party model, the business needs a written rule on what may be sent, what must be redacted, and what stays in-house. Personal data, commercially confidential tender information, legally privileged material and anything covered by an NDA all need explicit treatment, and UK GDPR applies to the personal data regardless of how helpful the tool is. Retention periods should be set deliberately — twelve years for anything under a deed, and longer where latent defect exposure suggests it.

A development funder, a monitoring surveyor and a JV partner want broadly the same six things every month: progress against programme, cost against budget, forecast final cost, changes since last report, risks and mitigations, and the evidence for the drawdown being requested.

That is a fixed schema. Fixed schemas are worth building for once. The monthly effort should be assembling this month's inputs, not deciding what the report looks like.

Drawdown packs

Drawdowns are slow because evidence is assembled retrospectively — invoices found, valuations chased, photographs located. If the capture discipline from Chapter 7 exists, the pack is a filter over records you already hold. If it does not, every drawdown is a small archaeology project, and the delay costs interest.

The narrative

Use a model to draft the narrative sections from the underlying logs, then verify every number against its source before issue. The division is strict: generated prose, human-verified figures. A report to a lender containing a hallucinated figure is a serious problem regardless of how it got there.

Bad news travels badly when it travels late. A funder told in month four about a three-month delay is managing a project. The same funder told in month seven is managing a relationship.

Adoption in a small development business fails in a predictable way: someone enthusiastic runs a pilot, it works, nobody owns it, the enthusiastic person gets busy, and six months later the team is back on email.

Ninety days

1. Days 1–10: write the house rules. What may be sent to a third-party model, what must be redacted, what stays in-house, how outputs are verified, and where records live. One page. Signed off by whoever carries the risk.
2. Days 11–20: pick one workflow with a measurable before-state. Quote comparison and condition schedules are the usual best candidates because the current cost in hours is obvious.
3. Days 21–45: build it against real documents, not samples. Define the input, the instruction, the output shape, the verification step and the record location. Name one owner.
4. Days 46–60: run it in parallel with the old way. Compare outputs. Log every error the model made — this list becomes your training material and your prompt refinement.
5. Days 61–75: train the team on that one workflow only, using their own live documents. Resist adding a second workflow.
6. Days 76–90: measure against the baseline, write up what changed, and decide whether to expand. If it did not save time, say so and stop.

What to measure

• Hours spent on the task before and after, honestly recorded.
• Error rate: how often the verification step caught something.
• Cycle time: how long from document arriving to decision made.
• Coverage: how many of the eligible documents actually went through the workflow.

Coverage is the one that exposes failed adoption. A workflow used on 20% of eligible documents has not been adopted; it has been tolerated.

It is worth being precise about what an architect, a planner, a structural engineer, a solicitor and a quantity surveyor are for. They are not document-production services. They are accountable holders of technical judgement, carrying professional indemnity insurance, bound by codes of conduct, and answerable if they are wrong. That accountability is the product.

A model has none of it. It is not qualified, not insured, not regulated and not answerable. When a model's output is used as though it were professional advice, the risk does not disappear — it moves to whoever relied on it. Usually the developer, usually uninsured.

Standing rules

1. No model output is used as the basis for a planning, legal, structural, valuation or tax decision without a qualified professional reviewing the underlying source.
2. Every circulated output carries its assumptions and its unknowns, unedited.
3. Every factual claim used in a decision is traceable to a source document and page.
4. Confidential and personal data are governed by the written house rules, and UK GDPR obligations are not suspended by convenience.
5. Reconstructed records are labelled as reconstructed.
6. The prohibited-use list is reviewed every six months, because model capability changes and the temptation grows with it.

The question is never whether the machine can produce the answer. It is whether anybody is accountable for it being right.

What actually improves

Used properly, none of this is dramatic. Sites get screened in half an hour instead of half a week. Tender comparisons surface the gaps before award rather than after. Conditions are scheduled before mobilisation. Weekly reports get written. Decisions leave a trail. Professionals get instructed on the questions that need them rather than on reconstructing history.

That is a better-run development business. It is not a transformed industry, and anyone promising you the second is selling something. The judgement stays yours. That was always the point.

A search engine can find a page and a language model can summarise it. Neither act, on its own, is development intelligence. The commercial value appears when the system knows which source could actually support a proposition, records which version it used, distinguishes national policy from local policy, and tells the developer what could not be established.

Use a source hierarchy

For current planning policy, start with authoritative sources: GOV.UK, the local planning authority, legislation, Planning Data, the Planning Inspectorate and the relevant statutory or professional source. Commercial databases can enrich the picture, but they should not silently outrank the primary record.

• National policy and legislation: record publication/revision date and jurisdiction.
• Local development plan and validation material: retrieve from the responsible authority, not a neighbouring council or a model's memory.
• Planning history and appeals: retain application/appeal reference, decision date, actual reason and policy context.
• Title and registration: use HM Land Registry processes where legal extent or registration matters; never promote an index-map or mapping gap into a title conclusion.
• Market evidence: keep completed transactions separate from asking-market evidence and record the date each was retrieved.

Postcode-first research

A postcode can resolve coordinates, administrative geography and a likely local planning authority. From those coordinates the platform can launch satellite and Street View context and, in England, screen official Planning Data datasets. This is an investigation accelerator, not a professional search: Street View may be historic, mapping does not prove legal boundaries and national dataset coverage varies by authority.

Research the case against the scheme

Weak research asks the internet to support the intended development. Strong research asks what would make it fail. Search refusal reasons, dismissed appeals, contrary policy, access or amenity problems, technical evidence that decision-makers demanded and cases where a superficially similar proposal was treated differently.

A commercial sourcing engine is useful only while its data rights, coverage and operating cost remain stable. Building a business around unauthorised scraping creates a fragile dependency: a portal changes markup, rate-limits an address or changes its terms and the pipeline disappears. The stronger architecture uses an authorised API, licensed aggregator or other source whose automation rights are explicit.

A cheap listing is not automatically a deal

Asking price should be compared with completed transactions, floor area, tenure, condition, planning context and likely development costs. A listing below a local median can be worth investigating, but the median itself may combine different property types, specifications and micro-locations.

Close the sourcing loop

1. Capture the source and permitted use of the listing/feed data.
2. Resolve postcode, coordinates and planning authority.
3. Screen planning, title/access and visible physical constraints before consultant spend.
4. Separate achieved sold evidence from current asking evidence.
5. Run the deterministic appraisal and 49-case downside matrix.
6. Record the investigation priority and the reason — never an unexplained BUY/NO BUY score.

A small developer can now perform information work that once disappeared between roles: document indexing, policy retrieval, planning chronologies, quote normalisation, risk registers, consultant briefs, weekly reports, decision logs and evidence packs. That is a meaningful increase in operating leverage.

It does not mean one person becomes an architect, planner, engineer, QS, solicitor, valuer and lender. It means one person can arrive at those professionals with a cleaner evidence set, a sharper question and a record of what is still unknown.

Build a virtual information team

• Site Analyst: challenges the opportunity and prioritises investigation.
• Planning Evidence Analyst: separates policy, precedent, contrary evidence and missing source material.
• Commercial Analyst: challenges the appraisal while deterministic tools perform the arithmetic.
• Procurement Analyst: normalises scope and exclusions but never infers approval.
• Project Controls Analyst: watches risk, change, decisions and programme/cost evidence.
• Document Auditor: identifies claims, contradictions, superseded information and verification actions.

Spend professional money where judgement matters

If the system can assemble the planning history in minutes, a planning consultant can spend more of the fee interpreting the difficult policy issue. If it can reconcile drawings, evidence and questions into a structural brief, the engineer can spend more time on the structural answer. Information preparation and accountable judgement should not be confused.

Keep the operating system boring where it must be boring

The strongest implementation programme is deliberately narrow. It does not begin with 'deploy AI'. It begins with one development decision that repeatedly consumes time or loses information, defines a before-state, changes the workflow and measures whether the decision improved.

Days 1–30: establish SITE

1. Adopt one site-intelligence template using postcode/address, authority, mapping, planning history, current policy, title questions and commercial assumptions.
2. Define the authoritative source for each category and how retrieval date/version is recorded.
3. Use the five-question triage to decide which investigation stage each opportunity has reached.
4. Test the process on completed/known sites so false confidence and missing coverage are visible.
5. Measure the time from opportunity received to a documented investigate/park/escalate decision.

Days 31–60: establish BUILD

1. Normalise quotations on scope, exclusions, programme and design responsibility.
2. Maintain the risk register with cause, event, consequence, score, mitigation and owner.
3. Introduce variation and decision logs with the rule that discussion is not approval.
4. Generate management reporting from the maintained records rather than reconstructing the week from inboxes.
5. Measure clarification found before award, unapproved change exposed, and reporting time saved.

Days 61–90: establish PROVE

1. Fingerprint and index material evidence so later packs can identify the exact file reviewed.
2. Define what AI-generated material may enter the formal project record and who can adopt it.
3. Export the decision/risk/variation record in open formats and establish a backup routine.
4. Run one retrospective: could an independent reviewer reconstruct why the material decisions were made?
5. At day 90 keep only the workflows that demonstrably improve speed, coverage, evidence or error detection.