In this issue of Irish building magazine, we’ll explore why the next productivity leap in AEC won’t come only from better models, data, or dashboards – but from upgrading the agreement layer: contract administration across the full business lifecycle.

In Part 1,  we made visible the hidden “trust tax” that accumulates at contract boundaries in a fragmented sector – from tender clarifications and negotiated terms through design acceptance, change control, certification, payment, commissioning, and dispute avoidance. In Part 2, we introduce a practical architecture:  Law → Protocol → Code – that separates human judgement from automated record-keeping and settlement. In Part 3, we show how “dead” PDFs can become computable promises, and how BIM/CDE workflows – supported by AI and DLT tamper-evident audit trails – can generate verifiable proof, not just stored files. In Part 4, we map an adoption path that works incrementally without a platform reset.

Code is Not Law

In Part 1 we named the problem: the trust tax that appears when authority is unclear, acceptance is ambiguous, and proof gets reconstructed after the fact. Part 2 is about the design move that makes speed safe. The temptation is to say “code is law” and try to automate contracts end-to-end. In AEC that approach breaks, because projects are physical, contingent, and contested by nature. The practical alternative is an architecture that respects reality: Law → Protocol → Code, supported by a two-plane model – Decide vs Settle – and a simple mechanism that turns decisions into stable outcomes: the receipt.

1) Why “code is law” fails in physical industries

Reality is not deterministic – and that’s not a bug

Software lives in clean inputs and predictable outputs. Projects don’t. Ground conditions vary, tolerances stack, weather interferes, supply chains stumble, and site constraints rewrite the plan. That means judgement isn’t an exception – it’s the daily operating mode. If you design a contract system as if facts are always clear, you won’t eliminate ambiguity; you’ll just push it into workarounds and disputes. The system must assume uncertainty and still help the project move.

Contracts contain discretion by design

Good contracts aren’t scripts; they’re frameworks for managing uncertainty. That’s why they use terms like “reasonable,” “material,” “to the satisfaction of,” and “as instructed.” Those aren’t sloppy words – they’re legal tools that keep deals workable when reality deviates. The problem is that discretion is often handled informally, through emails and discussion under pressure, rather than through a repeatable decision pathway. Any “automation” that ignores discretion ends up brittle and unsafe.

Automation should settle, not decide

Here is the boundary that keeps everything sane: humans decide what’s true; systems settle what’s been proven. A contract engine shouldn’t pretend to interpret intent or replace professional judgement. Its job is to record decisions, validate that protocol conditions were met, and trigger consequences once proof exists. If automation starts acting on assumptions – implied approvals, ambiguous statuses, unverified completion – you get faster confusion, not faster delivery. Think of the system as a clerk and notary: it records what authorised humans decided, and then executes settlement predictably.

2) Law → Protocol → Code (what each layer does)

Law sets legitimacy: obligations, standards, remedies

Law is where the relationship becomes legitimate: obligations, performance standards, liability boundaries, and remedies when things go wrong. It is written for contestability because disagreement is normal in high-stakes work. That’s a feature, not a weakness. If you try to “replace law with code,” you don’t create certainty – you create brittleness, and you lose the ability to resolve disputes fairly when reality refuses to behave like the assumptions.

Protocol defines “what counts” day to day

Protocol is the missing middle. It translates legal intent into operational rules: what counts as a valid instruction, what counts as acceptance, what evidence is sufficient, what time window applies, who has authority at what thresholds, and what happens when parties disagree. Protocol isn’t law and it isn’t software – it’s the agreement about process legitimacy. When protocol is weak, projects rely on custom and politics. When it’s strong, routine matters settle quickly because everyone knows what counts. Crucially, protocol should be industry-applicable: a shared rulebook that any tool can implement, not decision logic trapped inside a closed “black box” vendor workflow.

Code executes repeatedly after proof exists

Code is where you gain speed and auditability – if it’s constrained. Code should do boring, repeatable work: timestamp, update registers, open dispute windows, enforce thresholds, send reminders, and trigger settlement steps once conditions are met. It should not invent meaning. The system doesn’t ask “is this true?” It asks “has the authorised decision been recorded, with the required proof, under the correct rule version?” That’s what makes automation safe in a contested environment.

3) Two-plane model: Decide vs Settle

Plane A (Decide): judgement, authority, accountability

Plane A is where humans do what only humans can do: interpret, decide, and take responsibility. This includes tender clarifications becoming binding, design packages being accepted or returned, instructions being confirmed as valid, and completeness being certified against an acceptance test. Plane A produces legitimacy because an authorised role attests a decision within defined thresholds. Without that, every downstream step stays vulnerable: “who said so?” becomes the hidden blocker.

Plane B (Settle): execution, record integrity, settlement steps

Plane B is where systems do what systems do well: maintain record integrity, move state predictably, and trigger downstream actions. Once a legitimate decision exists, Plane B can update the change register, trigger notices, open or close dispute windows, and prepare payment readiness. This is the difference between “workflow” and “settlement.” Workflow moves paperwork; settlement moves consequence – so it must be gated by legitimate decisions, not implied activity.

Why the separation matters: speed without accidental injustice

Without separation, you risk accidental injustice: payment withheld or released based on ambiguous states, approvals implied by silence, or obligations assumed because someone clicked a status. Decide vs Settle prevents that. It allows speed where it’s safe – automation after proof – while keeping judgement where it belongs. It also reduces conflict temperature, because disputes anchor to explicit decision points and receipts, rather than to competing stories about what the workflow “meant.”

4) Receipts: the atomic unit of accountable decisions

A receipt is not “logging” – it’s a proof object

A receipt is a compact proof object that captures: the event, the outcome, who attested it, what evidence supports it, which protocol version applied, and when it happened. It turns “we agreed in a meeting” into something the project can rely on without reconstructing memory later. Receipts don’t replace the contract; they operationalise it. They are how a fragmented coalition behaves like a coherent enterprise: decisions become legible, traceable, and defensible.

“No Receipt = No Settlement” as the safety rail

This rule keeps the engine honest: No Receipt = No Settlement. If there is no receipted decision, the system should not trigger settlement actions – no acceptance state change, no payment readiness, no downstream consequence that commits the project commercially. This doesn’t slow delivery; it prevents re-litigation. It forces clarity at the moment decisions are made, which reduces defensive admin and stops the project living in ambiguous “almost accepted” states.

Versioned, portable, contestable

Receipts must be bound to the rule version that created them, otherwise the record becomes ambiguous when processes evolve mid-project. They should also be portable because projects outlive platforms and people. And they must remain contestable, because AEC is not a closed system: parties need defined pathways to challenge a receipt within dispute windows. A receipt is not a weapon; it’s a stabiliser. It confines disagreement to a bounded process instead of letting it infect everything. And ‘openness’ isn’t a cure by itself. If your decision logic and thresholds are embedded in one platform’s workflow, you’re still locked in. The point of receipts and protocol versioning is portability of logic and proof, not just export of files.

5) Authority & thresholds: speed without chaos

Thresholded authority makes delegation safe

Projects slow down when authority is fuzzy. People escalate everything because they don’t know who can commit the project. Thresholded authority fixes this by making decision rights explicit: who can instruct changes up to what value, who can accept deliverables at what stage, who can certify payments within what limits, and what must be escalated. This isn’t centralising power; it’s making delegation safe. And it matters because receipts must be attested by someone who is genuinely authorised.

Dispute windows and escalation paths prevent “slow bleed” conflict

Speed doesn’t come from pretending there will be no disagreement. It comes from bounding it. Dispute windows stop conflict becoming a slow bleed: a receipted decision can be contested within a defined period; after that it stabilises and settlement proceeds. If contested, the escalation path is explicit: revise, negotiate, adjudicate, expert determination – whatever the contract provides. The outcome is not “no disputes.” It’s disputes that don’t stall the whole project.

Dual-core decisions: consensus vs certification

Projects contain different kinds of “yes.” Some decisions are routine and can be handled through lightweight consensus or delegated approval. Others require active certification: safety-critical acceptances, commissioning outcomes, regulatory compliance, professional sign-offs. A contract engine must support both and must not confuse them. If certification becomes a casual click, trust collapses. If routine coordination issue becomes a heavy certification, velocity collapses. The protocol needs a clear distinction: what requires formal attestation, and what can be settled by process.

6) Minimum Viable Protocol: where to start and how to win early

Start with one high-friction pathway

The fastest way to fail is to try to “digitise the whole contract”. Start with one pathway where the trust tax is obvious and measurable: variations, payment applications, design acceptance gates, commissioning sign-off, or tender clarifications becoming binding. Define it end-to-end: triggers, roles, thresholds, evidence bundle, acceptance test, dispute window, settlement consequence. The aim is a real reduction in friction, not a theoretical model of everything.

Define minimum evidence bundles and acceptance tests

Teams over-produce evidence because they don’t know what will count later. A minimum viable protocol fixes that by stating the minimum evidence bundle up front. For a variation: instruction + scope delta + entitlement hook + valuation basis + any programme impact evidence. For payment: acceptance receipts + completion proof + agreed deductions/snags. Keep it small but sufficient – designed to survive audit and dispute without becoming an administration monster. When proof standards are agreed early, decision speed increases and defensiveness drops.

Govern the protocol like commercial infrastructure

Protocol changes are not “workflow tweaks.” They change commercial reality, so they must be versioned, controlled, and communicated. Bind receipts to protocol versions. Pilot inside live projects without demanding a platform reset. Measure cycle time, churn (resubmissions), dispute incidence, and payment predictability before and after. This is how adoption becomes real: you prove the trust tax is coming down in a place where money moves, and then expand to the next pathway with confidence.

Conclusion and Next Step

Part 2 has introduced the architecture that keeps the Contract Engine grounded in reality: Law → Protocol → Code, Decide vs Settle, and Receipts as the unit of operational proof. The point is not to automate judgement, but to make judgement settleable – so routine matters can move quickly and safely in a fragmented, contested environment. In Part 3 we’ll make this concrete: how “dead” PDF contracts become computable promises, how BIM/CDE workflows become an evidence rail that can generate decision receipts, and how enabling technologies (like AI and tamper-evident DLT audit trails) support the proof pipeline without turning AEC into a crypto theatre.

Ralph Montague is an Architect and Director at ArcDox BIM Consultants, a member of the Royal Institute of Architects of Ireland (RIAI), the National Standards Authority of Ireland (NSAI) Technical Mirror Committee for BIM Standards, and co-founder of the international BIM Heroes Community. With over 30 years of industry experience, Ralph specialises in advising individuals, businesses, and project teams on information management practices and implementing BIM standards (ISO19650). www.ArcDox.com www.BIMhero.io

Follow Irish building magazine on LinkedIn for the latest news and updates.