“Keep a human in the loop” is directionally sensible and operationally vague. It does not say which human, at what moment, looking at which evidence, with authority to do what.
A useful control model starts with the action's consequence, reversibility, uncertainty, and coordination reach. The same AI capability may need light review when it summarizes a closed issue and strict approval when it proposes a geometry change or releases a contractual response.
The matrix below is Matechi's operating framework, not an industry standard. It translates governance concepts from the NIST AI Risk Management Framework into action classes that an AEC project can assign, test, and audit.
Four Questions Before Choosing the Review Gate
- Consequence: What could be affected if the output is wrong—an internal queue, a model, another discipline, a purchase, a submission, safety, or professional responsibility?
- Reversibility: Can the action be undone cleanly, and is the prior state preserved?
- Uncertainty: Is the result a deterministic rule outcome, a probabilistic interpretation, or a mixture of both?
- Coordination reach: Can the action remain inside one person's workspace, or does it alter another team's work, a shared record, or an external commitment?
The Five Action Classes
- Observe and inform. Examples: summarize a closed issue set, calculate a metric, or show a non-authoritative trend. The system may display the output without pre-release approval when sources, timestamp, scope, and uncertainty are visible. A named owner still monitors failures and corrections.
- Draft and classify. Examples: propose an issue category, draft a coordination note, extract a requirement, or recommend an owner. A knowledgeable reviewer approves or edits the result before it becomes an official project record or external communication.
- Change bounded project data. Examples: correct an approved parameter value, update a controlled status, or apply a deterministic naming rule. Require an exact preview, authority for that data class, validation after the change, rollback, and a receipt. Batch release needs a tested error boundary and sampling plan.
- Change shared geometry or cross-discipline state. Examples: reroute a system, move an element, accept a clash exception, or close an issue that another model owner relies on. Require the discipline owner or coordinator identified by the project, impact checks, alternatives where appropriate, and confirmation in the next coordinated version.
- Release an external or consequential decision. Examples: issue a contractual response, certify compliance, approve a submittal, release fabrication information, or make a safety-critical determination. The accountable professional or contractual authority reviews and releases the decision. Automation may assemble evidence and draft options; it does not inherit professional or contractual authority.
Controls That Travel With Every Class
The review gate changes by action class, but the record should always preserve the input version, applicable rule or source, system output, uncertainty or failure state, reviewer or operating owner, and final disposition. For changes, add the before state, proposed state, impact checks, applied state, and rollback result.
For Revit changes, Autodesk's transaction classes provide the technical structure for document modification and rollback. They do not choose the human authority or prove the project decision. The operating control must sit above the API transaction.
Escalate When the Premise Changes
- The source requirement is missing, contradictory, or superseded.
- The model, document, or rule version changed after the output was generated.
- The proposed action affects an object, discipline, zone, or contract outside the approved scope.
- A deterministic check and a model-generated interpretation disagree.
- The result introduces a new clash, warning, validation failure, or downstream inconsistency.
- The named reviewer is unavailable or lacks authority for the action class.
Escalation should change the workflow state visibly. “Needs input,” “coordinate,” “hold,” and “not applicable” are often more honest outcomes than forcing every finding toward an approve-or-reject button.
Turn the Matrix Into a Release Rule
For one recurring workflow, list each output or action, assign its class, name the approving role, define the evidence that reviewer must see, and test the failure route. Then run a representative set through the matrix and record where reviewers modify, reject, or escalate the system's proposal.
The result is not less automation. It is a clearer boundary around where automation saves review time and where the project must preserve accountable judgment. Matechi uses this matrix when configuring reviewed QA/QC, coordination, and model-action workflows around a client's existing roles and approval structure.