Privacy Notice
Target-deployment draft for client legal review. Effective date: [Client to insert effective date].
This notice describes the PotholeIQ target architecture; it is not yet a complete client privacy policy. Before launch, [Client legal entity] must identify itself as the controller/owner where required, complete its contact details and retention policy, and have counsel or the responsible privacy officer approve the adopted notice.
Do not add analytics, advertising, email/SMS vendors, public map services, integrations, or other processors without updating this notice and completing the client’s required review.
1. Who is responsible
[Client legal entity / department] operates this road-reporting service and is responsible for the information it collects through the deployed portal. Privacy contact: [privacy officer or data-protection contact]. Postal address: [client address].
2. What we collect and why
| Information | Why it is used |
|---|---|
| Operational case details: case ID, date/time, road address or map location, severity/routing and workflow information. | To receive, assess, route, manage, document, and close a road-condition report; to identify possible duplicates and show authorised staff the operational status. |
| Free-text description. | To help with initial submission and AI workflow only. In the target build it is transient and is deliberately stripped before Box, Supabase, generated documents, application storage, or security-log payloads are written. Do not include sensitive information. |
| Submitted photo evidence and crew after-photo evidence. | To assess the reported condition, support work planning, document repair work, and retain evidence under the client’s records process. |
| Images may contain people, vehicles, licence plates and camera metadata such as GPS coordinates. | The portal reads available GPS for location confirmation and prepares a new JPEG for privacy review. Automatic face blurring is supplemented by manual masking of remaining people and number plates before submission. New uploads default to processed images only; original retention requires an explicitly approved deployment policy. Neither detection nor user review guarantees removal of every identifying detail. |
| Optional reporter name and contact details, only when a person supplies them for an acknowledgement. | To attempt one acknowledgement during that submission request. In the target build, these details are intentionally not written to Box, Supabase, generated documents, application storage, or security-log payloads after the request finishes. |
| Essential technical and security information, such as request time, trace ID, authentication/rate-limit outcome, and the minimum network context needed to defend the service and investigate an incident. | To operate the portal securely, prevent abuse, troubleshoot failures, and meet incident-response obligations. Security logs must be configured to exclude report payloads, photos, contact details, credentials, and access tokens. |
If you choose not to provide optional contact information, you may submit anonymously. The portal cannot use information it does not retain to send later status updates or reliably retry a failed acknowledgement.
Optional acknowledgement delivery is off by default in the target deployment. If the client explicitly enables ALLOW_EXTERNAL_NOTIFICATIONS=true, the configured, client-approved email delivery provider receives the email address, case ID and acknowledgement content, not the photograph or submitted address. That provider becomes an additional processor and may have its own retention under the client’s contract. Provider acceptance does not guarantee inbox delivery. The application itself does not persist the reporter contact in Box, Supabase, generated documents, application storage, or security-log payloads in the target deployment.
3. Where the target deployment stores information
| Location | What is kept there |
|---|---|
| Client Box tenant | Processed pothole and optional damage photographs, processed after-photos, work order/review/final-closeout materials, and sanitized case metadata. Existing originals remain subject to the client’s access and retention policy; this change does not erase them. Target mode creates no public Box share links. |
| Client Supabase project | Operational case index and workflow facts: case ID, status/timestamps, road location/coordinates, routing, severity/duplicate data, repair/workflow fields, opaque Box IDs, audit events, and retention/legal-hold fields. It does not store image bytes, raw EXIF, reporter name/contact, access tokens, or Box URLs. |
| Client secret vault | Application and provider credentials/keys. It is not a case-data store. |
| Transient processing memory | A photo and intermediate processing files only while local AI, blurring, or document generation runs. The target deployment uses memory-backed temporary storage and cleanup paths; this is not a durable case database. |
| Client security logging/SIEM and provider backups | Redacted security events and provider/platform copies governed by the client’s configured log and backup settings. Backups are not a separate PotholeIQ database and may retain deleted information until the relevant backup window expires. |
4. How information is shared
Information is available only to authorised client staff and approved service providers needed to operate the selected deployment, including the client’s Box and Supabase environments and, only if explicitly enabled, the approved acknowledgement-email provider described above. It may also be disclosed where the client is required or permitted to do so by applicable law, including public-records, records-management, court, audit, or legal-hold obligations.
The target PotholeIQ build does not create public Box links and does not include third-party advertising or analytics scripts. A client’s WAF, hosting platform, map/GIS provider, email/SMS service, or future integration can change the data flow; each must be approved by the client and reflected in the adopted notice before it is enabled.
5. Retention and deletion
The application can record retention and legal-hold status but does not decide a retention period or automatically delete case evidence, operational records, backups, or security logs. [Client legal entity] must publish or link its adopted retention schedule here: [retention schedule / records policy link].
Records subject to a legal hold, public-records requirement, audit, dispute, or other legal obligation may be retained longer. Deletion from the active client system does not necessarily remove a record from provider backups until the configured backup-retention period ends.
6. Security
In the target deployment, data travels between the browser, the client’s security gateway, the private application container, Box, and Supabase over HTTPS/TLS. The client configures access controls, private networking, credentials in a vault, and provider permissions. These measures reduce risk; they do not make any internet service risk-free.
7. Cookies and browser storage
The target build uses essential, httpOnly, Secure, SameSite=Strict cookies for staff sessions and redeemed case access. It does not deliberately persist reporter contact details, report payloads, or bearer access tokens in browser storage. The client must disclose any cookies, WAF logs, consent tools, or analytics added by its own infrastructure.
8. Your choices and requests
Depending on applicable law, you may have rights to request access, correction, deletion, restriction, objection, or information about processing. Send a request to [privacy contact] and include enough detail for the client to locate the report. The client will evaluate requests under its legal and records-management obligations; some records may need to be retained or disclosed by law.
9. Changes to this notice
The client will update the adopted notice when the deployment, integrations, legal requirements, or retention practices materially change. The current page must show its effective date and client contact information.