Lookup data
Brand, model, serial, type, and fuel entries are processed to return the lookup. They are not stored in first-party usage metrics or intentionally added to optional third-party analytics. For model evidence, the server fetches the same bounded current ENERGY STAR Certified Water Heaters dataset and matches locally; it does not add the entered brand or model to the EPA request URL. The live CPSC request likewise retrieves the water-heater recall feed without adding the entered identifiers, then matches locally. EPA, CPSC, server, and hosting providers may retain ordinary network, security, and access logs under their own configured policies.
Rating-plate photo reading
If a person chooses a rating-plate photo, the browser may resize and convert it before sending it to a same-origin, rate-limited endpoint. The server sends the image to OpenAI solely to extract visible equipment identifiers and facts, requests a non-stored API response, returns the structured result, and does not write the image or extraction to the application database or usage metrics. The image and extracted text may still be processed or retained by the browser, hosting provider, network, and OpenAI under their respective security, abuse-prevention, account, and data-control policies. Photo reading is optional; the person can enter identifiers manually and should review every extracted character before running a lookup.
Read-only agent service plans
The REST service-plan endpoint and MCP planning tool combine the same equipment lookup with optional exact-ZIP provider discovery. Their strict input accepts equipment identifiers, optional type and fuel, an optional exact ZIP, and an optional bounded service category; every unexpected field is rejected, including name, email, and phone. The call creates no handoff, service request, or provider contact. Its constituent lookup and provider-search outcomes may add the same low-cardinality aggregate counts described below. One additional service-plan bucket records only the technical surface and one final bounded navigation outcome: recall review, official-source limitation, current-provider review, no current directory provider, or exact ZIP needed. That planner bucket contains no model, serial, ZIP, contact field, or provider identity. If a ZIP matches an operator-configured launch market, only that configured market ID may enter the separate aggregate demand bucket. The calling assistant, platform, server, hosting provider, and security provider may retain their own request or response records under their respective policies.
Public provider references
Each public provider entity includes an opaque version derived only from its public representation. The eligible provider's public profile also includes linked ProfilePage and Organization structured data made from that same public projection: business name, public customer phone, optional official website, exact service ZIPs, public capability labels, and the latest public review date. Exact ZIPs describe the provider's stated service area; they are not a business or technician location. Neither representation contains a private application contact, license number, operator note, evidence record, billing detail, secret, physical business address, precise location, rating, price, or business hours. REST directory and provider-record responses permit storage only in a private client cache, require revalidation before reuse, and expose a weak ETag. A client may return that value in If-None-Match; the server still rechecks current eligibility. An unchanged current representation returns an empty HTTP 304 response with a new validation time. A provider that is no longer current returns 404 instead of preserving access through an older validator. Exact-ZIP query URLs and responses are not marked for shared-cache storage. MCP provider resources remain zero-TTL. Client, agent, browser, hosting, network, and security providers may retain their own request URLs, headers, cached responses, or logs under their respective policies.
Public provider-coverage state
An exact-ZIP directory search compares the current eligible result count with the server-side launch-market plan and returns only current-matches, network-building, or outside-active-market; a combined service plan without an exact ZIP returns not-run. Current matches take precedence. Network building means only that the ZIP belongs to an onboarding, invite-only, or live market. The public response contains no market name or ID, internal market status, provider target, readiness threshold, demand count, gap, prospect, or private sourcing record. The comparison creates no additional record or metric. For an exact-ZIP result, the provider-application URL repeats only that already-supplied ZIP in a URL fragment. A browser does not send the fragment in its HTTP request; the application removes it from the address bar before any invitation check and treats it only as an editable draft. Opening the link creates no application, provider attribution, or additional market-demand record. A verified private prospect invitation overrides the public draft. The existing market-demand aggregate, when applicable, retains only the selected configured market ID and low-cardinality result as described under Analytics—not the searched ZIP. Browsers, agents, chat histories, hosting systems, and link recipients may separately retain the complete URL or copied value under their own controls.
Official-source status
The public source-status page, REST endpoint, and MCP resource send fixed, non-user-specific availability probes to the ENERGY STAR water-heater dataset and CPSC water-heater recall service. They accept no lookup input and do not add a model, serial, ZIP, contact, provider, or visitor identifier to either upstream URL. The report is cached for five minutes and creates no first-party history or availability metric. EPA, CPSC, server, hosting, and monitoring providers may retain ordinary network, security, and access logs under their own configured policies.
Service operating status
The public status page, REST endpoint, and MCP resource also expose fixed low-cardinality states for the application response, official sources, durable record-table readability, service-intake control, scheduled notification and provider-lifecycle work, and paid-provider billing configuration. The report accepts no input and contains no configuration values, database address, private record, provider or customer data, event identifier, or processing volume. Each scheduled worker keeps only its current worker name, first and latest successful check times, and a bounded succeeded/degraded result; later checks replace that worker heartbeat rather than creating an activity log. Hosting, upstream, and monitoring providers may retain ordinary access and security logs.
Service-capability status
The public REST report and MCP resource describe whether each read or write interface is enabled in the deployed application and whether new service intake is operationally paused. They expose only low-cardinality action state, interface, confirmation, data-consequence, alternative, limitation, generic intake source, and update-time fields. They do not return configuration keys or values, database addresses, private provider records, contact details, visitor input, pause reasons, operator notes, or a first-party capability history. The report refreshes on a 30-second interval. Production write enablement requires the expected shape for durable storage, a separately initialized managed schema, traffic controls, and retry safety; production runtime code does not create tables or indexes. Configuration enablement does not test actual schema or grants, database connectivity, or establish provider coverage, legal approval, email delivery, billing, operator response, or production launch readiness; an unreadable intake control fails closed. Hosting providers may retain ordinary network, security, and access logs under their own configured policies.
Portable lookup reports
After a lookup, the user may copy a plain-text evidence report to the device clipboard or open the browser's print dialog, which may save a local PDF. The portable report contains the equipment label or unresolved state, manufacture-date interpretation, recall status and check time, candidate and source links, next actions, and limitations. It intentionally omits the entered serial number and creates no new server record. The browser, operating system, clipboard manager, print service, or destination chosen by the user may retain the resulting copy under its own controls.
Abuse prevention
Lookup, agent, application, request, consumer-outcome, provider-correction, public provider-action, consumer/provider-access, and operator-login routes apply request limits. A trusted hosting-network address is transformed with a keyed one-way HMAC before a counter is stored; the application does not place the raw address in its rate-limit table or in-process bucket keys. Production counters expire after their fixed window. Hosting and security providers may separately retain ordinary access logs under their own policies.
Retry safety
Provider applications, service handoffs, service requests, and provider corrections require a client-generated retry key. The raw key is not stored. A dedicated secret transforms the key, action, and validated input into an opaque record identifier and non-reversible payload fingerprint retained as private technical metadata with that record. This lets an unchanged retry return the original receipt without duplicating a record or operational notification, while changed input under the same key is rejected. Handoff and consumer-status tokens are reproduced only for exact receipt replay; the database continues to retain only their one-way hashes. The calling browser, agent, platform, hosting provider, or ordinary network log may separately retain request headers or responses under its own controls.
Provider plan-fit worksheet
The public worksheet processes the provider's exact ZIP count, contribution margin, and close-rate scenario entirely in the browser. The application makes no request, creates no first-party record, and sends none of the inputs or calculated results to first-party analytics. The fields are cleared by the user or normal browser-page lifecycle rather than retained by Water Heater Lookup. Copying writes a plain-text scenario to the user-controlled clipboard; the browser, operating system, clipboard manager, or destination chosen by the user may retain that copy under its own controls.
Provider application coverage preflight
While the provider edits service ZIPs or switches the selected plan, the application form counts unique exact five-digit ZIPs and identifies malformed or repeated entries in the browser. A valid coverage_zip fragment from provider discovery may add one ZIP to that editable draft; malformed fragments are ignored, and a verified private invitation controls its own prefill. The fragment is removed before any invitation request. That draft review and fragment restoration create no separate request, first-party record, provider attribution, or analytics event. Malformed, empty, and over-limit lists are stopped locally. When the provider deliberately submits a passing complete application, the unique valid ZIP list and selected plan become part of the private provider application record described below; the preflight does not create a separate copy.
Provider application status lookup
Checking application status sends the random application reference and private review email in a same-origin POST body for comparison with the existing application. Neither value is placed in the page URL or sent to optional analytics. A reference carried from the application receipt uses a URL fragment, is copied into the local form, and is removed from browser history before any lookup; opening that fragment alone sends no request. A successful match returns only coarse progress, selected plan, server-owned submission and update dates, and one accountable next step. It does not return business or contact details, license or coverage information, operator notes, evidence records, billing identifiers, commercial history, portal tokens, or private links. A lookup attempt creates no separate application, status, analytics, notification, access, billing, qualification, ranking, or routing record. Rate-limit counters retain only the existing one-way network identifier described below.
Private provider-application triage
The authenticated operator dashboard derives one private next-review action for each applied, verification-stage, or rejected provider record from its existing status, exact-match identity review, pending profile changes, separate public-phone field, and current structured license and insurance evidence. Exact state/license and evidence conflicts appear before other work; profile/public-contact gaps precede missing current license and insurance evidence; a complete input set ends in a human approval decision, never automatic approval. Email-only matches remain warnings rather than automatic blockers. Equal-priority records are oldest first. Loading, filtering, or following an in-page link creates no additional record, request, message, reminder, status change, evidence event, profile update, qualification decision, access, payment, ranking, routing, or public disclosure. The linked application row and its existing controls remain authoritative.
Provider sourcing
The private operator pipeline may store researched business names, markets, business contact information, websites, license references, source-specific evidence records containing a name, link, category, check date, claim, limitation, and supported ZIP/brand/service/fuel dimensions, capability notes, outreach stage, follow-up dates, private notes, do-not-contact status, invitation issue/expiry/revocation dates, and the resulting application reference when a private invitation is used. Each explicitly logged conversation adds an append-only private record with a server-created identifier and time, bounded channel and contact role, bounded outcome, required concise note, and optional follow-up date. A connected or interested owner/manager record may additionally contain one bounded snapshot of exact ZIPs, brands, services, fuels or technologies, and lead-capacity status directly stated in that conversation. A later snapshot preserves the earlier record but becomes the complete latest statement; omitted fields are not inherited from research or an earlier conversation. A decline, no-contact request, or not-a-fit outcome closes later outreach in the application; logging the outcome sends no message and grants no contact permission, qualification, publication, coverage, readiness, or commercial access. Source categories distinguish government license registries, manufacturer directories, utility/program directories, trade associations, business websites, and other public sources; none automatically establishes licensing, insurance, capability, quality, availability, or willingness to participate. Marking all listed sources rechecked updates their private check dates only after the operator reviews every listed source; it performs no remote verification. After a direct pricing conversation, the operator may append one low-cardinality signal, its server timestamp, and the exact Core and Network monthly hypotheses presented. Earlier records are retained when another conversation is added. The structured pricing signal stores no quoted budget, transcript, free-text answer, promised purchase, or inferred willingness to pay. These records are private operator research, not public provider claims, market estimates, conversions, or revenue forecasts. A private first-market panel derives a rolling 30-day acquisition view from these existing records and stores nothing additional. It counts each organization at most once toward a 15-conversation target and only for an owner/manager record with a connected, interested, declined, do-not-contact, or not-a-fit outcome inside the window. Repeated conversations, no response, wrong contact, other roles, stale records, and future records do not count. Current-price interview counts additionally require the latest stored anchors to match the current hypotheses. A separate direct-capability hypothesis uses only each organization's latest nonfuture owner/manager snapshot within 90 days, an accepting or limited capacity statement, and a sourcing path that has not declined or closed. It requires every exact ZIP, brand, service, and fuel dimension for each counted cell; five candidate organizations and two candidates in all proposed cells still do not establish license, insurance, quality, availability, application, qualification, commercial access, public coverage, market readiness, or routing. An attributed application may retain its earlier sourcing snapshot without becoming verified coverage. Direct snapshots remain private and never enter public pages, REST, MCP, invitation prefill, provider profiles, ranking, or matching. A business phone or work email remains a research path, not contact authority; the panel does not send, schedule, authorize, qualify, invite, publish, bill, route, or predict conversion or willingness to pay.
The sourcing queue's relationship search runs only against the already loaded selected operator view. It can compare the entered terms with private identity, contact, license, research, exact-ZIP/capability, conversation-note, direct-capability, and pricing-signal fields, but the search text remains browser state and is not sent, logged, stored, measured, or used for qualification, ranking, coverage, invitation, publication, billing, or routing.
The dashboard may compare private prospect research with configured launch-market gaps. A bundled candidate count requires a nonterminal prospect, exact ZIP and capability support across its source records, and every listed source to be dated within 90 UTC days. Stale, undated, or future-dated bundles remain separate. Candidate counts never reduce verified coverage, unlock a market, or enter provider ranking, public pages, REST, or MCP. An authenticated operator may download a JSON or CSV research brief containing every uncovered configured cell, current verified counts, shortfalls, aggregate current/stale prospect counts, a research priority, source-category limitations, and a required return contract. This brief contains no prospect or provider name, contact, license, source URL, evidence note, private note, customer data, or demand record. It permits public-source research only and does not authorize an assistant or researcher to contact or invite a business, qualify or publish a prospect, alter readiness, or perform billing or commercial actions. One prospect may match several cells, so its counts are not unique available providers or predicted coverage.
Operators may process returned research fields through a preview-first CSV import and download a separate private no-store pipeline research snapshot containing prospect research data, source-specific evidence encoded in research_evidence_json, and encoded append-only pricing history; the durable application store remains authoritative for conversation and direct-capability history. A separate authenticated versioned JSON relationship archive preserves current operator-visible research, private business contact, notes, outreach events, direct-capability snapshots, pricing interviews, invitation issue/expiry/revocation metadata, and application attribution. The archive excludes the stored invitation hash and every raw invitation link. Generating either export writes no application record or message and changes no prospect, invitation, qualification, market, provider, billing, ranking, or routing state. The relationship archive is a private point-in-time portability copy—not a re-import contract, database restore, proof of backup success, retention action, or replacement for the durable store and independently tested production backups. Spreadsheet-active prefixes are neutralized in the CSV export, but every downloaded file must still be protected. A private application invitation stores only a hash of its 256-bit token; the raw token is placed in a URL fragment, removed from browser history after opening, replaced or revoked by a later operator action, and consumed when a linked application is accepted. A valid link may prefill the prospect's business contact, website, license reference, and target ZIPs but never returns source classification, capability research, direct-capability snapshots, evidence notes, pricing history, conversation history, or operator notes. Prospect records are not published, treated as verified, contacted automatically, or included in provider matching. Before live outreach, the operator must establish a lawful sourcing and contact policy for the applicable jurisdiction.
For an unscheduled research-stage prospect, the dashboard derives one next research action from four private facts: whether every listed source check is current within 90 UTC days; whether named evidence supports at least one exact ZIP, brand, service, and fuel or technology; whether a government license-registry source is present for identity review; and whether a public business phone or work email is recorded privately. The checklist performs no remote lookup or write. Four recorded checks mean only that the packet is ready for an operator research review; they do not qualify, verify, insure, contact, authorize contact, publish, route leads to, bill, or activate the business.
The operator may copy a versioned AI verification research queue from the currently visible private sourcing lane. It includes only active pre-application records and, for each task, an opaque prospect reference plus normalized business name, license state, and license number marked as untrusted search keys, fixed Illinois or Texas source paths when mapped, an empty-source authority-finding fallback otherwise, source limitations, and a human-review return contract. Applied or linked records and declined, do-not-contact, or disqualified paths are excluded. The copy omits contact names, email, phone, website, market, exact ZIP and capability/source research, notes, outreach and direct statements, pricing, invitations, applications, providers, customers, requests, and billing. It is derived from records already loaded in the browser; copying makes no request, analytics event, or application write. The browser, operating system, clipboard manager, AI service, researcher, or destination chosen by the operator may retain the copied JSON under its own controls. The queue authorizes no contact, access-challenge solving, account creation, form submission, terms acceptance, qualification, invitation, publication, billing, or routing, and returned material is not evidence until the operator independently reviews it.
Portable provider conversation brief. The private acquisition panel may derive a copyable conversation aid from trailing-30-day planner outcome aggregates, the first-market experiment totals, the public Core and Network price hypotheses and feature boundaries, and the current deterministic evidence milestone. It includes a fixed owner/manager question set and explicit non-claims. It contains no prospect name or identifier, contact, research source or note, conversation note, customer data, request detail, service-ZIP history, license or insurance evidence, invitation token, or billing identifier. Zero measured planner activity is stated as zero and instructs the operator not to claim agent adoption, traffic, provider demand, or lead volume. Copying writes only to the device clipboard, stores no report, sends no message, creates no invitation or application, and grants no outreach, qualification, publication, billing, or routing authority. The operator must confirm lawful contact authority outside the application before using it.
First-market cohort conversion. The authenticated acquisition panel may join a first-market prospect to a provider application only when the prospect's application ID and exactly one provider's source-prospect ID agree. One-sided, missing, or duplicate relationships remain private linkage exceptions and do not count. A linked provider counts as activated only while the existing public-eligibility rule says it is active, accepting leads, explicitly public-contactable, currently qualified, profile-confirmed within 90 days, and covered by current paid or time-bounded founding access. Paid and founding activated counts remain separate, and founding access is excluded from paid MRR. This read-only projection stores no additional record, sends no message, and changes no application, provider, qualification, commercial access, ranking, routing, or launch-market state. It does not establish that outreach caused conversion, revenue, provider quality, future retention, redundant coverage, or market readiness.
First-market value-response cohort. The authenticated acquisition panel may derive a response denominator only from bidirectionally linked first-market providers that are currently public-eligible. A response enters the current numerator only when it is that provider's latest event within 45 days and matches the current plan, centralized price, and fixed 30-day review period. Paid and founding responses remain separate. Prior-plan or stale events for a currently activated provider and any event for a linked provider that is no longer public-eligible remain separate private counts instead of disappearing or counting as current evidence. The projection stores no cohort record or report copy and changes no provider, billing, commercial access, qualification, eligibility, ranking, routing, or market state. These are explicit provider statements, not renewals, churn predictions, revenue, ROI, causal attribution, future retention, pricing instructions, or market willingness-to-pay evidence.
Provider identity screening
Each valid provider application remains a separate private record, even when it uses the same email or license text as another application. The public receipt never says whether a match exists. In the authenticated operator dashboard, the service normalizes application email by case and surrounding space and normalizes state/license identity by case, spacing, and punctuation. Exact email reuse is a review warning, not an automatic decision. A reliable exact state/license match prevents a second record from receiving current approval, activation, a new portal link, founding access, checkout, or Stripe activation until an operator resolves the records. Common placeholder license text is excluded from the automatic ownership gate and remains subject to manual review. The service does not fuzzy-match business names or automatically merge applications, terms receipts, verification evidence, contacts, billing identifiers, or commercial histories. Match evidence and conflicting private record identifiers are available only to the authenticated operator; public profiles, REST, MCP, application receipts, and provider-search results do not expose them.
Provider applications, public profiles, and portal
We store business and contact details, license information, capabilities, service area, the insurance-attestation time, a history of accepted provider-terms versions, permanent document paths, and acceptance times, plan preference, operator notes, verification status, profile-confirmation date, commercial-access mode and term, portal authorization version, profile-change requests, Stripe customer/subscription identifiers, current billing-period date, cancellation flag, last processed Stripe event metadata, and a private commercial transition history to evaluate and operate the provider network. Qualification review also stores append-only private license and insurance evidence events: category, bounded outcome and source category, concise evidence reference, optional HTTPS source URL, evidence-validity date when current, required operator note, and server-owned event ID and check time. Operators must not enter credentials, full policy numbers, customer data, or unnecessary personal information. The newest event for each category controls and a negative or expired result supersedes earlier positive evidence. Evidence remains current for no more than 365 days and never beyond its validity date. The provider portal receives only whether license and insurance evidence is current and the next review date; it does not receive evidence references, links, or notes. The attestation and terms record is visible to the applicant in the submission receipt and later private provider portal, and to the authenticated operator; it is not public and does not substitute for evidence review or final legal terms. The private operator view applies an ordered rule to this existing billing, access, qualification, lead-response, and aggregate value evidence to identify one next account action; it does not create a churn score or automated account decision. Operators and providers may copy a 30-day aggregate value review into their own clipboard. The application does not store another copy, and the review excludes customer contact, request details, service ZIPs, license number, private profile evidence, job price, revenue, and inferred return on investment. Current public profiles expose the business name, business phone and website, license state, brands, services, fuels, exact service ZIPs, radius, after-hours flag, and verification and confirmation dates. They do not publish contact-person names, application emails, license numbers, insurance or attestation records, evidence events, evidence references, evidence source links, operator notes, terms acceptances, commercial terms, billing details, or commercial history. MCP provider-resource reads expose the same public record plus freshness and ranking guidance, do not create another provider record, cannot enumerate provider IDs, and return nothing after the provider ceases to be current. A first-party phone or website link activation may add one daily aggregate action for the current provider; it does not store the visitor, destination, page, ZIP, or session and is not treated as a confirmed call, website arrival, lead, hire, or revenue. Raw single-use portal tokens are not stored. Portal and access routes do not load optional analytics.
Private provider-status history. An actual status change stores a server-created identifier and time, prior and new status, a bounded source and reason, and—when staff initiate it—a required 10–500 character private decision note. Verification, commercial-access, Stripe, reconciliation, and scheduled lifecycle changes use bounded system reasons and do not accept free-form system notes. Repeating the current status creates no event. The provider record retains only its latest 100 status events. Operators must not enter customer data, payment data, secrets, raw evidence documents, or unnecessary personal information in a decision note. This history is visible only to an authenticated operator and is excluded from applicant status, provider portal, public pages, REST, MCP, sitemap, notifications, exports, and value-review output.
Provider lifecycle and closure checks. The operator interface and server allow only defined next status stages. Before closing an approved or paused account, the server reads the provider's commercial state, current checkout attempts, and private service assignments to confirm there is no founding access, pending/active/past-due subscription, unexpired creating/open checkout, or unresolved assignment without a closed request or explicit consumer outcome. An active account must pause routing first. The count and blocker explanation remain inside the authenticated operator workflow and are not returned through applicant, provider, public, REST, or MCP views. Closing an account invalidates provider access but retains the application, terms, evidence, commercial, lifecycle, assignment, and outcome records under the applicable retention policy; it does not contact the provider or perform Stripe, founding-access, or service-work actions automatically.
Post-value-review provider responses. After an approved, active, or paused provider with current paid or time-bounded founding access has seen its privacy-bounded 30-day value review, the authenticated operator may append one coarse response. The server records an event ID and time plus the provider's current Core or Network plan, centralized monthly price, and the fixed 30-day review period. Repeated responses append rather than overwrite. The dashboard treats only the latest event within 45 days at the current plan and price as current; the 45-day period is an operator follow-up heuristic, not a contract term or statistical claim. The event stores no report copy, metric snapshot, transcript, quoted budget, free text, customer or request data, job price, revenue, satisfaction, or ROI. A response is not a renewal commitment, churn prediction, market willingness-to-pay estimate, pricing instruction, or automated decision. Recording it sends no message and changes no Stripe, commercial access, qualification, eligibility, ranking, or routing state.
Provider contact roles. A provider application stores a private review email and private review phone for application, account, and operator communications, plus a separately entered public customer-facing phone. A private invitation may prefill only the private review phone. Older stored phone values migrate to the private review role only and are never copied into the public role. Approval, checkout, activation, public discovery, and routing remain unavailable until the provider deliberately confirms a public phone. Website, REST, MCP, and private consumer status views may return only that public phone; they never fall back to the private review phone.
Provider activation path. The private portal derives six current/not-current gates and one accountable next step from the provider's existing public-contact, qualification, approval, commercial-access, profile-confirmation, capacity, pause, and public-eligibility fields. It stores no score or additional history, sends no notification, changes no account state, and loads no optional analytics. A complete path does not guarantee search appearance, lead volume, a hire, revenue, workmanship, or return on subscription spend.
Provider lead queue. The private portal sorts only that provider's assigned requests into needs-action, in-progress, closed, and all views from the recorded assignment and current consumer outcome. Accepted requests without recorded contact appear before undecided sent or viewed requests; contacted work remains in progress; declined, closed, or consumer-reported work remains available as history. A consumer outcome changes only the displayed queue classification and does not rewrite an assignment. Opening the portal may record a newly delivered assignment as viewed. Changing a filter sends no message, changes no lead status, infers no hire, and affects neither billing, qualification, ranking, nor later matching. Accept, decline, contact, and closure remain separate provider actions.
Managed-provider queue. The authenticated operator view sorts approved, active, and paused accounts from each account's existing highest-priority billing, access, qualification, lead-response, current provider-stated value, acquisition-evidence, or monitoring action. Urgent and due-soon accounts appear in review now; routine monitoring and acquisition review remain separate. Applied, verification-stage, and rejected records remain in the application workflow. Filtering stores nothing, sends no message, and changes no provider, subscription, qualification, lead, coverage, outreach, ranking, or billing record. A next-workspace link changes only the page position; provider controls, service-request actions, and marketplace decisions remain separate explicit operator actions.
Private commercial operations snapshot. An authenticated operator may download the current managed-provider queue as JSON or CSV. The file includes provider ID and business name; coarse lifecycle, plan, billing, access, capacity, and public-eligibility facts; ZIP count without the exact ZIPs; freshness dates; the derived next action; listed plan price and modeled current paid MRR; latest coarse value-response status; and provider-level aggregate discovery, profile-action, assignment, response, outcome, and timing measures. It excludes private provider contact, exact service areas, license number and evidence records, Stripe customer/subscription/price identifiers, operator notes, customer or request records, and private decline detail. The response is authenticated, private, non-indexed, and not stored by shared caches, but the browser, operating system, spreadsheet software, or destination selected by the operator may retain the downloaded file. Generating it writes nothing and performs no Stripe reconciliation, account action, accounting recognition, retention-policy action, backup, or restore.
Private commercial transition archive. A separate authenticated JSON or CSV download projects every stored commercial transition, including history for providers that are no longer current. It includes provider ID, current business name at export, server event ID and times, bounded event source and kind, and the resulting billing, access, provider, plan-verification, period-end, and cancellation states. It excludes event notes and summaries, external Stripe event identifiers, private reconciliation identifiers, contacts, exact service areas, qualification evidence, checkout data, operator notes, and customer/request data. The response is private, non-indexed, and not stored by shared caches; the operator-selected browser, operating system, spreadsheet, or destination may retain the file. The current business name is an export-time locator, not historical-name proof. Downloading writes nothing and performs no Stripe retrieval or reconciliation, accounting recognition, retention execution, re-import, backup, or restore.
Provider profile corrections
A correction request stores the provider, requester's name and email, relationship, category, description, consent, queue status, review and closure dates, optional operator notes, and up to 20 newest-first status events containing a server ID/time, prior and new status, bounded reason, and optional decision note. It remains private and does not edit a public profile automatically. The operator uses an internal 48-calendar-hour triage target and a seven-calendar-day resolution target after review begins; these are not guaranteed response times. A new request may enter review, a reviewing request may be resolved or dismissed with an evidence-based note, and a closed request is terminal. Correction notifications omit requester identity, email, and free text. Before launch, the operator must staff the monitored correction channel, verify response ownership, adopt a retention policy, and record current launch evidence for those procedures.
Service requests
An agent may prepare a seven-day service handoff without supplying homeowner contact details. Before submission, the server stores only an opaque handoff ID, a one-way hash of the 256-bit handoff token, a private HMAC retry fingerprint, creation and expiry timestamps, and whether MCP or REST prepared it. The non-contact equipment and service context remains in the URL fragment, is not sent with the initial page request, and is removed from browser history before verification. The calling assistant or platform necessarily receives the supplied context and private handoff link and may retain them under its own privacy policy. If the person reviews the context, enters contact details, and consents, the handoff is consumed atomically with the request and the request records its agent-handoff source. Expired, used, invalid, or operationally paused handoffs store no new request; an exact completed retry with the original key may return the first receipt, and the person may otherwise submit directly when intake is open.
For a submitted request, we store the supplied equipment context, need, ZIP code, name, email, optional phone and notes, consent record, technical request origin, status, provider assignments, and an authorization version for private consumer access. Contact details are visible only to the operator and eligible providers assigned to that request. When more than three providers qualify, a one-way request-specific order derived from the server-owned request ID and public provider IDs selects the initial three; an exact retry keeps the same selection. Plan, payment, business name, public directory position, aggregate appearances, and profile actions are not inputs. The order creates no separate score or ranking record and does not guarantee equal distribution, provider response, availability, quality, lead volume, or a hire. Provider assignment events may retain sent, view, acceptance, contact, decline, and closure timestamps to operate matching and measure response times. A decline may also retain one bounded provider-entered category and an optional private detail; the other category requires a detail, while older reason-only records remain legacy-unclassified. Provider and operator account views and copied value reviews may aggregate category counts, but exclude private detail. The assigned provider's private Network lead export includes both fields, while operational notifications include neither. A decline category is operational feedback, not a verified customer fact, provider-quality score, public ranking input, or automatic profile, eligibility, routing, or future-matching change. A one-time consumer status token is stored only as a hash, exchanged from a URL fragment for an HttpOnly same-site session, and then removed from browser history. Request handoff, access, and status pages do not load optional analytics.
The authenticated operator dashboard derives one private request-review state from existing assignment status and times, the count of current eligible providers not already assigned, and the latest explicit consumer outcome. Its 24-hour provider-decision and seven-day consumer-outcome points are operator review thresholds, not delivery guarantees. Merely loading or filtering this queue creates no history, message, reminder, private link, assignment, request or provider update, inferred hire, qualification change, or commercial access. A provider assignment or replacement consumer-status link remains a separate explicit action.
The operator may pause new handoffs and requests with a bounded private reason and required free-text note. Every pause and reopen event stores its server date, status, bounded reason when paused, and operator note in append-only private history. Notes must not contain customer or service details. The website does not display contact fields until the current capability check permits intake; a write that loses a race with a pause fails without storing the request or consuming its handoff. Lookup, provider discovery, applications, corrections, and existing private request access remain available.
The consumer may report hiring an assigned provider, hiring someone outside the network, or not hiring a provider. Corrections append a new dated outcome rather than deleting the earlier record. This flow does not collect job price or a free-text review. Assigned providers may see the current outcome for their lead, and Network-plan CSV exports include that provider-specific current outcome. The private export remains `no-store` and contains only requests assigned to that provider.
Marketplace operations
The authenticated dashboard includes a fixed provisional first-market research packet containing five proposed ZIPs, aggregate public Census housing estimates, shared-boundary evidence, official and first-party research-source links, source limitations, a dated 15-organization research-only starter snapshot, and unresolved fieldwork gates. Nine organizations have at least one exact-pilot-ZIP source record; six have only municipality, radius, office, or general service-area evidence and therefore retain empty ZIP arrays. Area-only evidence never increases exact-ZIP lead or capability-cell counts. The authenticated starter CSV preserves public business research and its per-source limitations but contains no contact person, email, license finding, qualification, or outreach event. Viewing, downloading, or prefilling the packet stores nothing. Previewing the starter packet fetches that protected CSV and submits it only to the existing no-write validation and duplicate review; it opens the importer and does not call the commit path. A later explicit import is a separate action. None of these actions creates a market, contacts a business, or grants qualification or launch authority. Common area labels are for orientation only, and the estimates and raw lead counts are not household, customer, verified-provider, job, lead-delivery, demand, or revenue records.
Private launch-market records store operating requirements such as market name and status, ZIPs, brands, services, fuels, and minimum provider coverage. Aggregated operator and provider-specific metrics count provider, prepared agent-handoff, technical request-origin, assignment, response, and explicit consumer-outcome states without creating another copy of homeowner contact information. Daily aggregate demand metrics also count completed lookups, provider searches, provider appearances by website, unmarked REST, or observed MCP surface, and first-party public provider phone-link or website-link actions using low-cardinality results. When a searched ZIP exactly matches a configured launch market, the server may place one additional count in that market's daily bucket; only the market ID is retained in that bucket, not the searched ZIP. A provider appearance means an eligible profile was returned in a search; it is not a unique person, click, lead, endorsement, paid placement, or ranking signal. A public profile action means the link was activated, not that a call connected or the provider website loaded. Repeated or automated traffic may count more than once. Provider-retention actions use existing account state and these aggregate metrics without changing provider eligibility, alphabetical result order, subscription status, or any stored record. Handoff conversion links one issued token to one submitted request; it does not establish that an agent caused the request or identify a unique person. A hire counts only when the consumer selects an assigned provider; unreported outcomes are excluded from the hire-rate denominator. Job revenue, satisfaction, market size, and return on investment are not inferred.
Search multiplicity and market request performance. Each new provider search adds one low-cardinality result count for zero, one, or multiple eligible providers. Older some counts remain successful searches but are shown separately and excluded from the two-plus-rate denominator because they do not reveal exact multiplicity. This bucket contains no searched ZIP, model, serial, contact field, visitor identifier, or returned provider identity. The private dashboard also derives a trailing-30-day report for each configured market from the exact ZIP and assignment history already stored with consented service requests. It does not copy that ZIP, contact information, or request into another record. One request may contribute several provider assignments. Request assignment, provider decision, accepted-contact, and timing measures are operational aggregates, not unique people, hires, provider quality, revenue, satisfaction, or return on investment.
The authenticated operator dashboard also derives a launch-readiness report from whether required production settings are present and structurally plausible. Automated checks return statuses and missing control names, never secret values. External facts such as database recovery, DNS, delivery, legal approval, monitoring, market coverage, and live billing remain manual evidence gates. The operator may append a private evidence event for one of those seven gates containing a server-created identifier and time, outcome, concise reference and note, optional credential-free HTTPS source without query parameters, and a review date for a current claim. Newer entries supersede earlier status without deleting history; failed, review-needed, and expired entries remain blockers. This operator record is not independent verification or legal approval and must not contain secrets, signed URLs, database addresses, payment data, or provider/customer personal data.
Operational email
When operational email is configured, the delivery provider receives the provider or operator destination address, a privacy-minimized subject and message, and an idempotency identifier. These messages may contain a service category and ZIP code, but intentionally omit homeowner names, email addresses, phone numbers, equipment identifiers, request free text, and correction-reporter details. Authorized customer and correction details remain behind operator or provider sign-in. Delivery status, attempt count, provider message identifier, and low-cardinality error codes may be retained in the outbox; provider response bodies are not stored.
Payments
When billing is enabled, Stripe processes subscription checkout and returns customer, Checkout Session, subscription, status, item, quantity, and price identifiers. Water Heater Lookup stores a private checkout-attempt record containing an opaque attempt identifier, dates and state, initiating surface, selected plan and Stripe price identifier, fixed return URLs, optional Stripe Checkout Session identifier, and a low-cardinality failure code. The provider record may retain the expected Stripe price identifier, plan-verification status, and a low-cardinality mismatch reason. The raw hosted Stripe checkout URL is returned only to the authenticated operator or provider for immediate private handoff and is not stored in the application outbox or provider record. Stripe receives the provider record identifier and checkout-attempt identifier as reconciliation metadata plus the provider application email when no existing Stripe customer is known. One unresolved attempt is reused across operator and provider retries, and an attempt-derived Stripe idempotency key limits duplicate Session creation. A returned browser page, `active` Stripe status, or application configuration alone does not establish paid access. Subscription access may change only after a signature-verified Stripe event or an authenticated, server-to-server retrieval confirms the current Stripe record, provider identity, and exactly one quantity-one item at the expected plan price. These status checks retain the observation time and a private reconciliation identifier; a commercial activity entry is added only when the stored billing or plan-verification state materially changes. Price identifiers and plan-verification details remain private and are not included in public provider records, REST discovery, MCP resources, or provider-search responses. Water Heater Lookup does not store full payment-card details or raw Stripe event payloads. Stripe, the calling browser, and a trusted channel used to deliver a private billing link may retain their own copies under their respective controls.
Analytics
First-party usage measurement stores only UTC date, technical surface, event, low-cardinality result, optional provider ID for a provider appearance or public profile action, optional configured launch-market ID for a separate market-demand count, aggregate count, and update time. Provider-search result buckets use only none, one, multiple, and the retained legacy some value; they never contain a returned provider ID. It does not store the lookup input, searched ZIP, action destination, page, contact details, network address, user agent, cookie, or session identifier in those buckets. The website marks its own requests and profile actions; unmarked REST traffic may include people, agents, scripts, or other software, while MCP usage is observed at the protocol endpoint. If multiple configured markets contain the same ZIP, one market is selected deterministically by operating stage and then name. Searches outside configured markets create no market-demand record. Optional third-party analytics are configured only after a privacy-preserving provider URL is supplied. Model numbers, serial numbers, ZIP codes, contact details, provider application routes, provider portal routes, and consumer request handoff/access/status routes are not sent as custom analytics properties.
Logical backup and recovery
An operator-only workflow may copy the durable application record table and the retained daily aggregate usage and market-demand tables into a versioned logical backup package. That package can therefore contain private provider and prospect contacts, evidence and notes, customer service requests and contact details, notifications, operational controls, commercial records, and other durable application data. Per-table row counts, checksums, and non-reversible source-identity digests support integrity and empty-target recovery checks; the package does not contain the database URL or credential. Short-lived keyed rate-limit counters are excluded and begin clean after recovery. Backup files and restored targets require encrypted storage, restricted access, an approved retention and destruction schedule, and the same or stronger privacy controls as the source. Creating or verifying a package does not establish managed-provider backup or point-in-time recovery, least privilege, encryption, retention compliance, successful recovery, availability, or launch readiness.
Retention and choices
Daily aggregate usage and launch-market demand buckets are pruned after 25 months. Before public launch, the operator should publish a domain email for access, correction, deletion, and privacy questions, define prospect, correction, service-handoff, request, application, delivery-metadata, logical-backup, and recovered-target retention periods, and execute vendor agreements appropriate to the operating jurisdiction. Legal review is required before collecting real customer data.
Contact and rights requests
The public contact directory distinguishes support, privacy, evidence-correction, and provider-operations channels and publishes only structurally valid @waterheaterlookup.com addresses configured for the current build. An address marked pending is not represented as monitored. Before production collection, the operator must verify inbox delivery, response ownership, retention handling, and the published legal identity; do not email passwords, access tokens, payment details, or emergency information.