data protection · document Q-D1 · revision 1 · 2026-11-01
Who holds what, on whose instruction.
This page sets out how Q Division processes personal information on your organisation's behalf, in the schedules a data processing agreement is made of. The signed terms issued with your agreement govern where they differ.

the route
Where a record goes.
Four points on the route of any record your organisation places in Q.
in
It enters
As a document or content your organisation places, a request one of its people makes, or data a connector it has enabled brings in.
rest
It rests
In your organisation's tenant: PostgreSQL rows under forced row-level security, with files in object storage keyed to the tenant.
out
It goes out
Only what a run needs, to a model provider your policy allows, or to a system your organisation has connected, and the receipt says which.
end
It ends
By erasure with a receipt, or when its retention period runs out. Approval records and spend lines stay as evidence.
the schedules
Five sheets.
Parties, processing, measures, sub-processors, and rights. Each sheet says where it stands today.
schedule 1
Parties and roles
in service
Your organisation decides what is processed and why. Q Division processes it on those instructions.
- controller
- Your organisation, the legal entity that holds the account and the keys.
- processor
- Q Division, a unit of Elementary Digital, Mauritius.
- instructions
- Your organisation's agreement, the configuration its administrator sets, and the requests its people make through the service.
- contact
- q@elementary.mu
- sub-processors
- Listed in schedule 4. Each acts for Q Division under written terms no less protective than these.
- duration
- For the term of the agreement, then thirty days in which the export is available, then erasure.
schedule 2
The processing
in service
What is processed, for what, and about whom.
- subject matter
- The work your organisation asks Q to do in and across its systems, and the record of that work.
- nature
- Retrieval over the content placed, generation of answers and documents, actions in connected systems after approval, and the keeping of the journal, receipts and spend lines.
- purpose
- To do the work asked, to keep its record, to bill for it, and to keep the service secure and working. Not training or evaluation of models unless your organisation has opted in.
- data types
- Documents and content as placed, including the names and contact details they contain; the account details of your organisation's people; run records, approvals, receipts and spend lines; request logs and traces; memories a user's work produces.
- data subjects
- Your organisation's people, and its customers, tenants, suppliers and others named in the content it places.
- special categories
- Not sought. Where your organisation's content contains them, they are processed only as part of that content, on its instruction.
schedule 3
Security measures
in service · not yet certified
The measures that are in force today, and the one that is not.
- isolation
- Row-level security forced in PostgreSQL with a runtime role that is not a superuser. A request without tenant context sees no rows.
- approvals
- Protected actions stop for a person. Each approval is bound to the tenant, the person, the run and the exact action version, and expires unused.
- the journal
- Every step, decision and cost of a run is appended in sequence. Entries are never rewritten; runs replay from it.
- guards
- Input guards against injection and malformed requests; output guards against leaked personal data and claims without a source; cost guards for budgets and rate limits.
- transport
- Calls to model providers and connected systems are made over HTTPS.
- operator access
- Q Division operators reach a tenant's records only for support.
- certification
- None yet against an external standard. It will be stated here and on the security page when there is one.
schedule 4
Sub-processors
in service · locations to be confirmed
The categories of sub-processor the service uses, with the provider in service today. The named list with its locations is issued in the signed terms, and your organisation is told before a new one handles its data.
- hosting platform
- Runs the service. Railway, as deployed today.
- database
- PostgreSQL, hosted with the platform, holding every tenant's rows under row-level security.
- object storage and index
- Files and the search index. Supabase.
- cache and queues
- Short-lived working state and rate limits. Redis; cached responses are kept at most seven days.
- model providers
- Those your organisation's policy allows for a task. Configured today: OpenAI and Anthropic. The receipt names the one used.
- connected systems
- Only those your organisation enables, under its own agreements with them. Google Workspace and ClickUp today.
locations and the named list · issued in the signed terms
schedule 5
Rights, requests and incidents
in service · assurance export in design
What your organisation can ask for, and what Q Division does when something goes wrong.
- export
- Per document with its derived records, up to 8 MB per operation, on request through the service.
- erasure
- Removes the document's chunks, artefacts and memories at once and marks it deleted. The receipt lists the obligations the system cannot attest alone, and stands as awaiting external evidence until an operator attests each with a hash of the evidence.
- requests from individuals
- Addressed to your organisation as controller. Q Division assists within the time the law allows.
- audit
- The journal and the receipts are the record. An assurance export for one department and one period is in design.
- incidents
- Your organisation is told without undue delay when Q Division becomes aware of a personal data breach affecting its data, with what is known and what is being done.
- training
- Off unless your organisation has opted in. Evaluation likewise.
revisions
The record of this document.
- revision 1
- 2026-11-01 · first full schedules; sub-processor locations to be confirmed
- revision 0
- 2026-10-31 · placeholder pending the full document
Questions about data protection go to q@elementary.mu.

