Jira progress: loading…

AI-DIAL

EPAM AI DIAL — Governed AI Execution Gateway

1. Purpose

EPAM AI DIAL is the governed AI execution gateway within the ZAYAZ architecture.

Its role is to provide a standardized infrastructure layer between ZAYAZ AI orchestration and approved external or internally hosted model deployments.

AI DIAL MAY provide execution capabilities such as:

provider and model abstraction;
standardized model invocation;
model/application access control;
request and token limits;
execution-level cost limits;
load balancing across approved deployments;
provider failover inside approved routing boundaries;
request and response interception;
execution telemetry;
observability;
integration of additional AI providers over time.

AI DIAL is not the intelligence authority, commercial authority, routing-policy authority, evidence authority, or audit authority of ZAYAZ.

The fundamental architecture rule is:

ZAYAZ governs the intelligence. AI DIAL industrializes its execution. CUEM governs its commercial consumption.

2. Architectural Boundary

AI DIAL sits below ZAYAZ reasoning, evidence, governance, identity, and policy layers and above approved model-provider endpoints.

It MUST NOT become a parallel architecture that replaces or duplicates:

ZARA;
ZAAM;
ZADIF;
GRPE;
AIGS;
Pergamum Pulse;
the ZAYAZ AI Intelligence Layer;
compliance-grade ZAYAZ RAG;
TrustGate / validation components;
ALTD / ZAR;
CUEM.

The intended split is:

Capability	ZAYAZ Authority	AI DIAL Responsibility
User intent	ZARA / ZAAM	None
Agent selection	ZADIF	Execute selected workload
ESG reasoning	ZARA / governed specialist components	None
Regulatory interpretation	Pergamum Pulse / standards-aware ZAYAZ intelligence	None
Compliance-grade RAG	ZAYAZ AI Intelligence Layer	Consume prepared context
Evidence authority	ZAYAZ evidence and trust architecture	None
AI governance	AIGS	Enforcement point where configured
Trust / validation	ZAYAZ validation and trust components	None
Geographic policy	GRPE	Execute inside approved region
Model abstraction	ZAYAZ model governance + DIAL	Runtime provider abstraction
Endpoint load balancing	Policy-bounded by ZAYAZ	Yes
Provider failover	Policy-bounded by ZAYAZ	Yes
Raw execution telemetry	Operational telemetry	Primary source
Commercial entitlement	CUEM	Enforce derived runtime limit only
Usage accounting	CUEM	Measurement source only
Allowances / quotas	CUEM	Enforce approved execution quota where delegated
Customer price	CUEM	None
Provider / AI COGS	CUEM Cost Ledger	Supply execution measurements / estimates
Invoice aggregation	CUEM	None
Audit semantics	ALTD / ZAR	Raw execution trace source

3. Core Runtime Principle

ZAYAZ decides:

WHAT should be done
WHY it should be done
WHICH evidence may be used
WHICH user and E-C-O scope requested it
WHICH AI risk controls apply
WHERE processing is legally allowed
WHICH model capability is required
WHICH fallback behavior is permitted
WHICH commercial entitlement applies

AI DIAL executes:

HOW the approved workload reaches an approved model deployment
WHICH approved endpoint inside the allowed routing boundary serves the request
HOW execution limits are enforced
HOW endpoint-level failures are handled
HOW operational telemetry is emitted

CUEM interprets:

WHAT commercial usage occurred
WHICH allowance is consumed
WHETHER overage applies
WHAT attributable cost occurred
WHAT customer charge, if any, results

4. Reference Architecture

5. Headless-by-Default Deployment

ZAYAZ SHOULD use AI DIAL as headless infrastructure.

The normal production deployment SHALL expose ZAYAZ interfaces to users, not a generic DIAL chat product.

Preferred production scope:

Required:
- AI DIAL Core
- approved model/provider adapters
- required regional storage/cache dependencies
- observability integration
- ZAYAZ-specific interceptors where appropriate

Optional:
- restricted administrative tooling

Not part of normal ZAYAZ client UX:
- generic DIAL Chat
- generic prompt workspace
- generic conversation workspace

This preserves ZAYAZ:

white-label control;
identity semantics;
prompt contracts;
governance;
telemetry;
commercial accounting;
user experience;
auditability.

6. Identity

The AI DIAL integration SHALL preserve canonical ZAYAZ identity.

The authoritative identities remain:

eco_number;
user_id;
uom_number where applicable.

ZAYAZ MUST NOT introduce tenant_id as a canonical business identity merely to fit gateway or provider conventions.

Provider-native tenant identifiers MAY exist where technically required, but they remain external-system identifiers.

7. Upstream Identity Minimization

The full E-C-O Number SHOULD NOT be forwarded to upstream model providers unless functionally required.

Where correlation is necessary, ZAYAZ SHOULD use an opaque execution subject key.

The mapping between the opaque execution subject and canonical E-C-O identity remains inside the ZAYAZ trust boundary.

AI DIAL MAY receive the minimum identity context required for:

authorization;
execution-class selection;
tracing;
quota enforcement;
incident investigation.

It SHOULD NOT become the canonical client registry.

8. Authentication

Human users authenticate through ZAYAZ IAM.

AI DIAL SHOULD normally receive service-mediated or short-lived execution identity rather than user-managed permanent gateway credentials.

Internal ZAYAZ services SHOULD use workload identity or controlled service credentials.

White-label backends MAY use governed machine credentials, but the credential itself MUST NOT replace:

E-C-O attribution;
user attribution where a human initiated the action;
partner attribution;
payer/beneficiary resolution in CUEM.

9. AIExecutionEnvelope

ZADIF SHOULD NOT send ungoverned provider requests directly to AI DIAL.

A governed AI request SHOULD be represented by an AIExecutionEnvelope.

Conceptual example:

{
  "request_id": "airq-...",
  "trace_id": "trace-...",

  "identity": {
    "eco_number": "ECO-...",
    "user_id": "usr-...",
    "uom_number": null
  },

  "business_context": {
    "intent": "csrd.report.generate",
    "framework": "ESRS",
    "framework_version": "pinned-version",
    "reporting_period": "2026"
  },

  "governance": {
    "ai_risk_class": "high",
    "data_classification": "confidential",
    "human_review_required": true,
    "residency_policy": "EU_STRICT",
    "tenant_ai_policy": {
      "policy_id": "client-ai-policy-...",
      "version": 7,
      "policy_hash": "sha256:..."
    }
  },

  "evidence": {
    "bundle_ref": "evidence-reference",
    "manifest_hash": "sha256:...",
    "version_pinned": true
  },

  "execution_policy": {
    "capability_profile": "reasoning-high",
    "latency_class": "interactive",
    "fallback_allowed": true,
    "cross_region_fallback_allowed": false
  },

  "commercial_preflight": {
    "entitlement_decision_ref": "cuem-decision-ref",
    "reservation_ref": null
  }
}

The exact runtime schema SHALL be versioned.

9.1. Resolved Tenant AI Policy

The governance.tenant_ai_policy object SHALL identify the resolved client AI policy that was in force for this execution, using a stable policy identity, immutable version, and content hash.

The term tenant AI policy describes the client-scoped operational policy. It does not introduce tenant_id as a canonical ZAYAZ business identity; the governed organizational scope remains the applicable eco_number.

The policy pin SHALL follow the same evidence principle used for client-approved delegation policy:

client / E-C-O scope
      ↓
resolved AI settings and governed defaults
      ↓
policy_id + version + policy_hash
      ↓
AIExecutionEnvelope
      ↓
AIGS / execution controls
      ↓
Replay Manifest

The execution path MUST consume the pinned resolved policy. It MUST NOT re-read mutable "current settings" during execution and later claim those settings governed the historical request.

The policy hash SHOULD be calculated from a versioned canonical representation of the resolved policy so that replay can demonstrate exactly which client AI settings were effective, including settings such as:

permitted model capability classes;
AI risk restrictions;
data-classification constraints;
human-review requirements;
provider/model restrictions;
fallback permissions;
tool-use permissions;
retention or privacy controls;
applicable residency constraints.

Where the authoritative AI-policy subsystem maintains additional policy evidence, the envelope MAY carry a reference to that evidence in addition to the required ID, version, and hash.

10. ZAYAZ Retains RAG Authority

Compliance-grade RAG SHALL remain ZAYAZ-controlled.

AI DIAL MUST NOT become the default authority for:

regulatory retrieval;
evidence entitlement filtering;
framework interpretation;
source-authority ranking;
version pinning;
provenance;
citation integrity;
evidence sufficiency.

Preferred flow:

User request
   ↓
ZADIF
   ↓
ZAYAZ retrieval policy
   ↓
Pergamum Pulse
+ canonical Docusaurus knowledge
+ authorized client evidence
+ validated ZAYAZ data
   ↓
EvidenceBundle
   ↓
AIGS / governance
   ↓
AI DIAL
   ↓
Approved model

AI DIAL MAY execute a model against prepared context.

It does not decide which regulatory evidence is authoritative.

11. Evidence Fail-Safe

For grounded workflows:

retrieval failure
OR insufficient authorized evidence
OR version mismatch
OR integrity failure
        ↓
BLOCK GROUNDED GENERATION

AI DIAL provider fallback MUST NOT convert an evidence failure into speculative generation.

12. ZADIF and AI DIAL

ZADIF remains the authoritative AI dispatcher.

ZADIF MAY determine:

agent;
task type;
capability requirement;
context requirement;
tool requirement;
evidence requirement;
AI risk;
latency class;
model capability class;
fallback permission.

AI DIAL MAY determine inside the approved policy:

which approved deployment serves the request;
how load is distributed;
whether an equivalent approved endpoint is retried;
provider-specific protocol translation;
request-limit enforcement.

AI DIAL MUST NOT independently choose a lower-assurance task policy merely because another model is available.

13. Model Capability Profiles

Application code SHOULD request governed model capability profiles rather than hard-coded provider model names.

Examples of logical capabilities may include:

fast-low-cost
structured-extraction
reasoning-standard
reasoning-high
long-context
multimodal
assurance-review
local-private

The governed model registry maps a capability to one or more approved DIAL deployments.

A provider alias that can silently change underlying model behavior is insufficient for historically assured execution where exact replay or validation requires a pinned version.

14. GRPE Owns Region Selection

GRPE remains authoritative for geographic execution policy.

Routing hierarchy:

E-C-O scope
   ↓
contract / residency / data policy
   ↓
GRPE
   ↓
approved regional AI cell
   ↓
AI DIAL
   ↓
approved endpoint inside that cell

GRPE selects the execution region from the client's contract-bound routing policy, residency policy, and current platform routing state.

Any UI, API, administration surface, or orchestration selector that exposes regional AI-cell choices SHALL show only cells permitted by the GRPE-governed policy for that client/E-C-O scope. It MUST NOT present a static global list of regions or cells and rely on rejection after selection.

The selectable set is a projection of GRPE-governed contract policy, not a new source of routing authority. A previously displayed option MUST be revalidated by GRPE at execution time because contract state, residency policy, maintenance state, or disaster-recovery state may have changed.

AI DIAL selects an approved deployment only inside the region selected by GRPE.

AI DIAL MUST NOT silently override a strict residency decision.

15. Regional AI Cells

ZAYAZ SHOULD prefer regional DIAL cells.

Regional-cell availability is client-specific and contract-scoped. The architecture SHALL NOT define a universal selector such as "EU / US / APAC" for every client.

Conceptual structure:

Client / E-C-O scope
        ↓
contract-bound routing policy
        ↓
GRPE
        ↓
contract-permitted regional AI-cell set
        ├── permitted cell A
        ├── permitted cell B
        └── permitted DR cell, only when policy allows
        ↓
GRPE selects active region at execution time
        ↓
AI DIAL selects approved endpoint inside that region

A client with one contractually permitted cell sees one selectable cell. A client with multiple permitted cells sees only that governed subset. A cell that exists in ZAYAZ infrastructure but is outside the client's contract or residency/DR policy SHALL NOT be offered.

A selector MAY display human-readable labels, but its option values MUST resolve to GRPE-governed regional identities. Cached selector options MUST be treated as advisory UI state and revalidated against GRPE before execution.

Each regional cell SHOULD control:

DIAL deployment;
regional storage/cache where enabled;
encryption keys;
provider credentials;
observability;
interceptors;
provider endpoints;
network egress.

16. Strict Residency

For strict policy such as:

EU_STRICT

if no compliant endpoint remains available:

FAIL CLOSED

The following is prohibited:

EU endpoint unavailable
→ silently route to unrestricted non-EU deployment

Provider resiliency never overrides GRPE.

17. AIGS and Interceptors

AI DIAL interceptors MAY act as enforcement points.

AIGS remains the governance authority.

A recommended chain is:

Request
 ↓
Route attestation
 ↓
AIGS policy check
 ↓
Privacy / DLP
 ↓
Model execution
 ↓
Output policy / structural validation
 ↓
ZAYAZ post-processing

Policies originate in ZAYAZ.

AIGS and related execution controls SHALL evaluate the resolved client AI policy identified by policy_id + version + policy_hash in the AIExecutionEnvelope. Mutable current client settings MUST NOT replace the pinned policy evidence for an in-flight or historical execution.

DIAL interceptors enforce selected policies at the execution boundary.

18. Commercial Preflight with CUEM

AI execution MAY have a commercial preflight through CUEM.

CUEM determines:

whether the beneficiary is commercially entitled;
whether an AI allowance applies;
whether spend caps apply;
whether usage should be metered;
whether a reservation is required;
whether overage is allowed;
whether commercial approval is required.

AI DIAL MAY receive a derived runtime limit.

AI DIAL MUST NOT create the underlying entitlement policy.

19. No Separate AI Usage Ledger

AI DIAL integration SHALL NOT create an independent ZAYAZ billing ledger for AI.

The canonical architecture is:

AI DIAL execution
        ↓
operational telemetry
        ↓
AI Metering Adapter
        ↓
CUEM Usage Metering Gateway
        ↓
CUEM Usage Ledger
        ↓
Entitlement / Allowance / Rating
        ↓
CUEM Charge Ledger

This prevents parallel billing architectures for:

AI;
reports;
API calls;
computations;
verification;
future monetized capabilities.

AI is one metered producer domain inside CUEM.

20. AI Metering Adapter

The AI Metering Adapter is responsible for normalizing DIAL/provider telemetry into CUEM-compatible usage.

The adapter MAY capture:

request reference
trace reference
model profile
DIAL deployment
provider
provider model/version
execution region
input tokens
output tokens
cached input
total tokens
latency
retry/fallback state
provider-estimated cost
execution status

The adapter SHOULD NOT determine the customer price.

21. AI Usage Measurement vs Customer Billing

Raw technical usage and commercial billing are intentionally decoupled.

Example:

Raw execution:
12,000 input tokens
2,000 output tokens
provider estimate EUR 0.11

Commercial contract A:
included in subscription
customer charge EUR 0

Commercial contract B:
deduct 14 normalized AI units
customer charge EUR 0

Commercial contract C:
allowance exhausted
customer charge EUR 0.35

Commercial contract D:
AI embedded in per-report price
no separate AI line

The same execution fact may produce different commercial outcomes under different contracts.

That interpretation belongs to CUEM.

22. AI Allowances

CUEM MAY govern:

monthly AI unit allowances;
monetary AI budgets;
model-class allowances;
premium-reasoning allowances;
per-user limits;
per-E-C-O limits;
group pools;
white-label partner pools;
hard caps;
soft caps;
overage.

For expensive executions, CUEM MAY reserve usage before the DIAL call.

Actual execution then commits measured usage and releases unused reservation.

23. DIAL Quotas

DIAL MAY enforce derived execution quotas for runtime protection.

Examples include:

request count;
token ceiling;
model-class restriction;
cost ceiling;
concurrency.

However:

DIAL quota configuration is an enforcement projection, not the commercial source of truth.

CUEM remains authoritative for entitlements, allowances, commercial limits, and charge interpretation.

24. Provider Cost

DIAL or provider adapters MAY emit estimated execution cost.

CUEM records attributable AI COGS separately from customer price.

A provider estimate is not a final invoice.

CUEM SHOULD reconcile estimates against:

provider billing exports;
cloud invoices;
private-model infrastructure cost;
agreed provider rates.

Reconciliation SHALL preserve both estimate and actual cost.

25. Cost Attribution

AI cost SHOULD be attributable, where available, to:

beneficiary E-C-O scope;
user;
white-label partner;
ZAYAZ Module;
Component;
agent;
intent;
framework;
report;
model profile;
provider;
region.

This enables CUEM to calculate:

AI COGS by E-C-O;
AI COGS by partner;
AI COGS by report;
AI COGS by model;
AI COGS by agent;
AI COGS by framework;
AI contribution margin.

26. White-Label Attribution

AI usage MAY involve:

Actor:
individual user

Beneficiary:
customer E-C-O

Partner:
white-label E-C-O

Payer:
customer, parent, or partner under CUEM contract

AI DIAL MUST NOT infer the payer.

CUEM resolves commercial responsibility.

DIAL only executes within the approved context.

27. Operational Telemetry

DIAL operational telemetry SHOULD feed the platform observability stack.

Operational measurements MAY include:

request count;
latency;
first-token latency;
provider errors;
retries;
endpoint saturation;
timeout rate;
model deployment health;
interceptor failures.

Operational telemetry is not automatically commercial accounting or assurance evidence.

28. Three-Level Telemetry Model

The canonical separation is:

Level 1
AI DIAL Operational Telemetry
        ↓
Level 2
AI Metering Adapter → CUEM Commercial Records
        ↓
Level 3
ALTD / ZAR Assurance Records where required

Level 1 — Operational

Infrastructure health and runtime execution measurements.

Level 2 — Commercial

Usage, allowance, cost, rating, and charge records owned by CUEM.

Level 3 — Assurance

Material AI-generated output, evidence manifests, governance decisions, model identity, human review, and other assurance-significant records.

Not every token belongs in ALTD.

Not every ALTD event is billable.

29. Trace Correlation

A shared trace reference SHOULD correlate:

user request
ZARA intent
ZADIF dispatch
RAG retrieval
EvidenceBundle
AIGS decision
CUEM preflight
GRPE route
AI DIAL invocation
provider response
AI metering
CUEM usage event
post-processing
trust validation
ALTD record where required
resulting artifact

This supports:

debugging;
replay;
assurance;
incident response;
cost attribution;
commercial reconciliation.

30. Prompt Governance

Prompt templates remain ZAYAZ-owned assets.

AI DIAL SHOULD NOT become the primary prompt registry for ZARA or ZAAM.

ZAYAZ prompt governance SHOULD preserve:

prompt template identity;
version;
applicable agent;
framework applicability;
required context;
fallback behavior;
AIGS requirements;
validation rules;
effective dates.

AI execution records SHOULD retain the prompt-template version where required for replay.

31. Tool Calls

Model tool support does not grant tool authority.

Tool permissions remain governed by ZAYAZ based on:

user authorization;
E-C-O scope;
agent profile;
intent;
workflow state;
data classification;
governance policy.

High-impact business actions SHOULD use:

LLM proposes
    ↓
ZAYAZ validates
    ↓
authorization / TrustGate / approval
    ↓
ZAYAZ service executes

AI DIAL is not the authority for irreversible ZAYAZ business actions.

32. Data Minimization

Before execution, ZAYAZ SHOULD minimize context to the task.

Avoid forwarding:

unrelated client data;
unnecessary personal data;
secrets;
credentials;
irrelevant E-C-O identities;
full documents when governed evidence fragments suffice.

Data minimization improves:

privacy;
cost;
latency;
attack resistance;
model focus;
auditability.

33. Persistence Boundary

Where the selected DIAL deployment persists conversations, prompts, files, cache, or other execution objects, that persistence becomes part of the applicable regional and security boundary.

DIAL storage MUST NOT become authoritative for:

ESG signals;
regulatory knowledge;
E-C-O identity;
report state;
commercial entitlements;
CUEM charge history;
ZAYAZ audit history;
canonical prompt governance.

34. Provider Approval

A model deployment SHALL NOT become production-approved merely because DIAL can call it.

ZAYAZ approval SHOULD cover:

security;
privacy;
data residency;
retention;
model capability;
validation;
contractual terms;
cost;
observability;
incident response;
governance suitability.

Technical reachability is not approval.

35. Model Change Control

Material model changes SHOULD pass governed validation.

Depending on risk, this MAY include:

gold-set regression tests;
structured-output tests;
RAG-grounding tests;
citation adherence;
multilingual validation;
safety tests;
cost comparison;
latency comparison;
canary deployment;
rollback.

Historically assured workflows SHOULD retain exact model identity where required.

36. Failure Classification

AI execution SHOULD classify failures such as:

routing_failure
residency_block
authorization_failure
commercial_entitlement_denied
commercial_allowance_exhausted
quota_exceeded
provider_rate_limit
provider_timeout
provider_unavailable
interceptor_failure
retrieval_failure
insufficient_evidence
context_limit_exceeded
invalid_structured_output
governance_block

Commercial failure classes should remain distinguishable from provider failure.

37. Fail-Closed Conditions

ZAYAZ SHOULD fail closed when:

no compliant region exists;
AIGS blocks execution;
required evidence is unavailable;
model capability is not approved;
exact model identity required for assurance cannot be resolved;
data classification exceeds model permission;
human approval is missing where required;
route attestation fails;
evidence integrity fails;
CUEM denies an execution that requires commercial preflight.

Cost or latency optimization MUST NOT override these conditions.

38. Caching

AI caching MAY reduce cost and latency.

Any reusable cache MUST preserve isolation across:

E-C-O scope;
user entitlement;
evidence set;
framework version;
prompt version;
data classification;
jurisdiction;
reporting period;
model policy.

A confidential response for one organization MUST NEVER be served to another organization through shared caching.

Cache savings MAY be measured operationally and reflected in CUEM cost accounting where supported.

39. Response Validation

A response from AI DIAL is not automatically trusted ZAYAZ output.

Post-generation processing MAY include:

schema validation;
citation validation;
evidence-claim checks;
numeric consistency checks;
policy checks;
trust scoring;
hallucination detection;
human review.

Only after required ZAYAZ controls pass should output become an accepted platform artifact.

40. Network and Secrets

AI DIAL SHOULD operate inside controlled infrastructure with:

private service networking;
TLS;
mTLS where appropriate;
restricted ingress;
provider egress allowlists;
least-privilege cloud IAM;
workload identity;
network policy;
approved secret management.

Provider credentials MUST NOT be embedded in:

source code;
MDX;
frontend configuration;
container images;
static public configuration.

41. Upgrade Strategy

AI DIAL is an external dependency and SHOULD be version-pinned.

Production deployment SHOULD pin, as applicable:

container image digest/version;
deployment chart version;
configuration schema;
adapters;
interceptors.

Upgrades SHOULD test:

API compatibility;
streaming;
structured output;
tool calls;
authentication;
limits;
interceptors;
provider adapters;
telemetry;
failure handling;
regional routing.

42. Initial Implementation Phases

Phase 1 — Gateway PoC

Validate at least two approved model deployments:

completion;
streaming;
structured output;
authentication;
model switching;
telemetry;
token accounting;
failure handling.

Phase 2 — ZADIF Execution Adapter

Implement:

AIExecutionEnvelope;
resolved tenant/client AI-policy ID, version, and hash pinning;
capability-profile mapping;
trace correlation;
normalized response contract;
route attestation.

Phase 3 — CUEM AI Metering

Implement:

AI Metering Adapter;
CUEM usage-event emission;
E-C-O / user / partner attribution;
AI allowance integration;
cost telemetry;
provider reconciliation hooks.

Phase 4 — Governed RAG

Integrate:

EvidenceBundle;
evidence manifest;
source hashes;
retrieval version;
citation metadata;
insufficient-evidence behavior.

Phase 5 — AIGS Enforcement

Add:

AI risk enforcement;
privacy / DLP;
output governance;
AI-origin metadata.

Phase 6 — Regional Cells

Deploy first production regional cell and validate:

GRPE ownership;
contract-scoped regional-cell option projection;
no static global region selector;
execution-time GRPE revalidation;
strict residency;
fail-closed routing;
policy-bounded endpoint fallback.

Phase 7 — White-Label Commercialization

Using CUEM, support:

partner attribution;
customer attribution;
AI entitlements;
AI allowances;
premium capability classes;
AI COGS;
AI margin reporting.

42.1. Governed Replay Semantics

AI-assisted execution SHALL declare replay semantics under the Replay Constitution and TrustGate Replay Profiles rather than treating reconstructable references as sufficient evidence.

The AI model output produced through AI DIAL uses the RECORDED replay profile by default. Model inference can vary across provider infrastructure, model servicing, and nondeterministic execution; ZAYAZ therefore SHALL verify the integrity and provenance of the originally accepted output rather than claim bit-identical regeneration.

A governed downstream specification MAY declare a BANDED profile for a specific AI-derived output only when that specification also supplies the governed tolerance-policy reference and all model/inference pins required by TG-RP. AI DIAL itself does not invent the tolerance.

Deterministic ZAYAZ routing, authorization, residency, commercial-preflight, schema-validation, or other rule-based outputs MAY separately declare EXACT in their owning specifications. Their replay profile does not change the RECORDED profile of the raw AI model output.

AI Replay Manifest

Every AI execution that is presented as replayable SHALL possess an immutable Replay Manifest. For the AI DIAL execution record, the manifest SHALL preserve or reference at least:

replay_mode: RECORDED for the accepted raw model output unless an owning specification explicitly governs another profile;
route attestation and GRPE region decision;
DIAL deployment identity;
provider and exact provider model/version identity where available;
model capability/profile requested by ZAYAZ;
prompt-template identity/version and prompt/input hash where retained by policy;
inference parameters that materially affect execution;
EvidenceBundle / retrieval-manifest references, source hashes, and retrieval version where RAG is used;
AIGS and other governance-decision references;
resolved tenant/client AI-policy identity, version, and content hash from the AIExecutionEnvelope;
CUEM entitlement, allowance-reservation, usage-event, and cost references where commercial preflight/metering applies;
trace/correlation reference;
accepted output hash;
provider response/execution metadata required to prove provenance;
the creation-time ALTD/DAL anchor or equivalent governed evidence reference required for a RECORDED output.

A later model change, provider fallback, cost reconciliation, or prompt revision SHALL NOT rewrite the historical replay manifest. Later evidence is linked as successor/reconciliation evidence.

For a RECORDED AI output, replay succeeds when the original recorded output, identity, lineage, evidence references, hashes, and required anchoring verify. Re-running the current model is not the pass criterion.

43. Acceptance Criteria

Test	Required Result
E-C-O scope executes AI request	Correct beneficiary attribution retained
Individual user executes	Correct `user_id` trace retained
White-label request	Partner context retained without making DIAL the commercial authority
Client opens regional AI-cell selector	Only cells permitted by the client's GRPE-governed contract/routing policy are shown; no static global region list is exposed
Strict-residency request	Only a GRPE-permitted compliant regional cell is available
Regional endpoint fails	Approved same-policy fallback or fail closed
Model changes	Exact governed model profile remains visible
RAG request	Evidence set is reproducible
Evidence unavailable	Grounded generation is blocked
Client AI settings change after execution	Replay still identifies the exact historical tenant AI policy by policy ID, version, and hash
AIGS policy blocks	DIAL execution does not proceed
CUEM entitlement denies	Required commercial preflight blocks execution
AI allowance reserves	Concurrent requests cannot overspend same allowance
AI execution completes	AI Metering Adapter emits CUEM usage
DIAL estimate differs from provider invoice	CUEM reconciles cost without rewriting usage
Contract includes AI	Usage recorded even when customer charge is zero
Contract bills normalized AI	CUEM rates, not DIAL
Audit replay	Immutable replay manifest verifies the RECORDED AI output, route, exact model identity, evidence, governance, commercial references, output hash, and required creation-time anchor
Cross-client test	No context/cache leakage

44. Architectural Decisions

The canonical ZAYAZ integration SHALL follow these rules:

AI DIAL is the governed model-execution gateway.
ZADIF remains the AI dispatcher.
GRPE remains the geographic routing authority.
ZAYAZ retains compliance-grade RAG and evidence authority.
AIGS remains the AI governance authority.
ALTD/ZAR remain authoritative for assurance-grade audit semantics.
E-C-O Numbers, user_id, and uom_number remain the governed identities.
AI DIAL does not introduce a canonical tenant_id.
Application logic requests governed model capability rather than arbitrary provider model names.
DIAL load balancing and failover remain inside ZAYAZ-approved routing boundaries.
Regional AI-cell selectors expose only the GRPE-governed cells permitted for the client's contract and current policy context; static global region menus are prohibited.
The AIExecutionEnvelope pins the resolved client AI policy by stable policy identity, version, and content hash, and replay preserves that policy evidence.
Strict residency fails closed.
AI DIAL operational telemetry is not the ZAYAZ billing ledger.
AI measurements flow through an AI Metering Adapter into CUEM.
CUEM owns AI commercial entitlement, allowance, rating, charge, and cost accounting.
Customer AI price is independent of raw provider token pricing.
Provider cost and customer charge remain separate.
DIAL MAY enforce derived runtime limits but does not own commercial policy.
Compliance-sensitive evidence failure never becomes speculative fallback.
AI output is not trusted until required ZAYAZ validation completes.
AI DIAL is headless infrastructure by default.

45. Final Principle

ZAYAZ
Identity + Intent + Evidence + Governance + Trust + Routing
                         │
                         ▼
                   EPAM AI DIAL
              Governed Execution Fabric
                         │
                         ▼
                 Approved AI Models
                         │
                         ▼
                AI Metering Adapter
                         │
                         ▼
                       CUEM
       Entitlement + Usage + Cost + Rating + Charge

ZAYAZ governs the intelligence. AI DIAL industrializes its execution. CUEM governs the commercial consumption.

GitHub Repo Request for Change (RFC)

1. Purpose​

2. Architectural Boundary​

3. Core Runtime Principle​

4. Reference Architecture​

5. Headless-by-Default Deployment​

6. Identity​

7. Upstream Identity Minimization​

8. Authentication​

9. AIExecutionEnvelope​

9.1. Resolved Tenant AI Policy​

10. ZAYAZ Retains RAG Authority​

11. Evidence Fail-Safe​

12. ZADIF and AI DIAL​

13. Model Capability Profiles​

14. GRPE Owns Region Selection​

15. Regional AI Cells​

16. Strict Residency​

17. AIGS and Interceptors​

18. Commercial Preflight with CUEM​

19. No Separate AI Usage Ledger​

20. AI Metering Adapter​

21. AI Usage Measurement vs Customer Billing​

22. AI Allowances​

23. DIAL Quotas​

24. Provider Cost​

25. Cost Attribution​

26. White-Label Attribution​

27. Operational Telemetry​

28. Three-Level Telemetry Model​

Level 1 — Operational​

Level 2 — Commercial​

Level 3 — Assurance​

29. Trace Correlation​

30. Prompt Governance​

31. Tool Calls​

32. Data Minimization​

33. Persistence Boundary​

34. Provider Approval​

35. Model Change Control​

36. Failure Classification​

37. Fail-Closed Conditions​

38. Caching​

39. Response Validation​

40. Network and Secrets​

41. Upgrade Strategy​

42. Initial Implementation Phases​

Phase 1 — Gateway PoC​

Phase 2 — ZADIF Execution Adapter​

Phase 3 — CUEM AI Metering​

Phase 4 — Governed RAG​

Phase 5 — AIGS Enforcement​

Phase 6 — Regional Cells​

Phase 7 — White-Label Commercialization​

42.1. Governed Replay Semantics​

AI Replay Manifest​

43. Acceptance Criteria​

44. Architectural Decisions​

45. Final Principle​