Technology
What we do with your data, and what we never do.
Every build runs inside your environment. The practical consequence is that most of the security questionnaire answers itself: your cloud, your region, your identity provider, your retention policy. What follows is the part that is ours to commit to.
| Control | What we commit to |
|---|---|
| Where it runs | Your cloud account or your own hardware, in your region. Nothing runs on our infrastructure after handover. During discovery, read access is scoped narrowly and revoked at the end of the fortnight. |
| Tenancy boundary | Your cases, patterns and confidence scores never leave your tenancy, are never pooled with another client's, and are never used to improve anything outside your instance. What we carry between engagements is method, not data. |
| Identity | Sign-in through your identity provider, with MFA enforced by your policy. Radexus engineers hold a builder role with no approval rights: they can change how a play works and cannot approve a write. |
| Write safety | No write reaches a system of record without a named approver from your side, per play, per field and per value threshold. Dry run first. Full audit trail. Rollback window of thirty days. |
| Personal data | PII masked at extraction and contact details tokenised before any model sees them. Dealers and reps see only their own accounts, enforced when the data is read, not at the screen. |
| Model training | No client data trains any model, ours or a provider's. Providers are configured with training opt-out where offered and avoided where not. |
| Grounding | A claim whose source cannot be resolved is dropped before it reaches a person. Enforced as an evaluation gate in code, not as a prompt instruction. |
| Retention and expiry | Run logs retained on your schedule, seven years by default for audit. Prior values on written fields retained thirty days. Knowledge carries a half-life and stale claims are held out of decisions rather than silently reused. |
| Residency | Per-step model routing to in-region endpoints, sovereign providers or open weights in your VPC. Documented per play and versioned. |
| Access after handover | Only what the assurance agreement names, revocable by you at any time. Cancel assurance and the system keeps running without us. |
| Certifications | The system inherits your cloud's certifications, because it runs inside your account under your controls. We are not asking you to accept a Radexus certification in place of your own: your auditors assess an environment you already own. |
What we will not build. Anything where a model's output affects a person without a human in the path: clinical decisions, credit decisions, employment decisions. Write-back always has a named approver, and the approver is never us.
The questions your risk committee will ask.
Taken from real questionnaires. If yours has something not answered here, send it and we will answer in a week.
Where exactly does our data live?
In your own cloud account, in the region you choose, under your own encryption keys. The system is deployed into your tenancy. After handover, no component runs on Radexus infrastructure and no client data is stored on it. During discovery, read access is scoped narrowly, time-boxed and revoked at the end of the fortnight.
Is our data pooled with other clients?
No, and it is not an architectural possibility rather than a policy promise: there is no shared tenancy, no shared store and no shared index. Each client instance is separate infrastructure in separate accounts. What we carry between engagements is method: connector code, resolution logic, evaluation harnesses. Never data, never patterns learned about you.
Do you train models on our data?
No. Not ours, not a provider's. Providers are configured with training opt-out where it is offered and avoided where it is not. This is contractual, not a setting, and it survives a change of provider.
What happens to personally identifiable information?
PII is masked at extraction. Contact details are tokenised before any model sees them, so a name or a phone number is replaced by a reference that only your instance can resolve. Row-level access is enforced when data is read rather than at the screen, so a dealer or a rep can only ever see their own accounts.
Can your engineers see or change our data?
Our engineers hold a builder role: they can change how a play works, and they cannot approve a write into any system of record. Role separation is enforced in your identity provider, not in our policy document. Access after handover is limited to what the assurance agreement names, and is revocable by you at any time without our involvement.
How do you prevent a model from writing something wrong into our ERP?
Four controls in sequence. A dry run showing the exact diff before anything is enabled. A named approver, set per play, per field and per value threshold. A complete audit trail with the prior value retained. A thirty-day rollback window your team can execute without us. No write path exists that bypasses all four.
What are your data residency options?
Three, and they can be mixed per step within one play. A frontier model pinned to an in-region endpoint. A sovereign provider with EU or Indian residency by design. Open-weight models running inside your own VPC where nothing leaves your tenancy at all. Air-gapped deployment is possible where the policy requires it.
How do you handle DPDP, GDPR and CCPA obligations?
Because the system runs in your environment on your data, you remain the controller and we act as a processor under the terms of the signed agreement. We support deletion and access requests through the same lineage that makes numbers traceable: if a record was read, we can show where it went. Data processing agreements and standard contractual clauses are executed before discovery begins, not after.
What is retained, and for how long?
Run logs on your schedule, seven years by default where audit requires it. Prior values on written fields for thirty days. Knowledge itself carries a half-life, so stale claims are held out of decisions rather than silently reused. Every retention period is a setting you own after handover.
What happens if you go out of business?
The system keeps running. It is deployed in your account, licensed to you perpetually and irrevocably, with no licence server, no phone-home and no kill switch. Source escrow is available where your legal team requires it, and the stack is deliberately ordinary so that another firm could pick it up.
Will this pass our penetration test?
It should, and you should run one. There is no Radexus-hosted surface to test after handover: what your testers are assessing is an application in your own cloud, behind your own identity provider, with your own network controls. We will support the test and fix what it finds as part of the build.
What will you refuse to build?
Anything where a model's output affects a person without a human in the path: clinical decisions, credit decisions, employment decisions. Write-back always has a named approver, and the approver is never us.
Send us your questionnaireMost of it will be your own cloud's answers, because the system runs there.
Factory