Checklists & custom checks
Every firm has standards that no off-the-shelf check covers: cover-sheet requirements, naming conventions, the way your details must be referenced. Most firms also already have their review checklists - in a spreadsheet, a Word document, or the back of somebody's head. This tool turns both into something runnable.
The two words describe one thing at two sizes. A custom check is one question you've written. A checklist is the list it lives in - and every check you create lands in one. Describe a single question to the chat and you get a one-item checklist; import your MEP completeness spreadsheet and you get a forty-item one. Either way, the checklist is the thing you keep: it lives in your library, outside any project, so you do the work of writing or importing it once and run it on every job.
Use case: create a check for your office's specific cover-sheet requirements and reuse it on every job.
A checklist is a list of questions to ask of a drawing set. A workflow is a whole multi-step review procedure - pull the schedules, cross-reference, write it up. Start here if you have a standard or a document to encode; save a workflow if it's a procedure.
Creating one
Two routes:
- Import a document. Upload the spreadsheet or checklist document you already use. The platform reads the items and turns the list into runnable checks.
- Describe it. Ask the chat in a project and describe what you need in plain language: what to look for, what counts as a violation, and what evidence matters.
Either way, the platform researches your project documents first, so the checks are grounded in what's actually in the set. Then it proposes a plan: which items it will run, which don't apply to this set, and which it can't do yet. You approve before anything runs.
That plan step is the one that saves you time later. A plan that says "eight of your twelve items will run, three don't apply to this set, one needs a measurement I can't do reliably" is worth more than twelve items that all appear to run and three of which quietly return nothing.
What custom checks can do
Custom checks handle the review moves a human checker makes:
- Text matching: tags, labels, and schedule entries that must agree.
- Cross-referencing: details, callouts, and references that must resolve.
- Vision: reading, categorizing, and matching what's drawn on the sheet.
- Calculations and connectivity: numbers that must add up, systems that must connect.
Each finding lands in Issues with a citation and a marked-up evidence image, so you can verify it at a glance.
Items that turn on measuring a distance off the drawing and comparing it to a numeric limit (clearances, widths, separations) are the hardest thing to do reliably in a custom check, and the platform will tell you when an item falls in that bucket rather than running it and being confidently wrong. For a measurement you need now, measure it yourself on the sheet - see Measuring - and for a measurement check you need repeatedly, talk to us about building it into your library.
Where they show up in a project
Checklists are not a separate panel. Inside a project, a checklist you've run appears in the Project QAQC panel's list alongside your library's built-in checks, marked with a Custom or Shared pill so you can tell yours from ours. The checklist is the grouping; the checks under it are the rows.
A checklist run is a run like any other: it appears in the tasks tray, its findings go to Issues, and it shows in your activity.
Your library
Open Checklists from your account menu. Three groups:
- Mine - checklists you created or imported. Private until you share them.
- Shared with me - checklists a colleague shared with you.
- Organization - checklists shared account-wide.
The checklist library, showing all three groups
A checklist here is the recipe, not a run. Run on project asks which project, then hands off to the chat, which proposes how it will work the list before starting - the same plan-and-approve step as when you created it.
From the library you can also rename, delete, and download the original file you imported. That last one matters more than it sounds: the source document is the thing your team recognises, and having it attached to the runnable version means nobody has to hunt for "the real checklist". Older checklists, imported before we started retaining source files, say so plainly rather than offering a link that goes nowhere.
Reusing and rerunning
Saved checklists run on the next revision or the next project; the checks adapt to the new set rather than expecting identical drawings - so last year's checklist works on this year's job.
Sharing
Sharing a checklist grants run-only access: colleagues can run it, not edit it. That keeps one authoritative version instead of five forks.
Sharing follows the standard model - private, then shared with a team, then shared with the organization, each promotion approved. See How access works. A checklist shared with a team appears on that team's page.
From chat to check
If the chat just did something you'll want again, ask it to save the work. A single question becomes a check in your library; a whole procedure becomes a workflow.
If a check you built keeps landing slightly wrong, you don't have to rewrite it from scratch - ask the chat to propose a refinement to it and review the change.