Primary store
The principal persistent store for a defined data category and environment.
Deletion schedule applies directly.
Data Location and Residency
Know where data is handled — and what each location actually means
Storage, processing, replicas, backups, access, transfers, failover, and exports are separate concepts with separate evidence. Each carries its scope, status, effective date, limitations, and owner. None of them proves the others.
Scope invariant
A map pin is not a residency guarantee. A location claim must explain what data, why it is there, who can access it, what copies and exceptional paths exist, and how the statement is verified.
Definition Boundary
Eleven Terms That Are Routinely Collapsed Into One
Most misleading location claims are not lies. They are one true statement presented as if it answered a different question. The third column is where that happens.
| Term | Definition | What it does not prove |
|---|---|---|
| Data location | A named country, region, facility jurisdiction, or provider region associated with a defined handling activity. | Does not by itself prove residency or exclusive handling. |
| Primary storage | The approved principal persistent store for a defined data category and environment. | Replicas, indexes, caches, logs, and backups remain separate. |
| Residency | A scoped operational or contractual commitment that designated data is stored or handled within defined locations and conditions. | Meaningless unless it states data, copies, processing, access, transfers, and exceptions. |
| Processing location | Where a service, provider, or authorized human performs an operation on data. | May differ entirely from storage location. |
| Access location | Where an authorized person or service can reach data. | Remote access may cross a border without moving the primary store. |
| Replication | Additional copies maintained for availability, performance, integrity, or recovery. | Replica location and consistency model are separate evidence. |
| Backup / archive | Copies retained for recovery, continuity, legal hold, or approved archival purpose. | Deletion and access timing differ from primary storage. |
| Transfer | Disclosure, remote access, transmission, or movement across an organizational or geographic boundary. | The technical path and the legal mechanism are distinct things. |
| Failover / disaster recovery | Temporary or sustained use of alternate systems or locations after defined conditions. | Emergency paths require explicit scope and governance — they are not silent exceptions. |
| Customer-controlled destination | A location created by customer export, integration, download, forwarding, or local storage. | Customer responsibility begins at the defined handoff. |
| Data localization requirement | A legal, regulatory, contractual, or policy condition on location or handling. | ZoikoTime does not determine whether one applies to you, and gives no legal advice. |
A worked example
"Primary storage in the EU" can be entirely true while a replica sits elsewhere for recovery, a support engineer accesses the record remotely from another country, diagnostic metadata is processed by a provider in a third, and a customer-configured export delivers a copy to a destination we never see. Each of those is a separate statement requiring separate evidence.
Region & Provider Availability
Nine Availability States, Styled Honestly
Planned and Unavailable never use current styling. Selecting a filter narrows evidence — it does not confirm availability, legal suitability, or a contractual commitment.
Current — generally availableCurrent — limited availabilityCustomer-specificUnder reviewPlannedUnavailableNot applicableSupersededWithdrawn
Product / moduleData categoryEnvironmentCustomer typeRegion / countryLocation activityProviderStatusEvidence level
| Public region | Provider category | Product scope | Activity | Reviewed | Availability |
|---|---|---|---|---|---|
| EU | Contracted cloud | Core platform | Primary storage | 28 Jun 2026 | Generally available |
| EU | Contracted cloud | Core platform | Backup & recovery | 28 Jun 2026 | Limited — eligibility applies |
| US | Contracted cloud | Core platform | Primary storage | 28 Jun 2026 | Generally available |
| APAC | Contracted cloud | Core platform | Primary storage | 20 Jun 2026 | Under review |
| UK | Contracted cloud | Core platform | Primary storage | — | Planned — not operational |
| Any | Any | Core platform | Exclusive in-country handling | — | Unavailable |
| EU | Support operations | Support access | Access location | 01 Jul 2026 | Customer-specific |
Illustrative public taxonomy. Region names are generic; no private region identifier, provider account, or customer deployment appears here.
Why "exclusive in-country handling" reads Unavailable
Because no current approved capability guarantees that every copy, every processing operation, every access session, every log, and every exceptional path stays within one country for any product scope. Marking it Unavailable is more useful than omitting the row.
What a provider name does not mean
A provider appearing against one service does not mean all services or all data categories use that provider. And a region name does not imply residency for all categories or all copies. Provider and subprocessor relationships link to current approved evidence rather than to a logo.
Data-Flow & Location Model
Ten Stages From Collection to Backup Expiry
Rendered as structured text rather than an architecture diagram, because a diagram either exposes topology or oversimplifies it.
| # | Stage | Location type | Access roles | Transfer relationship |
|---|---|---|---|---|
| 01 | Source & collection Approved input categories only | Customer region | Worker, authorized entry | None |
| 02 | Transmission Protected in transit | In transit | Service identities | Boundary crossing possible |
| 03 | Primary processing Core application operations | Processing region | Service identities | Within approved scope |
| 04 | Primary storage Principal persistent store | Storage region | Role-scoped | None in normal path |
| 05 | Derived processing Classification, reporting, security | Processing region | Service identities | Results may or may not persist |
| 06 | Integrations Customer-authorized connectors | Third-party | Per connector scope | Handoff — control ends |
| 07 | Exports Download, API, webhook, SFTP, email | Customer-controlled | Customer | Handoff — control ends |
| 08 | Retention Per record-type schedule | Storage region | Role-scoped | None |
| 09 | Deletion Scoped verification | Storage region | Platform | None |
| 10 | Backup expiry Separate schedule from deletion | Backup region | Recovery roles | None |
Stages 06 and 07 are highlighted because they are where platform control ends. Everything after a handoff is a customer-controlled or third-party destination, and revoking a connector does not erase copies already exported.
Worker-facing summaries use plain language and restate the collection limits. No worker-level record appears in any example on this page.
Primary Storage, Replicas, Caches & Backups
Five Kinds of Copy, Each With Its Own Location
Persistent and temporary copies are exposed separately, because they behave differently on deletion and on recovery.
Replicas
Additional copies for availability, performance, integrity, or recovery.
Location and consistency model stated separately.
Search & index copies
Derived structures supporting retrieval.
Rebuilt rather than restored; may lag.
Caches & temporary data
Short-lived copies supporting performance.
Distinct expiry, not covered by retention schedules.
Backups & archives
Retained for recovery, continuity, legal hold, or approved archival purpose.
Deletion and access timing differ from primary.
Backups, archives & legal holds
Partially publishedObjective: make recovery copies inspectable without implying they behave like the primary store.
- Stated per backup set
- Protected object, environment, region or provider category, retention, encryption, access roles, restore path
- Legal hold
- Suspends ordinary expiry. A held copy survives a deletion request, and that is disclosed rather than hidden.
- Timing
- Backup expiry runs on its own schedule — deletion from primary storage does not delete a backup instantly
Limitations: restore evidence and recovery testing route to Platform Reliability, where that evidence is currently under review. Backup existence is not restore proof, and no RPO or RTO is published here.
Retention, deletion & location retirement
CurrentObjective: govern the end of the lifecycle, including what happens when a whole location is retired.
- Distinct outcomes
- Deletion, anonymization, archive expiry, backup expiry, legal hold
- Location retirement
- Migration plan, verification, evidence, and a preserved record of the retired location
- Verification
- Scoped — we state what was verified rather than claiming universal erasure
Limitations: no "deleted everywhere immediately" claim. Provider backup and retirement schedules may affect completion timing, and customer-controlled copies are outside our reach entirely.
Processing & Support Access
Where Services and People Act on Data
Remote access and data movement are not the same event, and this page does not treat them as one.
| Processing category | Results persist? |
|---|---|
| Core application operations | Yes — to primary storage |
| Deterministic time classification | Yes — as a reviewable record. Not AI. |
| Analytics & reporting | Yes — governed outputs |
| Security operations | Yes — logs, minimized |
| Reliability operations | Yes — telemetry, service-scoped |
| Support operations | Case records only |
| AI-assisted functions (Kairos) | No new record created. Kairos decides nothing and cannot create a residency commitment. |
Access model
- Access type, purpose, eligible role, region, and approval stated per category
- Least privilege, session control, logging, and review apply throughout
- Customer support, security response, reliability operations, and implementation services are distinct access types
- Break-glass access has a named authority, a reason, a time limit, and an audit record
No individual employee location is published, and no support-access location promise is made without staffing and operational evidence.
Transfers & Mechanisms
The path and the basis are separate
Every transfer record states
- Origin and destination
- Data category and purpose
- Recipient or provider category
- Frequency
- Whether it is a normal or exceptional path
- Status, and the approved transfer-mechanism field
What we do not do
ZoikoTime does not determine whether a transfer mechanism is legally applicable to your situation, and does not guarantee its sufficiency. Mechanism status and legal wording are authority-gated, and restricted legal documents use controlled or contractual access.
Where platform control ends
Exports, email delivery, downloads, APIs, webhooks, and SFTP are separate channels with separate handoff points. Customer responsibility begins at the defined delivery or access boundary.
Revocation does not erase already-exported copies. Turning off a connector stops future delivery; it does not reach into a destination we never controlled. Not all integrations support the same region or transfer model.
Failover, Disaster Recovery & Migration
Exceptional Paths Are Published, Not Hidden
A commitment with an undisclosed emergency exception is not a commitment. Alternate locations are documented at a safe level before they are ever used.
Failover & emergency paths
Partially publishedObjective: disclose that alternate locations exist, under what authority they activate, and what happens afterwards.
- Documented
- Normal and alternate region or provider categories, trigger classes, approval authority, customer notice, state, affected data categories
- Governed
- Return-to-primary, reconciliation requirements, and cleanup or retirement of the alternate path
- Authoritative elsewhere
- Recovery methods route to Platform Reliability; live events route to System Status
Limitations: exact security-sensitive topology is never published. But there is no hidden emergency exception to a published commitment — if an exceptional path can move data, it is disclosed here at a safe level.
Migration & region change
CurrentObjective: make movement between locations a governed, reversible, evidenced event.
- Lifecycle
- Request, assessment, approval, preparation, execution, cutover, verification, retirement of the source location
- Customer role
- Approve scope, timing, and business checks. Platform provides method, validation, rollback, and evidence.
- Preserved
- Migration history, including the prior location and the date it was retired
Limitations: migration is not instantaneous, and backups created before a migration retain their original location until their own expiry. That interval is disclosed rather than glossed over.
Responsibility Model
Eight Areas, Three Parties
| Area | ZoikoTime | Your organization | Provider / shared |
|---|---|---|---|
| Region availability | Verify capability, evidence, dependencies, and status. | Confirm eligibility, requirements, and contract. | Provider service and evidence may constrain availability. |
| Data categorization | Define product categories and purposes. | Configure lawful and appropriate use, and local labels where allowed. | Shared review for custom integrations and content. |
| Storage & processing | Operate approved platform scope. | Select available options and control downstream copies. | Provider delivers contracted service; duties remain scoped. |
| Access | Enforce roles, approvals, and audit. | Assign authorized users and protect credentials. | Shared for support, incident, and implementation access. |
| Transfers | Document platform flows and approved mechanisms. | Assess legal and contractual needs, and customer-controlled transfers. | Provider and recipient evidence and contracts may apply. |
| Exports & integrations | Provide governed handoff and audit where supported. | Own destinations, recipients, retention, and downstream controls after handoff. | Third-party responsibilities remain explicit. |
| Migration | Provide method, validation, rollback, and evidence. | Approve scope, timing, and business checks. | Shared provider and implementation dependencies. |
| Deletion | Execute platform schedules and scoped verification. | Manage customer copies and legal or contractual holds. | Provider backup and retirement schedules may affect completion. |
Professional boundary. Product information is not legal advice, and not a determination that your configuration satisfies any localization or transfer law. Authorized humans approve region availability, exceptions, cross-border access, transfer mechanisms, migrations, and contractual commitments — Kairos may retrieve or summarize governed location evidence where approved, but it decides nothing and cannot create a residency commitment.
Change History & Notices
Location Changes Are Published, Not Absorbed
| Item | Previous | New | Reason | Effective | Owner |
|---|---|---|---|---|---|
| APAC primary storage | Generally available | Under review | Provider evidence reassessment | 20 Jun 2026 | Privacy & Platform |
| UK primary storage | — | Planned | Approved roadmap intent; no date committed | 28 Jun 2026 | Platform |
| Legacy "EU data stays in the EU" wording | Published | Withdrawn | Unsupported — did not account for support access or backups | 02 Jun 2026 | Trust & Governance |
| Backup region statement | v2 | Superseded by v3 | Scope clarified per data category | 28 Jun 2026 | Privacy |
Illustrative change log. Unsafe, stale, or unsupported claims may be removed first, followed by a retrospective correction record.
The withdrawn row is a real category of correction: a statement that was true about primary storage but was being read as a claim about all handling. Withdrawing it was more honest than qualifying it further.
Controlled Residency Review
Request Customer-Specific Location Evidence
Your configured regions, enabled providers, migration history, and applicable contractual position are customer-specific and cannot be published. This is the route to them.
Review states
ReceivedNeeds clarificationUnder reviewApprovedPartially approvedDeclined with reason categoryExpiredWithdrawn
Direct Answers
Nine Location Questions
That depends on the product, data category, environment, and your configuration. The availability matrix shows current public options with their scope, provider category, and status — and every entry covers one activity only. Primary storage, replicas, caches, indexes, and backups each have their own location.