Who Is Accountable

The first thing to understand is why automated compliance makes the question of responsibility genuinely hard, rather than just uncomfortable. Manual checking, for all its faults, keeps responsibility legible: a professional certifies the design and a plans-examiner approves it, and if something is missed you know whose reading it was. Insert an automated check into the workflow and the task is now shared among several actors and a machine, and each can plausibly say the failure was not theirs.

Walk the chain. The vendor can say the engine ran exactly as designed - it applied the rules it was given and reported correctly. The rule-encoder can say they encoded the clause as they read it, or that the version was current when they wrote it. The designer can say the tool passed the design, so they reasonably relied on it. The approving authority can say it is entitled to consider a recognised checking result as part of its process. Every statement is partly true, and yet the design was non-compliant and no one is squarely answerable. This is the accountability gap: a diffusion of responsibility that appears whenever a decision is distributed across many hands and a system, and it is well known in the study of automation and complex organisations.

What makes it worse in compliance is the presence of the machine itself as a tempting sink for blame. A tool feels neutral and authoritative; when it is in the loop, humans are prone to treat its output as the decision rather than as input to their decision - automation bias again - and then, when it fails, to speak as if 'the system got it wrong', as though that ended the matter. But a tool cannot hold a duty. It cannot be professionally accountable, cannot be sanctioned, cannot owe anyone a standard of care, cannot explain its judgement to an inquiry. Letting responsibility settle on it is not an answer; it is the absence of one. So the accountability gap is not a technicality to be waved away - it is the central governance risk of putting automation into a safety-relevant decision, and closing it requires a deliberate answer to the question the tool cannot answer for itself: which human is responsible, for what?

Closing the gap starts with naming the parties honestly and separating what each can legitimately be answerable for, because the answer is not that one person is to blame for everything - it is that different actors owe different, real duties, and the tool owes none of the binding ones.

The vendor who builds the checking engine is answerable for the tool working as described: running the encoded rules faithfully, reporting passes, fails and unknowns honestly, being transparent about scope, and not overclaiming - not marketing a check as 'automatic compliance' or an approval. The rule-encoder is answerable for the fidelity of the encoding to the source clause: making interpretive choices defensibly and visibly, keeping the rule traceable to the law, and versioning it. These are real responsibilities, and doing them badly is a genuine failing - but note what neither the vendor nor the encoder is answerable for: whether a particular design actually complies. They never saw the project; they cannot certify it. The designer of record is answerable for exactly that - for the design meeting the regulations, for the truth and completeness of the model data fed to the check, for exercising professional judgement over the tool's output rather than deferring to it, and for the rules the tool never checked. The approving authority is answerable for the determination of compliance and the grant of permission, made against the actual law; a checking result may inform its process but does not replace its judgement or its responsibility.

Seen this way, the gap closes not by blaming one party but by holding each to its own duty - and by recognising that the two binding duties, whether the design complies and whether it is approved, sit squarely with the designer of record and the authority, exactly where they sat before automation arrived. The tool and its makers carry real but bounded responsibilities for the quality and honesty of the instrument; they do not carry the duty to get this building right. Keeping those distinct is what stops the automation from becoming a place where the binding responsibilities quietly disappear. In India, the professional of record who signs and certifies the drawings, and the sanctioning authority, hold those binding duties under the governing byelaws - a checking tool does not stand in for either.

From naming the parties comes the principle the whole lesson defends: accountability for compliance must stay with the accountable humans and the authoritative law, and an automated check must never be allowed to inherit it. This is not nostalgia or distrust of technology; it is a requirement that follows from what the tool is and is not.

Start from what a check actually establishes. A 'pass' means only that the encoded rules the tool could evaluate found no flaggable issue in the data it was given. It does not mean the design complies - the encoding may be wrong or stale, the model data may be false or incomplete, the uncheckable and judgement-laden rules are untouched, and interpretation the tool cannot do remains undone. So a pass is evidence, sometimes strong evidence, that certain checkable requirements are probably met; it is never a determination of compliance and never an approval. A determination of compliance is a human act of judgement against the law, and an approval is a legal act of an authority. Neither can be performed by a tool, so neither responsibility can rest on one. The designer of record must still exercise judgement and certify; the authority must still decide and approve; and both must do so against the actual code and byelaw, not against the tool's reading of it.

This is why the honest framing of an automated check is as an assistant - it finds likely issues fast, catches missed clauses early, reduces the mechanical burden, and gives the accountable humans better information to exercise their judgement with. It augments them; it does not replace them or absorb their duty. The failure mode to guard against is the quiet slide from 'the tool helped me check' to 'the tool checked it', because the second sentence has smuggled the responsibility onto something that cannot hold it. Designing the human-tool relationship well means keeping the human visibly in the loop and answerable: the professional reviews and owns the result, the authority decides, and the tool's output is logged as input, not verdict. Hold that line and automation makes compliance faster and more consistent without hollowing out responsibility. Lose it, and you get speed and consistency with no one answerable when it goes wrong - which, for buildings people live and work in, is a bargain no one should accept. The authoritative rule is the law; the accountable parties are human.

Principles hold only if the workflow is built to keep them, so it is worth being concrete about what keeps accountability legible in practice - because good intentions drift under time pressure, and a badly designed process quietly transfers responsibility to the tool whatever anyone intended.

The first practice is honest tool design and marketing: a check should present itself as an assistant, report unknowns and scope limits as prominently as passes, and never use the language of approval or 'automatic compliance'. A tool that overclaims invites over-trust and is the first mover in creating an accountability gap. The second is keeping the human in the loop by design: the professional of record reviews the tool's output, signs off on the design against the actual regulations, and records that they did so - the sign-off, not the tick, is the act that carries responsibility. The third is traceability and logging: recording which rule versions were checked, for which jurisdiction, on what data, with what result, so that if something is later questioned the chain can be reconstructed and each party's contribution examined - this is also what lets a genuine encoding or tool failure be identified and fixed rather than absorbed. The fourth is preserving the authority's independent judgement: even where an authority accepts checking results into its process, its determination and approval must remain its own act against the law, not a rubber stamp of the tool.

None of this is exotic, but it has to be deliberate, because the default drift is the other way - toward trusting the tick, skipping the review under deadline, and treating a machine result as the decision. The competent posture is to use automated checking exactly where it earns its place (fast, early, consistent checking of the clean quantitative subset) while engineering the process so that a human always reviews, a human always signs, an authority always decides, and every result is traceable to a dated rule and a named party. Studio Matrx teaches this as a matter of professional integrity as much as technique: the tool is a genuine help, but whether this building complies, and who answers for it, must never be questions the software is left to answer. Defer every binding result - actual compliance, the authoritative interpretation, and legal responsibility - to the qualified professional of record, the approving authority and the governing law.