The boundaries are part of the answer.

What the lookup does

The tool runs three independent checks: exact normalized model comparison against the current U.S.-market EPA ENERGY STAR Certified Water Heaters dataset, serial-date interpretation for narrowly supported manufacturer formats, and a text match against the current U.S. Consumer Product Safety Commission water-heater recall feed. One check never silently fills gaps in another.

Model catalog matching

The server downloads the same bounded ENERGY STAR dataset and performs matching locally, so the entered brand and model are not added to the EPA request URL. Exact status requires the complete normalized brand and model to equal a current U.S.-market row. ENERGY STAR permits * and # wildcards in model patterns; Water Heater Lookup does not promote those family rows—or multi-component + patterns—to an exact unit match. If matching current rows disagree on material specifications, the result remains ambiguous. If the dataset cannot be reached, the result says unavailable rather than falling back to stale product specifications.

A no-match result does not prove that a model is invalid, not ENERGY STAR certified, absent from historical data, or outside another manufacturer dataset. ENERGY STAR certification identifies a product record; it does not establish this unit's condition, warranty, installation, or safety.

Confidence language

Supported serial formats

Rheem

The supported 10-character pattern is interpreted as two-digit month, two-digit year, plant letter, and five-digit sequence. Other Rheem/Ruud formats may exist; they remain unsupported rather than coerced. Manufacturer source.

A. O. Smith, State, and American

The current A. O. Smith service guide names A. O. Smith, State, and American alongside a matrix that treats the first two digits as year and the next two as production week. The supported numeric family continues with a numeric sequence. A State-hosted manufacturer-family guide also publishes a form with a manufacturing-location letter in the fifth position followed by six digits. The tool accepts only those two narrowly described forms. American Standard is a separate brand and is never normalized to American Water Heaters. Current manufacturer-family service guide.

Bradford White

The first letter maps to year and the second to month. Year letters repeat every 20 years, so the tool returns all past candidates unless context removes the ambiguity. Manufacturer source.

Recall screening

The service queries the official CPSC recalls API for water-heater-related notices, then compares a normalized complete model across titles, descriptions, manufacturers, products, models, and hazards. Brand-only evidence uses whole phrases rather than unbounded substrings. Because State and American are ordinary words, those brands require an explicit manufacturer phrase such as “State Water Heaters,” “State Industries,” or “American Water Heater” in structured title, product, or manufacturer text; generic references to states or American homes are ignored. A full model text match is stronger than a brand-only match. The complete CPSC notice controls because applicability can depend on manufacture date, component, fuel, region, or label details.

No candidates found means only that the current search did not surface a candidate. It is not an “all clear,” proof of safety, or proof that the unit has never been subject to another notice.

Official-source status

The source-status page, REST endpoint, and MCP resource make a fixed five-minute point-in-time availability check against the ENERGY STAR model dataset and CPSC recall service. They accept no lookup input and add no entered model, serial, ZIP, contact, provider, or visitor identifier to the fixed upstream URLs. HTTP 200 means both responses were reachable and structurally usable for this service at that check; HTTP 503 means at least one could not be confirmed. This is not historical uptime, complete-data validation, a safety result, or proof that database, provider, email, billing, analytics, DNS, or operator systems are ready.

Service operating status

The operating-status report and matching MCP resource add fixed one-minute states for application response, source availability, production record-table readability, service intake, scheduled notification and provider-lifecycle work, and paid-provider billing configuration. A notification-worker heartbeat is stale after 90 minutes; provider lifecycle is stale after 26 hours. HTTP 503 means a required component is unavailable, not configured, awaiting its first successful invocation, or stale. The report exposes no configuration value, database address, private record, provider/customer data, event identifier, or processing volume. It is point-in-time monitoring—not uptime history, backup/restore evidence, future-availability assurance, delivery proof, coverage, legal approval, or launch approval.

Database recovery boundary

The operator-only logical recovery workflow can export the three durable application tables into a versioned private package, verify per-table counts and checksums, refuse a matching or nonempty target, restore within one transaction, and compare the recovered rows with the artifact. Short-lived rate-limit counters are deliberately excluded so expired throttling state is not revived. The package can contain all durable private provider, customer, sourcing, request, operational, and commercial records and therefore requires encrypted storage, restricted access, and an approved destruction date. The workflow does not inspect or establish managed-provider backups or point-in-time recovery, database grants, infrastructure settings, encryption, retention compliance, availability, or launch readiness. A successful operator drill and separate current evidence remain required.

Deployed-action capabilities

The service-capabilities report and matching MCP resource let an agent distinguish published reads, deployment-disabled writes, and a temporary service-intake pause before sending provider or customer data. The report refreshes on a 30-second interval and exposes only low-cardinality action states, consequences, confirmation requirements, alternatives, and limitations; it never returns secret values, private records, pause reasons, or operator notes. A pause disables new handoffs and direct requests across the website, REST, and MCP while lookup, provider discovery, applications, corrections, and existing private request access continue. “Enabled” means only that durable storage, the separate managed-schema declaration, traffic controls, and retry safety have the expected configuration shape. Production runtime code never creates tables or indexes, and a business write is refused before its first database query without that declaration. The report does not test actual table structure or grants, database connectivity, or establish provider coverage, email delivery, legal approval, billing, operator response, or production launch readiness.

One-call agent service planning

The read-only plan_water_heater_service tool and POST /api/v1/service-plans route compose the existing equipment and optional exact-ZIP provider checks without creating a service handoff, request, or provider contact. The strict input rejects contact and unexpected fields. The returned next step follows a fixed order: review recall candidates first; otherwise preserve unavailable official-source states; otherwise review current provider results, explain an empty Water Heater Lookup result, or request an exact ZIP. One daily service-plan aggregate records only the technical surface and that final bounded outcome, never the model, serial, ZIP, contact field, or provider identity. The dashboard keeps planner outcomes separate from their constituent lookup and provider-search counts so component traffic is not mislabeled as adoption of the one-call workflow. Counts may repeat and are not unique agents, people, leads, market size, safety findings, or revenue. This is navigation logic—not diagnosis, risk scoring, a safety conclusion, provider endorsement, or a hiring recommendation. The complete evidence, provider freshness, independent-verification duty, and separate write boundary remain controlling.

Retry-safe writes

Every public write requires a client-generated retry key. REST sends it as Idempotency-Key; MCP sends idempotencyKey. The server combines the key, action scope, and validated payload with a dedicated secret to derive an opaque record ID and private payload fingerprint. It stores neither the raw key nor a reversible payload copy. The same key and unchanged input return the first completed receipt without creating another record or notification; changed input under the same key is rejected. Private handoff and request-access tokens are deterministically derived for exact receipt replay, but only their one-way hashes are stored.

What serial numbers cannot tell you

A serial date does not establish installation date, maintenance, corrosion, venting, leaks, combustion safety, remaining life, warranty status, or whether a particular unit is safe. Those require manufacturer confirmation, label comparison, or qualified physical inspection.

Portable evidence reports

Copy and print controls preserve the resolved equipment label, confidence states, manufacture interpretation, recall check time, candidate and source links, next actions, and limitations so a person can bring the same evidence to a provider or another assistant. The entered serial number is deliberately omitted. Copying uses the user-controlled clipboard; printing uses the browser and may create a local PDF. Neither action creates another server record, and live sources should be rechecked before a safety or hiring decision.

Provider ranking and payment

Release one filters providers by active operator status, exact service ZIP, requested brand, fuel/technology, and service type. Capability matching is exact after case and punctuation normalization. Diagnosis and repair are one service family; gas maps only to natural gas. A service plan for heat-pump equipment uses the heat-pump provider capability, while other or unknown equipment fuel does not become a provider constraint. The response exposes the canonical query and constraint policy. ZIP, brand, replacement, maintenance, recall, installation, emergency, propane, and every other capability remain unwidened. Public website, REST, and MCP results are alphabetical after those gates. Payment provides access to the marketplace workflow; it does not override eligibility, buy public directory position, or create a safety endorsement. The private retention queue chooses one operator follow-up from ordered billing, access, qualification, lead-response, and aggregate-value rules. Aggregate public-profile actions can inform a human value review but never affect ranking or create an automatic account action. The private sourcing panel can also create a copyable provider-conversation brief from aggregate planner outcomes, first-market experiment counts, public plan hypotheses, and the current evidence milestone. The brief deliberately exports no prospect identity or private sourcing, customer, request, qualification, invitation, or billing data and treats zero planner activity as no adoption proof. Neither the queue nor the brief is a provider grade, churn prediction, demand estimate, revenue estimate, ROI estimate, contact authority, or automated decision. Consumers should independently verify current license, insurance, references, scope, and price before hiring.

Public provider-coverage state

Exact-ZIP provider search returns one coarse state in addition to the current records. Current eligible matches always produce current-matches. When none match, network-building means the exact ZIP belongs to an onboarding, invite-only, or live sourcing market; a draft, paused, or unconfigured ZIP produces outside-active-market. A service plan without an exact ZIP produces not-run. The state exposes no market name or ID, internal status, provider target, readiness threshold, demand count, gap, prospect, or private sourcing record. For an exact-ZIP search, the application URL carries only that already-supplied ZIP in a coverage_zip fragment. Opening it removes the fragment from browser history and prefills an editable service-ZIP draft without creating an application, provider attribution, or additional market-demand record. A verified private prospect invitation takes precedence over this public draft. The state and URL are navigation aids—not market availability, a claim that no other qualified local professional exists, outreach authorization, provider qualification, approval, listing, demand, or service assurance. A provider application remains a separate provider-authorized write and guarantees none of those outcomes.

Initial service-request selection

After a person explicitly consents to a service request, the same current eligibility and exact capability gates run before contact data is shared. When more than three providers qualify, an opaque request-specific deterministic order over the server-owned request ID and provider ID selects the initial three. An exact idempotent retry keeps the same request and selection. Plan, payment, business name, alphabetical directory position, aggregate appearances, and profile actions do not affect that order. The rotation adds no provider score and is not an equal-share promise, quality ranking, response prediction, availability guarantee, or lead-volume guarantee; short-run assignment counts can still differ and must be measured before any fairness claim.

Provider plan-fit worksheet

The public provider worksheet compares an exact service-ZIP count with the release-one Core limit of 25 and Network limit of 100. For each plan whose ZIP limit fits, completed-job equivalents equal monthly plan price divided by the provider-entered contribution margin after direct job costs. Expected contribution per eligible request equals that margin multiplied by the provider-entered close-rate scenario; eligible-request equivalents equal monthly plan price divided by that expected contribution. Whole-job and whole-request displays round the respective equivalents up. A zero margin produces no finite job or request threshold, and a zero close rate produces no finite request threshold. The worksheet supplies no default margin, close rate, or lead volume. It is arithmetic only—not a demand or lead-volume forecast, ROI estimate, plan recommendation, qualification decision, or guarantee. Inputs and results remain in the browser; copying writes the displayed scenario only to the user-controlled clipboard.

Provider application coverage and capability preflight

Before a provider application is submitted, the form locally splits the service-area draft on commas and whitespace, accepts only exact five-digit entries, preserves the first entered order, and includes repeated ZIPs once. It compares the unique count with the currently selected Core 25-ZIP or Network 100-ZIP limit and shows remaining or excess slots immediately. Changing the radio selection recomputes only that count check. Malformed entries, an empty list, or a unique count above the selected limit stop submission before any application request. Service and fuel/technology choices use the same bounded vocabulary as provider discovery. The server stores repair as diagnosis and gas as natural-gas, deduplicates aliases, and rejects unsupported values before creating an application or notification. A passing preflight establishes only list shape, plan-count fit, and capability vocabulary—not licensing, insurance, capability truth, availability, qualification, approval, public eligibility, provider ranking, lead volume, or a plan recommendation.

Provider application status lookup

The non-indexed status utility requires the complete random application reference and the same private review email. The server compares the pair against the existing provider application and returns only its reference, server-owned submission and update times, selected plan, coarse lifecycle label, five derived progress steps, and one accountable next action. Qualification is complete only when current structured license and insurance evidence passes the existing evidence rule; current discovery is complete only when the authoritative public-eligibility rule passes. The lookup never returns the business identity, contact details, license number, service area, capabilities, operator notes, evidence records or links, billing identifiers, commercial history, portal token, or private access link. It creates no application, status event, portal session, message, payment, qualification, ranking, or routing change. The result is workflow orientation—not independent verification, approval reasoning, a service promise, lead-volume evidence, or a revenue forecast.

Private provider-status history

Every actual provider-status change retains a private newest-first event containing its server-created identifier and time, prior and new status, bounded source, and bounded reason. Staff changes additionally require a concise private decision note; asking for the current status again creates no event. Verification evidence, commercial-access revocation, Stripe event or reconciliation, and scheduled lifecycle pauses identify their own source rather than accepting free-form system text. Only the latest 100 events are retained for a provider. This history is operator accountability evidence, not provider scoring, qualification, quality, availability, ranking, demand, lead-volume, or revenue evidence. It is excluded from applicant status, the provider portal, public pages, REST, MCP, sitemap, notifications, and value-review output.

Provider lifecycle and account closure

The operator cannot use status as a free-form label. Applied, verifying, approved, active, paused, and rejected records each expose only their defined next stages; rejected is terminal and a later review requires a new application. An active provider must pause routing before closure. Approved or paused closure is blocked while founding access remains, a paid subscription is pending, active, or past due, an unexpired checkout can still complete, or a service assignment remains unresolved without a closed request or explicit consumer outcome. The server evaluates the same rule against private authoritative records even when a client bypasses the dashboard. These checks prevent contradictory account state; they do not cancel billing, revoke access, close service work, contact a provider, or decide that any prerequisite is resolved.

Provider application review order

The private operator application queue includes only applied, verification-stage, and rejected records and derives exactly one next action from stored facts. Its fixed precedence is an exclusive normalized state/license conflict, a latest conflicting license or insurance evidence result, pending profile changes, missing separate public phone, missing current license evidence, missing current insurance evidence, and the explicit approval decision. A new application without a blocking identity conflict first requires the operator to start review. Email-only matches remain private warnings and never become automatic blockers. Equal-priority records sort by oldest submission, then business and record identity. The projection is workflow triage—not automated qualification, legal-identity proof, provider scoring, approval, availability, quality, lead volume, or revenue evidence. Rendering, filtering, and in-page navigation write nothing and execute none of the recommended actions.

Provider verification research handoff

The private evidence form gives the operator fixed official source paths for the Illinois launch jurisdiction and Texas fallback, each with a narrow use, limitation, and source-path review date. An unmapped state receives an authority-finding checklist rather than an invented regulator link. A copy control creates a browser-local research brief containing only the provider-supplied business name, license state, and license number as untrusted search keys, plus the same source boundaries and human checklist. It excludes application contacts, service ZIPs, capabilities, evidence history, billing, and customer data. Copying does not fetch a source or create a record. The brief authorizes public-source research only: no contact, access-challenge solving, account creation, form submission, qualification conclusion, evidence event, approval, payment, or eligibility change. An authenticated operator must reopen the authority, interpret the result, review insurance and municipal obligations separately, and deliberately append any bounded evidence event.

The private sourcing queue can batch the currently visible active pre-application prospects into versioned JSON for a human or AI researcher. Each task contains only an opaque internal reference and business name, license state, and license number as untrusted search keys, plus the fixed mapped guide or a no-source fallback and manual return contract. Applied, linked, declined, do-not-contact, and disqualified paths are excluded. Contact details, websites, markets, ZIP and capability research, source evidence, notes, outreach, pricing, invitations, application details, provider/customer data, and billing are excluded. Generation and copy stay in the browser and perform no fetch, analytics call, or write. The queue grants no contact, access-challenge, account, form, terms, qualification, invitation, publication, billing, or routing authority; returned material remains untrusted until the operator independently reviews it and takes a separate explicit action.

First-market cohort conversion. The private acquisition panel counts toward the eight-application pilot floor only when the first-market prospect and exactly one provider application point to one another. Missing, one-sided, or duplicate relationships remain exceptions. It counts toward the five-provider activation floor only while the linked provider passes the full current public-eligibility rule used by the directory, REST, MCP, sitemap, and routing. Paid and time-bounded founding activation remain separate, and founding access is excluded from MRR. The projection stores nothing and changes no record. It is not attribution proof, revenue, quality, retention, redundant coverage, or market readiness.

First-market value-response cohort. After the activation floor, the same strict linked and currently public-eligible provider set becomes the response denominator. The numerator includes only each provider's latest event within 45 days when its plan, centralized price, and fixed 30-day review period still match. Paid and founding responses remain separate; prior-plan, stale, and linked-but-now-ineligible response evidence remains visible outside the current numerator. The projection stores nothing and changes no account. Its categories are explicit provider statements—not renewals, churn predictions, revenue, ROI, causal attribution, future retention, price recommendations, or willingness-to-pay estimates.

Managed-provider value responses. Prospect pricing discovery and managed-account renewal evidence remain separate. Only after a provider with current paid or time-bounded founding access sees its 30-day value review may the authenticated operator append a coarse response. The server owns the event ID/time, current plan and centralized price, and fixed review period. Current category counts use only the latest response within the 45-day operator follow-up heuristic when its plan and price still match. The immutable event carries no report copy, metric snapshot, transcript, budget, free text, customer or request data, job price, revenue, satisfaction, or ROI. It is not a renewal commitment, churn prediction, willingness-to-pay estimate, price recommendation, ranking input, or automated account decision and changes no billing, access, qualification, eligibility, or routing state.

Private commercial operations snapshot

An authenticated operator may download a point-in-time JSON or CSV snapshot of approved, active, and paused provider accounts in the same deterministic review-now/monitor order used by the dashboard. Each row contains provider ID and business name, coarse lifecycle, plan, billing and commercial-access states, public-eligibility and freshness dates, service-ZIP count rather than exact ZIPs, the current next-action rule, listed plan price and modeled current paid MRR, the latest coarse value response, and privacy-bounded discovery, profile-action, assignment, response, outcome, and timing aggregates. The export excludes private provider contact, exact service ZIPs, license number and qualification evidence, Stripe customer/subscription/price identifiers, operator notes, customer or request records, and private decline detail. Spreadsheet-active prefixes are neutralized. Generating either format writes nothing and does not reconcile Stripe, recognize accounting revenue, change or retain an account, execute a recommendation, satisfy a retention policy, or create a database backup or restore artifact.

Private commercial transition archive

The authenticated operator may separately download the complete stored commercial-transition history as versioned JSON or spreadsheet-safe CSV. Unlike the current-account snapshot, this archive retains events for providers that are no longer current. Rows sort newest first and contain the provider ID, current business name at export, server event ID and time, bounded event source and kind, and the resulting billing, access, plan-verification, provider, period-end, and cancellation states. It excludes free-form event notes, stored summaries, external Stripe event IDs, private reconciliation IDs, provider contact, exact service areas, qualification evidence, checkout records, operator notes, and customer or request data. The current business name is an export-time locator rather than a claim about its historical value. Generating the archive writes nothing and is not a Stripe refresh, accounting ledger, recognized revenue, retention-policy action, re-import contract, or database backup or restore artifact.

Provider reference freshness

Every public provider entity carries an opaque version derived only from the public representation plus an explicit instruction to revalidate. REST directory and stable-record responses use private, no-cache, must-revalidate semantics and expose weak ETags. If-None-Match may save retransmission, but the server still evaluates current provider eligibility: HTTP 304 means the current public representation is unchanged at the returned validation time; HTTP 404 means the provider is no longer current. The opaque version never makes an old copy safe to present, contact, or route from. MCP provider resources remain zero-TTL and must be reread through the returned resource URI.

Provider profile semantics

Each current eligible profile emits a linked ProfilePage and Organization JSON-LD graph derived only from the same public provider projection used elsewhere. Exact service ZIPs appear as areaServed places with nested postal codes; they are service-area statements, not the provider's physical address. The graph deliberately makes no LocalBusiness, physical-address, geo, rating, price, business-hours, ranking, or endorsement claim. It disappears with the page when eligibility lapses and never replaces a fresh REST or MCP provider reread before an agent presents, contacts, or routes to a provider.

Data handling

Model numbers, serial numbers, searched ZIP codes, contact details, network addresses, user agents, cookies, and session identifiers are excluded from first-party aggregate usage metrics. The service keeps daily counts by technical surface, event, low-cardinality result, and provider ID only when an eligible provider is returned or a first-party phone/website link is activated; service-plan and provider-search result buckets never contain a provider ID. New provider searches use zero, one, or multiple-result buckets. Legacy some records remain successful searches but are excluded from the two-plus denominator because their exact multiplicity is unknown. A profile action does not confirm a connected call, completed website visit, unique person, lead, hire, or revenue. If a provider search exactly matches an operator-configured launch market, a separate daily bucket stores the selected market ID rather than the searched ZIP. These counts may include repeated or automated requests, do not affect provider order, are not market-size estimates, and are pruned after 25 months.

The private market report derives trailing-30-day request assignment, provider decision, accepted-contact, and timing measures from the ZIP and assignment history already stored with explicit-consent quote requests. It creates no duplicate request, ZIP, contact, or telemetry record. One request may have multiple assignments, and no denominator is presented as a hire, quality, satisfaction, revenue, or ROI measure. Contact information is stored to operate the request and shared only with eligible providers assigned to it. See the privacy notice.

Corrections

Manufacturer formats and product records change. Every source record carries a verification date. Use the public evidence-corrections channel only when it displays a configured domain address; current provider profiles also have a private record-specific correction form. A provider-profile concern enters a review-first private lifecycle: the internal target is to start evidence review within 48 calendar hours and close it with an evidence-based resolution or dismissal within seven calendar days after review begins. Each actual transition retains its server time, prior and new status, bounded reason, and any private decision note. Closed requests are terminal; new evidence requires a new correction record. These are operator review targets, not emergency service, guaranteed response times, proof that a concern is correct, or authority to edit, pause, remove, qualify, rank, bill, or contact a provider automatically.