Government reference architecture — EMENA

How an EMENA public-sector body deploys Operayde for citizen-data processing under PDPL + NDMO (KSA) or GDPR + NIS2 (EU), with an air-gapped topology and multi-classification handling.

Regulatory context

An EMENA public-sector body processing citizen data operates under tightly-scoped regimes with no cross-border latitude. In the Kingdom the National Data Management Office (NDMO) sets the data-classification framework (public / internal / confidential / top-secret) and PDPL sets residency and consent obligations. In the EU, NIS2 obliges essential entities to keep operational technology under governance and reportable within 24 hours; GDPR governs any processing of personal data by public authorities. Operayde deploys as an air-gappable appliance so a ministry, tax authority, or public health service can run AI copilots on citizen data without any part of the compute or evidence chain leaving the sovereign perimeter.

Architecture

The body installs an appliance in an accredited government datacentre. In an air-gapped deployment there is no tunnel to the Operayde control plane at all — the appliance runs standalone, policy updates arrive via a signed offline bundle on media, and audit chains are exported to the body's own long-term evidence store. In a semi-online deployment (typical for EU public-sector NIS2 posture), the appliance uses the reverse tunnel only for signed policy bundles and daily Merkle root deposit; no prompt or citizen data leaves the datacentre.

Workspace-runtime handles inference and RAG against the body's policy corpus, statute text, and internal case files. Appliance- gateway partitions traffic by classification: a citizen-service copilot sees only public and internal knowledge; an investigative analyst copilot may access confidential; secret scopes are pinned to physically-separated appliance instances.

Citizen-data attestation chain

Every model call that touches a citizen record emits an audit event with the citizen record's classification and the actor's clearance level. The event is Merkle-linked and Ed25519-signed on the appliance:

{
  "event_id": "01JC7DH4N8P2Q5R9T1V3W6Y0Z4",
  "prev_hash": "4d5a8b1c2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b",
  "hash":      "9f8e7d6c5b4a3928170615043f2e1d0c9b8a7968574635241302f1e0d9c8b7a6",
  "signature": "MEQCIF...base64url-Ed25519...zA==",
  "actor":     { "subject": "case-worker-1428", "realm": "tenant:tax-authority-ksa" },
  "tenant_id": "tax-authority-ksa",
  "action":    "gateway.inference",
  "resource_uri": "model://local-70b-ksa",
  "outcome_status": "ok",
  "occurred_at": "2026-07-13T13:47:19.331Z"
}

The daily Merkle root is co-signed and deposited into the body's own long-term evidence store — the ministry retains cryptographic proof of completeness independent of Operayde.

Data residency

Every gateway invocation is evaluated against operayde.residency before any inference. For a KSA public-sector deployment the virtual key's residency list is ["sa-central"] and any attempt to route across the border is denied:

package operayde.residency
 
import rego.v1
 
default allow := false
 
allow if {
    input.source == "gateway"
    some region in input.params.virtual_key.residency
    region == input.ctx.region
}
 
reason := "region not in allowed residency" if {
    not allow
}

Multi-classification handling

The appliance ships with three logical partitions:

Unclassified / public — RAG corpus is public statute and policy text; models may include a locally-hosted 8B open-weights model plus an external model if the body's classification policy permits.
Restricted / internal — RAG corpus adds internal case notes and departmental knowledge; models are constrained to locally-hosted weights only; external models are denied by OPA.
Secret — physically-separated appliance instance with no reverse tunnel, offline signed policy bundles, its own signing key and its own Merkle chain. No cross-appliance traffic is permitted.

Every request carries a classification tag; the appliance-gateway denies any cross-classification routing at the policy boundary and signs the denial into the audit chain.

How this maps to the regulations

Requirement	Operayde surface	Evidence
PDPL Art. 29 + NDMO (KSA) — classification & residency	Per-classification appliance partition; residency OPA rule	Signed denials of cross-region calls; classification tag on every audit event
GDPR Art. 35 + NIS2 Art. 21 — DPIA & operational governance	Cosign-signed OPA policy bundle; operator step-up MFA	Policy-hash attestation per day; step-up event log
NIS2 Art. 23 — 24-hour incident reporting	Fleet control plane telemetry + audit chain	Timestamped Merkle root; audit chain export

Deployment topology

For the secret partition, the topology is fully air-gapped: policy bundles arrive via signed offline media, audit exports leave on signed offline media, and no network path exists from the appliance to the Operayde control plane. For unclassified and restricted partitions, the reverse tunnel carries only fleet telemetry and daily Merkle roots — never prompt or citizen data. Every OPA policy change is cosign-signed before the appliance loads it, and every operator session requires MFA step-up every five minutes of privileged work.