AIX execution and data flow

AIX separates fast API requests from durable work. The browser may disconnect after a task is accepted; execution continues from committed state and the UI reconnects to persisted progress.

Task lifecycle

sequenceDiagram
    participant UI as AIX workspace
    participant API as Product API
    participant DB as Product PostgreSQL
    participant W as Product worker + DBOS
    participant L as Legal Core
    participant M as Model provider

    UI->>API: Submit message and task
    API->>DB: Commit message, task and command
    API-->>UI: Accepted task ID
    DB-->>W: Relay committed command
    W->>DB: Load authorized context
    W->>L: Retrieve legal evidence
    W->>M: Plan, synthesize and assess
    W->>DB: Publish result and ordered events
    UI->>API: Reconnect with event cursor
    API-->>UI: Events or current snapshot

The command and the state that justifies it commit together. Repeated delivery uses stable identifiers. A result publishes only if its task generation, permissions, deadline, and document base revision still match.

Reasoning loop

flowchart LR
    Context[Assemble authorized context] --> Plan[Plan bounded work]
    Plan --> Action{Next action}
    Action -->|research| Evidence[Retrieve evidence]
    Action -->|tool| Tool[Run typed capability]
    Action -->|missing fact| Wait[Durable clarification wait]
    Evidence --> Assess[Validate and assess]
    Tool --> Assess
    Wait --> Context
    Assess -->|gap within limits| Plan
    Assess -->|supported| Draft[Assessed draft]
    Assess -->|risk or incomplete| Review[Review-required draft]

The loop is bounded by task deadlines, context size, step count, provider concurrency, and AIX credits. Tool arguments and results use typed contracts. Unknown provider outcomes are reconciled instead of blindly repeated.

Execution status and legal assessment are separate: a task can complete with an assessed, review_required, or incomplete result. Lawyer acceptance is a further explicit decision.

Data ownership

flowchart TB
    subgraph ProductData[Product data]
        Conversation[Conversation and messages]
        Task[Task, stages and events]
        Documents[Document versions and proposals]
        Memory[Preferences and project memory]
        Usage[Credits and provider usage]
        PrivateIndex[Private chunks + pgvector]
        ProductFiles[(Private file bytes)]
    end

    subgraph Execution[Durable execution]
        Journal[DBOS journal<br/>IDs, timers and step state]
    end

    subgraph LegalData[Legal data]
        Sources[Immutable legal versions]
        Generations[Published index generations]
        LegalIndex[Legal chunks + pgvector]
        Originals[(Corpus originals)]
    end

    Task --> Journal
    Journal -. stable references .-> Task
    Documents --> PrivateIndex
    Documents --> ProductFiles
    Task --> Usage
    Task -->|Legal Core API| LegalIndex
    Sources --> Generations --> LegalIndex
    Sources --> Originals

Large or sensitive content stays in application-controlled PostgreSQL or object storage. Workflow state carries stable references and bounded results. Search indexes and caches are derived data and cannot widen source permissions.

Documents and legal evidence

flowchart LR
    Upload[Private upload] --> Parse[Bounded extraction]
    Parse --> Private[Private chunks and embeddings]
    Question[Research question] --> Retrieve[Authorized hybrid retrieval]
    Private --> Retrieve
    Published[Published legal generation] --> Retrieve
    Retrieve --> Evidence[Versioned passages and provenance]
    Evidence --> Proposal[Revision-bound proposal]
    Proposal --> Accept{Lawyer accepts?}
    Accept -->|yes, base still current| Revision[New document revision]
    Accept -->|no or conflict| Keep[Keep existing revision]

Private retrieval applies tenant and resource access before text reaches a model. Legal retrieval returns stable source versions and passage anchors. Citation matching is mechanical; semantic assessment can expose unsupported claims and contradictions but cannot certify legal correctness.

Corpus ingestion follows acquire → parse → version → index → publish. A complete index generation becomes visible through one active pointer, so search never serves a partially built legal index.

Control and recovery

stateDiagram-v2
    [*] --> accepted
    accepted --> running
    running --> waiting: clarification
    waiting --> running: response
    running --> completed
    running --> failed
    running --> cancelled
    accepted --> cancelled
    running --> recovery_required: unsafe restore or unknown state
    completed --> [*]
    failed --> [*]
    cancelled --> [*]
    recovery_required --> [*]

Material steering creates a new generation and fences results from the old one. Cancellation blocks publication before propagating cleanup. A normal process restart can replay durable steps; a cross-store restore cannot assume PostgreSQL, DBOS, blobs, and providers share one consistent point, so affected work is quarantined for explicit reconciliation.