Superintelligence Prep for Radon Mitigation: Tests and Fan Checks

A radon mitigation company that uses an AI agent for customer follow-up needs each test result and fan check recorded with its conditions, observer and approval status before the agent writes anything. Without those fields, a message can quote a result from an invalid run, describe a fan as working when the last visit showed otherwise, or promise a level nobody has measured. The practical starting point is a short, fixed set of record fields and a clear line between what the agent may repeat and what a certified person must explain.

Key takeaways

• A follow-up message is only as accurate as the record it reads, so store the measurement conditions next to the number, not in a technician's memory.
• Fan checks need the current state, the readings taken, the observer and the date, so a later message can say what was seen and when.
• Keep interpretation and health language out of free drafting. Anything that sounds like a conclusion goes to a certified person first.
• Start with one role, one record set and one observable success criterion, such as every outgoing message matching the stored record on the day it was sent.

What an accurate follow-up depends on

After a test or a fan visit, customers tend to ask the same few questions: what was the result, is the system still running, when should it be checked again, and does this mean the home is safe. Each question maps to a different part of the record. The result answers the first. The fan status and last service date answer the second. Retest timing depends on the test type and on whether the building was in the condition the protocol requires. The last question is not a record question at all. It is an interpretation the company has to own.

An agent that cannot tell these apart will sound helpful and still be wrong. It will also be wrong in a quieter way when it reads an earlier version of a record. A retest, a fan replacement or a corrected lab report supersedes what came before, so every record needs a version date, and the agent should read only the current version.

Test results: record the conditions, not only the number

A result without context is hard to follow up on. For each test, store the test type, the device or laboratory identifier, the placement in the building, the start and end times, whether the building was closed as the protocol requires, who placed and retrieved the device, and the unit printed on the report. For tests sent to a laboratory, store the chain of custody and the laboratory's reference number. A message that says the reading was in the range discussed on the phone cannot be checked against anything if these fields are missing.

Illustrative scenario: a company runs a short test in a basement. The device is retrieved earlier than the protocol allows, and the record gets an exception flag. The agent's draft to the homeowner must not present the result as final. It should say that a repeat test is being arranged and that a technician will call. Without the flag, the agent would send a confident result based on a run that should not be relied on.

The exception flag has to be visible in the record the agent reads, not only in the technician's notes. Authorization guidance from OWASP is useful here: the agent should have read access to the fields it needs and no access to fields it does not need, so it cannot quietly pull in internal remarks that were never meant for a customer.

Fan checks: state, readings and observer

Mitigation systems are judged over time, so fan checks matter as much as the first test. For each visit, record the fan make and model, the serial number, the installation date, the reading from the system's gauge where the design includes one, the state of any indicator or alarm, any noise or vibration noted, the electrical checks performed and any change made. Record the observer by name or role. If a customer reports a sound, smell or alarm, store what they described and, separately, what the technician confirmed on site.

Keep the last confirmed reading as a baseline. A later message can then say that a reading is lower than at the last visit and that a technician will look at it, which is accurate. A message that says something is wrong with the system is an interpretation and belongs with a person. Companies that already track equipment in other field trades, such as irrigation zones and repairs, face the same problem of storing a last known state so that follow-ups can refer to it.

A setup sequence for the record

The following order keeps the first version small enough to check.

• Give every active test and every installed fan one identifier that appears in all related records.
• Define the minimum fields for a test (conditions, device, unit, exception flag) and for a fan visit (observer, readings, indicator state, change made).
• Mark which fields a customer message may quote and which stay internal.
• Add a version date to each record so superseded results are easy to tell apart from current ones.
• Give the agent read access to the records and drafting access to approved templates only. Writing to the record stays with staff.
• Review a sample of sent messages against their records every week during the early period, and log each mismatch with its cause.

The last step is the one most companies skip. The sample review shows whether the agent is reading the right fields, and the log shows whether the problem is in the record, the template or the agent's instructions.

Deciding what the agent may say

The decision guide below separates routine messages from those that need a person. Local regulator guidance sets the thresholds and disclosure rules for each market, and this article does not set them.

• Quote a result exactly as stored, with its unit, test type and date, only when the record has no exception flag.
• Explain the next steps listed in approved templates, such as scheduling a retest or a fan visit.
• Report a fan indicator state only when the current record version shows it, with the observer and date.
• Route any message that interprets health risk, compares a result to a threshold or predicts a future level to a certified person before it is sent.
• Hold messages that touch legal disclosure, insurance claims or property sales for review.
• Escalate any customer report of a sound, smell or alarm to a human within the same working day.

Warranty wording deserves the same caution. Exclusions and conditions need to be quoted from the contract, not paraphrased, which is the same discipline that matters in wildlife removal warranties. The NIST AI Risk Management Framework is a reasonable reference for documenting who reviews which kinds of output and how those reviews are recorded.

How Be Human handles this

Be Human designs the agent around one defined role, here a follow-up role for test and fan records. The first engagement sets the memory the agent reads (the record fields above), the tools it can use (read access to current records, drafting and approved templates), the approval boundaries that send interpretation to a certified person, and a success criterion the company can observe, such as message accuracy against the stored record. In managed operations, Be Human can monitor that accuracy, run recurring evaluations against sampled messages, review permissions when staff or systems change, and handle incidents where a message did not match its record. The company keeps control of its identity, its channels and what the agent is allowed to say. If your team is unsure where the first task belongs, the free Be Human AI diagnostic will help you find the first task worth handing to an agent.

Frequently asked questions

Can an AI agent tell a homeowner that the house is safe after mitigation? It should not. Safety is a conclusion that depends on measurements, local rules and professional judgment, so the agent should only repeat stored results and approved next steps. Any sentence that declares a home safe or unsafe goes to a certified person before it is sent.

What should happen if a customer reports that the fan sounds different? The agent should record exactly what the customer described, with the date and the channel used, and then escalate the report to a human the same working day. The technician's confirmation goes in a separate field, so the record shows what was reported and what was observed.

Does the agent need write access to the test and fan records? Not at the start. Read access to current record versions and drafting access to approved templates are enough for follow-up messages. Changes to results, flags and fan status should stay with staff, who can record their reasons in the same record.

How do we know the agent is accurate enough to keep running? Accuracy is measured, not assumed. Sample sent messages on a regular schedule, compare each one with the record it cites, log every mismatch with its cause, and adjust fields, templates or instructions based on what the log shows.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.