EntryStandard

How It Fits

A sidecar access-record layer, not another LSLR platform.

EntryStandard works beside the systems already used for inventory, GIS, public communication, construction management, and reporting. Your existing platform identifies the line. EntryStandard documents the access outcome.

For a pilot, EntryStandard needs a worklist export, not a system migration.

If you only read one thing: for each unreplaced property, the program needs a file. EntryStandard creates that file while outreach and field work happen, labels how each record entered the file, and exports a ProofPack when asked.

The division of labor

A program's inventory, GIS, and construction systems answer where the lead lines are, what the material classification is, which addresses are in the program, and what the construction status is. EntryStandard answers a different set of questions — the ones a reviewer asks about access:

  • Who was contacted, by what method, and when?
  • Who responded, and what authority did they hold — owner, tenant, occupant, trustee, manager, agent?
  • What document was shown, and in what version?
  • Was right-of-entry granted, refused, or was a waiver presented?
  • Was the property non-responsive after the required attempts?
  • Is the property actually crew-ready — and can the record be exported and verified?

EntryStandard is not the system of record for inventory. It is the system of record for access outcomes. That distinction is the whole product.

How the record moves

Existing systems inventory · GIS · comms construction · reporting worklist EntryStandard outreach · ROE · refusal waiver · non-response tenant routing · crew-ready append-only ledger status fields ProofPack Program archive counsel · state review audit · closeout identifies the line, runs the program owns the access record keeps the defensible file
No GIS migration, no construction-management replacement, no deep integration required for a pilot. EntryStandard owns one narrow thing: the defensible access record.
  1. Existing systems identify the line and produce a worklist.
  2. EntryStandard captures outreach, right-of-entry, refusal, non-response, tenant routing, and crew-ready status.
  3. EntryStandard returns access-status fields to the systems already in use.
  4. EntryStandard archives the ProofPack for counsel, state review, audit, and closeout.

Program forms, notice procedures, waiver handling, and retention policies should be reviewed by the water system's counsel.

What this means for your role

  • Public works director — when the state or a reviewer asks for the no-access file, it is two clicks, not a records project.
  • Engineering prime — closeout documentation for the properties that did not move forward, without adding record-keeping scope to your delivery team.
  • Contractor — crew-ready means access is documented; trucks stop rolling to properties that were never going to open the door.
  • Counsel — records captured at the time, with source, actor, both timestamps, and integrity protection visible; admissibility remains your determination.
  • Finance / grant administration — the documentation that annual state reporting expects for unreplaced lines exists before anyone asks for it.

The three-file model

For an early program there is no integration project. The operating model is three exchanges of ordinary files.

1 — Property worklist in

A CSV or export from the existing system: program and property identifiers, address and unit, PIN/parcel, utility account, owner and mailing address, occupant if known, service line status, program phase, contractor package.

2 — Access status out

Fields that go back into the existing system: access status, ROE status, refusal status, waiver status, reasonable-effort status, attempt and method counts, crew-ready, last event timestamp, and a ProofPack reference.

3 — ProofPack archive

A per-property evidence packet — summary PDF, event-ledger CSV, document fingerprints, evidence index, chain-verification result. See a sample ProofPack (synthetic).

Deployment modes

Mode 1 — Mock No-Access File Audit

No integration. Sample or exported records from the current workflow; output is an access-risk scorecard, gap memo, and sample ProofPack. (scope, PDF)

Mode 2 — CSV pilot

No API required. The program sends a property worklist; EntryStandard returns status fields and ProofPacks. Suited to a 250–500 property phase.

Mode 3 — Status sync

Scheduled export or API sync of access statuses back to the program's tracker. Scoped only after the CSV workflow has proven useful.

Mode 4 — Embedded / OEM

For incumbents and engineering firms that want the ES-R record engine inside their own platform. See For platform vendors.

Live capture vs. reconstruction

The Mock Audit and the pilot are the same idea pointed in two directions. The audit tests what can be reconstructed from the records a program already has. The pilot creates the file while the work happens, so nothing needs reconstructing later.

For lines not replaced due to lack of access, this is not only a file someone may request — documentation of the reasons and of each reasonable effort is part of annual state reporting (40 CFR §141.90(e)(10)). The record keeps the source of each event visible: recorded live, imported from another system, entered later from historical records, reconstructed during review, unsupported, or system-derived — alongside the time it claims to have occurred and the time EntryStandard received it. Not all records are equal, and the record says so itself.

Mock No-Access File AuditProduction pilot
Tests what can be reconstructedCreates the file while work happens
Uses existing records, as they areCaptures events in the workstream
Grades record completenessBuilds the no-access file going forward
Gap memo, scorecard, sample ProofPackLive ProofPacks and status exports

If your current records are solid, the audit says so. If they are scattered, the audit shows what can and cannot be reconstructed.

The demonstration explorer

Prospective programs receive a personal, read-only link to a fully populated synthetic program (the City of Alder Run, which is fictional) — worklist, drilldowns, record-source labels, ProofPack downloads, status export. Page views and downloads on that link are recorded so we can follow up, and the site says so on every page. It demonstrates record structure and verification; it is not legal advice or a compliance opinion, and no real resident data exists anywhere in it.

Watch the 3-minute walkthrough — a narrated tour of the synthetic Alder Run program: worklist, non-responsive drilldown, record-source labels, verification, and the ProofPack export. Narrated walkthrough using synthetic voice; demo data is synthetic.

How it works in the field

"How is this real-time if our crews use another vendor's field software?"

The record has three entry paths, and every event is labeled with the one it took. The resident moment — signature, refusal, tenant acknowledgment — is captured live, because the resident interacts with the program's EntryStandard link directly. Staff doorstep capture is live where the program uses it. Field data from existing systems (Survey123 exports, contractor logs, mail-vendor files) arrives as a labeled import on a cadence, with the source file fingerprinted and the import time shown honestly. A prompt import from a source-system log with a source-file hash is a more supportable record than a reconstruction months later — the problem was never "imported"; it was "reconstructed years later." Tighter, automated ingestion — deep API integration with third-party systems — is separately scoped if wanted, per the pilot statement of work.

"Does the file show photo evidence — like the door hanger left at the property?"

Yes. Photo evidence is preserved in the property’s record alongside the attempt, with a cryptographic fingerprint, its claimed capture time, and the time the system received it, and it renders in the ProofPack as an evidence exhibit. The demonstration explorer's 300 Cedar St ProofPack is the reference.

"Do field crews have to work in two systems?"

No — double entry is where field adoption dies, so the design avoids it. Crews keep working in their existing tools. The door hanger or mailer they leave carries the property-specific link as a QR code, so the resident's own response creates the live record. Program staff who want doorstep capture have a lightweight phone screen. Everything else reconciles through labeled imports — and the record-source label on every event tells the reviewer which path it took.

What a pilot requires

For a 250–500 property pilot, EntryStandard needs:

  • A property worklist export.
  • The approved ROE, refusal, and waiver forms.
  • Program outreach rules and channels.
  • A contact for city or firm review.
  • A desired status-export format.

What it does not require:

  • Replacing GIS.
  • Replacing an inventory, public-communication, survey, or e-signature system.
  • Migrating historical inventory.
  • Connecting to billing systems.
  • Changing construction-management software.
EntryStandard is CSV-first and low-disruption by design. If the workflow does not make the access record cleaner, it does not deserve to expand.

For platform vendors

An incumbent inventory or program-management platform can add a form. The harder thing — and the thing EntryStandard is — is a defined access-record standard with refusal and waiver logic, tenant/occupant routing, ledger verification, and ProofPack export. If your platform already manages inventory, communications, or construction status, EntryStandard can supply the access-record subsystem beside it, as a sidecar or as an embedded ES-R conformance layer.

Start a conversation, or take the summary with you: No Rip-and-Replace — how EntryStandard fits into an existing LSLR stack (PDF).