Batch boundary

The Round.

User actions accumulate continuously. A round takes one consistent snapshot, performs the synthesis it requires, commits guarded mutations, and only then acknowledges the inputs.

scroll ↓
01

One snapshot, while the UI stays open

Boot pulls the live project state and records its generation. The round works from that stable snapshot; it does not repeatedly re-read a moving workspace while specialists reason.

Users can keep answering and uploading. New actions remain safely queued for a later round instead of being silently mixed into work that already started.

02

Required work is detected before it is interpreted

Pre-triage deterministically identifies triggers: submitted responses, pending uploads, stale evidence, outdated readiness, unmapped Requirements, draftable Sections, due Deliverables, and other work that must not be overlooked.

Auto mode chooses the smallest safe round shape. If a narrow mode would drop a required trigger, the runner escalates to a full round. Triage then batches and scopes specialist tasks.

03

Specialists work; dependencies re-close

Document summarisation, evidence evaluation, and question architecture fan out where useful. Their outputs are typed at the boundary.

Any evidence or question change triggers a same-round readiness plan and sweep. Elevator does not wait until tomorrow to discover that a newly answered Question unblocked a Requirement—or that stale Evidence blocked it again.

04

The package is planned and composed

The document architect routes Requirements to Deliverables. The draft composer writes confirmed, draftable material. The consistency auditor checks contradictions across the resulting package.

Integrate reconciles those outputs into one proposed state change, a round note, and recipient-specific email drafts. It omits tables it has no reason to touch.

05

Cheap gates fail first

JSON-schema validation catches invented columns, missing fields, and invalid nulls before a model-based checklist runs. The independent checklist then audits the round's reasoning and user-facing outputs.

Deliverable commands are planned and validated separately. A malformed action or missing trigger acknowledgement stops the round before production state changes.

06

Commit is guarded, not singular

The snapshot-shaped state push uses optimistic concurrency against the boot generation. Deliverable actions then execute through typed server-side RPCs. Pending uploads are promoted through compare-and-swap operations rather than stale table replacement.

Inputs are marked processed last. If any required durable mutation fails, the input remains queued instead of being acknowledged for work that never landed.

07

The round leaves a human-readable trail

Finalisation records the post-commit generation and writes the user-facing round note. Relevant participants receive draft emails in the outbox; sending remains a deliberate human action.

Local artefacts make a round inspectable and resumable, but they are scratch. Durable project state lives in the Worker, object storage, and edit logs.

read next · one input, four outcomes
The Question Workflow

How a verbatim human response can answer, partially fulfil, open a new gap, or reveal that the original question was framed incorrectly.