Privacy

For each client we expect to process business operational data: inbound and outbound messages, contact and lead records, appointment and task records, bid documents, and content drafts. We do not seek consumer financial account data, health records, or government identifiers, and the platform is not designed to store them.

During the current pre-pilot period, Arnexyia does not require real client system records to validate its core safety gates. Synthetic fixtures and controlled test data are used for release testing; any future client data connection requires explicit authorization and separate readiness gates.

Every record is bound to a single client tenant identifier. Access is enforced at the database layer by row-level policies keyed to tenant membership, not only in application code.

Cross-tenant access attempts, including instructions embedded in message content that name another client, are treated as isolation violations: blocked, logged as an audit event, and raised as an exception.

Operational records are intended to be retained for the life of the engagement plus a defined tail period for audit purposes. Audit events are intended to be retained longer than operational records, because they are the evidence of what the system decided and why.

Exact retention periods are unset in this draft and must be agreed with counsel and with each client before any live engagement. Nothing is deleted automatically today.

When you submit the founding-client form, we store what you enter plus campaign attribution (UTM parameters, referring page and landing page).

To limit spam and abuse, the server also stores a pseudonymous device/network fingerprint derived from request characteristics. It is used to throttle repeated submissions. It is pseudonymous, not anonymous: it could be linked back to a device or network in combination with other information.

The retention period for intake submissions and this fingerprint is TBD pending counsel review and an approved production retention policy.

Arnexyia uses platform service providers for hosting, model evaluation, workflow runtime and operational telemetry. These providers are tracked in a subprocessor register and require security/contract review before pilot approval. Separately, no client-owned business system is currently connected for real-data processing; client provider connections require explicit client authorization.

A model provider used for drafting or classification is treated as a subprocessor. Arnexyia's current model path is bounded, has no external-action tools, and is configured not to use model calls as an authorization decision.

If a client chooses to connect a Google Workspace account, Arnexyia will request only the Google API scopes required for the enabled workflow and will begin with read-only access wherever the workflow permits.

Arnexyia's use and transfer of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. Google user data will be used only to provide or improve the user-facing workflow the client authorized, not for advertising or sale.

Client connections are intended to use per-user authorization so one client's Google credentials and data are not shared with another client. A connected user must be able to revoke the connection, and production use of restricted Google scopes remains subject to Google's applicable verification and security requirements.

We intend to support access, correction, export and deletion requests. Data export and destructive deletion are both classified red in the authority matrix: they are performed by a person with an audit record, never autonomously by the system.