01State transition model
Transactional state changes
Configured writes can use locks, invariant checks, ordered transitions, and recorded projections.
- Locks and invariant checks
- Ordered transitions
- Recorded projections
MaxQ Engine V2
A runtime for transactional state, checkpointed work, and scoped task context.
This MaxQ V2 architecture concept combines transactional state changes, saved checkpoints, and permission-scoped task access.
Failure state is explicitConfigured recovery paths are modeled in product state.
Task context is assembledAgents receive selected fields and actions, not raw data access.
Concept model
Statetransition model
Workcheckpoint model
Accesspermission gates
State graphExample
Checkpointed workflow timelineConfigurable waits
Example executionIllustrative
Workflow: customer-onboarding.example Status: waiting Current step: wait.documents Wake condition: DocumentBundleUploaded Committed steps: ok start-onboarding ok emit CustomerOnboardingStarted Pending: - verify-documents - approve-or-escalate
Task contextTask-scoped example
The concept uses three controls
Transactional stateConfigured writes use locks and invariant checks.
Saved checkpointsConfigured workflows pause and resume from stored state.
Scoped task contextAgents receive selected fields and permitted actions.
The problem
Retries, waits, approvals, and agent actions fragment product state.
Retries, timeouts, human approvals, and agent actions can leave systems with conflicting or incomplete state when recovery and permissions are handled separately.
State drift
Multiple systems update the same entity with no single source of truth.
Fragile workflows
Retries, waits, and long jobs create duplicate side effects.
Context sprawl
Agents lack permission-scoped, current context and invent missing product state.
Poor observability
Teams cannot see what happened, why, and what is allowed next.
The engine
Transactional state, durable checkpoints, and scoped agent context in one runtime.
MaxQ combines transactional state changes, durable checkpoints, permission-scoped task context, and audit records for agent writes.
Review design checks ->02Pause and resume model
Checkpointed workflows
Configured workflows can save a checkpoint, wait for a timer, signal, or approval, and resume from saved state.
- Saved checkpoints
- Configured waits
- Idempotency keys for side effects
03Permission-scoped access
Scoped task context
Agents receive fields and permitted actions selected for a task instead of broad database access.
- Task-specific fields
- Permission-scoped tools
- Recent source events
Interactive concept
Customer onboarding concept model.
Click through the configuration models to compare inputs, execution state, task context, and permitted outputs.
ScenarioTransactional
Intent receivedcomplete
Entity lockedcomplete
State committedactive
Context refreshedpending
Action deliveredpending
Concept consoleIllustrative
Workflow: customer-onboarding.example
Mode: transactional state
tx.start("start-onboarding")
lock customer record
require status != "blocked"
transition onboarding.started
project CustomerAccess
result: illustrative state transitionTask contexttransition model
Inputs
Events
Entities
Identity
Permissions
MaxQTransactionalConfigured writes use locks and invariant checks before a state transition.transition model
Outputs
State model
Allowed actions
Projections
Replay
This concept records an event, checks configured invariants, locks the record, updates projections, and commits the next state.
Design checks
Controls represented in the architecture.
Locks, invariant checks, and ordered transitions record how configured writes change product state.
Configured work can wait on timers, signals, or human approval and resume from a saved checkpoint.
Recovery can start from saved execution state instead of rerunning the entire job.
The context model selects current fields, permissions, workflows, and recent events for a task.
Conceptual TypeScript sketchTransactional state
const tx = await maxq.kernel.transaction("customer.onboarding");
tx.lock(Customer, customerId);
tx.require(customer.status !== "blocked");
tx.transition("onboarding.started");
tx.project(CustomerAccess);
await tx.commit();Illustrative outputexample
lock customer record
validate invariant
commit next state
Conceptual coherence checkexample
example entity schema loaded example transition map loaded example invariant set loaded example permission check complete
Where MaxQ fits
For products with long-running work, shared state, and agent actions.
Wait for documents, verify risk, escalate when needed, and resume from a saved checkpoint.
Record transitions for subscriptions, invoices, permissions, and agent decisions.
Give agents task-specific fields and permission-gated actions instead of broad database access.
Implementation
Add checkpointed work and permission-gated writes to your product.
Use transactional state changes, durable checkpoints, scoped data, permission gates, and audit replay in one runtime.