Data and security

This page explains how Rixe handles your data: how one organisation is kept apart from another, what is sent to outside services, how credentials are stored, how long each kind of data is kept, and how you get your data out or have it deleted. It describes what the product does today, as built — use it when you answer a security questionnaire or a data-protection request.

#Each organisation is isolated in the database

Every table that holds customer data carries the organisation it belongs to, and the database itself enforces who may read it, using PostgreSQL row level security:

• Each request runs in its own database transaction that is stamped with your organisation. The database only returns rows of that organisation, whatever the query asks for.
• The rule is forced on the table owner too, so not even the application's own database user can bypass it.
• Client portal users are narrowed one level further, to the single workspace they were given, by the same mechanism.
• Asking for another organisation's record by its ID returns "not found", so IDs reveal nothing about who else uses Rixe.

Isolation is covered by automated tests that try to read and write across organisations and expect to fail.

#What leaves our systems

Measurement. Your prompts are sent to the AI engines you measure, exactly as you wrote them; that is what measurement is. See How measurement works.

Answer analysis. To find which brands an answer names, and in what tone, Rixe uses a language model. Only the answer text and the list of brand names are sent to it — no customer name, no email address, no workspace identifier, nothing that identifies who is asking.

Payments. Card details are entered on the payment provider's checkout and stay there. Rixe never receives or stores a card number. See Billing and subscription.

#How credentials are stored

Secrets are never returned to the panel once saved: a screen shows that a key or secret exists, not its value. Data exports leave credential tables out entirely.

#Data classification

Every table in Rixe's database is labelled with the kind of data it holds:

The build fails if a new table is added without a label, so the inventory cannot quietly fall out of date.

#How long data is kept

Each table has a retention period. A job runs every night at 03:40 UTC and deletes rows older than their period, organisation by organisation. A few of the periods that matter most:

The owner can ask for a shorter period on any table, between 30 and 2,555 days. A longer setting never extends the default, and billing records cannot go below seven years. There is no form for this in the panel yet; contact us and we will apply it.

#Exporting your data

The owner can request a full export of the organisation's data. The export:

• covers everything created in the chosen period (one year by default),
• includes up to 10,000 rows per table,
• comes with a manifest of row counts per table, so you can check nothing was left out,
• leaves out credentials and tokens, and the engines' raw response envelopes.

There is no export button in the panel yet; contact us and the owner will receive it. For reporting data you use every day, the API and Looker Studio connector are the better route.

#Deleting your organisation

The owner can ask for the organisation to be erased. The request is confirmed by typing the organisation's name exactly, and then:

1. A 7-day grace period starts. During it the request can be cancelled and nothing is removed.
2. After the grace period the data is removed, and the whole process is finished within 30 days of the request.

What happens to each kind of data:

To start a deletion, contact us from the owner's account.

#Access inside Rixe

Within your organisation, what each person can see and change is set by their role and enforced by the API — see Team and roles. Every change made in the organisation is written to a tamper-evident audit log — see Governance. For central control over who can sign in, use Single sign-on.

#Related pages

• Team and roles
• Governance
• Single sign-on
• Billing and subscription