Aksara [v0.7.0] — Durable Authorized Operations

[nagarjuna-tella]

Aksara v0.7 makes authorized backend operations durable.

v0.6 established the rule that AI agents and tools must execute inside the same authentication, tenancy, permission, policy, transaction, and audit boundaries as the rest of the application.

v0.7 extends that model across time and failure.

An operation can now outlive the HTTP request, process, or worker that started it while preserving authoritative state, scoped retry identity, current authorization, fenceable ownership, approval and cancellation intent, and recoverable execution history.

Durable Operations

Aksara now provides a first-class durable execution model built around two concepts:

• Operation — the authoritative logical request.
• Attempt — one physical execution of that Operation by a worker.

Operations are stored in PostgreSQL and survive:

• request loss
• application restart
• worker crashes
• worker replacement
• retry delays
• approval waits
• cancellation
• transient execution failures

The current PostgreSQL Operation row remains authoritative. Attempts and transition records explain execution history without becoming a separate source of truth.

Safe retries and scoped idempotency

Durable submissions can use scoped idempotency.

The identity includes the relevant application, tenant, initiating principal, action/version, client key, and normalized semantic input.

This means:

• concurrent identical submissions resolve to one logical Operation
• retrying after a lost response returns the same Operation
• reusing the same identity with changed input fails deterministically
• deduplication remains explicitly time-bounded rather than being promised forever

A lost response is therefore no longer a reason to blindly repeat a mutation.

Clients can reread authoritative Operation state or safely resubmit the same idempotency identity.

Database-time leases and fencing

Each physical claim creates a new Attempt with:

• worker ownership
• lease expiry
• monotonically increasing fence

Lease decisions use PostgreSQL time rather than worker clocks.

If Worker A owns fence N, its lease expires, and Worker B later acquires fence N+1, Worker A can no longer:

• heartbeat
• update authoritative execution state
• retry
• cancel
• finalize
• perform a guarded application mutation

The ownership check happens before application SQL inside the protected transaction.

This prevents a stale worker from waking up after replacement and corrupting application state.

Atomic PostgreSQL execution

For supported postgres_atomic actions, Aksara provides a strong same-database guarantee.

The following share one guarded PostgreSQL transaction:

• ownership validation
• application mutation
• Attempt success
• Operation success
• result persistence
• transition evidence
• outbox intent

They commit together or roll back together.

This means Aksara does not produce durable state where a supported application mutation committed but the Operation still claims it did not succeed, or vice versa.

The guarantee applies only to supported writes through the owning Aksara Database and guarded execution context.

Independent database connections, separate databases, subprocess/thread mutations, direct connection-pool escapes, and external network effects are outside that atomic boundary.

Authorization across time

Durable execution does not freeze authorization at admission time.

Aksara stores non-secret principal provenance, not reusable credentials or permanent authority.

Before supported delayed effects, the framework resolves the current Principal and checks current:

• identity
• tenant membership
• scopes
• action authorization
• PolicyEngine decisions

Application-specific object, permission, field, and model validation continue to belong to the registered action authorization boundary.

If a user loses permission while an Operation is waiting, the old admission decision does not grant permanent access.

Durable approvals

Approval decisions can now survive worker and process loss.

A durable decision is bound to the exact:

• Operation
• action/version
• normalized input
• tenant
• requester
• approver
• expiry

Approval records intent.

It does not replace authorization.

If the requester loses permission after approval, execution still fails current authorization.

Durable cancellation

Cancellation is now durable intent.

It can prevent future work when it wins the race against execution, including while an Operation is waiting, ready, delayed, or running.

Cancellation does not:

• undo already committed PostgreSQL work
• reverse an external effect already sent
• rewrite a successfully completed Operation

Completion and cancellation compete through the authoritative Operation row.

Background task integration

Existing Aksara background tasks remain supported.

Tasks can optionally schedule durable Operations, but task state does not become execution authority.

For linked work:

• the task schedules execution
• the Operation owns logical state
• the Attempt owns physical execution
• the fence controls current ownership

Existing unlinked v0.6 task APIs, IDs, queues, scheduling, and CLI behavior remain compatible.

External effects

Aksara explicitly distinguishes external-effect behavior.

Supported effect classes include semantics for:

• idempotent providers
• reconcilable at-least-once providers
• nonretryable providers
• read-only work

Before an external mutation, Aksara can persist durable intent and a stable operation-scoped effect identity.

On recovery:

• idempotent providers reuse the same downstream key
• reconcilable providers are checked before repeating work
• unreconcilable ambiguity becomes external_outcome_unknown

Aksara does not claim exactly-once execution for arbitrary external systems.

PostgreSQL and an external provider do not share one atomic transaction.

Operational history and outbox

Durable Operations include bounded transition evidence and transactional outbox intent.

This supports:

• diagnostics
• export
• operational history
• external audit pipelines

The current Operation row remains authoritative.

Aksara does not turn this into event sourcing or claim that application-owned history is a tamper-resistant compliance ledger.

Retention

Durable state is intentionally bounded.

The framework supports retention and pruning for:

• terminal Operations
• Attempts
• results
• errors
• transitions
• approval decisions
• idempotency identities
• outbox records

Active work is protected, and idempotency identities remain available for their promised deduplication window.

Compatibility

Durable Operations are additive and opt-in.

Existing applications do not need to:

• register durable actions
• mount the durable router
• start durable workers
• use task-backed Operations

Existing v0.6 behavior remains in force for:

• ORM
• migrations
• generated REST
• synchronous MCP
• identity
• permissions
• tenancy
• background tasks
• CLI
• diagnostics
• signed synchronous approval grants

Principal remains Aksara's runtime authority type.

MCP

Existing synchronous Streamable HTTP MCP remains supported.

Protocol-level durable MCP Tasks are not included in v0.7.

The current official MCP Python SDK does not yet implement the io.modelcontextprotocol/tasks extension, and Aksara does not introduce a competing private wire protocol.

Durable Operations are therefore available independently of protocol-level MCP Tasks.

Infrastructure

PostgreSQL remains the only mandatory durable authority.

v0.7 does not add mandatory dependencies on:

• Redis
• Kafka
• Celery
• Temporal
• another coordination database

What remains experimental or deferred

v0.7 does not stabilize:

• planner quality
• persistent AI conversations or sessions
• memory
• multi-agent execution
• autonomous workflows
• provider-specific quality
• Studio AI internals
• generic workflow/DAG composition
• approval workflow UX
• long-term compliance retention
• protocol-level MCP Tasks

DurableStep also remains an evolving workflow-step cache and does not inherit the new Operation/Attempt guarantees.

Validation

The final v0.7.0 release passed:

• 8,271 full-suite tests with 2 expected skips
• 8,271 passed, 2 skipped in each supported Python 3.11/3.14 runtime matrix cell
• 258 durable-operation tests
• 24 production-bound invariant tests
• 429 security tests
• 165 fuzz tests
• 314 diagnostic tests
• 455 migration tests
• 114 documentation-contract tests
• 15/15 installed-wheel checks
• 66/66 packaged Support Desk checks
• 7/7 performance sanity invariants
• 21/21 hosted release checks with PostgreSQL 16

Doctor completed with no warnings, failures, or blockers.

Ruff and mypy ratchets passed.

Bandit, dependency audit, Gitleaks, Twine, strict documentation, package validation, and CycloneDX SBOM validation also passed.

Upgrade notes

After installing v0.7.0:

1. Run aksara migrate using the migration role.
2. Grant the restricted application role the required DML and sequence privileges on the new internal tables.
3. Register all durable action and principal resolver versions before starting workers.
4. Run check_durable_operations() for each deployed application/tenant profile.
5. Start explicitly tenant-scoped durable workers and the application-owned outbox exporter where used.
6. Configure and monitor Operation, result, error, idempotency, and audit-retention windows.
7. Keep old action/resolver versions deployed while nonterminal Operations still reference them.

Release artifacts

aksara_framework-0.7.0-py3-none-any.whl

SHA-256:

b5ceaafb547bdf095011a2ab10138c5e596a012143dd25ae7b482ff164f7816e

aksara_framework-0.7.0.tar.gz

SHA-256:

b52895d0b5f4443be6801f43d265d6520544ea1a3012edd1b7dac8d1379e34be

---

Aksara v0.7 moves the framework from safe execution inside a single invocation to durable execution across failure and time:

An authorized operation can outlive the request, process, or worker that started it without escaping the backend's authorization, tenancy, transaction, ownership, and recovery boundaries.

---

This discussion was created from the release Aksara [v0.7.0] — Durable Authorized Operations.