Field-Level Routing for HVAC Note Summaries
An HVAC office does not need one blanket rule for AI note summaries. It needs a per-field routing decision: which fields the summarizer may see, which must be withheld, and which must be escalated to a named person before anything moves. This guide gives you a routing record, an executable prompt, a synthetic worked case, and a verification checklist.
The worked case is deliberately awkward. The customer name is withheld, but the equipment serial is a real identifier that must still be summarized, because the next office action — a warranty lookup — depends on it. That is the point of field-level routing: the route follows the next action, not the label "personal" or "technical." Redaction reduces exposure; it does not guarantee anonymity, and it is not a compliance certificate. A person still reviews the output before it reaches billing, dispatch, or a customer.
Start with what the office actually has to do next
Before you decide what to strip, write down the next office action for the job. A warranty lookup needs the serial. A dispatch decision needs the symptom and the technician's observation. A billing step needs parts and labor notes. A customer callback needs a contact method, which the office already holds in its own system and does not need to send to a summarizer.
The FTC's business guidance frames data security around five principles, beginning with taking stock of what personal information you have and where it lives, and scaling down to keep only what you need (FTC: protecting personal information). Applied here, that means asking a blunt question for every field: does the summarizer need this field to produce the artifact the next action requires? If not, the field is withheld. If yes, it is summarized, and the artifact is named.
This is why a single "redact everything personal" rule fails. It would strip the serial that the warranty coordinator needs, and it would leave the office with a summary that cannot drive the next step. Field-level routing keeps the record useful without carrying identifiers into a system that does not need them.
The routing record and the worked case
The table rendered after this section is the generic redaction baseline: remove direct identifiers, preserve technical substance, replace the record key with a synthetic job identifier, review for residual context, and enforce an UNKNOWN output rule. It is a summary of the pattern, not the per-field decision itself, so the actual routing record for the worked case is written out below as its own labeled block.
Routing record — synthetic job JOB-0001:
- Customer name: [CUSTOMER NAME] — route: withhold — owner: office lead — artifact: none
- Street address: [STREET ADDRESS] — route: withhold — owner: office lead — artifact: none
- Access code: [ACCESS CODE] — route: withhold — owner: office lead — artifact: none
- Equipment serial: [SERIAL NUMBER] — route: summarize — owner: warranty coordinator — artifact: warranty lookup sheet
- Equipment symptom: Occupant reports the upstairs zone does not reach the thermostat setpoint during the afternoon. — route: summarize — owner: dispatcher — artifact: job summary
- Technician observation: Return grille partly blocked by furniture. Filter recently changed. Blower wheel shows dust buildup. Static pressure readings taken at the return and supply plenums differ noticeably. — route: summarize — owner: dispatcher — artifact: job summary
- Warranty status question: Occupant asked whether the unit is still under the manufacturer warranty. — route: escalate — owner: warranty coordinator — artifact: warranty lookup sheet
Read it as a decision table: withhold means the field never enters the summarizer input; summarize means it does, and the named owner receives the artifact; escalate means a person must act before the summary is treated as complete. The equipment serial is the interesting one: it is a real identifier, but it is routed to summarize because the warranty lookup sheet depends on it. The office lead owns the withhold decisions; the warranty coordinator owns both the serial artifact and the escalation.
Notice what the record does not claim. It does not say the serial is anonymous, and it does not say withholding a name makes the job unidentifiable. A serial plus a model plus a neighborhood can still point to a household, which is exactly why the review step exists and why the artifact is scoped to a warranty lookup rather than a general-purpose summary.
Executable prompt for the summarizer
Use a prompt that receives only the routed fields and is forbidden from inventing the rest. A workable version:
```
You are summarizing a synthetic HVAC job record for an office handoff.
Input fields are provided below. Use only those fields.
Rules:
1. Output the job identifier exactly as given.
2. For each provided field, restate the content in plain office English.
3. If a value is missing, write UNKNOWN. Never guess a model, serial, reading, price, diagnosis, or part.
4. Do not add a diagnosis, a repair recommendation, or a price.
5. Do not merge two fields into one line.
6. End with a Flags line listing every field whose value is UNKNOWN.
Fields:
Job identifier: JOB-0001
Equipment symptom: [ROUTED SYMPTOM TEXT]
Technician observation: [ROUTED OBSERVATION TEXT]
Equipment serial: [ROUTED SERIAL PLACEHOLDER]
```
The UNKNOWN contract is the load-bearing part. A model that invents a serial or a static-pressure reading is worse than one that says it does not know, because the office may act on the invention. Keep the prompt free of customer names, addresses, and access codes; those fields are withheld upstream, so the model never sees them.
Three labeled samples
These three samples are synthetic. They use obvious placeholders and no realistic access code, address, or account number.
Sample 1 — synthetic raw note (do not process as-is):
````
Job: [CUSTOMER NAME], [STREET ADDRESS], [UNIT], gate code [ACCESS CODE].
Arrived 2pm. Occupant says upstairs never cools. Outdoor unit [MODEL] short-cycles.
Serial [SERIAL NUMBER]. Suction line cold, filter loaded. Occupant asked about warranty.
Call [PHONE].
Sample 2 — routed input (what the summarizer actually receives):
````
Job identifier: JOB-0001
Equipment symptom: Occupant reports the upstairs zone does not reach the thermostat setpoint during the afternoon.
Technician observation: Return grille partly blocked by furniture. Filter recently changed. Blower wheel shows dust buildup. Static pressure readings taken at the return and supply plenums differ noticeably.
Equipment serial: [SERIAL NUMBER]
Sample 3 — expected summary:
````
Job identifier: JOB-0001
Equipment symptom: Occupant reports the upstairs zone does not reach the thermostat setpoint during the afternoon.
Technician observation: Return grille partly blocked by furniture. Filter recently changed. Blower wheel shows dust buildup. Static pressure readings taken at the return and supply plenums differ noticeably.
Equipment serial: [SERIAL NUMBER]
Flags: UNKNOWN - none; all provided fields present.
Compare the three. The raw note carries a name, an address, an access code, and a phone number. The routed input carries none of those, but keeps the serial because the warranty lookup needs it. The expected summary restates only what it was given and flags nothing as UNKNOWN because every provided field had a value.
Human verification checklist
Before the summary moves anywhere, a person checks the following. Confirm the job identifier matches the record and is not a reversible personal initial. Confirm no withheld field — name, address, access code, phone — appears anywhere in the routed input or the output. Confirm the serial artifact is scoped to the warranty lookup and is not pasted into a general-purpose summary or a customer-facing message. Confirm every UNKNOWN flag is genuine and not a value the model should have received. Confirm the escalation to the warranty coordinator actually happened and has an owner. Confirm the summary contains no diagnosis, no price, and no repair recommendation; those remain engineering and pricing decisions for responsible staff. Finally, ask whether the combination of remaining fields could still point to a household, and redact further if it could.
Failure modes and limits
The most common failure is route drift: someone pastes the raw note into a tool "just this once," and the withheld fields enter the system. A second is artifact creep, where the serial sheet is reused for marketing or a general summary. A third is silent invention, where the model fills a missing reading with a plausible number; the UNKNOWN contract and the flags line are the defense. A fourth is treating the routing record as a one-time setup rather than a per-job decision.
Keep the limits in view. Redaction reduces exposure; it does not guarantee anonymity, and it is not a compliance certificate. Context can still identify a person. The FTC's guidance supports data minimization and reasonable security, not approval of a particular AI vendor (FTC: start with security). This workflow is a documentation aid for US HVAC office work; it is not a safety diagnosis, and it does not decide engineering or pricing questions. Those stay with responsible staff. For related office workflows, see the guides index.
Sources and method
- FTC: protecting personal information — retrieved 2026-09-26
- FTC: start with security — retrieved 2026-09-26
AI-assisted writing with automated source, calculation and editorial checks. No hands-on testing or professional certification is claimed. Check the stated assumptions before applying this guide.