How Roofers Can Use Permit History To Find Aging Roof Opportunities

Roofers can use permit history to find aging roof opportunities by treating public records as worklist prioritization signals, not proof. A permit search can help answer a narrow question: which properties deserve a closer, source-labeled review before the team spends field time? It cannot prove the roof is old, damaged, noncompliant, uninsured, neglected, or ready for replacement. The workflow has to keep those ideas separate.

The clean version is simple. Gather permit and property context from sources you can name. Label each source by reliability. Convert records into internal reason codes. Cap weak signals. Block outreach until contact-channel, privacy, advertising, solicitation, and data-use questions are cleared. When a homeowner or property manager corrects the record, fix the record and suppress or reroute the property instead of arguing about what a database says.

The best phrase is not "this roof is old." The better internal phrase is "roof-age review candidate based on a source-labeled permit history check." The better customer-facing phrase is usually even softer: "We help homeowners review roof age, maintenance timing, and storm exposure." Public-record language can sound invasive when it is pushed too hard, and it can become inaccurate fast when a permit field is incomplete or local rules are misunderstood.

Start with the source. The U.S. Census Building Permits Survey gives useful construction activity context by geography, but it is aggregate data. It is not an address-level roof-permit lookup. Local systems can be more specific. NYC Department of Buildings describes tools that show building history, permits, jobs, filings, complaints, violations, and status for New York City properties. The City of Chicago Building Permits dataset is an official local open-data example. Those sources are useful because they are official, but they still require local interpretation.

Marketing and privacy sources belong in the same workflow. The CFPB advisory opinion on FCRA permissible purposes is a boundary marker for consumer-report use. The FTC advertising FAQ is a boundary marker for claim support and disclosures. The FTC CAN-SPAM business guide is relevant when commercial email is planned. The FTC Telemarketing Sales Rule guide and the FCC guide on unwanted robocalls and texts are reminders that call and text outreach is not cleared just because a record is public. The FTC Cooling-Off Rule page is a useful boundary when door-to-door contact could lead to covered in-home sales, contracts, deposits, or cancellation notices.

RoofPredict fits best as the worklist system. RoofPredict can organize ranked lists, source labels, routes, notes, storm context, and follow-up states. It should not be framed as a permit authority, legal reviewer, consumer-report reviewer, or marketing-compliance reviewer. The product should make the workflow auditable. It should not turn a record gap into a sales conclusion.

The Rule That Keeps The Program Clean

Permit history should answer one question before any other: is there enough source-labeled context to justify a review? If the answer is yes, the property can move to a manager queue. If the answer is no, it should stay out of the field route until the record is corrected or another signal is added.

That rule matters because roofing teams often want public records to do too much work. A city record might show a permit for "roof," "re-roof," "exterior repair," "building alteration," "solar," "structural," "siding," "storm repair," or a shorthand code that only makes sense inside that jurisdiction. A bulk feed might omit attachments. A status field might say issued, expired, void, finaled, closed, pending, cancelled, or unknown. A roof replacement might have been done before the searchable period. A repair might not have required a permit in that location. An owner might have records that are more current than the municipal export.

Those limits do not make permit history useless. They define the right use. Permit history is a sorting layer. It helps the office decide which records deserve a second look, which neighborhoods might be aging into roof-review timing, which past customers need service follow-up, and which addresses should be held because the data is too thin. It is not an accusation engine.

Use this internal operating principle:

A permit record can support a review reason. It cannot write the roof conclusion.

The same principle should appear in training notes, route notes, call scripts, email templates, and manager QA. A rep who sees "no documented recent roof permit in checked source" must understand what it means. It means the checked source did not show a recent roof permit. It does not mean nobody replaced the roof. It does not mean the homeowner violated code. It does not mean the roof is due. It does not mean the property is safe to contact by any channel.

Permit History Source Ladder

Not every permit signal deserves the same weight. Rank the source before ranking the property. A company invoice from five years ago, an owner-uploaded warranty, a local permit record, an open-data feed, a Census market report, and a vendor-inferred roof-age field do not carry the same meaning.

Source tier	Best use	Required label	Main risk
Company job history	Known work your company performed, bid, inspected, serviced, or declined.	company_record with job type, date, and internal reference.	It only covers your relationship, not all work by other contractors.
Owner-supplied document	Warranty, invoice, closing packet, seller disclosure, roof report, or insurance document supplied by the owner or authorized party.	owner_supplied with document date and uploader/source note.	It may describe repair, maintenance, or partial work, not full replacement.
Official local permit record	Parcel-level or address-level roof permit, where scope, date, status, and jurisdiction are visible.	official_local_record with jurisdiction, retrieval date, status, and URL or file reference.	Local fields vary, and status does not always prove completion.
Official local open-data feed	Repeatable feed used for route building, mapping, and batch review.	official_open_data_feed with import date, dataset name, and field mapping version.	Bulk feeds may lag, flatten scope notes, omit attachments, or use codes that need local review.
Aggregate government construction data	Market context, geography prioritization, and seasonality.	aggregate_context with geography and period.	Not property-specific roof history.
Vendor property data	Sorting support when source, date, and confidence are disclosed.	vendor_inferred with vendor, retrieval date, field name, and confidence.	Inferences can be stale, unsupported, or mixed with data that needs legal review.
Hold tier	Consumer reports, credit-derived data, protected-class proxies, sensitive data, unclear consent data, or unknown provenance.	quarantine_data_use_review; do not score or route from it.	Can create privacy, fair lending, advertising, consumer-report, or discrimination risk.

The ladder should live in the system, not only in a training document. If a score uses permit history, the record should show which tier created the score. If the source tier is unknown, the property should not jump into a high-priority route.

"Aging" must mean roof system age, documented roof-work age, or record recency. It must not mean homeowner age. It must not rely on household composition, ethnicity, language, disability, health, income, credit, family status, or any other sensitive or protected-class proxy. A system that says "find aging roofs" should be able to prove it is not really finding older residents, lower-income households, or storm-vulnerable communities for pressure selling.

What A Permit Record Can And Cannot Prove

A permit record can prove only the record itself, and even that has to be read carefully. A permit record may show that a jurisdiction received, issued, amended, denied, expired, or closed a filing. It may show a contractor name. It may show a scope label. It may show a valuation. It may show a status. It may show a final inspection. It may also show typos, incomplete text, outdated parcel references, or a broad construction category that includes roof work but does not isolate it.

Use the following claim boundary when writing internal notes:

If the record says	Internal conclusion allowed	Internal conclusion blocked
A roof permit exists from a clear date.	A roof-related permit was found in that source for that date.	The entire roof was replaced, the roof is currently good, or the work was done correctly.
No recent roof permit was found.	No recent roof permit was found in the checked source.	No roof work occurred.
The permit status is issued.	The jurisdiction shows an issued status.	The work was completed.
The permit status is finaled or closed.	The jurisdiction shows a finaled or closed status.	The roof has no current defects.
The scope is ambiguous.	Manual review is needed.	The property should receive roof-age points automatically.
The address match is fuzzy.	Hold for cleanup.	The record belongs to the target property.
The dataset is aggregate.	It can inform market planning.	It identifies a specific aging roof.

The same boundary should be used in content generation. If an article, route note, sales script, or landing page says "permit history shows the roof is overdue," the claim is too strong. If it says "public records can help roofers identify properties that may deserve a roof-age review," the wording is much easier to support.

Data Normalization Before Scoring

The scoring system is only as good as the normalized fields behind it. A sloppy import can make a good source look bad. A clean import can prevent field teams from chasing records that should have been held at the desk.

Create a standard record shape before any points are assigned:

Field	Example values	Why it matters
source_tier	company record, owner supplied, official local record, open-data feed, aggregate context, vendor inferred, hold review	Prevents weak sources from outranking direct evidence.
source_name	NYC DOB, Chicago Data Portal, county permit portal, company CRM, owner invoice	Lets a reviewer trace the record.
retrieval_date	2026-05-29	Stops old imports from pretending to be fresh.
jurisdiction	city, county, state, parish, township, AHJ	Keeps local rules from being generalized.
parcel_or_address_match	exact, likely, fuzzy, mismatch, unknown	Blocks bad joins.
scope_raw	the raw permit text or code	Preserves the original record.
scope_normalized	roof replacement, roof repair, exterior ambiguous, solar related, structural ambiguous, non-roof	Makes scoring repeatable.
permit_status	issued, finaled, closed, expired, void, pending, cancelled, unknown	Prevents issued permits from being treated as completed work.
permit_date_type	application, issue, final, close, last update	Prevents date confusion.
confidence	verified, official, likely, ambiguous, stale, unknown	Tells the routing system how much trust to place in the signal.
human_review_state	not needed, required, passed, failed, corrected, suppressed	Creates an audit trail.

Keep the raw field and the normalized field. If the team overwrites raw scope with a cleaned label, future reviewers cannot see whether the system took too much liberty. The raw value protects the team when a source changes, a manager questions a route, or a homeowner says the property record is wrong.

Normalization should also separate address matching from roof scoring. A fuzzy address match can make every later decision untrustworthy. Unit numbers, street suffixes, parcel splits, owner mailing addresses, corner lots, duplexes, new subdivisions, and post-disaster temporary records can all create bad joins. If the address match is not strong, the roof-age score should not matter yet.

Data Intake Board Before Scoring

The first board in the workflow should not be a lead board. It should be a data intake board. That distinction changes behavior. A lead board asks, "Who should we contact?" A data intake board asks, "Is this record clean enough to become a review candidate?"

Use one intake row per source import, portal search, owner document batch, vendor file, or CRM export. Do not merge everything into a single property score until the intake row is signed off. The intake board should show who pulled the data, when it was pulled, what source terms allow, which fields were mapped, which fields were rejected, and which reviewer accepted the source into the roof-age workflow.

Intake field	Required entry	Why it belongs before scoring
intake_owner	Named person or role.	Prevents orphaned imports with no accountable reviewer.
source_category	Company record, owner supplied, official local record, open-data feed, aggregate context, vendor inferred, or hold review.	Keeps strong and weak evidence separated.
source_access_method	Portal search, API, CSV export, owner upload, CRM export, manual file, vendor delivery.	Helps the team understand freshness, repeatability, and permission limits.
source_terms_checked	Yes, no, not available, or review needed.	Stops a useful file from being used beyond what the source allows.
retrieval_window	Date pulled and period covered.	Prevents old exports from looking current.
field_map_version	Version number or dated note.	Lets the team diagnose route quality when a field is later remapped.
rejected_fields	Columns dropped before scoring.	Creates proof that sensitive, irrelevant, or unclear fields were not quietly used.
join_key	Address, parcel, permit number, job number, owner-provided reference, or CRM record.	Shows how records were connected.
sample_review_count	Number of rows checked by a human before automation.	Forces a small quality test before volume.
release_for_scoring	Approved, limited, held, or rejected.	Keeps data intake separate from campaign approval.

The intake board should also record source-specific caveats in plain language. For example: "Chicago open-data permit scope uses broad categories; roof-related scoring requires manual review of description fields." Or: "County portal search by address misses parcel-level attachments; do not treat no result as no work." Those notes are more useful to a sales manager than a generic confidence score.

Before any daily route is built, run a small sample review. Pull twenty records from each source category that will influence the route. Check whether the address match is correct, whether scope labels are being normalized too aggressively, whether statuses are being overread, and whether rejected fields were actually dropped. If the sample exposes repeated errors, the source stays in intake. Do not let a high appointment target push a bad source into the field.

RoofPredict can support this by keeping intake states visible beside route states. A property should show whether it came from an approved source intake, a limited-use intake, a held intake, or a rejected import. That one label can prevent a common failure: a stale or questionable file gets mixed into a strong route and nobody remembers which records came from which source.

Aging Roof Opportunity Scorecard

The scorecard should reward stronger evidence and cap weaker evidence. A property should not jump into the top route simply because a public source did not show a recent roof permit. Missing data is not roof age. Ambiguous scope is not replacement timing. Aggregate data is not parcel proof.

Use a 100-point internal score, but make contact release a separate gate:

Factor	Points	Cap or hold rule
Clear roof-related permit older than local review threshold	0-22	Award only when scope is clearly roof-related and address match is exact or verified.
No documented recent roof permit in checked local source	0-12	Cap this factor; missing data never creates a top-tier route by itself.
Company has no recent roof job history	0-8	Use only inside your own records.
Owner-supplied or CRM note indicates roof-age review is appropriate	0-12	Use documented owner or internal records, not hearsay.
Property fits service area, crew capacity, and appointment logistics	0-12	Keep operational fit separate from condition assumptions.
Material, weather, or neighborhood age context supports review	0-12	Keep each source label separate; do not convert storm context into damage proof.
Source quality bonus	0-10	Award only when source, date, status, scope, confidence, and reviewer are recorded.
Recency of last manual review	0-6	Lower score if a recent review already suppressed or corrected the record.
Existing relationship or inbound interest	0-6	Prior relationship or inbound request can support prioritization when contact rules allow.
Contact release	Pass/Hold	No points. A strong score can still be blocked from outreach.

The system needs hard stops:

Condition	Action
Only signal is "no recent permit found."	Cap below high-priority route.
Scope is exterior, building, alteration, repair, or unknown.	Hold for manual review before roof-age points.
Permit is issued but not closed or finaled.	Do not infer completion.
Address match is fuzzy or mismatched.	Hold for cleanup.
Source is aggregate only.	Use for market planning, not property scoring.
Vendor field lacks source, retrieval date, or confidence.	Hold or score as low confidence.
Consumer-report, credit-derived, sensitive, or protected-class proxy data appears.	Hard quarantine before import, scoring, routing, or contact. Do not use it in this workflow unless counsel documents an FCRA permissible purpose for a separate lawful process.
Outreach channel is not released.	Keep out of campaign tools.

This design prevents two common failures. First, it stops thin public records from creating false certainty. Second, it gives sales managers a reasoned queue instead of a mystery score. A manager should be able to click a property and see the reason: "official local record, roof permit finaled in 2009, exact address match, no newer roof permit found in same source as of retrieval date, service-area fit, contact channel held until review."

Permit Record Review Checklist

No permit-history candidate should move from desk review to route review until the basic checklist is complete.

Review item	What to check	Pass condition
Jurisdiction	City, county, parish, township, state, or AHJ.	The source is named and local scope is understood.
Retrieval date	When the page, file, API, or export was checked.	The record is fresh enough for the campaign.
Address match	Street number, suffix, unit, ZIP, parcel, owner/site-address split.	Exact or manually verified.
Scope	Roof, re-roof, tear-off, overlay, repair, solar, structural, exterior, trade code.	Clear enough to score or held for review.
Status	Issued, pending, expired, completed, finaled, closed, cancelled, void, unknown.	Status is not overread.
Date type	Application, issue, expiration, final, close, last update.	The date used in scoring is identified.
Attachments	Plans, notes, inspection files, amendment documents.	Important attachments are checked when available.
Local rule	Whether roof work is recorded in expected fields.	Reviewer understands local caveats.
Score reason	Internal reason code.	Written as a record observation, not a roof conclusion.
External language	Script, email, ad, mailer, or door-knock note.	Does not mention permit findings unless approved.
Contact release	Channel rules, opt-out, consent, suppression, vendor terms.	Released only for the specific approved channel.

Make the checklist easy to complete, but do not make it optional. The goal is not to slow every route. The goal is to stop record mistakes before they become homeowner conversations.

Reason Codes And External Language

The internal reason code can be precise. The external message should be restrained. Public-record details often sound more aggressive to a homeowner than they feel to the office team.

Internal reason code	Better external language	Avoid
No documented recent roof permit in checked source.	"We help homeowners review roof age and maintenance timing."	"You have not replaced your roof."
Clear older roof-related permit found.	"Some homes in your area may be ready for a roof-age review."	"Your roof is overdue."
Ambiguous exterior permit.	"We can review visible roof concerns by appointment."	"The city record says your roof was only repaired."
Recent roof permit found.	Suppress, route to warranty/service review, or mark low priority.	"Your roof is fine."
Address mismatch.	Hold for cleanup.	Any homeowner outreach.
Owner corrected record.	Update, suppress, or reroute based on corrected information.	Arguing that the database is still right.
Storm context plus older permit context.	"We help homeowners check roof age, maintenance timing, and recent storm exposure."	"You have storm damage."

This split protects quality and reputation. A rep should not stand at a door and debate a homeowner about a city database. The office can use public records to choose where to spend review effort. The field conversation should stay respectful and observational.

If permit history is mentioned externally, it needs manager and compliance approval. In many markets the safer path is not to mention it at all. The homeowner usually cares less about how the company built the route and more about whether the inspection is useful, honest, and low pressure.

Contact Release Checklist

Public records can support prioritization. They do not clear contact. A property can score well and still be blocked from calling, texting, emailing, retargeting, or door knocking. Treat contact release as a gate, not a score factor.

Outreach path	Release question	Practical release rule
Email	Is it a commercial email? Are sender identity, subject line, physical address, opt-out, and third-party responsibilities handled?	Review FTC CAN-SPAM guidance, vendor settings, suppression lists, and state or platform requirements before sending.
Calls	Are TSR, DNC, FCC, consent, autodialer, prerecorded voice, vendor, state, local, and time-window rules addressed?	Hold until federal, state, vendor, and internal compliance review releases the list for the exact call method.
Texts	Is there documented consent for the exact text use case, plus opt-out handling, vendor controls, platform rules, and suppression?	Hold unless the full text program is approved. Consent language alone is not enough without suppression, vendor, platform, and legal review.
Door knocking	Are local solicitation, licensing, storm-response, emergency, no-solicitation, consumer-protection, cancellation, contract, and deposit rules reviewed?	Release by jurisdiction and campaign, not as a blanket permission. If in-home sales may occur, review cancellation notice and right-to-cancel requirements before the route.
Direct mail	Are claims supportable? Are lists cleaned for suppression and sensitive-use exclusions?	Often easier to control than calls/texts, but still needs claim and privacy review.
Paid search or social ads	Are targeting fields, custom audiences, claims, disclosures, and platform rules reviewed?	Keep targeting broad enough to avoid sensitive inferences and misleading property claims.
Retargeting	Was the audience built from lawful, permitted, and platform-compliant data?	Hold if source or consent is unclear.
Inbound follow-up	Did the homeowner request contact or submit information?	Use the stated channel and scope, and still honor opt-outs and consent limits.

The data-use question comes before the contact question. If the list uses consumer reports, credit-derived fields, sensitive personal data, protected-class proxies, or unclear identity data, the campaign should stop before channel review. Quarantine those fields outside the roof-age workflow. A phone-compliance review cannot fix a bad data source. An email opt-out link cannot fix a scoring model built on fields the roofing company should not be using.

Contact-Channel Release Matrix

A scored property should not move straight into campaign software. Create a channel matrix for every route batch. The matrix should answer three separate questions: is the data allowed in the workflow, is the message supportable, and is the specific channel approved? A route can pass the first two questions and still fail the third.

State	Meaning	Allowed action
data_intake_hold	Source, terms, fields, or provenance are not clean enough.	No scoring, routing, exporting, or outreach from that source.
score_only_hold	Data can be scored internally, but campaign use is not released.	Manager review, source QA, territory planning, and suppression cleanup only.
mail_claim_review	Direct mail is possible, but wording and list use need approval.	Draft mailer review, claim-support check, suppression check, and vendor check.
email_hold	Email is not approved for the route.	Do not export to email tools; review commercial-email requirements first.
call_hold	Calls are not approved for the route.	Do not export to dialers or call queues; review call method, DNC, consent, vendor, state, and time-window rules first.
text_hold	Texting is not approved for the route.	Do not export to SMS tools; require documented consent scope, opt-out handling, vendor controls, and platform review first.
door_hold	Door knocking is not approved for the route.	Do not assign to canvassers; review local solicitation, licensing, storm-response, cancellation, contract, and safety rules first.
approved_channel_limited	One channel is approved with limits.	Export only the approved fields to the approved channel for the approved campaign window.
suppressed	Owner correction, opt-out, wrong address, recent roof, or manager decision blocks use.	Exclude from route and keep suppression visible in future imports.

The matrix should also stop field leakage. If a route is approved for direct mail, that does not mean a rep can load the same records into a call campaign. If a homeowner submitted an inbound form, that does not mean the company can retarget the entire household with permit-history messaging. If a manager approves a door route in one city, that approval does not automatically travel to another city with different solicitation rules.

Exports should be narrow. A canvassing list might need property address, route order, approved talk track, manager note, suppression state, and appointment outcome fields. It probably does not need raw permit attachments, owner-uploaded private documents, vendor confidence notes, or historical rejected fields. A mail vendor might need address and approved creative. It does not need call notes or internal reason-code history. Narrow exports reduce misuse and make audits easier.

Use expiration dates. A contact approval should not last forever just because it existed once. Weather events, local emergency orders, solicitation rules, platform terms, opt-outs, and source freshness can change. Route batches should carry approved_channel, approved_by, approved_at, expires_at, and approved_message_version. If one of those fields is missing, the route should return to review.

This is where RoofPredict can make the workflow materially better. The system can display strong roof-age opportunity signals while still refusing to export a route when the contact-channel state is held. That is the difference between useful prioritization software and a risky list generator.

Protected-Class And Sensitive Proxy Exclusion

A roofing business does not need sensitive household signals to find aging roof opportunities. The useful inputs are roof-system context, permit-record context, property-record context, weather context, service-area fit, owner-supplied documents, and your own job history. The system should reject fields that make the program look like it is targeting people rather than roofs.

Exclude these from roof-age scoring. Any separate lawful use belongs outside this workflow and needs documented legal/privacy review before import, scoring, routing, or contact.

Field or proxy type	Why it should be excluded from the roof-age score
Homeowner age or age bands	"Aging" must refer to roof systems, not residents.
Household composition	Not needed to judge roof-review timing.
Income, wealth, credit, or ability-to-pay proxies	Creates targeting and consumer-report risk.
Ethnicity, race, language, religion, disability, health, or family status proxies	Not relevant to roof age and can create serious compliance and reputation risk.
Medical, financial hardship, disaster vulnerability, or insurance-claim vulnerability indicators	Can turn helpful outreach into exploitative targeting.
Consumer-report or credit-derived identity fields	Requires permissible-purpose analysis and should not be quietly blended into marketing scores.
Unclear consent fields from a vendor	Consent cannot be assumed from a label nobody has audited.

This exclusion list belongs in the data dictionary and the QA checklist. If a vendor sends a file with extra columns, the import should not accept everything by default. The workflow should map only approved fields and reject the rest.

Owner Document Privacy Rules

Owner-supplied documents can be useful, but they are not free-form sales fuel. A warranty, invoice, closing packet, insurance document, or inspection report can contain details the routing team does not need. Treat those files as homeowner-controlled records with a narrow purpose.

Rule	Required handling
Minimum necessary fields	Store only roof-relevant date, scope, source label, and confidence when that is enough.
Access control	Limit document access to the roles that need to verify the record.
No financial scoring	Do not score insurance payment, mortgage, claim, credit, or ability-to-pay details for roof-age routing.
Retention	Set a retention rule instead of keeping every uploaded file forever.
Deletion and correction	Give the office a way to mark documents corrected, stale, withdrawn, or deleted.
External language	Do not tell a homeowner that private documents prove a sales conclusion.

This keeps owner documents in the evidence lane. They can help resolve a roof-age question, but they should not become a hidden profile of the household.

The Route Workflow

Permit-history routes should move through stages. Each stage should have a clear owner and a clear reason to proceed or stop.

Stage	Owner	Output
Source ingest	Data or ops lead	Raw source file, source tier, retrieval date, field map.
Normalization	Data or ops lead	Cleaned scope, date type, status, address-match confidence, raw fields preserved.
First score	System or analyst	Internal score with caps, source labels, and hold flags.
Manager review	Sales manager or operations manager	Approved route, held route, suppressed property, or data-cleanup task.
Contact release	Compliance, owner, or assigned reviewer	Channel-specific release or hold.
Script review	Manager and compliance reviewer	Approved external language.
Field execution	Canvassing lead, estimator, or office team	Contact outcome, appointment, no answer, not interested, record corrected, suppression.
Post-contact QA	Manager	Rep notes, correction handling, script drift, complaint review.
Feedback loop	Ops lead	Scoring adjustments, suppression updates, source-quality notes.

Do not let one person bypass all stages because the list "looks good." The workflow does not have to be bureaucratic, but it does have to be inspectable. If a complaint, correction, or bad route appears, the team should be able to see which source, score, reviewer, channel release, and script created it.

Handling No Permit Found

"No permit found" is the riskiest useful signal in the workflow. It can identify records worth reviewing, but it is also the easiest signal to overstate. Missing records have many explanations.

Possible explanations include:

• the work happened before the searchable window;
• the work was recorded under a broad scope label;
• the jurisdiction did not require the expected permit for that work type;
• the work was recorded under a prior address, parcel, contractor, or owner;
• the public feed lags behind the permit portal;
• attachments contain the roof detail but the export does not;
• the roof work was part of a larger alteration permit;
• the owner has private documents that are more accurate than the public feed;
• the address match is wrong;
• the source search failed or used the wrong fields.

The safe internal language is:

Record state	Internal note
No record in one checked source	"No recent roof permit found in [source] as of [date]."
No record across multiple checked local sources	"No recent roof permit found in checked local sources as of [date]; not proof no work occurred."
Old clear roof permit found, no newer roof permit found	"Older roof-related permit found; no newer roof permit found in same checked source as of [date]."
Ambiguous record found	"Ambiguous permit scope; manual review required."
Homeowner disputes record	"Record corrected by owner; suppress or reroute pending manager review."

The unsafe language is:

Unsafe phrase	Why it fails
"Your roof has not been replaced."	Public records may be incomplete or misunderstood.
"The city says you are overdue."	A permit record does not set a replacement deadline.
"You do not have a valid roof permit."	That may be false, and it can sound like an accusation.
"Your roof is old because we could not find a permit."	Missing data is not age proof.
"We know your roof is damaged."	Permit history does not prove current damage.

Make the safer language a software constraint. If a route note contains blocked phrases, the system should flag it before it reaches a rep.

Homeowner Correction Workflow

The correction workflow is a quality signal. A team that handles corrections well can keep using public records without eroding trust.

When a homeowner says the record is wrong, the rep should not argue. The rep should say something simple: "Thanks for correcting that. I will update the note so we do not keep relying on the old record." Then the property should move into a correction state.

Use these states:

Correction state	Meaning	Next action
owner_says_recent_roof	Homeowner reports recent roof work.	Suppress from roof-age route unless owner requests service.
owner_has_documents	Homeowner offers invoice, warranty, or closing document.	Accept only through approved document channel; update source label if provided.
address_wrong	Record belongs to a different property or unit.	Hold and clean address mapping.
scope_wrong	Permit was not roof work or was misread.	Correct normalized scope and adjust scoring logic.
contact_not_wanted	Homeowner does not want contact.	Add suppression and honor channel-specific opt-out rules.
needs_manager_review	Correction is unclear.	Manager decides suppress, reroute, or request more context.

Corrections should feed model quality. If many homeowners say a local permit field is misleading, the team should lower that field's score weight or require manual review. If a dataset's address matching creates repeated wrong-property routes, the import should be paused. The goal is not to defend the list. The goal is to build a list that deserves trust.

Homeowner Correction And Suppression Playbook

Corrections need a playbook because the first response determines whether the company looks careful or careless. The rep should acknowledge the correction, stop debating the record, and move the property into the right state. The office should then update the source label, score, suppression record, and route history before the address appears in another campaign.

Use a three-part response:

1. Acknowledge: "Thank you for correcting that."
2. Narrow the purpose: "We use records only to decide whether a roof-age review may be useful."
3. Commit to cleanup: "I will mark the record so we do not keep relying on the old note."

Then choose the right operational state:

Situation	Rep action	Office action	Future routing
Homeowner says the roof was recently replaced.	Stop the roof-age pitch and ask whether they want any service follow-up.	Add owner_says_recent_roof, lower roof-age score, and suppress from age-based routes.	Service, warranty, or no-contact lane only, depending on homeowner preference.
Homeowner says the address is wrong.	End the record discussion and apologize for the mismatch.	Add address_wrong, pause the join key, and inspect parcel/unit mapping.	No route until address mapping is corrected and reviewed.
Homeowner says they are not the owner or decision-maker.	Do not ask for personal details beyond what the approved script allows.	Add wrong_party_or_role_unclear and review contact source.	Suppress from that channel unless a valid inbound or authorized contact path exists.
Homeowner asks how the property was selected.	Use the approved broad explanation, not raw database details unless approved.	Log transparency question and review script clarity.	Keep route only if language remains supportable.
Homeowner requests no further contact.	Confirm the request and stop the contact attempt.	Add suppression using the channel-specific process and visible global note where appropriate.	Exclude from future matching before exports.
Homeowner provides documents.	Direct them to the approved document channel; do not photograph or store files casually.	Apply minimization, access control, source labeling, and retention rules.	Update roof-age context only from approved document fields.
Homeowner disputes the sales claim, not the record.	Stop the claim and return to observational language.	Review script drift and retrain if needed.	Hold affected route if multiple disputes appear.

Suppression should outrank scoring. A property with a strong roof-age signal but a no-contact state is not a lead. A property with recent owner-corrected roof work is not an age-based candidate. A property with a wrong address match is not a route opportunity until the join is repaired. The system should make that obvious to the manager.

Review suppression before every export, not once a month. When the same address can enter through a city feed, a vendor file, a CRM import, and an owner document, suppressions must match across source paths. Use address normalization carefully, but do not let fuzzy matching override a homeowner correction. If an exact suppression match exists, the route should stop. If a likely match exists, the record should go to manager review instead of a rep.

Corrections can also improve the product. Track correction rate by jurisdiction, source, reason code, route owner, and script version. A high correction rate from one city feed may mean the scope mapping is wrong. A high wrong-address rate may mean parcel joins are failing. A high "how did you choose my home?" rate may mean the external language feels too targeted. Those signals should change the workflow before volume increases.

RoofPredict Field Design

RoofPredict should make the right behavior easier than the wrong behavior. The workflow should lead toward fields and review states that can be implemented without asking a rep to remember every source limit.

Recommended fields:

Field	Purpose
permit_source_tier	Shows whether the signal came from company record, owner document, local official record, open-data feed, aggregate source, vendor inference, or hold tier.
permit_source_name	Names the source, such as a city portal or internal CRM.
permit_source_url_or_reference	Lets a reviewer trace the source without relying on memory.
permit_retrieved_at	Records freshness.
permit_jurisdiction	Keeps local records local.
permit_scope_raw	Preserves original wording or code.
permit_scope_normalized	Supports repeatable scoring.
permit_status_raw	Preserves original status.
permit_date_type	Avoids mixing application, issue, final, and close dates.
address_match_confidence	Prevents bad joins from entering routes.
roof_age_signal_reason	Explains why the property is in the queue.
roof_age_signal_confidence	Shows verified, official, likely, ambiguous, stale, or unknown.
score_caps_applied	Shows which caps prevented overranking.
contact_release_state	Keeps channel release separate from property interest.
approved_channels	Limits release to email, call, text, mail, door, ad, or inbound as approved.
suppression_state	Records opt-outs, corrections, and do-not-contact states.
review_owner	Assigns accountability.
last_manager_reviewed_at	Prevents stale approvals.
public_language_approved	Blocks unapproved mention of permit history in scripts or content.

Recommended internal reason-code values:

Reason code	Use
older_clear_roof_permit	A clear roof-related permit exists and is older than the local review threshold.
no_recent_roof_permit_checked_source	No recent roof permit was found in the named checked source.
ambiguous_exterior_scope	A record may be related but is not clear enough to score automatically.
recent_roof_permit_found	The property should usually be suppressed or moved to a service/warranty context.
owner_supplied_roof_year	Owner or authorized party supplied a roof date or document.
company_job_history	Internal records show a prior job, inspection, bid, or service visit.
address_match_hold	Record does not cleanly match the target property.
data_use_hold	Data source or field requires privacy/legal review.
contact_release_hold	Channel release has not been approved.
correction_suppression	Homeowner or manager corrected the record.

These fields create concrete operational value. A weak permit-data workflow says "use public records for leads." A stronger RoofPredict workflow shows the data model, scoring caps, contact checks, and correction loop a roofing business can actually implement.

A 90-Minute Implementation Sprint

A roofing company can start with a small, controlled implementation before trying to build a large daily route program.

Minute 0-15: pick one jurisdiction

Choose one city or county where the team already works. Do not start with ten jurisdictions. Pick one source, one data owner, and one manager. Record the source URL, retrieval date, fields available, and known caveats.

Minute 15-30: map the fields

Create the raw-to-normalized field map. Identify scope, status, date type, address fields, parcel fields, contractor fields, and notes fields. Preserve raw text. Mark unknowns clearly.

Minute 30-45: create three reason codes

Start with only three:

• older_clear_roof_permit;
• no_recent_roof_permit_checked_source;
• ambiguous_scope_manual_review.

Do not add fine-grained scoring until the team can apply these three consistently.

Minute 45-60: score only twenty records

Score twenty properties manually. Look for confusing scope labels, address mismatches, stale records, and unclear status. If five or more records are confusing, the source is not ready for automation.

Minute 60-75: write one internal note and one external message

The internal note can include permit source, retrieval date, reason code, and confidence. The external message should avoid permit accusations. Use a roof-age review angle, not a record-surveillance angle.

Minute 75-90: decide the release state

Pick one channel or no channel. If call, text, email, ad targeting, retargeting, or door knocking is not cleared, the list stays in manager review. Direct mail may still need claim and privacy review. Inbound follow-up can use the homeowner's submitted channel and purpose, but opt-out and consent limits still apply.

The output of the sprint is not a huge campaign. It is a tested workflow with a source map, score reason, hold rules, and correction path.

Quality Metrics For The Program

Measure the workflow by quality, not only volume. A roofing company that creates 10,000 weak public-record leads can burn trust faster than it creates appointments. A smaller route built from source-labeled review candidates may produce fewer doors and better conversations.

Track these metrics:

Metric	Why it matters
Percent of records with named source and retrieval date	Shows traceability.
Percent of roof-age scores with exact or verified address match	Shows join quality.
Percent of records held for ambiguous scope	Shows whether the system is cautious enough.
Percent of routes released by channel	Prevents contact compliance from being assumed.
Correction rate by source	Identifies bad datasets or bad normalization.
Complaint rate by campaign and script	Shows whether language feels invasive or misleading.
Appointment rate by reason code	Shows which signals are useful without overstating them.
Suppression handling time	Shows whether opt-outs and corrections are respected quickly.
Rep script drift	Shows whether field language stays inside approved boundaries.
Manager override rate	Shows whether the scorecard is too aggressive or too timid.

These metrics also decide whether the workflow deserves to scale. If correction rates, complaint rates, address mismatches, or script drift rise, the team should pause the route and improve the source map before increasing volume.

How This Differs From A General Property Data List

A general property data program compares many inputs: ownership, parcel, structure, weather, roof age estimates, service area, past work, and inbound activity. Permit history is narrower. It deserves its own workflow because a permit record can look official while still being incomplete, local, delayed, ambiguous, or easy to overread.

Keep these lanes separate:

Lane	Owns	Does not own
Property data source list	Which sources exist, what each source can support, and how to label confidence.	A permit-specific scorecard or script-release workflow.
Permit-history workflow	How to read permit records, cap missing-record signals, handle corrections, and release routes.	Broad property-data strategy or every lead source.
Roof-age homeowner workflow	How an owner can collect records without climbing on the roof.	Contractor routing, sales release, or call/text compliance.
Roof-permit homeowner workflow	Why permits matter and what to ask a contractor or local office.	Contractor lead scoring or territory route design.

That separation reduces topic overlap and makes the content more useful. The permit-history workflow can go deep on source interpretation, scoring caps, and contact release without trying to become the entire property-data playbook.

Manager QA Before A Route Goes Live

The final review should be short enough that managers use it, but strict enough to catch the mistakes that create complaints. Treat it as a release checklist for each route, not a one-time policy note.

QA question	Pass standard
Can the manager name the source behind every high-score property?	Each route record has source tier, source name, retrieval date, and reason code.
Are any properties ranked high from missing permit data alone?	None. Missing-permit signals are capped and paired with other approved context.
Are ambiguous permit scopes blocked?	Exterior, building, alteration, repair, solar, and unknown scopes are manually reviewed before roof-age points.
Are old approvals being reused?	Contact release and manager review have current dates for the specific route and channel.
Does any external message accuse the homeowner?	No. Scripts avoid "you have not replaced your roof," "you are overdue," and similar claims.
Are opt-outs and corrections loaded before the route leaves the office?	Yes. Suppression state is checked after scoring and before field assignment.
Can reps explain the purpose without naming private-sounding records?	Yes. The approved talk track focuses on roof-age review, maintenance timing, storm exposure, or visible concerns.
Is RoofPredict positioned correctly?	Yes. It is the workflow and record system, not a permit verifier or legal authority.

The manager should also listen for script drift. A route can be clean in the software and still become risky if a rep turns a cautious internal reason code into a hard claim. Review a sample of call notes, door notes, and appointment notes from each route. If the notes show pressure language, permit accusations, or claims about damage, pause the route and retrain before scaling it.

One useful rule is the "homeowner newspaper test." If the exact sentence appeared in a local story about the company, would it sound fair and accurate? "We help homeowners review roof age and maintenance timing" is defensible. "We know from permit records that your roof is overdue" is not.

Quarterly Source Audit

Permit-history programs drift. Local portals change fields. Open-data exports lag or revise category names. Vendors add columns. Managers change scripts. A route that was careful in May can become sloppy by August if no one audits the source map.

Run a quarterly source audit before scaling into a new season, after any major storm period, and after any source or vendor change. The audit should be small enough to finish, but serious enough to catch errors before a daily route expands.

Audit item	Test	Failure response
Source availability	Can the reviewer still reach the named source and reproduce the search?	Mark source stale and stop new scoring until refreshed.
Field stability	Did scope, status, date, parcel, or address fields change names or meanings?	Freeze automation and update the field map version.
Status interpretation	Are issued, pending, expired, closed, and finaled statuses still handled separately?	Retrain reviewers and correct affected records.
Address matching	Do sampled records still match the target property, unit, and parcel?	Pause route generation from that source until joins are repaired.
Missing-record cap	Are "no recent permit found" records still capped below high priority?	Lower scores and review manager overrides.
Rejected fields	Are sensitive, consumer-report, unclear-consent, or protected-proxy fields still excluded?	Quarantine the import and document the cleanup before reuse.
Contact state	Are channel approvals current, campaign-specific, and not reused beyond expiration?	Stop exports and require renewed review.
Script language	Are reps using approved roof-age review wording?	Hold the route, retrain, and review recent notes.
Corrections	Are homeowner corrections and opt-outs suppressing future imports?	Repair suppression matching before the next export.
Product claims	Is RoofPredict still described as a workflow organizer, not a permit or legal authority?	Rewrite scripts, pages, and sales enablement.

Keep the audit record attached to the source, not buried in a meeting note. A future manager should be able to see the last audit date, sampled rows, failures found, changes made, and next review date. If the audit cannot be reproduced, it is not a control.

This audit also helps decide whether to increase volume. A route with low correction rates, clear source labels, clean address joins, and stable channel approvals can earn more daily capacity. A route with stale sources, script drift, and repeated corrections should shrink until the source map improves. Volume should follow quality evidence.

Permit-Record Claim Ledger

Permit records are useful because they can be official. They are risky for the same reason. A rep, manager, or marketer may treat the record as more complete than it is. Use a claim ledger before any permit-history signal leaves the internal workflow.

Claim	Source Needed	Allowed Wording	Blocked Wording
A roof-related permit exists	Local record with address or parcel match, scope, date, and status.	"A checked local record appears to show roof-related permit activity."	"The roof was replaced correctly."
No recent roof permit was found	Named source, retrieval date, checked period, and search method.	"No recent roof permit was found in the checked source as of the retrieval date."	"The roof has not been replaced."
Permit scope is roof-specific	Scope text, category, notes, contractor field, and reviewer interpretation where needed.	"The scope appears roof-related and should be reviewed before scoring."	"Every exterior or building permit is a roof permit."
Permit status is complete	Local status field and local meaning of final, closed, issued, expired, or pending.	"The record status is listed as [status] in the local source."	"The work passed all inspections everywhere."
Property may deserve review	Permit reason code plus other approved context such as relationship, roof age, or inbound request.	"This record is a review candidate."	"This homeowner is overdue."
Contact is allowed	Channel release, suppression check, script approval, and campaign state.	"This record is released for the named channel and message version."	"Public records mean we can call or text."
RoofPredict helped organize the workflow	Stored source, reason code, route state, correction, and follow-up record.	"RoofPredict organizes permit-history review records and release states."	"RoofPredict verifies permits or clears compliance."

The ledger should sit beside the scorecard. If the team cannot point to the source, retrieval date, status interpretation, allowed sentence, and blocked sentence, the route is not ready. The ledger also helps with training because it converts vague risk into concrete language choices.

Permit-history outreach should be especially careful with homeowner tone. A homeowner may not know whether a prior owner pulled a permit. A permit portal may be incomplete. A local record may describe a repair, overlay, exterior alteration, or project that included the roof only as one component. The company should sound like it is offering a review, not accusing the homeowner of neglect or noncompliance.

Route Release States

The release state should be more precise than "approved" or "not approved." A permit-history record can be approved for manager review, held from calls, released for mail, suppressed from all outbound channels, or routed only after the homeowner requests help.

Use these route states:

Route State	Meaning	Next Action
source_review	Source, retrieval date, scope, status, or address match is unclear.	Permit reviewer checks the record before scoring.
manager_review	Record can be reviewed internally, but no outreach channel is released.	Manager decides whether another source or relationship context is needed.
mail_ready	Direct mail version, suppression state, and claim language are approved for this campaign.	Export only mail-safe fields and approved message version.
inbound_only	The record may be used if the owner asks for help or submits documents.	Do not start outbound outreach from the permit signal.
relationship_followup	Prior customer or open account context supports follow-up through an approved channel.	Use relationship-specific wording, not permit-surveillance wording.
field_hold	Door route, door hanger, or canvassing is not approved.	Keep out of field tools until solicitation, script, and local review clear.
privacy_hold	Sensitive, restricted, consumer-report, vendor-provenance, or contact-permission issue exists.	Quarantine or review outside ordinary route generation.
suppress	Opt-out, recent roof, bad address, duplicate, outside service area, dispute, or correction blocks the route.	Exclude from campaign export.

These states protect the company from a common failure: a record leaves the office because someone sees a score but not the channel state. The route state should appear in every export and downstream task. If a field tool cannot display the state, the record should not be exported to that tool.

The route state should also expire. A source checked in March may not be current in September. A script approved for mail may not be approved for door knocking. A suppression check should run again before every export. Treat each route as a dated release, not a permanent permission slip.

Do not merge the route state into the score. A property can have a high roof-age priority and still be privacy_hold. Another property can have a moderate score and be relationship_followup because the homeowner asked for help. A third property can have weak permit evidence but be mail_ready after the message is rewritten around optional roof-age review. Keeping score and state separate lets managers make better decisions.

The export should show both fields:

Export Field	Example
permit_priority_score	64
reason_code	no_recent_roof_permit_checked_source
route_state	manager_review
channel_state	mail held, call held, text held, door held
release_expires	2026-06-30
review_owner	permit_source_manager

That small set of fields prevents downstream tools from treating a score as permission.

It also gives the office a fast audit path when a route is questioned: the manager can see why the record was scored, why it was held or released, which channel was named, and when the decision expires.

Correction Loop Example

Corrections are not edge cases. Homeowners will correct records, managers will find bad joins, and local sources will change. A good workflow handles corrections without embarrassment and without arguing.

Example:

Step	Event	Correct Response
1	A permit-history route includes a property because no recent roof permit was found in one source.	The internal reason code stays source-labeled and capped.
2	A mail piece or approved follow-up says the company can help review roof age and maintenance timing.	The message avoids saying the homeowner failed to replace the roof.
3	The homeowner replies with an invoice from three years ago.	The team thanks the homeowner, updates the record, and suppresses replacement outreach.
4	The office adds the invoice date, source type, correction date, and reviewer.	The score changes from aging-roof candidate to recent-roof record.
5	The route owner reviews whether other records from the same source have the same problem.	The source map or missing-record cap is adjusted if needed.
6	Future exports include the correction and suppression state.	The homeowner is not contacted again for the same mistaken reason.

The important part is step five. A correction is not only a customer-service event. It is model feedback. If one homeowner has a missing record because the portal excludes certain permits, other homeowners may have the same issue. If one address join failed because of unit numbers, the join rule should be reviewed. If one script felt accusatory, the message version should be rewritten before the route expands.

RoofPredict should make this loop visible: corrected source, old reason code, new reason code, suppression state, reviewer, and date. That record is more valuable than a one-time apology because it prevents repeat mistakes.

Source Limits

Each source should be used for what it can support, and no more.

Source	Good use	Do not use it for
U.S. Census Building Permits Survey	Market-level construction and permit activity context by geography.	Parcel-level roof history or a specific property conclusion.
NYC DOB building data tools	Example of official local building history, permits, jobs, filings, complaints, violations, and status.	National rules or roof-condition proof.
City of Chicago building permits dataset	Example of official local open permit records.	National standard or proof that work was completed correctly.
Local AHJ records	Stronger parcel-level permit context when current and interpreted locally.	Proof that all roof work appears in records.
Company job history	Known relationship, bid, inspection, service, repair, or replacement history.	Complete roof history across all contractors.
Owner-supplied documents	Useful roof-age context when supplied by the owner or authorized party.	Permission to contact through unrelated channels.
Vendor property data	Sorting support when source, date, and confidence are labeled.	Certainty about roof age, ownership, consent, or condition.
CFPB FCRA advisory opinion	Boundary caution for consumer-report use and permissible purpose.	Approval to use consumer reports for roofing marketing.
FTC advertising FAQ	Truthful, supportable advertising and disclosure discipline.	State or local solicitation clearance.
FTC CAN-SPAM guide	Commercial email boundary review.	Call, text, door, or ad-platform clearance.
FTC Telemarketing Sales Rule guide	Call, DNC, registry, and telemarketing boundary review.	Complete state, platform, vendor, TCPA, or legal clearance.
FTC Cooling-Off Rule page	Door-to-door or in-home sale cancellation boundary review.	State home-solicitation law, contract drafting, or deposit approval.
FCC robocalls and texts guide	Federal call/text risk awareness and consumer-protection context.	Complete TCPA, state, DNC, platform, vendor, or legal clearance.
RoofPredict	Ranked lists, source labels, routes, notes, review states, and follow-up workflow.	Permit authority, legal advice, privacy approval, contact compliance approval, or roof-condition proof.

FAQ

Does no permit mean a roof is old?

No. It means no relevant permit was found in the checked source, if that is true. The work may have been done before the searchable period, under a different scope label, by another jurisdiction, without a permit requirement, or outside the records checked.

Can Census permit data find specific aging roofs?

No. Census Building Permits Survey data is useful for market and geography context. It is not an address-level roof-permit search and should not be used as proof about a specific property.

What is the safest internal reason code for missing permit history?

Use a source-labeled note such as "no recent roof permit found in checked source as of the retrieval date." Do not turn that into "the roof has not been replaced" or "the homeowner is overdue."

Should a roofer mention permit history in outreach?

Usually only after manager and compliance review. Permit language can sound accusatory or invasive. Many teams should keep permit history as an internal prioritization reason and use homeowner-friendly wording about roof age, maintenance timing, or optional review.

Can permit history be combined with storm context?

Yes, but keep the source labels separate. An older documented roof permit plus recent storm context may justify review, but neither signal proves address-level damage or a replacement need.

Can a roofing company call or text every public-record candidate?

No. Public-record status does not clear calls or texts. Contact release needs its own review for federal, state, DNC, consent, vendor, platform, opt-out, and internal suppression rules.

What data should be excluded from roof-age scoring?

Exclude homeowner age, household composition, income, credit-derived fields, consumer-report fields, health, disability, language, ethnicity, and other sensitive or protected-class proxies from roof-age scoring. Any separate lawful use belongs outside this workflow and needs documented legal/privacy review.

What should the team do when a homeowner corrects the record?

Do not argue. Record the correction, suppress or reroute the property, update the source-confidence note, and feed the correction back into the scoring and source-quality review.

How can RoofPredict help with permit-history workflows?

RoofPredict can store source labels, reason codes, confidence levels, route owners, contact-release states, suppression states, manager notes, and follow-up outcomes. It should not be framed as verifying permits, clearing compliance, or proving roof condition.

How is this different from a general property-data source list?

A general property-data list compares many source types. This workflow is narrower: it shows how roofers should label permit records, cap missing-record signals, quarantine risky fields, release contact channels, and handle homeowner corrections.

What should happen before a permit-history record is released to a call, text, email, mail, ad, or door route?

The team should complete data intake, source labeling, field rejection, score caps, suppression matching, message review, and channel-specific approval first. A strong roof-age score should not be exported to any outreach tool until the exact channel, campaign, message version, approval owner, and expiration date are recorded.

How should a team handle a homeowner who says the permit record is wrong?

The rep should acknowledge the correction, stop debating the record, and move the property into the right correction or suppression state. The office should update the source label, score, address match, route history, and future exports so the same mistake does not keep reappearing.

What should a permit-record claim ledger include?

It should include the claim, source needed, allowed wording, and blocked wording. The ledger keeps missing-record signals, scope labels, completion status, contact release, and RoofPredict positioning from turning into unsupported claims.

What route state should a permit-history record use before outreach?

Use a specific state such as source review, manager review, mail ready, inbound only, relationship follow-up, field hold, privacy hold, or suppress. A generic approved status is too vague because one channel may be cleared while another remains blocked.

Should route approvals expire?

Yes. Source checks, suppression matches, message approvals, and channel decisions should be dated and rechecked before each campaign. A record that was reviewed months ago should not become permanent permission for new outreach.

Why are homeowner corrections important to the scoring model?

Corrections show where the source map, address join, score cap, script, or suppression rule may be weak. Record the correction, change the score or route state, and review whether similar records need the same fix.