Privacy Policy

1. Scope and roles

This policy describes how the SOESimple building-management portal, connected edge servers, dashboards, protocol services, alarm services, and optional Analytics Lab (together, the Service) handle information. It applies to portal and edge users, access requesters, customer administrators, and people whose accounts are administered by a customer.

Customers control the building, equipment, site, dashboard, alarm, schedule, and operational information they submit or cause connected edge servers to collect. Clayton Plymill processes that customer data to operate the Service. [LEGAL REVIEW REQUIRED: identify the parties' controller/processor roles, including whether Clayton Plymill independently controls account, security, support, and product-operations data.]

This policy does not replace a customer's notices to its employees, tenants, contractors, or other people whose information the customer enters in the Service.

2. Information handled by the Service

Account and access information includes names or display names, usernames, email addresses, password hashes, roles, permissions, customer and site assignments, MFA enrollment state and encrypted authenticator secrets, local-display PIN hashes, session identifiers and expiry information, login timestamps, access-request reasons, IP addresses, browser user-agent strings, and security/audit events. Passwords, session tokens, device tokens, and local-display PINs are stored as hashes where implemented; the portal MFA seed is encrypted at rest by the application.

Building and operational information can include customer and site names and addresses, building locations and weather coordinates, edge-server and device identifiers, IP and network configuration, BACnet and Modbus devices and points, point metadata and values, trends and history, virtual and weather points, equipment definitions, dashboards and graphics, schedules, alarms and alarm actions, commands, command results, priority-array writes, temporary overrides, equipment status, energy calculations, environmental readings, and weather observations.

Technical information can include application and container logs, API and audit records, request method and path, response status, request duration, IP address and user agent, device heartbeats, certificates, synchronization cursors and statistics, error and health records, diagnostic snapshots, database state, backups, and exported files or reports.

The current code does not implement payment processing, advertising technology, cross-site behavioral advertising, or a third-party web analytics SDK. It does not implement SSO/OIDC yet. Email addresses are stored for accounts and access requests, but automated transactional email delivery is not currently enabled.

3. How information is collected

Information is provided by users and customer administrators, generated through use of the Service, read from configured building-automation networks and equipment, calculated by the application, or received from connected edge servers. Edge servers poll configured BACnet and Modbus systems and obtain weather data from Open-Meteo when weather features are configured. Portal and edge hosts proxy map tiles from OpenStreetMap for Live Map displays. The portal receives authorized edge state, configuration snapshots, alarms, health information, and point history over authenticated HTTPS and MQTT/TLS connections.

4. Uses of information

The Service uses information to authenticate users and devices; apply roles and site permissions; display and operate building systems; collect and graph trends; evaluate and manage alarms; execute and audit commands; synchronize edge and portal state; provide weather, energy, reporting, backup, recovery, diagnostics, security monitoring, and support functions; maintain service reliability; and comply with legal or contractual obligations.

Optional Analytics Lab jobs use selected equipment metadata and bounded point-history evidence to create deterministic reports. When separately enabled, a locally hosted language model may generate explanatory text from that bounded job context. The model has no direct database, portal API, MQTT, field-device, or control access. The feature and its language-model component default to off in new deployments.

Customer data may be used to improve machine-learning-assisted analysis and reporting provided within that customer's portal. This use is limited to improving the customer's own reports, insights, and experience. SOESimple does not currently use one customer's identifiable data, or aggregated or de-identified derivatives of customer data, for cross-customer benchmarking, general product improvement, or training models shared across customers or offered as general-purpose models.

5. Edge storage, cloud storage, and synchronization

Edge servers store local configuration, identities, permissions, dashboards, equipment and point metadata, alarm state, and operational data in service-owned SQLite databases and local files. High-volume point history is stored in local ClickHouse. Edge servers can continue collecting data during an internet outage. Upload cursors advance only after portal acknowledgement, so unsent observations remain locally available and are replayed after connectivity returns. The code does not define one universal maximum duration for this offline buffer; it depends on local history retention, storage capacity, configuration, and when synchronization succeeds.

The portal stores identity, customer, site, access, audit, command, snapshot, dashboard, and related operational data in PostgreSQL (with SQLite retained as a supported local store in the code). Portal point history is stored in ClickHouse in the production design, with PostgreSQL compatibility storage and bounded cleanup paths. Redis, when Analytics Lab is enabled, carries job identifiers and is configured as temporary in-memory storage.

6. Retention

Retention differs by data type and deployment configuration:

• Portal point-history samples default to 365 days. The production portal ClickHouse schema applies a 365-day deletion TTL. The PostgreSQL compatibility path defaults to deleting samples older than 365 days and also applies a default cap of 5,000,000 rows per site. Administrators may configure these values.
• Edge ClickHouse point history defaults to 365 days under the deployed schema. Legacy edge SQLite sample history is disabled by default; where legacy data exists, maintenance behavior is deployment-dependent.
• Successfully transmitted edge observation-outbox rows default to one hour before cleanup. Unsent rows remain for retry until transmitted or otherwise removed.
• High-volume portal heartbeat and synchronization events default to 30 days. Other appliance events default to 365 days.
• Terminal command payload bodies are pruned after a configured interval while command status metadata is retained. The precise deployed interval must be confirmed from deployment configuration.
• Analytics Lab completed reports default to 365 days. Failed or cancelled jobs and compact evidence packages default to 30 days.
• Portal and edge backup jobs keep the newest 14 local backup archives by default. This is a count, not a guaranteed number of days. Backup schedules affect the corresponding time span.
• Off-site portal backup replication is copy-only and does not delete remote objects when local archives expire. No enforceable off-site deletion period was found in the reviewed code. [BUSINESS/LEGAL DECISION REQUIRED: define off-site backup retention and deletion.]
• Container JSON logs rotate at 10 MB with five files in the reviewed Compose configuration. Other host, application, audit, security, database, and device logs may have different or unspecified retention.
• Account records are disabled rather than erased through the current portal administrator removal action. Sessions are revoked. Historical audit and privacy-acceptance records remain. No self-service account deletion workflow is currently implemented.
• Sites can be disabled and archived before deletion. An unlinked edge server can be explicitly deleted together with its portal-side history, snapshots, commands, certificates, events, and synchronization metadata. Edge-local copies and backups are separate and are not automatically erased by that portal action.
• Dashboards, graphics, configuration, user preferences, alarm records, audit logs, access requests, customer/site metadata, certificates, exports saved by a user, and other records without a cleanup rule are retained until an authorized administrator/customer deletes them, the deployment is removed, or a contractual/legal process applies. No fixed automatic period was found for these records.

Deletion from an active database does not immediately remove copies from existing backups. Copies can remain until the applicable backup is deleted or expires. Restoring an older backup can temporarily restore records that were deleted later and may require the deletion to be applied again.

7. Cookies and local browser storage

The Service uses first-party, HTTP-only session cookies for authentication. Session cookies use SameSite protections and are configured as Secure in production. Portal sessions default to 12 hours and may be refreshed during activity. The browser also uses local or session storage and first-party cookies for functional choices such as theme, display preferences, active views, and legacy portal-token compatibility. These technologies are used to provide the Service, not for third-party advertising.

8. Providers, integrations, and disclosures

The reviewed application can communicate with:

• the customer's configured BACnet and Modbus networks and devices;
• connected SOESimple edge servers through authenticated HTTPS and MQTT/TLS;
• Open-Meteo for configured weather observations;
• OpenStreetMap's tile service through a same-origin server proxy for map imagery;
• infrastructure used to host the portal, databases, MQTT broker, certificates, backups, and optional off-site backup copies, including a documented Wasabi-compatible backup destination when configured; and
• customer-directed APIs, exports, or integrations enabled for a deployment.

No active payment processor, external identity provider, marketing analytics SDK, or cloud language-model API was found in the reviewed implementation. Planned integrations are not current data disclosures.

Information may also be disclosed to authorized customer administrators and users according to role and site assignment; to service providers operating infrastructure under appropriate terms; when directed by the customer; to investigate abuse or protect safety and security; or when required by law. The Service does not contain code that sells personal information or shares it for cross-context behavioral advertising. [LEGAL REVIEW REQUIRED: confirm the company's actual commercial practices.]

9. Customer administrators and authorized users

Customer and system administrators can create or disable accounts, assign roles and sites, reset MFA, view authorized audit information, and access customer building data within their scope. Users should contact their customer administrator for access changes. System administrators have broader operational access. The application applies role, organization, site, dashboard, and point-level checks, but authorized administrators may still view information needed to operate and secure the Service.

10. Security

The Service uses password hashing, hashed session and device credentials, encrypted portal MFA secrets, MFA requirements for privileged portal users, permission checks, authenticated device enrollment, TLS/mTLS for portal-edge transport where deployed, audit logging, rate limits, network isolation, and container hardening. No system is completely secure. These controls reduce risk but are not a guarantee against unauthorized access, loss, or misuse.

11. Exports, deletion, rights, and choices

Authorized users can export certain point/equipment data and reports. Exported files are controlled by the person or system that receives them and are not automatically deleted by the Service.

The current application provides administrator actions to disable users, revoke sessions, archive or delete sites, unlink/delete edge servers, and delete selected configuration. It does not provide a complete self-service privacy request, account erasure, or portable full-account export workflow. To request access, correction, deletion, restriction, or a copy of information, contact admin@soesimple.com and the relevant customer administrator. Rights depend on location, the customer's instructions, contractual obligations, and applicable law. Some information may be retained for security, audit, backup, legal, or contractual reasons.

Users may decline this policy by not creating an access request, not accepting after sign-in, and logging out. A user who does not accept the currently required policy version cannot use protected portal or edge functions. Essential endpoints remain available to view the policy, record a decision, complete required account-security setup, or log out. Declining does not automatically delete an account or previously stored information; contact the customer administrator or admin@soesimple.com for a deletion request.

12. Children

The Service is intended for business building-management use, not for children. [LEGAL DECISION REQUIRED: specify the minimum user age and any jurisdiction-specific children's privacy statement.]

13. International processing

Deployment hosts, connected customer sites, support personnel, and backup destinations may be in different jurisdictions. [LEGAL DECISION REQUIRED: identify hosting locations, transfer mechanisms, and whether international transfers occur.]

14. Changes and consent records

Each published policy has a version, effective date, content hash, and preserved text. The Service records the version a user accepts, the policy effective date and hash presented, acceptance time, source, and available request IP address and user agent. A later required version prompts for new acceptance and does not overwrite earlier acceptance records. Material-change notice obligations and the standard for requiring renewed consent are [LEGAL DECISION REQUIRED].

15. Contact

Questions and privacy requests: Clayton Plymill, admin@soesimple.com

Mail: Clayton Plymill, 5510 Old Hickory Blvd Ste B #1007, Hermitage, Tennessee 37076, United States