Durable Task States
How Aevum Encyclopedia persists, tracks, and transitions long-running knowledge workflows across AI processing, expert review, and publication pipelines.
State Overview
The durable task state machine governs all article creation, revision, and metadata synchronization workflows. Each state represents a stable checkpoint where the system guarantees persistence, observability, and safe transition conditions.
State Machine Flow
Tasks progress through a deterministic directed acyclic graph (DAG). Backtracking is only permitted via explicit resolution events.
State Definitions
| State ID | Description | Entry Trigger | Exit Conditions |
|---|---|---|---|
| DRAFT | Initial state. Content is locally stored but not queued for processing. | Manual creation or import webhook | Submit for AI review |
| AI_ANALYSIS | Automated fact-checking, entity extraction, and cross-reference generation. | Transition from DRAFT | Analysis complete → PEER_REVIEW or RESOLUTION_REQUIRED |
| PEER_REVIEW | Assigned to domain experts for human verification and editorial pass. | AI analysis passes confidence threshold | Approval → APPROVED, or Rejection → RESOLUTION_REQUIRED |
| RESOLUTION_REQUIRED | Conflicts, low-confidence assertions, or editorial disputes flagged. | AI or reviewer flags issues | Author/editor resolves → re-enters PEER_REVIEW |
| APPROVED | Content meets all quality gates. Queued for canonical publication. | Consensus from ≥2 domain reviewers | Auto-transition to PUBLISHED |
| PUBLISHED | Live in the public encyclopedia. Indexed and cached globally. | Approval pipeline completes | Manual deprecation or version supersession |
| DEPRECATED | Archived. Superseded by newer version or factually invalidated. | Editorial board decision or automated decay rule | Terminal state (immutable) |
State Transitions & API Contract
All state changes must be requested via the orchestration API. The system validates preconditions, applies business rules, and appends a signed event to the durable log.
{
"new_state": "PEER_REVIEW",
"metadata": {
"reviewer_ids": ["usr_8x92a", "usr_4k11m"],
"ai_confidence_score": 0.94,
"flagged_claims": [],
"version": "v2.1.0"
},
"idempotency_key": "uuid-7a3b9c2d-1e4f-5g6h-7i8j-9k0l1m2n3o4p"
}idempotency_key field is mandatory. Duplicate requests with the same key within a 24-hour window are silently deduplicated to prevent state corruption.
Transition Guards
Before committing a transition, the engine evaluates:
- Precondition Checks: Verifies required metadata fields and reviewer availability.
- Consistency Locks: Optimistic locking prevents concurrent modifications on the same task version.
- Event Validation: Cryptographic signature verification and schema validation via JSON Schema draft-2020-12.
Persistence & Replay Architecture
Durable tasks are implemented using an event-sourced architecture. Instead of storing mutable state, the system maintains an append-only event log:
- Each state transition emits a strongly-typed event (
TaskCreated,AnalysisCompleted,ReviewApproved, etc.) - Events are written to a distributed commit log with WAL (Write-Ahead Logging) guarantees.
- State is derived by projecting events forward from a known checkpoint.
- Crash recovery replays the event log to reconstruct the exact state at the time of failure.
This design ensures exactly-once semantics, full audit trails, and safe horizontal scaling of the orchestration workers.
Related Documentation
- Checkpointing & Replay Strategies
- Conflict Resolution Protocol
- Webhook & Event Streaming Configuration
- Orchestration Worker Scaling Guide