● ASES V7.2 — ARKA SOVEREIGN EXECUTION STANDARD

Governance & Security

Every Arka AI deployment operates under ASES V7.2 — a named, versioned execution standard. Governance is not a feature layer or a monitoring add-on. It is the execution architecture: 9 gates evaluated synchronously before any state-changing action, fail-closed by design.

ASES V7.2
Named execution standard — every deployment
9 Gates
Synchronous — before any mutation executes
Fail-Closed
Any gate failure → QUARANTINED immediately
Execution Standard

ASES — Arka Sovereign Execution Standard

ASES is not a marketing claim — it is a contractual architecture. When we say "We operate under ASES V7.2," it means your engagement is governed by a specific, versioned standard that PE operating partners and auditors can review, validate, and rely on.

ASES defines the minimum standards for: mission qualification (ADLC steps 1–4 must be completed before production), trust progression (Shadow mode before Autonomous), governance enforcement (9 gates, fail-closed), evidence production (7 canonical events per mission cycle), and audit capability (full forensic replayability).

"We operate under ASES" means a PE due diligence reviewer can verify:
what standard was applied → what gates ran → what evidence was produced → what the audit shows.

ASES V7.2 — Specification Summary
VersionV7.2 (current)
Mission GateADLC Steps 1–4 mandatory pre-production
Trust Progression9 states; Shadow mandatory before Autonomous
Governance Gates9 synchronous gates; fail-closed
Evidence Standard7 canonical events; ECDSA-SHA256 sealed
Ledger ArchitectureDual-ledger; immutable, append-only, hash-chained
HITL RequirementGate 7 — human approval for defined escalations
Forensic StandardBit-for-bit replayability per Proof Pack
Data Residency (US)GCP us-central1
Data Residency (UK)GCP eu-west2
Compliance AlignmentSOC 2 aligned; OSCAL-native export
IP Framework3-Tier: Arka core / adapter / client data
ActionGateway

9 Gates of Governance — In Detail

Every mutation request — every state-changing action a worker takes — is evaluated synchronously through all 9 gates before execution. Gates run in order. Any gate that fails terminates the request and moves the worker to QUARANTINED. No partial execution. No retry without remediation.

1
Identity
Verify actor identity, tenant context, and session validity. Reject unrecognized actors or expired sessions before any policy evaluation.
→ QUARANTINED
2
Role
Validate the actor's role is permitted to perform the requested action type. Role bindings are OPA-managed; no hardcoded permission checks.
→ QUARANTINED
3
Policy (OPA)
Evaluate the full OPA/Rego policy bundle. Action context, tenant policies, compliance constraints, and mission-specific rules all evaluated deterministically. Zero LLM in this path.
→ QUARANTINED
4
Budget
Verify action falls within per-mission, per-cycle, and per-tenant budget constraints. Prevents runaway automation and unexpected cost exposure.
→ QUARANTINED
5
SLA
Confirm action falls within defined SLA windows and time constraints. SLA boundaries are contractual commitments — violation triggers quarantine, not degraded execution.
→ QUARANTINED
6
Evidence
Confirm all required evidence artifacts are present and valid for this action. A mutation without complete evidence provenance cannot proceed — this enforces the Evidence Ledger contract.
→ QUARANTINED
7
Approval (HITL)
Human-in-the-loop approval check. For actions designated as HITL-required in the Blueprint, gate 7 verifies the approval token is present, valid, and unexpired before proceeding.
→ QUARANTINED
8
Audit (pre-commit)
Write the pre-commit audit event to the Evidence Ledger before execution. The audit record exists before the action — if execution fails, the audit record still exists. Immutable.
→ QUARANTINED
9
Seal (ECDSA-SHA256)
Cryptographic seal of the approved action using ECDSA-SHA256. The sealed Proof Pack is written to the Evidence Ledger. This is the final gate — the action executes only after the seal is written.
Proof Pack sealed
Dual-Ledger Architecture

Evidence Ledger + Financial Ledger

Two separate immutable ledgers — one for audit and compliance, one for billing and financial verification. Both are append-only, hash-chained, and cryptographically tamper-evident.

Evidence Ledger

Immutable Audit Record

The Evidence Ledger is the source of record for every ADLC event, HITL approval, policy evaluation, and Proof Pack. It is append-only and hash-chained — any modification to a historical record invalidates the hash chain and is immediately detectable.

Availability99.99% read availability
Hash chainSHA-256 per record; chain over ledger
Tamper detectionAny modification invalidates chain
Export formatOSCAL-native (FedRAMP / SOC 2)
Retention7 years minimum (configurable)
AccessRead-only for clients; append-only for platform

OSCAL-native export supports direct ingestion into FedRAMP continuous monitoring workflows and SOC 2 audit packages.

Financial Ledger

Outcome-Backed Billing Record

The Financial Ledger records every billable event in the Outcome-as-a-Service model. Every line item in any Arka AI invoice is backed by a sealed Proof Pack in the Financial Ledger — you can verify what was done before the invoice is generated.

Event triggerfinancial_realized (Event 7)
Proof linkEvery billing event linked to Proof Pack
Tamper detectionSame hash-chain architecture as Evidence Ledger
Client accessRead access to own billing records
Dispute resolutionProof Pack replay as source of record
ReconciliationAutomated; no manual re-entry

No Arka AI invoice can contain a charge not backed by a sealed, ECDSA-signed Proof Pack in the Financial Ledger.

What's in a Proof Pack

Inputs

Full input data capture, data source provenance, tenant context, policy context snapshot at execution time

Actions

Complete action log, all 9-gate evaluations, HITL approval tokens, elapsed time, system interactions

Seal

ECDSA-SHA256 signature, model & prompt snapshots, lineage artifacts, timestamp, replay manifest

Infrastructure & Data Residency

Sovereign by Region

Arka AI customer data never leaves the designated region. Tenants are fully isolated at the infrastructure layer. No cross-tenant data access — architecturally enforced, not policy-enforced.

United States

GCP us-central1 (Iowa)

RegionGoogle Cloud us-central1
Data residencyAll PII, operational data, ledgers
Compliance alignmentSOC 2, CCPA, FedRAMP (planned)
Uptime SLA99.9% platform availability
Tenant isolationKubernetes namespace + network policy
United Kingdom

GCP eu-west2 (London)

RegionGoogle Cloud eu-west2
Data residencyAll PII, operational data, ledgers
Compliance alignmentUK GDPR, ICO standards
Uptime SLA99.9% platform availability
Tenant isolationKubernetes namespace + network policy
AES-256-GCM
Encryption at rest and in transit; per-tenant key management
mTLS
Mutual TLS on all internal service-to-service communication
Zero-Trust
No implicit trust between services; every call authenticated and authorized
Intellectual Property

3-Tier IP Framework

Clear, contractual delineation of IP ownership across every engagement. No ambiguity about what Arka owns, what you own, and how adapter layers work.

Tier 1 — Arka Core

Platform & Governance IP

ASES standard, ActionGateway, Evidence Ledger architecture, ADLC methodology, Mission Library framework, Sovereign LLM Router, Trust Progression State Machine. Owned by Arka AI, Inc. Patents pending. Licensed for use under engagement terms.

Tier 2 — Adapter Layer

Co-Developed Connectors

System-specific adapters, domain workers, and operational blueprints built for a specific client engagement. Ownership terms defined in the Outcome Contract. Clients may retain rights to domain-specific IP developed for their unique operations.

Tier 3 — Client Data

Always Client-Owned

All client data, operational records, financial records, and the Evidence Packages produced from client operations remain client property. Arka AI holds no license to use client data beyond execution of contracted services.

Security Posture

Infrastructure & Compliance

Arka AI is built on enterprise-grade infrastructure with a structured path to SOC 2 Type II certification. Every deployment runs in customer-controlled environments with full data sovereignty.

🔒
SOC 2 Type II — In Progress

Formal audit engagement in progress. Target completion 2026.

Our Evidence Ledger, ASES V7.2 governance standard, and OSCAL-native export architecture were designed from inception to support SOC 2 Type II audit requirements. Audit-ready artifacts are available to enterprise prospects under NDA.

Infrastructure
Google Cloud Platform
US: us-central1
UK: eu-west2
Isolation: Kubernetes namespace + network policy
Uptime SLA: 99.9%
Encryption
At Rest & In Transit
At rest: AES-256 (GCP-managed)
In transit: TLS 1.3 mandatory
Evidence seals: ECDSA-SHA256 per Proof Pack
Ledger integrity: SHA-256 hash chain
Secrets & Access
Zero Credential Exposure
Secrets: Vault-managed, ephemeral rotation
Client data: Never accessed beyond execution scope
Audit export: OSCAL-native (FedRAMP / SOC 2)
Retention: 7-year minimum, configurable

Security review or technical due diligence?

We provide full ASES V7.2 documentation, Evidence Ledger architecture specifications, and technical briefings for PE due diligence teams and security reviewers. Contact our team to begin.