A workflow can look convincing in a demonstration and still be unready for project use. The gap is usually not another model capability. It is missing evidence about scope, requirements, data, authority, failure handling, and who owns the process after the pilot.
This checklist is an implementation-readiness tool, not a claim of legal, contractual, code, or professional compliance. Use it to expose what must be defined and tested before an AI-assisted workflow influences a deliverable, a model change, or a project decision.
How to Score Each Control
For every control, record three things: the artifact that proves it, the person who owns it, and the test that has passed. Mark READY only when all three exist. Mark CONDITIONAL when the control is designed but untested, and NOT READY when the scope, owner, or evidence is missing.
This evidence-first approach is consistent with the NIST AI Risk Management Framework, which organizes risk work around governance, context mapping, measurement, and management. In an AEC deployment, those ideas need to become project artifacts and decision rights rather than a general policy statement.
Twelve Production-Readiness Controls
- Approved requirement source. Identify the specification clause, standard, owner rule, coordination agreement, product constraint, or other approved source that governs each check. Record its revision and what happens when sources conflict.
- Bounded applicability. Define which project, discipline, model, document, element class, zone, and lifecycle stage are in scope. State exclusions plainly. A system that cannot say where a rule applies should not report a confident finding.
- Data and access boundary. List every input, output, retention location, service, role, and permission. Confirm that the pilot uses authorized data and that people cannot see or change more than their project role permits.
- Version and freshness control. Preserve the exact source versions, timestamps, and rule-set version behind every result. A stale model or superseded document must be visible as stale, not presented as a current clean check.
- Deterministic versus probabilistic boundary. Separate calculations and exact rules from classification, summarization, retrieval, or option generation. Reviewers should know which result can be reproduced exactly and which depends on model behavior or context interpretation.
- Finding-level evidence. Every consequential finding should point to the affected object or passage, governing source, applicability logic, and relevant inputs. A score without inspectable evidence is not enough for review.
- Named human authority. Define who may accept, reject, modify, defer, or release each action class. Confidence is not authority. Cross-discipline, contractual, safety, or professional decisions require the accountable role already established by the project.
- Preview, transaction, and rollback. For a proposed model or data change, show before and after state, affected objects, impact checks, and rollback path. Autodesk's Revit transaction guidance describes the implementation boundary for document changes; the operating workflow still needs a review boundary before that transaction begins.
- Failure and uncertainty routing. Define what the system does when a source is missing, an identifier changes, a model check fails, tools disagree, or evidence is insufficient. The safe result is often a visible hold or request for input, not a guessed answer.
- Representative evaluation set. Test known positives, known negatives, ambiguous conditions, stale inputs, edge cases, and conditions that should be out of scope. Preserve the expected result so regressions can be detected after a model, rule, or integration changes.
- Operational handoff. Name the team that will review queues, maintain rules, resolve access problems, handle failures, and answer users after the build team leaves. A pilot without an operating owner is still a demonstration.
- Change monitoring. Record changes to models, prompts, rules, retrieval sources, integrations, and deployment configuration. Rerun the relevant evaluation set and retain the release receipt before a changed workflow returns to production.
Stop Conditions
Do not average critical controls into a reassuring total. Hold the pilot when a consequential result lacks a governing source, current input version, inspectable evidence, named authority, or failure route. Hold any writeback when the team cannot preview the exact change, test its impact, and recover the prior state.
A Practical Entry Rule
Start with one repeated workflow, one approved requirement family, and a representative project copy. Require every control above to reach READY or to have a documented, non-consequential limitation. Run the workflow, review every result, record modifications and rejections, test failure cases, and reconstruct one decision from the audit record.
If the team can explain what the system checked, why it applied, what evidence it used, who decided, and what changed next, the pilot has a credible production boundary. If those answers live only in the builders' heads, it does not. Matechi uses this checklist to scope client-specific AEC workflows before expanding automation depth or volume.