Privacy Policy

Weirlog is business software, and the data in it is rarely about the person typing.

Users. People at an operator firm who hold a Weirlog login: owners, admins, operators, technicians, and lab techs.

Customer contacts. Named people at the municipalities, districts, and industrial facilities your firm operates for. Your firm enters these; they never log in and never interact with us.

People named inside documents you file. Emergency Management Plans and similar facility paperwork routinely list after-hours contacts and personal phone numbers. Weirlog stores the file; it does not read it.

For Users, Hoss Automation decides what is collected and why. For customer contacts and for people named in filed documents, your organization decides — we hold that data on your organization’s instruction and process it only to run the service for you.

Weirlog computes and stages reports. It does not submit them.

Weirlog never files to NetDMR, CDX, or any state or federal system — submission happens on the state’s own system, signed by a certified human under their own login. It never applies an electronic signature — where a report is marked signed, that is a record that a named, certified person attested they signed it themselves, elsewhere. It never holds your state e-reporting credentials: there is no field for them and no place to put them. And it never renders a verdict — it shows every value’s position against your permit and leaves the compliance judgment with your certified operator.

This is a product boundary, not a policy promise — but it is also the reason a whole category of sensitive data never enters our systems.

a. Account information. When someone creates an account we collect an email address and a password, and when they set up their profile, a full name, an optional phone number, and a role. Passwords are stored only as a cryptographic hash by our authentication provider; we never see or store the password itself. Creating an account also creates an organization record: company name, and optionally the organization’s phone, email, address, and state.

Employees are added by invitation. An invitation record holds the invited email address, the intended role, an expiry, and a single-use token. Weirlog does not email invitations — the owner copies the invitation link and hands it over directly. Treat that link the way you would treat the invitation itself: anyone holding it can read the invited email address, the intended role, and your organization’s name without signing in, because the invitation page has to show an invitee who invited them before they have an account to sign in with.

b. Operator certifications. If your firm tracks certifications, Weirlog stores the certification class, certification number, issue and expiry dates, continuing-education hours, and notes, tied to a named user. A certification number is a state-issued professional credential. We collect it because certification is checked against the date an analysis was performed, not against a label on a person — and because a released procedure snapshots the certification in force at that moment.

c. Your operational record. This is the bulk of what Weirlog holds, and almost none of it is about a person: clients, sites and their addresses and counties, treatment systems, permits and permit limits, monitored parameters, watch levels, visits, samples, laboratory results, readings, plant events, observations, standard operating procedures, computed reports, equipment, and maintenance logs.

Most of these records carry who did it — who collected the sample, who took the reading, who entered it, who acknowledged the observation, who authored, approved, or released a procedure, who recorded the event, who attested the report. Several carry free-text notes, and a plant-event record carries who an operator says they reported an incident to, by what method, and when. Anything a user types into a notes field is stored as typed.

d. Documents you upload. Weirlog has one document store, used today for Emergency Management Plans, in a private bucket that is scoped per organization. The app asks for PDF and Word files — the file picker is set to offer them — but that is a convenience and not a restriction: the store itself does not check the file type or cap the file size, so what it holds is whatever your people send it. We cannot see inside these files, and we do not restrict what they contain — if a plan lists home phone numbers or an after-hours call tree, that is what we hold. Reads are served through short-lived signed links.

e. Permit PDFs you import — read, then discarded. When you import a permit, the file is read in memory, the fields are extracted, and the file itself is never stored and never leaves our servers. Only the extracted values — permit number, facility name and address, county, limits — are saved.

f. Unsaved field entries on your own device. So a technician can log readings at a plant with no signal, unsent entries are queued in your browser’s local storage under a single key. A queued entry holds a locally generated identifier, the system and parameter, the value and its qualifier, the sampling point, the time it was taken, the visit it belongs to, and — for a correction — the reason. It holds no name, no email address, and no location. Entries are removed once accepted by the server; rejected ones are kept locally with the server’s reason so they are not silently lost.

g. Pages cached for offline use. The installed app caches a small offline page and the most recent rendering of your home screen and the facility screens you use. Those cached pages contain your organization’s data — facility names, readings — and are stored on that device. They are purged whenever the app detects you are no longer signed in.

h. Error reports. When the application fails, an error report is sent to our error-monitoring provider. It contains the error, the page address it happened on, and a trail of the routes visited just before. Page addresses in Weirlog are built from opaque identifiers, not from facility names. It also contains, where the database refuses a write for a reason we cannot explain to you, the database’s own error text — which can name a table, a column, and sometimes the value that was rejected (a parameter code, a timestamp, a limit row). That text is the whole reason the report is worth sending: without it the report says only that something refused a reading. Personally identifying data is explicitly disabled in this integration, and no session recording, no performance tracing, and no user profiling is enabled.

We are stating this as a list because “we may collect” language would be less useful than the truth.

Weirlog does not collect, and has no field, table, or column for: your location or your device’s location; advertising identifiers; device fingerprints; browsing history outside Weirlog; contacts; photographs, video, or audio; microphone or camera input; biometric data; dates of birth; government identity documents; Social Security numbers; payment card numbers; or health information.

The application requests no device permissions at all — no location, no camera, no microphone, no contacts, no push notifications.

The Weirlog application contains no analytics or tracking software. We have not built in product analytics, session replay, heatmaps, an advertising pixel, a tag manager, an attribution SDK, or a third-party cookie, and nothing in the application reports what you do inside it to anyone. We do not track you across other apps or websites, we do not build advertising profiles, and we do not sell or share your personal information with anyone for advertising or for their own purposes. No data broker receives anything from us. Our hosting provider measures traffic to the site the way any host does; that is described in section 7.

Weirlog sets only the cookies its sign-in system needs to keep you signed in and to refresh your session. There are no analytics cookies and no advertising cookies, which is why you are not asked to dismiss a consent banner.

Beyond those cookies, the application stores on your device only: the offline draft queue described above, and the offline page cache described above. Signing out and clearing your browser’s site data removes both.

We use it to run the service you are paying for, and for nothing else: to authenticate you and keep your organization’s data separated from every other organization’s; to record, correct, and preserve your field ledger; to compute reports and observations from your own permit configuration and your own readings; to send the notifications described in section 7; to answer support requests and to investigate faults; to keep the service secure and to detect abuse; and to meet our own legal obligations.

We do not use your data to train machine-learning models, and Weirlog contains no generative AI. Its trend warnings are ordinary least-squares arithmetic over your own readings, shown with their inputs.

Weirlog runs on four outside services. Each processes data on our instruction, for us, to deliver the product — none of them receives your data for its own purposes, and none of them is an advertising network.

Notification emails. When Weirlog raises observations, it sends one digest email per organization per delivery pass — never one per observation — to the roles your organization has chosen for notifications, which are owners and admins unless it changes the set. The digest repeats the observation text as written. Delivery is suppressed during your organization’s quiet hours, which default to 8:00 p.m. through 7:00 a.m. judged in the Indiana time zone unless your organization configures a different one.

Authentication emails. Confirming a new account, resetting a password, and changing a sign-in address are sent by our authentication provider. These are the only messages sent to an address that does not yet belong to an established account.

One outbound lookup that is not a service provider. When someone with setup authority uses “Start from a PWSID” to add a drinking-water system, Weirlog queries the EPA’s public Envirofacts registry for that system’s public record. The request originates from our servers and carries only the public water-system identifier being looked up — nothing about you, your account, or your organization. The EPA is a public data source here, not a processor of your data.

We do not add providers quietly. If we bring on another one that handles your data, this list changes before it does.

Designated Hoss Automation staff can enter an organization’s workspace to provide support. While that is happening, the application displays a persistent banner naming the organization being viewed, on both the desktop and the mobile layout, so the question “whose data is on this screen” is never ambiguous.

We do not currently retain a history of that access. The application records an access in progress — one row naming the staff member and the organization — and that row is deleted the moment the session ends or is replaced when the same staff member opens a different organization. So there is no log of past access to give you, and we are saying so rather than promising a record that does not exist. If we build a retained access log, this section will say so before it starts running.

We access your workspace only to operate, support, or secure the service, or where we are legally required to.

A regulatory record belongs to the utility that produced it, not to the vendor storing it. Weirlog is built on that assumption.

Any owner or admin can download the organizational record at any time, without asking us: a single archive of twenty-two tables, each named in a plain-text README inside the archive — clients, sites, systems, permits, permit limits, watch levels, parameters, readings, samples, visits, plant events, observations, reports, procedures and their drafts, operator certifications, users, equipment, PM schedules, and PM logs — as CSV files. Nothing about that export requires our permission or our continued existence.

Filed documents are not in the export. The export writes CSV and never reaches the document store, so the Emergency Management Plans and similar files you uploaded are absent from it — as bytes and as a listing. They are still yours; ask us at the address in section 15 and we will provide them separately. We would rather say this here than let you discover it from an archive you opened during an audit.

Four tables are excluded by name in the README, with a reason each: the support-access row described in section 8, email delivery plumbing, pending invitations, and the log of account-closure requests. Three further tables are absent without being named there — your organization’s own record, the index of filed documents, and the list of platform administrators.

The field ledger is append-only by design. A reading, once recorded, cannot be edited or deleted — the database refuses both. A correction is a new record that supersedes the old one and carries the reason; both rows survive. Computed reports, released procedures, plant events, and filed documents are likewise retained rather than removed. This is the property that makes the record defensible years later, and it is the product’s central promise.

We therefore keep your operational record for as long as your organization has an account with us, and we do not run automatic deletion or expiry against it. That is a deliberate choice, not an oversight: the records Weirlog holds are subject to your own statutory retention obligations, which run for years — commonly three years for NPDES monitoring records, five years for microbiological and turbidity analyses, and ten years for chemical analyses, with longer periods where a regulator extends them or where records are under a legal hold. Deleting on a schedule of our choosing would put you in breach of yours.

We do not currently enforce those clocks for you. Weirlog classifies each monitored parameter by retention type, but that classification is a label today, not an automated purge, and Weirlog does not compute or act on an earliest-permissible-deletion date. Your organization remains responsible for its own retention schedule. If we build automatic enforcement, we will say so here before it starts running.

Account records — names, email addresses, phone numbers, roles, certifications — are kept while the account is open, and are handled on closure as described in section 11.

You may close your own account from inside the application at any time: open Account and choose Close my account. The screen tells you exactly what is deleted and what is kept before you confirm.

To close your organization’s whole account, or to ask about someone else’s, write to nick.hochstedler@hossautomation.com from an address on the account, or ask any Hoss Automation contact you already work with. We will acknowledge within five business days and complete what we can within thirty days.

Here is exactly what happens, including the parts that are not simple.

When you write to us, immediately and always: we deactivate the logins you name so no one can sign in; we stop all notification email; and we send you the records export described in section 9 together with the filed documents that export does not contain, so your compliance record is in your own hands before anything else happens.

Closing your own account from inside the application is different in one respect: it happens at once, and we do not send you an export first — you are closing a login, not the organization’s account. The organization’s record stays where it is, and any owner or admin can still export it at any time from the Team screen. If you are the only person in the organization, download the record before you close; once your sign-in is gone, nobody can. Any member may close their own account this way, with one exception: if you are the organization’s only owner and anyone else is still working here — including someone who has only been invited so far — the application refuses, until another member has been made an owner or the outstanding invitations have been revoked, so the organization is never left without one. An owner or admin may ask us to close another member’s account.

Personal data we can delete on request: operator certification records, pending invitations, a member’s phone number, and your organization’s own contact details. One caveat on certifications: when a procedure is released, the certification in force at that moment is copied into the released procedure as part of its provenance. Deleting the certification record does not remove that copy, and we do not alter a released procedure.

Closing your own account from inside the application deletes your certification records with it, without asking anyone else first — they are your certifications, and this section already promises they are deletable on request. If your organization needs them for its own compliance file, export the record (section 9) before you close.

What we cannot delete, and why we are telling you instead of promising it. The record names the person behind each entry — who took and entered every reading, who recorded each plant event, who filed each document — as a reference to that person’s user record, and the database refuses to remove or blank any of them. So anyone who has ever taken or entered a reading, recorded a plant event, or filed a document cannot have their user row or their sign-in account removed: the attempt fails outright rather than partly succeeding. For those people we do what is actually executable — we deactivate the member so the account resolves to no organization, we ban the login so it cannot be used to sign in, and we retain the name and the attribution columns. We also keep the sign-in email address itself: it is the identity the retained attribution belongs to, and it lives in the same account record the ledger refuses to remove.

The legal basis for keeping them, named. 40 CFR 122.41(j)(2) requires the records of monitoring information to include the individual who performed the sampling or measurement and the individual who performed the analyses, and requires those records to be retained for at least three years. A monitoring record that could be stripped of the person who produced it would not be the record that rule describes. The append-only ledger is how we enforce that, not why it exists — the requirement would stand if the database allowed the change. We keep the name and the attribution columns for as long as the operational record itself is retained under section 10, which is commonly longer than the federal minimum.

The operational ledger is the same story at scale. Readings, samples, reports, plant events, and released procedures are the record your firm and its customers may be legally required to retain, and the database is built to refuse their deletion. On request we will either (a) hand the record back to you in full — the export plus the filed documents — and then remove the organization’s data from our systems where the retention obligation has expired or has been transferred to you in writing, or (b) where you or your customer must keep it with us for a stated period, retain it and confirm to you in writing what remains, why, and until when. Where the record must be destroyed rather than retained, that is done by us, deliberately, outside the application, because the application itself has no path that performs it. We will not silently keep data you asked us to delete, and we will not silently destroy a record you may be required to produce. You choose; we do it and confirm it.

Two further limits. Documents you filed — including anything personal inside them — are retained with the operational record and are covered by the same choice above. And where the person whose data is at issue is a contact at your customer rather than one of your own people, we act on your organization’s instruction, because that data is yours to control, not ours.

Depending on where you live you may also have rights to access, correct, port, or restrict the processing of your personal data, and to object to it. Use the same address; we do not charge for these requests and we will not treat you differently for making one.

Every table in Weirlog carries the organization that owns it, and access is enforced in the database itself by row-level security — not only in application code — so one organization cannot read another’s records even through a direct API call. Filed documents live in a private store scoped by organization and are served only through short-lived signed links. Data is encrypted in transit. Passwords are stored only as hashes, by our authentication provider.

No system is perfectly secure. If a breach affects your data we will notify you and any regulator that must be told, without undue delay.

Weirlog is workplace software for licensed and supervised operators. It is not directed to children, and we do not knowingly collect personal information from anyone under 18. If you believe a child’s information has reached us, write to us and we will remove it. Where that information sits inside a record the ledger will not let us remove, section 11 applies and we will tell you exactly what we could and could not do.

If we change this policy we will update the effective date above, and for any change that materially affects what we collect, who receives it, or how long we keep it, we will tell account owners directly before it takes effect.

Hoss Automation LLC · Greenfield, Indiana