Security
Security and data custody
Who can see what, where the boundary is enforced, and what we have not built yet.
Trust
Built for the questionnaire before you send it.
A platform holding well construction, water level and production data is one of the automated systems your risk and resilience assessment has to cover. We publish the package so it drops straight into your appendix.
Your data stays yours
Every table, every attachment, every audit entry exportable at any time in open formats. No lock-in, no hostage-taking on exit, and no training models on customer data — written into the contract, not just the marketing.
District isolation in the database
Tenant separation is enforced by the database engine itself, not by application code, so no application bug can cross the boundary. Tested on 26 September 2026 by 873 database assertions on a clean rebuild; every one of the 152 cross-tenant attacks among them was refused — and an independent review is the next step, not a claim we make yet.
Nothing writes to your plant
Telemetry is a one-way outbound push from an agent inside your perimeter. There is no inbound path, no cloud-to-control-network session, and no ability to change a setpoint.
Records that can replace paper
Write-once storage, cryptographic hashing of every document and an immutable audit trail — the conditions a district needs before a digital copy can lawfully become the record of authority.
Retention and legal hold
Configurable per record class, with holds for pending litigation, claims and records requests that override every deletion rule. Nothing is ever hard-deleted by default.
Accessible by design
Built to WCAG 2.1 AA from the first commit — maps navigable by keyboard, charts with data-table equivalents, nothing encoded in color alone. Public agencies have a deadline and vendor applications get no exemption.
Architecture
The boundary is in the database, not the application
District isolation is enforced by PostgreSQL row-level security. Every table carries a district key, row-level security is enabled on every table without exception, and access is deny-by-default: a row no policy admits is simply not returned. A bug in application code should not be able to cross the boundary, because the database engine refuses the query rather than trusting the application to filter it. That is the design; the tests below are how we check it, on every change; and an independent review is the next step rather than something we claim already.
The database is tested the way an adversary would use it. On 26 September 2026, 873 assertions ran against a clean rebuild of the schema — 152 of them cross-tenant, every one refused — written from the position of “how would I get another district’s data out of this while holding a valid login”: reads, writes, aggregates, joins, revoked memberships, expired contractor assignments, attempts to move a record into someone else’s district, and every permission a title can hold, tried by someone whose title does not hold it. The application release of that date passed twenty-nine test suites of its own. A failure fails the build rather than merging quietly.
Titles and permissions
Access is by title. Every district starts with the ten built-in titles below; each is a set of named permissions, and a district owner can rename a title or change what it grants from the Titles page. Each permission is enforced in the database’s own row policies, so the interface cannot grant more than the record allows.
The default titles
| Default title | Can | Cannot |
|---|---|---|
| Owner | Everything, plus billing and the retention schedule | — |
| Manager | Everything an engineer can, plus the team, district settings and the audit log | Billing, the retention schedule, legal holds, or removing records |
| Engineer | Edit records, approve extractions, set baselines and thresholds | Billing, the team or district settings |
| Operator | Log field tests, edit records and upload documents | Change baselines or scoring weights |
| Contractor | Upload and file only against assigned work orders, while they are live | See the rest of the fleet, or read precise well locations |
| Consultant | Engineer-level work in each district that grants it | Anything not granted |
| Records officer | Legal holds, redacted exports, authorized purges | Edit technical records |
| Asset manager | Read wells, records, work orders, forecasts and board reports | Change anything, or see precise well locations |
| Analyst | Read wells, records, work orders, forecasts and board reports | Change anything, or see precise well locations |
| Auditor | Read everything, including superseded records and the audit log | Write anything at all |
Nothing writes to your plant. Telemetry is a one-way outbound push from an agent inside your perimeter. There is no inbound path, no cloud-to-control-network session, and no ability to change a setpoint. Water sector guidance requires operational technology connections to be denied by default, so we designed for that first rather than retrofitting it after your assessment asks.
Controls
Every control below carries its state, because a list that does not is a list you cannot buy from. Available means it is running in the product today and we will show it to you. Pilot means it is built but has only been exercised on our own data. Planned means it is not built — it is on this page because it is on your questionnaire, and you should know now rather than in week six.
| Control | State | What is actually there |
|---|---|---|
| Encryption in transit and at rest, United States data residency | Available | TLS to the browser. The managed database and the document store are encrypted at rest and run in a single US region. |
| District isolation enforced in the database | Available | Row-level security on every tenant table, so a query carrying the wrong district returns nothing regardless of what the application asks for. This is the control the adversarial tests below attack on every change, and the one the independent review will be aimed at. |
| Tenant-scoped audit log of writes, approvals and permission changes | Available | A database trigger records actor, role, action, table, record, the before and after values, request id and IP address. The application cannot skip it. |
| Retention schedule and legal hold, with no default hard delete | Available | Documents carry a retention class and a legal-hold flag, and a trigger refuses to delete a document that is under hold. Nothing is hard-deleted on a schedule. |
| Title-based access with a read-only auditor | Available | The ten built-in titles in the table above, editable per district. Every permission is enforced in the database’s row policies, not only in the interface; the auditor title holds read permissions only. |
| security.txt and a monitored security contact | Available | Published at the canonical location, pointing at [email protected]. |
| No training on customer data | Available | Stated in the privacy notice and written into the district agreement as a term, not a setting. |
| Ask IQ reads with the asker’s own access | Available | Ask IQ’s lookups run in the app with the signed-in person’s session, so row-level security decides what it can see, and it has no tool that writes to the record. Each question and answer is kept in the district for audit, readable by the person who asked and by titles with audit access; it cannot be edited from the platform. Questions asked in the public demonstration are not stored. |
| Field-level classification and coordinate precision degradation | Pilot | Well locations carry a public precision that defaults to section level. It is applied where records are read. There is no bulk export path to enforce it on yet, so we cannot claim it holds on every path. |
| Single sign-on and SCIM deprovisioning | Planned | Not built. Sign-in today is a one-time link and a six-digit code by email. |
| Phishing-resistant multi-factor authentication | Planned | Not built, and we will not describe what exists as MFA: a link and a code delivered to the same inbox are one factor, not two. |
| Tamper-evident audit log, exportable to your SIEM | Planned | The log above is complete but is not hash-chained, and there is no SIEM feed. Both are on the roadmap. |
| Full-fidelity self-service export | Available | One button in Settings produces a single archive: every table as RFC 4180 CSV, the document files themselves, the full audit log, and a manifest naming anything the running account could not read rather than dropping it silently. No charge, no notice, no request to us, and nothing needed from us to read it afterwards. |
| Documented key management | Planned | Keys are managed by the platform provider under their own published practice. We have not written and published ours. |
| Published vulnerability disclosure policy and software bill of materials | Planned | security.txt exists; the policy it should point to and the SBOM do not yet. |
| Annual third-party penetration test | Planned | None has been carried out. The independent isolation review described below will be the first outside look at this system, and it is not a penetration test. |
Continuous review, and what comes next
Review here is continuous, not a one-time event. Every change to the database is first applied to a rebuild of production’s exact structure, where it must pass the adversarial isolation suite and its own tests; only then is it applied to production, and production’s structure is checked afterward against what was tested. Every release is held to the same bar, and this page is updated when the results change.
That is our own review. The next step is a review of the isolation boundary by an engineer independent of the people who wrote it. It has not been carried out yet, so there is no report to send, and we will not imply that one exists. What we can send now is its scope: what the reviewer will be asked to attack, what we will tell them we have not built, and what we have agreed in advance would justify stopping a launch. Ask for it and we will send that, and the findings when they exist.
We will tell you plainly what is not built yet rather than letting a questionnaire imply it is. Ask, and you get the current list.
Report a vulnerability
Vulnerability disclosure policy 1.1 · effective 12 October 2026
BoreLogix builds Waterwell IQ for public water agencies. If you believe you have found a security vulnerability in anything we run, we want to hear from you, and we will treat the report as the help it is.
Scope
In scope:
- borelogix.com and app.borelogix.com
- the Waterwell IQ API: the functions under our Supabase project that the app and the telemetry agent call
- the district-side telemetry agent published in our repository
Out of scope:
- services we use but do not operate (Cloudflare, Supabase, GoDaddy, MailerLite, GitHub) — report those to the operator under its own policy
- findings from automated scanners with no demonstrated impact; missing best-practice headers on pages that carry no data; rate-limit behavior; version banners
- anything that requires physical access, social engineering of our people or customers, or denial of service
Our commitment to you (safe harbor)
When you conduct research in good faith and consistent with this policy, we will:
- not pursue or support legal action against you for accidental, good-faith violations of this policy, and consider your research authorized under applicable computer-use laws (including the Computer Fraud and Abuse Act) and exempt from restrictions in our Terms of Use that would otherwise prohibit it;
- work with you to understand and resolve the issue quickly;
- credit you by name, if you want it, once the issue is fixed.
If legal action is started by a third party against you for activity that followed this policy, we will make it known that your actions were conducted in compliance with it. This policy does not authorize you to act against anyone other than BoreLogix, and it does not bind third parties.
What we ask of you (good faith)
- Test only against accounts you own and the public demonstration district at app.borelogix.com/?demo=1. Never access, change, download or keep another organization’s data; if you reach it by accident, stop, delete what you took, and tell us.
- Do not degrade the service: no denial of service, no request flooding, no automated scanning at a rate that affects other users.
- Do not use social engineering, phishing, or physical attacks.
- Report promptly, through the channel below, and give us a reasonable time to fix the issue before you publish anything about it. We ask for 90 days from your report; if we need longer we will say so and why.
- Keep the details confidential until the fix ships.
How to report
Email [email protected] — it reaches the founder directly; [email protected] works too — with what you found, the steps to reproduce it, and the impact you believe it has. If you want the conversation encrypted, say so in your first message and we will arrange it. Both addresses are published in our security.txt.
What happens next
- We acknowledge your report within two business days.
- We give you a first assessment — confirmed, not reproducible, or out of scope — within ten business days, and we may ask you for more detail.
- For a confirmed vulnerability we agree a fix timeline with you, keep you informed as we work, and tell you when the fix ships.
- With your permission we list you under acknowledgments on this page.
What this is not
We do not run a paid bug bounty and do not offer rewards. We say so here rather than imply one.
This policy is adapted from the disclose.io core terms, released under CC0 1.0.