AI in a roofing business: Review a scope change before updating the job
Use AI to extract a roofing change request while keeping proposed scope, price, authorization and release separate. Includes a synthetic review record.
Let AI draft a change request with its source evidence, then require the responsible person to decide scope, price, authorization and release. A field note describing possible extra work is not itself permission to revise the job or order materials.
Keep the original approved scope visible while the request is reviewed. The useful automation is reducing the work of organizing the request, without pretending that extraction has settled the business decision.
Begin with a note that contains a condition
This is an invented example, not a technical recommendation:
Customer asked about adding two items to the job. I said the office needs to confirm the specification and price. They want an answer tomorrow. Do not order yet.
The word “two” is supported. The exact item specification, price and approval are not. A draft that adds two units to the approved order has crossed the boundary between summarizing a request and authorizing work.
Use this review record:
| Field | Draft supported by the note | What remains for a person |
|---|---|---|
| Request source | Linked field note and author | Confirm the request belongs to this job |
| Proposed change | Customer asks about two additional items | Define the exact specification |
| Requested response | Answer requested tomorrow | Assign the response owner |
| Price | Not established | Prepare and review the proposed amount |
| Customer authorization | Not established | Obtain evidence under the agreed process |
| Purchasing action | Do not order yet | Release only after the required decisions |
| Approved job baseline | Existing scope remains the reference | Apply an authorized change deliberately |
A useful draft preserves the negative instruction. It also preserves the distinction between a requested response date and an agreed production date.
Define the states the record may enter
Use a small set of states that correspond to actual decisions: request captured, information needed, proposal ready, authorization recorded, released to operations, or declined. Adapt the names to the business, but do not combine proposal and authorization into one vague “approved” checkbox.
Specify which role can move the record between states and what evidence is required. A request may be declined or remain unanswered; neither outcome should silently change the original job scope.
NIST's AI RMF Core emphasizes understanding the use context, evaluating behavior and managing risk through the lifecycle. The review record and state method here are original DATUM operating controls, not a certification or a claim that a model reliably follows them without testing. NIST AI RMF Core
Keep the AI's permitted output small
For the pilot, allow the workflow to prepare a draft request and highlight missing evidence. Keep updates to the approved job, purchasing records and customer commitments outside that draft action.
The AI permissions worksheet helps define the actual read and write boundary. Verify the connected account and tools enforce the intended restriction; a prompt saying “draft only” is not a substitute for implementation controls.
Store the source reference with each extracted field where practical. A reviewer should be able to resolve “where did this quantity come from?” without searching through unrelated customer history. Send only the information needed for the extraction task under the approved data rules.
Test conditional language and later corrections
Build a set of synthetic or permitted cases before using the workflow on live requests. Include:
- “Please price this” with no authorization.
- “Approved if the total stays below the amount in the proposal,” with the condition unresolved.
- A later correction changing the quantity.
- Two jobs mentioned in one conversation.
- A request withdrawn before work is released.
Have the responsible person write the expected draft and next state before testing. Reject unsupported specifications, lost conditions, wrong-job assignment and invented authorization. Track those errors separately from ordinary wording edits.
A change to the prompt or model should trigger a rerun of the cases that previously failed, plus ordinary examples. Preserve the tested version and reviewer corrections so the next improvement is based on evidence.
Verify the released version at the receiving handoff
After a person has completed the approval process, ask production to identify the scope now authorized and purchasing to identify the permitted order. This final check concerns the operating system's change process, not the AI's prose quality.
The roofing sales-to-production handoff worksheet helps keep measurements, approved scope, extras and completion evidence distinct. Use the same job reference throughout. The workflow is useful when a request becomes easier to review while the original scope remains protected until the authorized change is deliberately released.