Data residency

Moʻolelo treats data residency at the level of a data subject — an individual person — rather than at the level of a record. This matters when a single document mentions multiple people whose home jurisdictions differ.

Why subject-level residency

A wiki page authored by an EU employee may quote, mention, or reference colleagues in the US, India, and Canada. If you store that whole page in any one region, you've moved at least three data subjects' personal data across borders.

The conventional approaches don't fix this:

• Document-level residency — store each document in the region of its author. Doesn't help: the colleagues are still represented in the document body.
• Per-region copies of everything — replicate the whole corpus everywhere. Multiplies your storage cost and creates a compliance audit nightmare.

Moʻolelo's approach: store the document in one region, but extract the personally-identifiable fields (names, emails, IDs, …) into a regional vault keyed by the data subject's home region. Each personal-data field is replaced by an opaque token. The token resolves only in the data subject's home region.

A query that needs to display the actual name of a person whose home region is different from the query's region is a cross-region detokenize request, gated by an access-control check.

What's tokenized

Personal-data tokenization applies to:

• Names and aliases.
• Email addresses, phone numbers, instant-messenger handles.
• National identifiers, employee IDs, customer IDs.
• Free-text PII detected at parse time (Moʻolelo runs Microsoft Presidio over every chunk).

What's not tokenized:

• Source-system metadata (repo names, space keys, drive IDs).
• Structural metadata (file paths, heading paths, line ranges).
• Tenant IDs and instance IDs.

How the routing works

When the platform encounters a personal-data field during ingestion:

1. It asks the residency service which region the data subject lives in. The residency service knows this from your HRIS / IdP / corporate directory, with a fallback to a deployment default.
2. It calls the regional vault for that region to tokenize the field.
3. The token is what travels to the global graph and to the search index. The cleartext stays in the regional vault.

When a query needs the cleartext (e.g., to render a search result that mentions a person), the platform calls the regional vault to detokenize. The vault verifies that the calling user has source-system permission to see the underlying record before releasing the cleartext.

What this means for compliance

• Personal data of any individual physically resides only in the regional vault for that individual's home jurisdiction.
• The global graph and the search index carry tokens, never cleartext personal data.
• Cross-border data flows happen only at query time, only for fields the calling user is already permitted to see, and only via signed authorized requests that the vault audit-logs.
• Removing all data about a specific person ("right to be forgotten") is a single delete in the regional vault — every token everywhere else becomes unresolvable, which is the same as deleted from the consumer's perspective.

Single-region deployments

A single-region deployment doesn't need cross-region tokenization. The platform still uses the same vault interface internally, so when you later add a second region the migration is a configuration change, not a re-architecture.

Confidence levels

The residency service tells the platform how confident it is about a person's home region:

• Explicit — set by an authoritative input (HRIS record, IdP claim, manual administrator entry).
• Inferred — derived from signals like source-system region, IP heuristics, organizational mapping. Reasonable but not authoritative.
• Default policy — no signal available; the deployment default applies.

Lower-confidence resolutions are treated more conservatively: a default-policy resolution doesn't release cleartext to a cross-region detokenize request unless the operator has explicitly configured it to. Audit logs record the confidence at the moment of decision.

What you configure

When you onboard a tenant, you tell Moʻolelo:

1. The list of regions you operate.
2. The default residency policy for unresolved subjects (typically: their data stays in the region where it was first observed).
3. The HRIS / IdP integration for resolving subjects to their home region — or, for smaller tenants, a static mapping table.

Day-to-day operation requires no per-record decisions. The platform tokenizes during ingestion and detokenizes at query time, automatically.