- Designation
- ES-R v1.0, published 2026
- Title
- Record specification for right-of-entry documentation in lead service line replacement programs
- Publisher
- EntryStandard LLC
- Status
- Current. Additive revisions are versioned; published versions are never silently changed.
- Citations
- Regulatory citations current as of July 2026; the crosswalk is reviewed against amendments to 40 CFR §141 and 415 ILCS 5/17.12.
Scope
ES-R specifies the record objects, event taxonomy, integrity mechanisms, and export semantics required to document right-of-entry activity in an LSLR program: outreach attempts and methods, homeowner responses, electronic-signature ceremonies, refusals, non-responses, and the classification and evidence records that accompany them. It is designed to document the reasonable-effort requirements of 40 CFR §141.84 and the documentation obligations of 40 CFR §141.90(e), together with the Illinois overlay in 415 ILCS 5/17.12. It does not specify construction practice, and it does not interpret regulation: the crosswalk below cites the mandates the record structures are designed to document.
Core record concepts
- Event — one immutable fact: an attempt, a response, a ceremony step, a signature, a refusal. Events carry the property, the event type, the method (channel), the party where known, occurrence time, and a structured payload.
- Ledger — the append-only, per-property hash-chained sequence of events. Aggregates (attempt counts, current status) are always derivable from the ledger and never authoritative on their own.
- Instrument — the executed right-of-entry document, rendered to a final form, fingerprinted with SHA-256, archived under retention, and referenced from its signature event.
- Party and role — the person acting, with their claimed role and the basis for believing they hold it; ownership-authority roles are distinguished from occupancy roles at the schema level.
Regulatory crosswalk
The crosswalk maps each mandate to the record structures of the ES-R reference implementation, using the implementation's actual identifiers (contract v1.1.0). Where the current specification does not yet define a structure, the row says so — unmapped mandates are scheduled, not improvised.
| Regulatory mandate | Citation | Record structures (reference implementation) | Coverage |
|---|---|---|---|
| Reasonable-effort outreach minimums — at least 4 attempts using at least 2 methods (federal floor; states may require additional attempts or specific methods) | 40 CFR §141.84(d)(3)(i) | Each attempt is one ledger event: consent_event.event_type ∈ outreach_mail_sent, outreach_sms_sent, outreach_email_sent, outreach_phone_call, outreach_door_hanger, outreach_field_visit; the method is consent_event.channel (enum outreach_channel); timing is occurred_at. Attempt and distinct-method counts per property are derived from the ledger, never stored in its place. | ES-R v1.0 |
| Documented refusal of access, reportable to the state | 40 CFR §141.84(d)(3); state reporting | A refusal is a first-class outcome: event consent_refused with the structured reason in consent_event.payload (API field refusalReason), signer identity fields, and the property rollup property.access_status = ‘refused’. Ceremony and integrity protection are identical to a signed consent. | ES-R v1.0 |
| Change of ownership: offer to replace within 6 months of learning of the change; new reasonable effort within 1 year; applies until all lead and GRR lines are replaced | 40 CFR §141.84(d)(3)(ii) | Party tenure is representable today (property_party.valid_from/valid_to), but ES-R v1.0 does not yet define an ownership-change event or the derived re-offer deadlines. Scheduled for ES-R v1.1; this row will not be mapped until the record structures exist. | Planned — ES-R v1.1 |
| Documentation to the state for each service line not replaced due to no access or no response | 40 CFR §141.90(e)(10) | The no-access demonstration is the property’s complete event history: chronological consent_event export (attempts, methods, dates, outcomes) with chain verification via verify_consent_chain(), plus the derived state (property.access_status ∈ refused, unresponsive; view v_property_consent_state). | ES-R v1.0 |
| Illinois waiver documentation: waiver presented, signed, refused-to-sign, or property non-responsive | 415 ILCS 5/17.12(ff)(1)(D) | Outcome states map today: signed → consent_signed; refused to sign → consent_refused; non-responsive → conforming attempt history with access_status = ‘unresponsive’. Presentation is currently evidenced through delivery and portal events (outreach_*, portal_link_opened, portal_property_viewed, esign_disclosure_accepted); a dedicated waiver-presented event is scheduled for ES-R v1.1. | ES-R v1.0 (partial) |
| Electronic notification of waiver outcomes to IDPH | 415 ILCS 5/17.12(ff) | Not yet defined in ES-R v1.0 — the current record has no state-notification event type, and this row is not mapped to structures that do not exist. Scheduled for ES-R v1.1 as a system-channel ledger event carrying the submission reference. | Planned — ES-R v1.1 |
| Identification of the party granting access and their authority (owner vs. occupant) | 40 CFR §141.84(d); instrument validity | Parties and roles: party, property_party.role (enum party_role: owner_in_fee, co_owner, trustee, authorized_agent, property_manager, tenant) with authority_basis. At signature: consent_event.signer_role, signer_name_typed, authority attestation; submissions with a non-authority role for a grant are rejected (signer_role_not_authorized) and occupants are routed to occupant_acknowledged. | ES-R v1.0 |
| Record retention and integrity — records available for review, protected against alteration | 40 CFR §141.91; evidentiary practice | Append-only ledger (UPDATE/DELETE/TRUNCATE refused at the database layer) with a per-property SHA-256 chain: consent_event.event_hash commits to prev_event_hash; any retroactive edit is detectable by verify_consent_chain(). Executed instruments carry document_hash (SHA-256) and are archived under a multi-year retention policy; evidence objects verify declared sha256 before acceptance. | ES-R v1.0 |
| Service line material classification, both sides, with provenance | 40 CFR §141.84(a)–(b) (inventory) | Per side on property: utility_side_material, customer_side_material, connector_material (enum material_status: lead, grr, non_lead, unknown) with provenance *_basis (enum classification_basis) and verification dates *_verified_at. | ES-R v1.0 |
Field definitions (abridged)
| Field | Definition |
|---|---|
event_type | Closed taxonomy of documented facts: six outreach-attempt types, portal response events, esign_disclosure_accepted, consent_signed, consent_refused, consent_revoked, occupant_acknowledged, appointment and evidence events, document_rendered. |
channel | The method of the event: mail, sms, email, phone, door_hanger, field, portal, system. Distinct-method counting for the reasonable-effort test is computed over this field. |
event_hash / prev_event_hash | SHA-256 over the event's semantic content and the property's previous event hash, forming the per-property chain; verified by recomputation. |
document_hash | SHA-256 fingerprint of the rendered, executed instrument, stored in the signature event and comparable to the archived document at any time. |
access_status | Derived per-property rollup (not_started … consented, refused, unresponsive, work_completed). A cache for reporting; the ledger remains ground truth. |
signer_role / authority_basis | The claimed capacity of the signer and the recorded basis for the role (county record, utility account, self-attestation, program import). Grants require ownership-authority roles. |
Conformance language
A system produces conforming records under ES-R v1.0 when (a) each outreach attempt, response, ceremony step, and outcome is captured as a discrete event at the time it occurs; (b) events are append-only and integrity-chained such that retroactive alteration is detectable by independent verification; (c) attempt and method counts for the reasonable-effort test are derived from the event record; and (d) executed instruments are fingerprinted and archived under retention with the fingerprint recorded in the ledger. Suggested procurement citation:
"Right-of-entry documentation shall be maintained as conforming records under the ES-R v1.0 record specification (EntryStandard LLC, 2026), or equivalent: discrete per-attempt event records with method attribution, append-only tamper-evident storage with independent integrity verification, and SHA-256 fingerprinting of executed instruments."
Versioning
ES-R v1.0 is the current published version. ES-R v1.1 is planned and will define, at minimum, ownership-change events with derived re-offer deadlines (40 CFR §141.84(d)(3)(ii)), a dedicated waiver-presented event, and state-notification events for electronic reporting to IDPH. Revisions are additive where possible and versioned always.
To evaluate ES-R records against your program's requirements: structured pilot review.