Public JSON Release · Version 0.1
Version
0.1
Status
Public Draft
Document ID
SAQ-ECS-0.1-20260723
The Drift Stack™
Identity → Frame → Boundary → Drift → Correction
Public implementation surface
The public release defines the stable data structures and observable behaviors needed to build, inspect, and test an SAQ™ Execution Contract implementation.
Public structure enables interoperability. Controlled implementation, conformance, certification, and domain assets create the commercial product.
Raw machine-readable release
Each asset has a defined responsibility, an intended producer, and an intended consumer. The raw JSON opens directly in a new tab and can be retrieved by schema validators, developer tools, or automated documentation systems.
Core schema
Defines the complete versioned envelope that binds requester, actor, proposed action, target, authority, evidence, current state, policy, constraints, admissibility, execution, receipt, correction, and lifecycle state.
Used by: Contract builders, admissibility gates, validators, ledgers, and conformance tools.
Shared definitions
Defines reusable public objects including requester, actor, target, authority claim, delegation, evidence, current-state snapshot, policy binding, constraints, admissibility decision, correction record, and lifecycle record.
Used by: All SAQ™ public schemas.
Bounded authority
Defines the narrow, expiring, replay-resistant grant issued only after a contract is admitted. It binds one actor, action, target, constraint set, validity window, use limit, and revocation source.
Used by: Grant services, execution brokers, and boundary verifiers.
Proof of consequence
Defines the attributable receipt that distinguishes what was proposed, what was authorized, what was realized, the resulting state, execution variance, and whether correction is required.
Used by: Executors, ledgers, correction services, auditors, and conformance tools.
Decision language
Defines the structure of public reason codes used to explain denial, deferral, expiry, escalation, revocation, correction, and other boundary outcomes.
Used by: Admissibility gates, transition records, remediation workflows, and receipts.
Conformance examples
Defines the format of positive and negative examples used to test admissibility evaluation, grant verification, receipt validation, and correction behavior.
Used by: Implementers, reviewers, and future public conformance tooling.
State machine
Publishes the contract states, permitted transitions, required guards, transition-record requirements, and expressly forbidden transitions.
Used by: Contract orchestrators, ledgers, gate services, and state-machine validators.
Decision language
Publishes the public catalog of structured reason codes with category, severity, default disposition, message, remediation, retryability, and terminal-state meaning.
Used by: Boundary decisions, execution refusals, remediation, correction, and conformance evidence.
Verification
Indexes five positive and five negative test vectors covering admissibility, bounded grants, stale state, expired authority, action mutation, replay rejection, receipts, and correction.
Used by: Developers and reviewers validating public v0.1 behavior.
Publication
Identifies the public release, publication rights, excluded controlled assets, raw asset URLs, file sizes, and SHA-256 digests.
Used by: Provenance review, release verification, and automated documentation.
Plain-language object model
The schema descriptions provide field-level documentation. The definitions below explain what each major object means, why it exists, what produces it, and what consumes it during governed execution.
The person, service, workflow, or system that initiated the request.
Why it exists
Establishes request origin without assuming that the requester is also the actor, executor, or authority subject.
Produced by
Proposal interface or authenticated upstream system.
Consumed by
Contract builder, identity resolver, and policy resolver.
The model, agent, person, service, workflow, or composite runtime proposing or performing the action.
Why it exists
Separates the entity generating the proposal from the identity legally or operationally empowered to authorize it.
Produced by
Runtime identity and orchestration layer.
Consumed by
Authority validation, policy resolution, grant issuance, and receipt creation.
The exact candidate state change or consequential effect being requested.
Why it exists
Creates a canonical action digest so later mutation can be detected and the execution grant can remain narrow.
Produced by
Model, agent, human, workflow, or external system.
Consumed by
Contract builder, admissibility gate, grant service, executor, and receipt validator.
The person, account, record, asset, service, system, repository, or environment that may be affected.
Why it exists
Prevents general authority from silently widening to unintended resources or subjects.
Produced by
Proposal assembly and authoritative resource lookup.
Consumed by
Policy, authority, constraint, risk, grant, and execution validation.
An externally sourced assertion that a specific subject may perform a specific action against a specific target under defined conditions.
Why it exists
Prevents the proposing model or agent from reasoning itself into permission.
Produced by
Approved authority registry, role system, mandate, order, consent record, or delegated principal.
Consumed by
Authority validator, admissibility gate, grant service, and revocation process.
The attributable path by which authority moved from an authoritative principal to the acting subject.
Why it exists
Proves that delegation remained within scope and did not widen authority at any hop.
Produced by
Identity, role, mandate, and delegation systems.
Consumed by
Authority validator and conformance review.
An attributable view of authoritative operational reality at a recorded observation and retrieval time.
Why it exists
Ensures remembered, cached, inferred, or previously valid state is not treated as current state.
Produced by
External systems of record and state adapters.
Consumed by
Admissibility, grant verification, receipt comparison, and correction.
The separately preserved sources, provenance, timestamps, digests, and validation states supporting the decision.
Why it exists
Keeps evidence distinct from model interpretation, confidence, or narrative explanation.
Produced by
Evidence adapters, registries, records, sensors, and approved sources.
Consumed by
Policy evaluation, admissibility, audit, remediation, and correction.
The exact named, versioned, attributable rule set applied to the contract.
Why it exists
Prevents silent policy substitution and preserves which rule actually governed the decision.
Produced by
Policy resolver and approved domain profile.
Consumed by
Admissibility gate, transition ledger, receipt review, and conformance testing.
Machine-verifiable limits on action, target, amount, time, geography, data, tools, rate, approvals, and permitted effects.
Why it exists
Turns broad permission into enforceable bounded execution.
Produced by
Authority claim, policy, current state, risk classification, and domain profile.
Consumed by
Admissibility gate, execution grant, and execution broker.
The explicit boundary outcome determining whether the complete contract may proceed toward execution.
Why it exists
Separates probabilistic proposal generation from enforceable permission to act.
Produced by
SAQ™ Admissibility Gate.
Consumed by
Grant service, escalation workflow, remediation process, and ledger.
A narrow, expiring, revocable, use-limited, replay-resistant authority token bound to one admitted contract.
Why it exists
Allows the execution broker to verify the exact permitted action immediately before consequence.
Produced by
Execution Grant Service after admissibility.
Consumed by
Execution broker and receipt service.
The attributable record of the proposed, authorized, and realized action and resulting state.
Why it exists
Proves what occurred, exposes execution variance, and preserves the path from proposal to consequence.
Produced by
Executor and receipt ledger.
Consumed by
Ledger, correction service, conformance review, and accountability processes.
The record of revocation, reversal, compensation, suspension, remediation, escalation, or closure after reality changes or execution diverges.
Why it exists
Makes correction an architectural capability rather than a prompt edit or retrospective warning.
Produced by
Independent correction authority or correction service.
Consumed by
Ledger, affected workflows, operators, reviewers, and external authorities.
Non-executable starting state
A contract begins in DRAFT. This minimal example identifies the proposal and its parties but does not yet contain validated authority, evidence, current state, policy, constraints, or an admissibility decision. It cannot execute.
{
"header": {
"contract_id": "saq:contract:01K0EXAMPLE",
"schema_version": "0.1",
"created_at": "2026-07-24T15:00:00-05:00",
"expires_at": "2026-07-24T15:05:00-05:00",
"correlation_id": "workflow:ap:8841",
"digest": "sha256:...",
"digest_profile": "JCS-SHA-256"
},
"domain_profile": {
"profile_id": "enterprise-agent:payments",
"profile_version": "0.1"
},
"requester": { "requester_id": "shadow:person:8F31" },
"actor": { "actor_id": "agent:ap-ops-17", "actor_type": "ai_agent" },
"proposed_action": {
"action_type": "payment.release",
"action_digest": "sha256:..."
},
"target": { "target_type": "invoice", "target_id": "INV-8841" },
"lifecycle": { "current_state": "DRAFT", "transitions": [] }
}State before action
The lifecycle prevents a proposal from moving directly into consequential execution. Every transition is explicit, attributable, guarded, and recorded through the Ledger Layer inside the Coherence Boundary.
DRAFT → ASSEMBLING
The proposal is non-executable while identity, action, target, authority requirements, evidence requirements, policy, and constraints are assembled.
VALIDATING
External authority, current state, evidence, freshness, policy applicability, and required approvals are resolved.
ADMISSIBLE · CONDITIONAL · DENIED · ESCALATED · DEFERRED · EXPIRED
The gate records an explicit outcome, reason codes, and the exact basis of the decision.
AUTHORIZED → EXECUTING → EXECUTED
A narrow grant is issued, verified at the execution boundary, and consumed by the exact permitted action.
RECEIPTED → CORRECTED / CLOSED
The realized effect is recorded and remains linked to correction when authority, state, evidence, policy, or outcome changes.
DRAFT directly to EXECUTING, DENIED to EXECUTING without a new decision, expired authority reaching execution, material action mutation after authorization, receipt creation without executor identity, replay of a consumed grant, and silent policy substitution.
Positive and negative proof
The ten public vectors demonstrate the minimum visible behavior expected from an implementation. They do not disclose the full commercial conformance suite.
Publication, provenance, and rights
This page is the public documentation record for the machine-readable release associated with the SAQ™ Execution Contract Specification, Public Draft v0.1, document ID SAQ-ECS-0.1-20260723.
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.
Raw public schemas and examples may be inspected and used for technical evaluation. Claims of SAQ™ certification, conformance, authorized implementation, or commercial domain support require the applicable Samirac agreement and review.
Requirements describe. Mechanisms enforce. Conformance proves that the mechanisms operate.
Public Contract · Controlled Implementation · Provable Conformance
Samirac implementations enforce it at the execution boundary.
Builders and enterprises can evaluate the public contract now. Domain implementation, integration, conformance, licensing, and certification remain part of the Samirac commercial path.