Automate the labor, not the judgment

Automation scope is a liability question before it is a software question

Ask a design or construction team what they want to automate and the answer usually arrives as a list of tools: an agent, a connector, a scripting environment, a model server, a plug-in. That list is a capability inventory. It is not a scope. Scope is decided by a different question: when this task produces a wrong answer, who finds out, how late, and who carries the consequence?

A misnamed parameter is discovered in a schedule and corrected in an hour. A wrong idealization in a structural model may not be discovered at all, because the run completes and the ratios look acceptable. A wrong bearing detail is discovered when a panel arrives at a site and does not land where the foundation expects it. These three failures live in the same software stack and have nothing else in common. Treating them as one automation problem is how organizations end up with fast tooling and slower projects.

This report is the hub of a four-part series. It sets out the triage K&K uses to decide what may be delegated to software, what is reserved for a responsible person, and what counts as adequate evidence for each kind of claim. Two companion reports then apply the triage to specific boundaries: the BIM-to-structural-analysis handoff, where the reserved judgment is idealization, and change in a repeatable housing product, where the reserved judgment is which layer of the product a change belongs to. The native Revit model and readback report describes the authoring mechanics that make any of this checkable.

A working definition: labor has an acceptance criterion, judgment supplies one

The words “labor” and “judgment” are doing real work here, so they need definitions that survive contact with a project.

Labor is work whose acceptance criterion exists before the work starts and can be evaluated without renegotiating the criterion. If a rule says every exterior opening must carry an identifier that matches its source record, then after the operation runs, a query either finds the matching identifiers or it does not. Nobody has to be consulted about what the rule meant.

Judgment is work that produces the acceptance criterion. Deciding that a wall line may be represented as a single analytical member, that a tolerance may be absorbed at one joint rather than distributed across three, that a substituted product is equivalent for the purpose at hand, that an out-of-spec condition may be accepted as installed — these are not lookups. They are commitments made by someone with the standing to make them, under assumptions that a later reviewer must be able to see.

The practical consequence is that judgment cannot be automated away by making the software more capable, because the missing ingredient is not capability. It is standing. A system that generates a result and also certifies it has not eliminated the judgment; it has moved the judgment into an unexamined default and removed the person who was accountable for it.

The four-question triage

Before a task enters an automation backlog, K&K puts it through four questions. A task that answers yes to all four is a strong candidate. A task that fails any one of them is not forbidden — it simply cannot be delegated without a named person holding the gate that it fails.

1. Is the acceptance criterion machine-checkable? Can a query against the receiving system decide the question, without a human being asked what the rule meant in this case? “Every hosted opening resolves to a wall that exists on the intended level” is checkable. “The layout is sensible” is not.
2. Is the input identity stable? Does the task consume something with a durable identifier and a known revision, or does it consume whatever happened to be open, exported, or most recently touched? Automation over unstable identity produces results that cannot be reproduced or attributed, which makes disagreements unresolvable.
3. Is failure detectable from the receiving system? If the task does the wrong thing, will the engine that received the work be able to report the discrepancy? Some failures announce themselves as exceptions. The dangerous ones do not: an object created in the wrong category, a member quietly dropped from a set, a schedule filtered to a population that no longer matches its intent.
4. Is the consequence reversible before it becomes physical? A wrong model object can be corrected. A wrong cut list that has already been fabricated, or a wrong anchor layout that has already been cast, cannot. The further downstream an error can travel before someone notices, the more evidence the task needs before it is allowed to travel at all.

These four questions are deliberately about the task, not about the technology. They give the same answer whether the work is performed by a scripted routine, a language model, an add-in, or a person following a checklist — which is the point. A method that changes its safety argument every time the tool changes is not a method.

Work that passes the triage

The following classes of construction and BIM work generally satisfy all four questions, provided each one returns evidence rather than a status word.

• Rule-bound authoring. Creating or updating native model content from an explicit definition — levels, grids, wall and floor objects, hosted openings, structural members, types and parameters — within a stated scope and a stated stop condition.
• Identity and parameter propagation. Carrying source identifiers, revision markers, and classification data onto the objects that represent them, so that later queries can attribute an object to the decision that created it.
• Population reconciliation. Comparing what a definition expected against what an engine actually contains: counts by category, missing hosts, orphaned objects, duplicates, substitutions, and items the engine declined to create.
• Set-to-set comparison. Differencing two known revisions and reporting what changed, what was added, what disappeared, and what kept an identifier while changing meaning — the last of which is the one that quietly breaks downstream work.
• Quantity extraction under a declared basis. Deriving counts, lengths, areas, and assemblies from model objects, with the extraction rule and the source revision recorded alongside the number.
• Document and record assembly. Producing sets, indexes, transmittals, and evidence packages where omissions are detectable because the expected contents were declared first.
• Evidence capture and structuring. Collecting field observations, photographs, and status into records that keep their identity, location, and time context. K&K’s field-evidence research note covers this class in more detail; the same rule applies there — automated structuring organizes evidence, it does not adjudicate it.

Notice what these have in common. Each one produces a claim about the state of an information system, and each claim can be tested by asking that system a bounded question. None of them produces a claim about whether the building is right.

Reserved judgment

The following decisions stay with a responsible person or organization. They are not on a roadmap to be automated later; they are the decisions that automation exists to support.

• Idealization. Choosing which physical reality to represent and which to abstract away — end fixity, effective length, diaphragm behavior, base restraint, the stiffness credited to a connection. No exporter can make this choice, because it is a claim about how the building will behave, not about what the geometry contains.
• Code and jurisdictional interpretation. Determining which provisions apply, how an ambiguous condition is classified, and what an authority having jurisdiction will require for this project on this site.
• Tolerance allocation. Deciding where accumulated dimensional variation is absorbed, and which joint is permitted to take it. This is an engineering and constructability decision with cost and appearance consequences.
• Means, methods, and sequence. Erection stability, temporary conditions, lifting, access, and the order in which work is safe to perform.
• Substitution equivalence. Accepting that a different product, section, or assembly satisfies the intent of the specified one for this application.
• Acceptance of nonconformance. Deciding that an as-built condition outside the defined tolerance may stand, be repaired, or be removed.
• Professional certification. Sealing, signing, and taking responsibility for a design. K&K coordinates design and delivery interfaces with the required project professionals; the licensed roles for a given jurisdiction are defined for that project, as described on our project roles page.

A workflow can prepare all of these decisions — assemble the inputs, surface the conflicts, compute the options, show what changed since the last accepted state. Preparing a decision and making it are different acts, and the difference should be visible in the record.

Match the rung to the claim

The ladder is only useful if it is applied to specific claims. A few common ones, and the rung each actually requires:

• “The model was updated.” Rung two is enough to know something ran. Rung three is required before anyone plans work around it.
• “The model matches the current design definition.” Rung three, and only for the properties the readback actually queried. A readback that checked categories and hosts has said nothing about parameters it did not read.
• “The quantities are right.” Rung three establishes what the model contains; rung four establishes that the extraction rule produces the same number by a second path. Both must name the source revision.
• “The structure works.” Rung four at minimum, under assumptions a reviewer can inspect, and it remains an engineering opinion attached to a named professional rather than a system output. The BIM-to-analysis report deals with this case specifically, because a completed solver run is one of the most convincing rung two results in the industry.
• “It was built as designed.” Rung five, before the condition is concealed. No amount of model evidence substitutes for observing the physical thing.

The discipline is simple to state and easy to lose under schedule pressure: never let a claim inherit the confidence of a lower rung, and never let a system that produced a result be the only source of evidence about that result.

Five ways a workflow reports success and is still wrong

These are the failure patterns that survive naive automation, listed because each one is invisible at rung two and visible at rung three.

1. The green run. Every operation returns without error, and the operations that were supposed to happen but silently did not are absent from the report. A report that lists only what occurred cannot reveal an omission; the expected population has to be declared first.
2. The plausible object. Something exists at the right coordinates in the wrong category, on the wrong level, or hosted by the wrong element. It renders correctly and behaves incorrectly in every schedule, view filter, and downstream query.
3. The recycled identifier. An identifier is reused for a component that is not the component it originally described. Prior approvals, purchase records, and analysis results now appear to apply to something they were never about.
4. The stale source. The operation is performed correctly against a revision that is no longer current. Everything about the execution is defensible and the output is wrong.
5. The unrequested substitution. A receiving system quietly maps an unavailable type, section, or family to its nearest supported equivalent. The import succeeds, and the model no longer represents the decision that was made.

None of these are exotic. They are the ordinary consequences of asking a system whether it succeeded instead of asking it what it now contains.

The protocol layer is not the truth layer

Integration technology tends to absorb credit that belongs to process. A connector, an API, a plug-in, or a model-context protocol server can carry an instruction from one place to another and return a response. None of them establishes which source is authoritative, which revision was in force, which objects were permitted to change, or who may accept the outcome. Attaching a capable transport to an undefined process distributes uncertainty faster and more confidently.

To be specific about our own implementation: K&K does not use MCP to control Revit. Our implemented approach uses an internal C# Revit API add-in that receives a defined modeling request, creates admitted native BIM content, and returns structured evidence about the result. Protocol and agent layers, where used, are coordination and discovery aids. They are not the engineering source of truth, they do not author the building definition, and completion of a protocol call is a rung two fact about a message, not a rung three fact about a model.

The same caution applies to any assistant, retrieval system, or vector search used during research. Those tools help locate material. What is published, specified, or built has to be traced to the file, engine, or physical object that actually holds the fact.

Write down the authority register

The triage becomes operational when it is recorded rather than remembered. For each automated operation in a program, K&K’s practice is to state, in one place and in plain language:

• Which definition is authoritative, and at which revision.
• Which objects or records the operation is permitted to create, modify, or delete — and which it must never touch.
• What the expected result is, expressed as something a query can test.
• What evidence must return, and from which system.
• What conditions require the operation to stop rather than continue on a best guess.
• Which claims the result is allowed to support, and which it explicitly does not close.
• Who accepts the result, and what their acceptance covers.

The last two lines are the ones most often omitted, and they are the ones that prevent an automation report from being quoted years later as proof of something it never examined. A register of this kind also makes it possible to change a tool without renegotiating the safety argument, because the argument was never about the tool.

What this means for a panelized housing program

K&K’s residential work is organized around permanent panelized steel homes, subject to project-specific design and approvals. That context sharpens the triage rather than softening it, because repeatability raises the cost of an undetected error: the same mistake is reproduced rather than encountered once. A project can define work for off-site preparation so that less has to be resolved from scratch in the field — but only if what was prepared off site is demonstrably the thing the project approved.

That is why the three companion reports in this series pick up exactly where the triage leaves off. The Revit authoring and readback report examines what a reopened native model can actually prove. The structural handoff report examines the boundary where reserved judgment is easiest to lose, because the receiving engine returns numbers and numbers feel like conclusions. The change report examines the boundary where a single approved edit can propagate into a product line, a fabrication release, and a site that has already begun work. All three are downstream of the same question this report asks: what did the system actually demonstrate, and what is still someone’s decision?

The wider delivery context — procurement, logistics, multi-trade coordination, installation, and handover — is described under our integrated project delivery capabilities and technology and R&D program.

Public boundary

This report describes a scoping and evidence method at a conceptual level. It is not a product certification, a released engineering capability, a promise of autonomous design, or a statement of performance, cost, or schedule. It intentionally omits internal implementation detail, control mechanisms, project data, and unreleased engineering material.

Project-specific architecture, engineering, permitting, production, supplier review, installation, and inspection remain the responsibility of the applicable parties and authorities, and local licensed roles are defined for the actual jurisdiction. See our compliance and project-record practices for the documentation boundary. If you are planning a permanent residential project, start with the requirements and property conditions through our steel home program or contact page.