Principle 1
Proposal Is Not Permission
A generated action is a candidate. It does not acquire executable authority merely because a model produced it confidently, repeatedly, or from a privileged position.
Public Draft v0.1 · Issued July 23, 2026
SAQ™ Execution Contract
A common contract for governed AI execution at the execution boundary.
The SAQ™ Execution Contract defines the information, authority, state, policy, constraints, decision, and proof required before a consequential AI action may cross from model proposal into operational reality.
The model may propose an action. The architecture decides whether it is admissible to become real.
Version
Public Draft v0.1
Issue Date
July 23, 2026
Document ID
SAQ-ECS-0.1-20260723
The Drift Stack™
Identity → Frame → Boundary → Drift → Correction
Execution before explanation
A Common Contract for Consequential Action
No consequential AI action should execute merely because a model produced it.
An AI system needs a shared, machine-readable contract that binds a proposed action to identity, authority, evidence, current state, policy, constraints, admissibility, execution, and correction.
Proposal
→Identity
→Authority
→Evidence
→Current State
→Policy
→Admissibility
→Bounded Execution
→Receipt
→Correction
No domain rule is universal. The contract shape is universal.
Payments, healthcare, insurance, infrastructure, human resources, enterprise agents, and other consequential domains retain their own authority, evidence, policy, constraints, and correction requirements.
The standardization boundary
What the Standard Defines
The Common Contract Defines
- Who or what is acting
- What action is proposed
- Which target and state may be affected
- What authority supports execution
- Which evidence and policy apply
- What constraints and expiry govern the grant
- What actually happened
- How executed reality can be corrected
The Domain Profile Defines
- Authoritative systems and registries
- Required evidence and freshness
- Domain-specific prohibitions
- Risk and consequence classifications
- Human approval and escalation rules
- Reversal and remediation duties
- Sector-specific conformance tests
- Required receipts and reporting
A conforming system can explain not only what a model recommended, but why execution was allowed, denied, constrained, deferred, expired, or escalated; which external authority supported that decision; which exact state was evaluated; and what action actually occurred.
Normative foundation
Design Principles
Principle 2
Identity Is Not Authority
Authentication establishes who or what is present. Authority establishes what that identity may do, to which target, under which conditions, and for how long.
Principle 3
Remembered State Is Not Current State
Consequential execution must rely on externally validated current state when changing reality can alter the admissibility decision.
Principle 4
Evidence Is Not Interpretation
Provenance, source, timestamp, freshness, and validation state remain separate from model interpretation, confidence, or narrative explanation.
Principle 5
Policy Must Be Explicit
Applicable policy must be named, versioned, attributable, and bound to the decision. Hidden preferences must not masquerade as architectural invariants.
Principle 6
Execution Must Be Narrow
Authorization is scoped to the exact actor, action, target, limits, duration, permitted tools, and operating conditions admitted at the boundary.
Principle 7
Control Precedes Audit
Logging is necessary but post-hoc. A governed system controls execution before relying on receipts, monitoring, or retrospective accountability.
Principle 8
Correction Is Architectural
When state, authority, evidence, or policy changes, the system must support revocation, suspension, reversal, compensation, remediation, or escalation.
Requirements describe. Mechanisms enforce.
A prompt, confidence score, policy document, model role, or audit log does not independently establish execution authority.
Required envelope
Canonical Contract Structure
The execution contract binds the complete decision context into one attributable, versioned record. A material change to any governing element invalidates the prior admissibility decision.
Requester, Actor, and Identity
Separates who initiated the request, which model, agent, service, or human proposed the action, and who is legally or operationally empowered.
Proposed Action and Target
Defines the exact requested effect, affected record, account, person, asset, service, system, or operating environment.
Authority and Delegation
Names the external source of authority, its scope, issuer, subject, conditions, expiry, delegation chain, and revocation source.
Current State and Evidence
Binds the decision to attributable, externally validated state and evidence with provenance, observation time, retrieval time, and freshness requirements.
Policy, Risk, and Consequence
Identifies the exact policy version, jurisdiction, consequence class, reversibility, value at risk, affected subjects, and escalation thresholds.
Constraints
Expresses machine-verifiable limits covering value, time, target, geography, data, tools, approvals, rate, use, and permitted effects.
Admissibility and Execution Grant
Records the boundary decision and, when permitted, issues narrow, expiring, replay-resistant authority for the exact admitted action.
Receipt and Correction
Preserves what actually occurred, the resulting state, any execution variance, and the correction path when authoritative reality changes.
Identity Separation
The contract may separate public identity, operational identity, external-system identity, and privacy-preserving or pseudonymous identity. A Shadow ID or equivalent mechanism can govern execution without placing unnecessary personal information into model context, vector stores, logs, or portable receipts.
Machine-Readable Public Specification
The public JSON specification publishes the canonical contract, grant, receipt, lifecycle, reason-code, and test-vector structures developers can inspect and validate. Production adapters, policy engines, domain implementations, enforcement mechanisms, and certification infrastructure remain controlled Samirac assets.
State before action
Contract Lifecycle and State Machine
The contract is not a static payload. It moves through explicit, attributable, and recorded states. It begins non-executable and cannot cross directly from proposal into execution.
1
Draft and Assembly
DRAFT → ASSEMBLING
The candidate action is canonicalized and bound to identity, target, authority, evidence requirements, policy, and constraints.
2
Validation
VALIDATING
External authority, current state, evidence provenance, freshness, policy applicability, and required conditions are resolved.
3
Boundary Decision
ADMISSIBLE · CONDITIONAL · DENIED · ESCALATED · DEFERRED · EXPIRED
The system produces an explicit, attributable outcome with reason codes and the exact evidence, state, and policy basis.
4
Authorization and Execution
AUTHORIZED → EXECUTING → EXECUTED
A narrow grant is issued and independently verified immediately before the executor performs the admitted action.
5
Receipt and Correction
RECEIPTED → CORRECTED / CLOSED
The realized effect is recorded and remains connected to revocation, reversal, compensation, remediation, suspension, or escalation.
Forbidden transitions include:
DRAFT directly to EXECUTING, DENIED to EXECUTING without a new decision, expired grants reaching execution, material action mutation after authorization, receipt creation without executor identity, and silent policy substitution.
Boundary decision
Admissibility Outcomes
Admissibility determines whether a proposed action, under the specified identity, authority, evidence, current state, policy, and constraints, may proceed toward execution.
ADMISSIBLE
All required conditions are satisfied. A narrow execution grant may be issued.
CONDITIONAL
Execution is permitted only after additional constraints, evidence, or approvals are bound and revalidated.
DENIED
An authority defect, evidence defect, prohibited target, policy rule, or consequence threshold prevents execution.
ESCALATED
A designated human or external authority must make the decision before automation can continue.
DEFERRED
The action cannot be decided until missing, conflicting, or stale information is resolved.
EXPIRED
The contract, authority, evidence, state snapshot, decision window, or grant is no longer valid.
Execution grants remain narrow
A grant is bound to one contract, action, target, constraint set, validity window, use limit, and replay state. The executor must verify the grant immediately before execution and refuse any mutated, expired, revoked, or replayed authority.
Reality after execution
Execution Receipts and External Correction
The contract must follow the action into reality. A system is not governed merely because it made a correct pre-execution decision. It must also know what actually occurred and respond when authoritative reality changes.
Proposed
What the model, agent, user, or workflow asked to do.
Authorized
What the execution boundary permitted under explicit conditions and constraints.
Realized
What the executor actually changed in the operational world.
Architecture must preserve the execution worldline.
The system retains the chain from proposal to consequence so it can route back to the exact point where authority, evidence, policy, expected effect, and authoritative reality diverged.
Implementation pattern
Reference Architecture
The public standard defines the component responsibilities and trust separations required for governed execution. It does not publish Samirac’s production source code, internal SDKs, full adapter implementations, policy engines, or commercial conformance harness.
1
Proposal Interface
Accepts a candidate action from a model, agent, user, workflow, or external system without conferring authority.
2
Contract Builder
Canonicalizes the proposed action and assembles identity, authority, target, evidence, state, policy, and constraints.
3
Authority and State Adapters
Query authoritative external systems and return attributable authority, evidence, and current-state records.
4
Policy Resolver
Selects the applicable domain profile and policy version for the actor, action, target, jurisdiction, and consequence class.
5
SAQ™ Admissibility Gate
Determines whether the proposed action is admissible, conditional, denied, deferred, expired, or escalated.
6
Execution Grant Service
Issues narrow, expiring, invalidatable, and replay-resistant authority bound to the admitted contract.
7
Execution Broker
Verifies the grant and performs or delegates only the exact action permitted under the encoded constraints.
8
Ledger and Correction Service
Records transitions and receipts, detects divergence, invalidates grants, and initiates correction or escalation.
Trust Separation
The proposing model should not control the authority adapter, policy resolver, admissibility gate, grant validation, or receipt ledger. These components may use AI internally, but their authoritative decisions and state transitions must remain independently verifiable.
Testing the mechanism
Conformance Model
Conformance is demonstrated through operating mechanisms and testable behavior—not policy statements, diagrams, copied field names, or self-attestation.
EC-1
Contract Producer
Produces canonical, versioned contracts with stable digests and required core objects.
EC-2
Authority Validator
Resolves external authority, delegation, scope, expiry, conditions, and revocation.
EC-3
State and Evidence Validator
Retrieves attributable current state and verifies provenance, observation time, and freshness.
EC-4
Admissibility Gate
Applies explicit policy and produces deterministic boundary outcomes with reason codes.
EC-5
Bounded Executor
Verifies grants and enforces action, target, time, use, value, tool, and data constraints.
EC-6
Receipt Ledger
Records realized effects and links the contract, grant, executor, external references, and resulting state.
EC-7
External Correction
Invalidates, reverses, compensates, suspends, remediates, or escalates when authoritative reality changes.
EC-F
Full Conformance
Implements EC-1 through EC-7 under an approved domain profile and passes independent conformance review.
Certification claims are controlled
A product may not claim “SAQ Certified,” “SAQ Conformant,” or equivalent status merely because it adopts terminology or contract fields from this page. Certification requires implementation review and conformance testing under the applicable Samirac program.
One contract, many domains
Domain Profiles
The common execution contract remains stable while each domain supplies its own authoritative systems, evidence requirements, freshness limits, policy bindings, risk classes, approval rules, execution constraints, receipt requirements, and correction duties.
These public profiles identify the consequence model at a high level. Detailed schemas, authority adapters, policy mappings, conformance tests, and production implementation packages remain separate domain assets.
Payments
Account authority, payment mandate, balance, counterparty state, amount limits, destination controls, settlement windows, reversal, dispute, and compensation.
Banking and Lending
Customer identity, KYC and AML state, credit authority, funds availability, account restrictions, disclosures, servicing actions, approval thresholds, holds, and remediation.
Capital Markets and Trading
Order authority, account mandate, instrument eligibility, position and market state, risk limits, trade windows, cancellation, settlement, supervisory review, and exception handling.
Insurance
Coverage, delegated claims authority, reserves, exclusions, loss state, prior payments, documentation requirements, payment thresholds, recovery, amendment, and escalation.
Healthcare
Practitioner authority, patient identity and consent, medication and order state, allergies, contraindications, dosage constraints, required review, hold, counter-order, and notification.
Aerospace and Defense
Mission authority, operator identity, aircraft or vehicle state, command hierarchy, maintenance status, safety envelopes, dual authorization, abort, isolation, and fail-safe behavior.
Critical Infrastructure and Energy
Operator authority, equipment mode, maintenance state, interlocks, load conditions, safe operating limits, emergency command, shutdown, isolation, restoration, and incident response.
Retail and Commerce
Pricing, inventory, promotions, purchasing authority, refunds, fulfillment, fraud state, customer data, supplier actions, cancellation, reversal, and customer remediation.
Manufacturing and Supply Chain
Production authority, work orders, equipment state, quality holds, supplier status, inventory movement, scheduling, shutdown, rollback, quarantine, and remediation.
Enterprise Agents and Business Systems
Role and workspace authority, CRM and ERP record state, repositories, permitted tools, data classification, spend limits, rate limits, rollback, token revocation, and workflow quarantine.
Human Resources and Workforce
Managerial authority, employment and protected-workflow state, decision class, jurisdiction, data minimization, required human approval, reopened review, amendment, and notice.
Public Sector and Regulated Services
Statutory authority, eligibility, identity, jurisdiction, due process, official records, human review, notice, appeal, correction, reporting, and public accountability.
Domain variation changes the authority, evidence, policy, and consequence model. It does not change the governing sequence.
Every profile must preserve proposal, identity, authority, evidence, current state, explicit policy, admissibility, bounded execution, receipts, and correction. A domain may add requirements, but it may not remove the integrity requirements of the common execution contract.
Publication and provenance
Public Draft Status and Rights
This page is the public publication and provenance record for the SAQ™ Execution Contract Specification, Public Draft v0.1, issued July 23, 2026 under document ID SAQ-ECS-0.1-20260723.
Samirac Partners LLC is the initial specification steward. Public machine-readable schemas, lifecycle definitions, reason codes, and test vectors are published separately through the JSON specification page. Production SDKs, authority and state adapters, policy engines, commercial domain profiles, enforcement mechanisms, full conformance harnesses, and internal working materials remain controlled Samirac assets.
Citation and technical discussion are welcome with clear attribution to Christopher S. Ciappa and Samirac Partners LLC. Publication does not grant patent rights, commercial implementation rights, certification rights, licensing rights, or trademark rights.
The public standard defines the common execution contract. Licensed implementations, domain profiles, conformance, certification, and integration establish how it is applied and proven.
Specification · Implementation · Conformance · Licensing
AI does not need one universal mind.
It needs a universal way to prove what may become real.
Samirac works with builders, enterprises, platforms, and implementation partners applying governed execution to real products and consequential workflows.
Proposal → Identity → Authority → Evidence → Current State → Policy → Admissibility → Bounded Execution → Receipt → Correction