Inspections

Inspections are checklists you run against the work. A template defines the sections, the questions, and what counts as a pass; an inspection is one run of that template at a place and time, with answers, photos, signatures, and a report.

The register is at Inspections. Checklists in the register header opens the template library.

Templates and instances are different things

A template is a definition. An inspection is a run of it, and it carries a snapshot of the template's sections and items taken when it was stamped. Editing a template in March does not rewrite an inspection signed in February. There is no retroactive propagation anywhere in this module, which is what makes a signed inspection evidence rather than a view over changing configuration.

Company templates and project templates

A template is scoped either to the company or to a project. Assigning a company template to a project creates a project-scoped copy that remembers where it came from, with every inherited section and item marked as inherited. The split of ownership is fixed:

Owned by the company	Owned by the project
The two evidence flags on inherited items, Require photo and Require observation	Wording, ordering, and any items the project adds
Custom response sets. A project may reference one but may never author one	The project's own description

Re-syncing a project copy from its company source is an explicit action, never automatic. An automatic re-sync would rewrite a project's customised wording every time a company admin fixed a typo. The project surface tells you the company template has changed and lets somebody decide.

Deleting a template moves it to a recycle bin. It is recoverable.

Building a template

A template is sections, each holding line items. Each item has text and one of six response types:

Response type	Notes
Pass / Fail / NA	The built-in status set
Custom response set	A company-authored named option list
Number	Stored so a report can aggregate without re-parsing
Text
Date
Signature	Captures a signature on that line item

Every selectable option carries two independent flags, conforming and deficient. The label is decoration; those flags are what drive deficiency reporting, the require-photo and require-observation triggers, punch promotion, and what carries into a reinspection. An option may be one, both, or neither: Pass is conforming, Fail is deficient, and NA and Not Required are neither, because they are answers rather than judgements.

Items can also carry references, read-only context pointing the inspector at a photo, a drawing, a form, or a document.

Conditional logic

An option-bearing item can reveal other items when a particular answer is given. The rules are enforced when the template is saved, not just in the editor:

• The parent and every revealed item must be in the same section.
• At most four conditions per parent item.
• The parent's response type must be option-bearing (Pass / Fail / NA, or a custom set).
• The values a condition matches on must exist in the parent's option list.
• An item cannot reveal itself, and the graph cannot cycle.

Start an inspection

1. Click Start inspection.
2. Pick the Checklist.
3. Set the location, trade, due date, spec section, responsible contractor, and equipment as needed.
4. Optionally mark it Private.
5. To stamp several at once, set How many and, optionally, one location per line.
6. Click Start inspection.

Bulk stamping covers up to 100 inspections in one call. Assignees default to the creator.

The lifecycle

Three states, and only three:

Status	Ball is with	Meaning
Open	The assignees	Somebody has to walk the work and answer
In Review	The point of contact, or the creator	Completed, awaiting review
Closed	Nobody	Terminal

In Review is not decoration. It blocks observation creation from a line item, which is the behaviour that gives the state its meaning.

There is no reopen. Closed is terminal, and that is what makes two other rules enforceable: signing is blocked once an inspection is closed, and reinspection is available only from Closed. An edge back to Open would let anyone reopen instead of reinspect, and the reinspection chain, which is the audit artefact a quality director actually wants, would never get built.

Responding, signing, and commenting are all blocked on a closed inspection, as a property of the machine rather than a check each screen has to remember.

A closed inspection's header is frozen for everyone. It is signed evidence.

The lifecycle actions are Send for review, Return to open, and Close inspection.

Answering

Each answer records the value, an optional comment, and any photos or files attached to that line.

Progress and deficiency counts are derived from the answers, never stored, so they cannot drift from what is on the record.

The evidence gate is at close, not at the answer

An item can require a photo, or require an observation, before a deficient answer on it counts as complete. That requirement is enforced when you close the inspection, not when you record the answer.

The reason is the basement with no signal: a field user has to be able to record the answer now and attach the photo when they are back in range. Blocking the answer loses the answer; blocking the close loses nothing.

The screen shows an outstanding-evidence warning with a count while any remain, and the close is refused with the same count until they are cleared.

Signatures

Two independent levels:

• Whole inspection. One or more signers attached to the inspection itself.
• Per item. A line item whose response type is Signature captures its own.

Neither implies the other. An inspection can be signed with unsigned signature items on it, and a signature item can be captured hours before sign-off. Treating one as a special case of the other is how "the plumber signed for his own rough-in" ends up looking like "the plumber signed the whole inspection".

Any user with STANDARD access or higher can sign on behalf of a listed signer. When that happens the record stores both identities: whose signature it is, and who performed the action, plus an on-behalf flag that the PDF prints. A record that read "signed by the superintendent" when the office coordinator clicked it is the kind of thing that loses a claim.

A signature row exists only once it has been captured. There is no pending or declined signature state, because a signature that has not been captured is a signature that is not there.

Turning a failure into work

A deficient answer can be promoted two ways. Both run off the same deficiency test, which reads the option's deficient flag rather than its label, so a company-authored response set works exactly like the built-in one.

Into a punch item

One tap raises a punch item from the failed line, and it is synchronous: you get the punch number back before you walk to the next room. Attachments on the answer carry over to the punch item.

You can set the assignees, priority, due date, and description as you promote.

Promotion is idempotent per line item. Re-posting returns the punch item that already exists rather than issuing a subcontractor two identical items, and a tablet that retried on a flaky connection cannot produce a duplicate. If a second request arrives while the first is still writing, the retry that follows gets the item the first one created.

You do not need Punch access to raise one. An inspector who may run inspections but holds no punch permission would otherwise silently produce nothing; instead the item is raised and the response tells the UI you cannot open it.

Into an observation

The standard path. It needs STANDARD on both Inspections and Observations, and the inspection must still be Open. In Review and Closed both block it.

The location, spec section, responsible contractor, due date, and the link back to the inspection carry across. Type, priority, trade, distribution, description, attachments, hazard, contributing condition, contributing behavior, and the private flag are all entered by hand on the observation, deliberately: they are judgements about the observation rather than facts about the checklist line.

The observation carries a read-only origin link back to the inspection and the item it came from. See Observations.

Reinspection

A reinspection is a linked child inspection, created from a Closed parent. It is how a closed inspection is revisited, since there is no reopen. The register labels those records as reinspections, and an inspection in a chain shows the whole chain at the top of its detail.

What carries over: the section and item snapshot from the parent inspection, not from the template, which may have changed since; the whole header; and the answers on conforming items, with their comments and photos, so the reinspection focuses on what failed.

What does not: deficient answers (that is the point), signatures (a new inspection is a new sign-off), the parent's activity feed and history, and the promotion links. A punch item raised from the parent stays attached to the parent; carrying the link forward would make one punch item look like it was raised twice.

The chain is linear. An inspection that has already been reinspected cannot be reinspected again.

Summarize deficiencies

Summarize deficiencies hands the inspection's deficient lines to a model and returns a headline, a per-deficiency list, and a recommended next step.

It is a suggestion. Nothing is written to the inspection. An inspection is a record a contractor forwards to an owner, and machine-written text nobody read before it left the building is a real liability.

It is metered against the project's credits, settled against actual usage on success and released on every failure, including a model response that could not be parsed: you got nothing, so you pay nothing. It covers up to 40 deficiency lines and says when it truncated.

Export

Inspection report renders the completed checklist as a PDF, which is the document you forward to an owner, an authority having jurisdiction, or a subcontractor. It needs READ_ONLY on Inspections, the same level as viewing the record.

Private inspections

A private inspection is visible to its creator, point of contact, assignees, distribution list, and anyone with ADMIN on Inspections. Everyone else gets 404 Not found, never a 403.

Being on the distribution list grants view access, not just notifications.

Permissions

Action	Level
View the register, open an inspection, export the PDF	READ_ONLY on Inspections
Start an inspection, answer, sign, comment, submit for review, close	STANDARD on Inspections
Edit somebody else's inspection header	ADMIN on Inspections
Promote a failure to an observation	STANDARD on Inspections and on Observations
Author custom response sets, edit company-template conditional logic	ADMIN on Inspections

Limits

Limit	Value
Inspections read per project	5,000
Register page size	200 maximum
Signatures per inspection	50
Activity rows per inspection	1,000
Inspections stamped in one bulk create	100
Conditions per line item	4
Items per section	1,000
Sections per template	100
Items per template	2,500
Templates per company	2,000
Deficiency lines summarized	40

Troubleshooting

"Inspection not found" on a link somebody sent you. It is private and you are not one of its parties. Private records answer 404 rather than 403 on purpose. Being added to the distribution list is enough to see it.

You cannot sign. The inspection is Closed. Signing is blocked at Closed as a property of the lifecycle, so no screen can offer it. Reinspect instead.

Creating an observation from a failed item is refused. Either the inspection is In Review or Closed, and only Open allows it, or you hold STANDARD on Inspections but not on Observations. Both gates are required.

"Only a deficient answer can be promoted." The line item's recorded answer is not mapped to the deficient axis. Record the deficiency on that item first. Remember that the axis, not the label, is what counts: a custom option called Fail that was not flagged deficient will not promote.

Promotion returned a punch item you cannot open. The punch item was raised correctly; you do not hold access to the Punch tool. Ask for Punch access, or ask the punch manager for the number.

Promotion answered "in progress". A concurrent request is still writing. Retry; you will get the item the first request created rather than a second one.

A project cannot change Require photo or Require observation on a checklist item. Those two flags are company-owned on inherited items and read-only at project level. Change them on the company template, then re-sync.

The project template says the company template has changed. Re-sync is deliberate rather than automatic, so your project's wording is not rewritten under you. Review the change and re-sync when you are ready.

Close is refused with a count of deficient items. Those items still owe a required photo or a required observation. The requirement is checked at close rather than when the answer was recorded, so the answers are safe; attach the evidence and close again.

A reinspection cannot be created. Reinspection runs only from a Closed parent, and only once per inspection. If the inspection already has a child, work on the child.

Editing a closed inspection is refused. Closed headers are frozen for everyone, admins included. It is signed evidence.