Workstream

Workstream is governed contribution infrastructure for coordinating, verifying, and recording work performed by humans, AI agents, or both. It transforms project-defined tasks, immutable submissions, policy-governed checks, and policy-governed acceptance into trusted ContributionRecord facts that applications, organizations, and economic systems can consume.

Workstream governs the work lifecycle; it does not need to own the system that requested the work, the tools used to complete it, the identity provider, or the consequence applied afterward. A project defines the rules, an authorized contributor performs the work, Workstream binds the exact submitted artifact to those rules and its verification evidence, and records the authorized outcome under the project's locked acceptance rules. The resulting immutable contribution lineage establishes who did what, under which rules, using which artifact, and with what verified result.

End-To-End Lifecycle

The complete Workstream model is:

Project Guide
-> Versioned Policies
-> Task Assignment Or Claim
-> Artifact Preparation And Pre-Submission Intake Checks
-> Immutable Submission
-> Post-Submission Work Evaluation
-> Policy-Governed Acceptance (Human Review When Required)
-> Accept / Needs Revision / Reject
-> Revision And Resubmission When Required
-> Immutable ContributionRecords
-> Optional Project-Specific Consequences

The current submission contract normally receives one outer ZIP containing the complete work. Workstream computes canonical content identity, stores the bytes through its artifact boundary, verifies stored content before trusted use, and runs configured checks against the submitted package and its bounded recursive contents. After Submission creation, the contributor's submitted work, post-submission checkers, reviewers, and downstream projections are tied to the same immutable Submission lineage. Before creation, intake evidence refers to the prepared artifact and locked intake context, not an existing Submission.

Pre-submission and post-submission checking are different stages:

• Pre-submission intake checks assess whether the prepared package is fit to submit: required outputs, packaging, evidence integrity, and configured intake-quality rules. Blocking failures return feedback before a Submission is created. Passing intake does not establish that the task was done correctly.
• Post-submission work evaluation assesses the immutable submitted work against the locked task/project requirements. Durable results determine review eligibility, not final acceptance. Task-specific evaluation may use deterministic rules or, when supported and registered, model/agent-based evaluators such as a quality judge. These are not the setup agent that proposes checker policies. Raw checker results are not acceptance authority; when human review is required they do not replace that Review.

The v0.1 project setting human_review_required defaults to true in the existing locked ReviewPolicy. After required post-submit checks pass, true requires human review; false uses an authorized automated FinalAcceptance and submitter ContributionRecord, with no reviewer contribution. The separate requires_second_review policy field is fixed to false at input, immutable lineage, and database boundaries; second-review and adjudication behavior remain deferred. The automated-acceptance branch is not live yet: the policy setting is implemented for configuration, and the hidden submitter participant can stage or exactly replay its complete frozen award set. Shared acceptance, TASK terminal effects, authority/source custody, routing activation and public composition remain pending. Adjudication is excluded.

The stage describes the purpose and lifecycle boundary, not a promise that all checks are deterministic. Deterministic compilation and policy routing do not make model-based judgments reproducible. Only supported implementations run; the roadmap distinguishes existing foundations from remaining integration and does not claim a live agent judge.

On the human-review branch, every valid Review creates a reviewer completed_review ContributionRecord. An accept decision also creates FinalAcceptance and a submitter accepted_submission ContributionRecord. These records cannot be created or edited directly by a person or downstream adapter. Together they are the central durable outcome of Workstream.

How Workstream Establishes Trust

• Identity is separate from authority. External identity verification does not grant product access. Explicit administrative or project-scoped grants, resource ownership, lifecycle guards, and revocation determine authority.
• Project rules are versioned and locked. Assignments, submissions, Reviews, and contributions retain the guide and policy context that governed them instead of silently adopting later rules.
• Artifacts are immutable and content-addressed. Workstream derives identity from server-computed SHA-256 and byte count, independently verifies stored bytes, and binds trusted content facts to that identity.
• Checks have distinct, attributable evidence. Pre-submit results refer to the prepared artifact and locked intake context before Submission creation. Post-submit results refer to the immutable Submission and locked evaluation policy. Intake feedback cannot substitute for post-submit review-gate evidence; recording an evaluation does not guarantee an identical judgment on rerun.
• Review is authorized and attributable. A Review records the authorized reviewer, exact artifact lineage, locked rules, findings, and one canonical decision: accept, needs_revision, or reject.
• Separation of duties limits self-dealing. Submitter and reviewer authority are independent, self-review is prohibited, and narrower project conflict rules may be enforced.
• History is preserved. Submissions, findings, responses, resolutions, Reviews, contribution records, awards, receipts, and audit evidence remain linked rather than being overwritten.

Source-Agnostic Core, Bounded v0.1 Intake

Workstream does not require tasks to originate from one marketplace, application, organization, or industry. AI evaluation programs, government workforce initiatives, research programs, open-source projects, contractor pipelines, academic review, data-labeling operations, and legal, medical, engineering, creative, human-to-agent, or agent-to-agent workflows can use the same governed lifecycle while retaining their own user experience and operating model.

Source-agnostic does not mean every source adapter is already implemented. v0.1 remains manual-first with controlled manual, Markdown, and CSV intake. External origin onboarding, external task-routing systems, and execution workspaces remain later adapters. Revision and reassignment belong to the governed lifecycle; adjudication remains a separately approved future capability rather than a claim about current v0.1 behavior.

Product Boundary

Workstream determines what governed work occurred and whether the resulting contribution fact can be trusted. Payments, points, tokens, staking, slashing, reputation, eligibility, reporting, datasets, and model-training systems may consume that fact and apply project-specific consequences. They do not create, revise, or control Workstream identity, authorization, submission, review, or contribution truth.

That boundary allows one Workstream core to support centralized, sovereign, federated, and permissionless applications without coupling lifecycle truth to any one application's business or economic model.

Flow Identity is the current v0.1 external authentication provider. It is an adapter boundary, not the definition or ownership boundary of Workstream. Workstream is not an execution workspace and is not blockchain-first.

Core Invariants

Different projects speak different domain languages, but Workstream preserves the same governing invariants across them:

• project guides and policies are versioned before they govern work
• tasks, assignments, submissions, checks, and Reviews retain their exact project and actor lineage
• invalid submission packets stop before trusted Submission creation
• findings, responses, resolutions, Reviews, and contribution facts append to history rather than rewriting it
• FinalAcceptance is the sole source of an accepted submitter contribution
• conditional compensation follows contribution truth and never controls it

These invariants turn project-specific operating knowledge into reusable infrastructure without narrowing the complete v0.1 lifecycle defined above.

Current v0.1 State

Workstream is under active v0.1 development. Progress is tracked by proven capabilities, not by calendar weeks or promised dates.

Implemented foundations on main include external Flow-token verification, canonical local actors and authorization, project guides and task records, submission packets, immutable artifact storage, pre-submit intake checks, and authorized retained submission/checker history. ARCH-04C implements hidden durable post-submit execution and unfinished-attempt recovery. ARCH-04D2 supplies exact service authority. ARCH-04E1A adds immutable route-neutral TASK source storage, detached source facts and accepted-effects contracts. B6 commits each new hidden Submission with its initial checker reservation and outbox request; automatic request delivery, routing and acceptance remain unavailable. Project-guide ingestion stores original documents, records immutable metadata and provides authorized exact-file reads to the unified setup agent. Guide metadata in PostgreSQL also holds at least one required task example; the agent assesses the examples with the uploaded guide documents. Findings and policy proposals retain document-access evidence.

ART-07A1 provides strict metadata-only reviewer packet types, not a resolver or byte-access capability. REV-03B persists immutable normalized packets using live guide ingest identities. REV-04A Review and REV-04B shared FinalAcceptance storage foundations are delivered; CON-03C contribution/award storage, REV-12A1's disabled controller/transaction fence, exact hidden AUTH preparation and CON-07 hidden source-neutral submitter participation with complete frozen award sets are delivered. REV-04C adds one hidden source-neutral participant that stages FinalAcceptance, TASK accepted/completed effects and the complete CON submitter outcome in the caller's transaction. It is not a complete authorized acceptance operation: its input has no exact AUTH decision-event receipt, and database complete-set enforcement, currentness race proof, shared audit/outbox and lifecycle activation remain. ARCH-04E1B-B1 requires TASK locking before checker reservation, current-result reads and review admission INSERTs, preserving exact read-only reservation replay after acceptance. ARCH-04E1B-B3 retains the inspected ZIP file metadata with immutable ART evidence and returns it on consumption without another storage read. ARCH-04E1B-B6 commits each new Submission, verified binding, exact AUTH receipts, generation-one evaluation reservation and one shared outbox request atomically. Fresh-authorized replay returns the original identities without recreating rows. ARCH-04E1B-B4 binds the Submission summary and attestation to the packet that passed intake, with service and database enforcement. ARCH-04E1B-B5 rejects evaluation content that exceeds the locked checker limits before any pre-check attempt or durable upload intent, using the same content contract required by later dispatch. ARCH-04E1B-B2 prepares exact source proposals from current CHECKERS custody and historical PROJECTS policy, without inserting a manifest or granting authority. Hidden handlers still need complete authorized currentness proof. These prerequisites do not require live human review before the first automated acceptance path.

Active work is connecting those foundations into the remaining production lifecycle: hidden routing handlers, acceptance authority/evidence closure, review and revision, reviewer participation and conditional fulfillment. Contribution evidence remains the input for a separately implemented future reputation projection. Frontend product work follows stable and tested backend contracts for the surface it consumes.

The release bar is a verified end-to-end v0.1 lifecycle, not the completion of an old timeboxed plan. See the v0.1 Roadmap And Capability Status for the lifecycle scoreboard, current critical path, and complete release gates; reading internal engineering records is not required to understand product progress.

Start Here

• Developer Quickstart
• Contribution Guide
• v0.1 Roadmap And Capability Status
• Product Principles
• Product Brief
• Architecture Lockdown
• System Architecture
• Glossary
• Historical Planning Index

Product And Operations Documentation

• Product Principles
• Product Brief
• First User Flows
• Architecture Brief PDF — target architecture
• Architecture Diagrams
• System Architecture
• Data Model
• Lifecycle State Machine
• Checker Framework
• Operator Workflow
• Project Operating Manual
• Queue Policy
• Workspace And Packet Convention
• Reviewer Workflow
• Revision Replay
• Review And Revision Lifecycle
• Roles And Permissions
• Authorization Service
• Immutable Artifact Storage
• Contribution And Compensation
• Authorization Operations
• Compensation And Reputation
• Risk Register
• Process Pattern Baseline
• Glossary

Historical Review Records

These records preserve earlier product, architecture, process, and adversarial reviews. They are evidence and design history, not current implementation status. Current changes receive review through CONTRIBUTING.md.

• Process Baseline Operations Review
• Final Product Strategy Review
• Final Architecture Review
• Final Adversarial Review
• Adversarial Quality Review
• Process Pattern Baseline Review
• Review Closure

Templates

• Project Guide Template
• Submission Artifact Policy Template
• Checker Policy Template
• Task Template
• Review Readiness Evidence Template
• Submission Packet Template
• Review Packet Template
• Task Status Template
• Prior Feedback Checklist Template

Decisions

• ADR 0001: Core Scope
• ADR 0002: Database Ledger Before Blockchain Settlement
• ADR 0003: Project Guides Are First-Class
• ADR 0004: v0.1 Implementation Stack Is Locked
• ADR 0005: Postgres Is The Record Database
• ADR 0006: Workstream Verifies External Flow Auth
• ADR 0007: Execution Is Async-First
• ADR 0008: Files Use An Object-Storage Abstraction
• ADR 0009: Review Decisions Are Canonical
• ADR 0010: Human Revision Rebase Uses The Complete Active Project Context
• ADR 0011: Submission Artifact Policy Drives Pre-Submit Intake
• ADR 0012: Workstream Owns Product Authorization
• ADR 0013: Immutable Artifact Storage Boundary
• ADR 0014: External Services Use One Adapter Convention
• ADR 0015: Project Contributor Roles Are Independent
• ADR 0016: Contribution Recognition Precedes External Fulfillment

Authorization Baseline

Workstream verifies externally issued Flow authentication tokens and owns its product authorization. Token role claims, email, display name, skills, reputation, and typed workflow profiles are not product authority. Canonical authority comes from local actor identity links, administrative grants, exact-project contributor grants, registered permissions, resource/lifecycle guards, revocation, and append-only evidence.

All public API documentation uses /api/v1. Imported reference specifications are immutable archival inputs. ADR 0012 and the canonical authorization service specification control authorization; ADR 0016 and the canonical contribution and compensation specification control contribution recognition, award eligibility, and fulfillment boundaries. Older chunk specifications remain implementation history until their owning migrations replace the runtime.

Terminal Client

The independent Go CLI provides workstream whoami and workstream project access PROJECT_ID, plus workstream profile update for caller-owned human display fields, through the currently public REST API. workstream project show PROJECT_ID inspects the project fields returned for the caller's current authority, preserving contributor-minimal disclosure. workstream project tasks PROJECT_ID and project task PROJECT_ID TASK_ID provide a paginated manager list-to-detail journey through public reads. workstream task ready PROJECT_ID and task show TASK_ID provide contributor discovery and instructions, with live Submitter authority and no task claim. workstream task claim TASK_ID --idempotency-key UUID and task start add contributor writes through existing public APIs, with server-owned authority, explicit caller retry keys and uncertain-outcome reporting without automatic retries. workstream task context TASK_ID and task requirements TASK_ID inspect the governing guide/policy selectors, server action hints and locked intake rules. Hints do not grant authority; requirements do not expose hidden submission upload. workstream task guide TASK_ID [--download DIR] lists or downloads the original documents of the task's locked guide for its currently authorized assignee. Downloaded bytes are verified against their retained hash and size; task examples remain private, and newer guide activation does not change existing task locks. workstream project create --name TEXT --slug TEXT --idempotency-key UUID creates a draft project shell through the public API, with explicit manual replay and uncertain-outcome handling; it does not approve or activate a guide. workstream project guide create PROJECT_ID --input FILE --idempotency-key UUID declares a draft guide, task examples and document upload targets. It does not upload documents or approve the guide; returned setup waits for those documents. workstream project guide upload PROJECT_ID GUIDE_ID DOCUMENT_ID --file FILE --media-type MIME --idempotency-key UUID uploads a declared original. The CLI streams its bytes and validates the storage receipt against their hash and size. An upload receipt is not setup completion, policy approval or guide activation. All support human-readable and JSON output, using the caller's Flow token. The first source package is buildable; further workflow commands and published binaries remain planned.

Repository-Native Human-Agent SDLC

Workstream uses a Repository-Native Human-Agent SDLC. Plans, tests, review, and durable decisions live with the code so humans and agents can collaborate without depending on chat history. GitHub permissions and branch protection remain the repository authority; process notes never create a second permission system.

Intent
-> Plan
-> Bounded Change
-> Evidence
-> Review
-> PR
-> Human Merge

Codex-discoverable skills live in .agents/skills/. Codex custom reviewer agents live in .codex/agents/. The smallest useful durable engineering records live in .commitrail/; start with its README.md and INDEX.md.

This engineering loop is separate from Workstream product state. It governs how the repository is changed; it does not define runtime task or review records. Independent initiatives and branches may proceed concurrently. Start with CONTRIBUTING.md before proposing repository work.

The shared outbox dispatcher uses the fixed service identity and phase-specific AUTH/PREP decisions for claim, invocation and finalization. AUTH-OUTBOX-02 binds those decisions to immutable delivery receipts and supplies Celery delivery and bounded recovery scans. ARCH-03C2 registers exact assignment invalidation, with atomic publication from supported authority mutations and separate fixed feature authority. Checker routing still needs its own authorized handler. Delivery consumes workstream.outbox only under a validated non-eager prefork Celery process; other queues can use their appropriate execution pool.

Developer Quickstart

The supported backend setup uses CPython 3.11 or 3.12. The pinned Docker image provides the Linux environment for macOS and Windows contributors. Guide originals are stored in ArtifactStore and read by the configured agent runtime; the backend does not run a separate guide extractor.

Docker Workflow (Recommended)

Prerequisites are Git, Docker Engine, and Docker Compose v2. From the repository root, create the ignored checkout-local configuration, give it a unique COMPOSE_PROJECT_NAME, replace every change-me value and select unused host ports. The local pilot runbook documents secret generation, identities, grants, isolation and teardown.

cp .env.example .env
chmod 600 .env

The chmod command applies to Linux, macOS and Git Bash. PowerShell users must restrict the copied file to their Windows user with an equivalent private NTFS ACL before adding secrets.

Then build the native-architecture Linux images and start the API, prefork Celery process, scheduler, PostgreSQL, Redis and MinIO:

docker compose --profile backend up --build --wait

Then verify the API with the command for your shell:

# macOS, Linux, or Git Bash
curl --fail http://127.0.0.1:<WORKSTREAM_API_HOST_PORT>/api/v1/health

# PowerShell
Invoke-RestMethod http://127.0.0.1:<WORKSTREAM_API_HOST_PORT>/api/v1/health

Replace the placeholder with the port selected in root .env. The expected response is {"status":"ok"}. The backend applies Alembic migrations before serving and all published services bind only to host loopback. API, Celery process and beat use the same S3-compatible MinIO and local Flow-HMAC settings. Startup creates and verifies the checkout-local bucket; authority still comes only from the existing trust-root and grant operations.

The pinned image supports Linux x86_64 and aarch64. On Docker Desktop, it runs inside the Docker VM.

Run focused checks in the same containerized environment:

docker compose run --rm --no-deps backend python -m pytest -q tests/test_app.py tests/test_guide_formats.py tests/test_guide_runtime_workspace.py
docker compose run --rm --no-deps backend ruff check app tests scripts

Dependency changes require a rebuild:

docker compose build backend

Native Linux Workflow

Use this path only with CPython 3.11 or 3.12 on Linux glibc 2.27 or newer and an x86_64 or aarch64 machine. Docker is still used for backing services. Confirm that python3 --version reports Python 3.11 or 3.12 before creating the environment. Install uv 0.12.3 and use the committed lockfile; an unconstrained pip install is not a supported setup path. Create and secure the root Compose configuration before its first command, as described in the local pilot runbook. Give it a unique project name, replace every required secret and choose unused backing service host ports. The separate backend/.env configures the native process.

cp .env.example .env
chmod 600 .env
# Edit root .env before continuing.
docker compose up -d --wait postgres redis
cd backend
cp .env.example .env
chmod 600 .env
# Edit backend/.env before continuing.
python3 --version
uv --version
uv sync --locked --extra dev --python python3
.venv/bin/python -m alembic upgrade head
.venv/bin/python -m uvicorn app.main:app --reload

The v0.1 schema starts at the single 0001_uuid7_v01 Alembic revision. Development databases stamped with any earlier revision are intentionally not upgradeable: delete and recreate the local database, then run alembic upgrade head. Workstream never rewrites or compatibility-stamps an old database.

Verify the API from another terminal with:

curl --fail http://127.0.0.1:8000/api/v1/health

Both files are ignored. In backend/.env, set WORKSTREAM_DATABASE_URL to the root file's PostgreSQL password and selected loopback host port, and set WORKSTREAM_CELERY_BROKER_URL to its Redis loopback host port. When native artifact storage is enabled, also select the MinIO profile and copy the root file's bucket and credentials while using the selected MinIO API host port in the loopback endpoint. These native process URLs use localhost; Compose containers continue to use internal service names and ports. The chmod commands are for POSIX shells; PowerShell users need equivalent private NTFS ACLs.

Native Unified Guide Inference

Set WORKSTREAM_PROJECT_AGENT_MODEL=gpt-5.6-terra (or your chosen supported model) and OPENAI_API_KEY in ignored backend/.env. Runtime, provider/API protocol, model and instructions are separate settings in backend/.env.example. Prepare the ignored root .env as described in the Docker workflow and start backing services using its port and credential settings. Put native backend and provider settings in ignored backend/.env, then install the agent runtime and load that file into API and Celery worker:

docker compose up -d --wait postgres redis minio
cd backend
uv sync --locked --extra dev --extra agents
uv run --env-file .env uvicorn app.main:app --reload
# In another terminal, from backend/:
uv run --env-file .env celery -A app.workers.celery_app worker --pool=prefork -Q celery --beat --loglevel=info

The model key must be in the process environment; --env-file supplies it without shell-exporting or printing it. For connected guide testing, start Postgres, Redis and MinIO, create the private bucket as described below, and enable the S3-compatible settings in .env. The disabled-store first-run profile does not support guide artifact ingestion. Committed original-document readiness runs one compilation and stops at findings and draft proposals; manager review/approval remains separate.

Logs, Shutdown, And Reset

The API and prefork Celery process emit privacy-bounded structured logs and can export explicit traces and metrics to an optional OTLP HTTP/protobuf collector. See the observability operations guide for the configuration, safe field contract, failure behavior, outbox trace boundary, and on-demand profiling procedure. Implemented instrumentation does not imply a collector or monitoring service is configured or deployed.

docker compose --profile backend logs -f backend worker beat
docker compose --profile backend down

For the native workflow, stop Uvicorn with Ctrl+C before running docker compose down for the backing services.

Database recreation is destructive and must be scoped to your disposable local environment. First stop its API, Celery workers and scheduler. Confirm the Compose project name, database host/port and attached volume with docker compose ps and docker volume inspect <exact-volume-name>. Do not reset a shared environment or another worktree's services. Remove only the verified disposable PostgreSQL volume after stopping that Compose project's containers; do not use down --volumes, which also removes artifact storage.

The UUIDv7 schema uses the distinct, Compose-project-scoped workstream_postgres_uuid7_data volume. Starting it does not convert or erase the old development volume. Once you have verified that the old volume is disposable and has no remaining consumers, it can be removed separately by its exact name. Compose also uses a fresh workstream_redis_uuid7_data volume so jobs from the discarded database are not reused. For subsequent database resets, reset only that environment's owned queue volume before restarting Celery workers; external Redis configurations require their own verified private queue reset. Use a fresh private artifact bucket/namespace for the new database; do not delete retained/shared S3 or MinIO objects as part of a database reset.

Backing Services And Artifact Storage

Workstream uses Postgres locally and in CI. It uses Celery with Redis for durable local project setup jobs and automatic pre-review checker gates. MinIO provides the S3-compatible artifact protocol in local development and CI. Start the local services with:

docker compose up -d --wait postgres redis minio

MinIO is built from verified, pinned upstream source using the shared development/CI image recipe, rather than an unavailable vendor image. The first build needs network access and compilation resources; later builds reuse Docker's cache. CI builds or restores this image once and shares it across the existing backend jobs. This does not change the hosted AWS S3 provider or delete existing artifact volumes.

Set every published host port in the ignored root .env: API, PostgreSQL, Redis, MinIO API and MinIO console. Native-backend users must put the same selected backing-service ports in backend/.env; containerized services always use the internal DNS names and ports.

MinIO uses checkout-local static credentials and the private bucket selected in root .env. API startup creates and verifies that bucket before migrations; the application and Celery process continue to access objects only through the canonical ArtifactStore. Configure a native runtime with the exact artifact storage settings and the same private bucket. The repository-managed MinIO port is bound to host loopback. A Workstream process running on a separate non-production container network may instead use an operator-controlled private MinIO endpoint; that remains development/test protocol proof and never qualifies as hosted-provider activation evidence. Native AWS S3 accepts workload-identity configuration but remains runtime-ineligible until live deployment proof is approved; startup fails with artifact_provider_live_proof_required before credential probing or provider I/O.

The local development URL uses the password and PostgreSQL host port selected in the ignored environment files:

postgresql+asyncpg://workstream:<password>@localhost:<port>/workstream

Destructive real API drills use the separate local test database:

postgresql+asyncpg://workstream:<password>@localhost:<port>/workstream_test

One project-guide compilation proposes sufficiency findings and separate pre-submission and post-submission policies through the OpenAI Agents SDK adapter. Use the locked installation and environment-loading commands in Native Unified Guide Inference.

The Celery worker captures runtime, model provider, model, API, instructions, timeout, document limits and tool budgets on the attempt before execution. Credentials stay in the Celery worker environment. WORKSTREAM_PROJECT_AGENT_INSTRUCTIONS and WORKSTREAM_PROJECT_AGENT_INSTRUCTION_VERSION configure trusted instructions; omitting the text selects the repository's canonical compilation instructions. The current adapter uses OpenAI Responses with a private Code Interpreter workspace. WORKSTREAM_PROJECT_AGENT_MODEL=gpt-5.6-terra selects the model independently of the runtime and instructions. Changing that setting requires verifying the chosen model supports the configured tools and structured output. WORKSTREAM_PROJECT_AGENT_REQUEST_TIMEOUT_SECONDS defaults to 300 seconds per provider request. WORKSTREAM_PROJECT_AGENT_RUN_TIMEOUT_SECONDS defaults to 1,800 seconds for the whole run, including retry waits. The Agents SDK retries a model request at most twice, with exponential backoff and jitter capped at 30 seconds. Only proven pre-transmission failures, explicit temporary rate limits, or provider-confirmed safe replay are eligible. Billing, authentication, invalid output, denied document access, and unknown dispatched outcomes do not retry. A process-local circuit opens after three exhausted transient model requests, then admits one recovery probe after 60 seconds. Cleanup remains available. The corresponding retry and circuit settings are listed in backend/.env.example. The runtime adapter is selected through the shared typed adapter factory.

Verified guide-source readiness automatically delivers one compilation. A ready result records both policy proposals and stops at a draft; an insufficient guide stops with findings. Automatic compilation ends without approving the proposals. POL-05B exposes exact Project Manager proposal review, pre-submission approval, setup-wide correction and explicit manual dispatch using POL-05A operations and AUTH-12F4 authorization. The setup response supplies finalized_compilation_id for opening the exact complete proposal, plus correction_operation_id and predecessor_compilation_id for recovering a saved correction after manager handoff or a lost creation response. See the manager proposal flow. POL-06B connects deterministic post-submission policy derivation to committed pre-submission approval. The fixed setup service derives from the saved result; project managers discover its post_submit_policy_id through the proposal read, inspect its complete body, and separately approve it or request a unified correction. Both correction origins use the same explicit manual dispatch. Derivation, reads, approval and correction creation do not invoke inference or post-submit evaluators. A periodic scan recovers publication failures from committed approvals; duplicate delivery retains one policy and receipt. Hidden post-submission execution and completion custody are implemented. ARCH-04D2 supplies exact service authority and ARCH-04E1A supplies source-only facts/types without a runtime entry. Automatic routing remains ARCH-04E work. The local Celery command above includes Beat; start it before creating guide sources.

The Beat scheduler must run alongside the Celery execution processes so artifact pending-work, verified guide-continuation and post-policy approval scans can recover publication failures automatically.

The hidden submission-bundle preparation flow reserves an exact pre-submit attempt before invoking checks. Completed retries recover the original evidence without rerunning checks or issuing a new upload capability. An uncertain attempt cannot execute again under the same key. POL-07B connects the internal checker phase service and removes the standalone JSON precheck. Both fresh pre-submit execution and completed replay use that service, with ART retaining canonical evidence ownership. The obsolete checker worker, manual execution and submission-finalize repair routes are removed. evaluate_post_submission now uses hidden durable execution with exact ARCH-04D2 service authority. ARCH-04E1A retains route-neutral source evidence. REV-04C uses its bounded exact-source verifier and hidden FinalAcceptance/TASK/CON participant, while no general routing publication writer/reader or current pointer exists. B7 implements hidden request delivery with invocation fencing. Production registration and completion routing remain ARCH-04E work. Submission and checker history use live exact-project Submitter authority for the original contributor. Separate /projects/{project_id} reads require a covering Project Manager grant and expose fixed management fields. Token roles confer no authority and authentication returns only the verified identity contract. Finance Authority can publicly discover, create, update, publish, read and retire a project's ContributionPolicy under /api/v1/projects/{project_id}/contribution-policies. The current-policy read recovers a draft selector, a published selector, or both for another authorized Finance actor. Each mutation requires one UUID Idempotency-Key. AUTH owns the authorization decision for the authenticated actor; the CON caller transaction atomically commits policy effects, AUTH evidence and immutable replay custody. Both contribution types must explicitly declare compensated or unpaid rules. Unpaid publication needs no compensation binding; compensated rules retain verified binding checks. Project Managers do not acquire Finance powers. Public compensation-binding administration remains pending.

CON provides internal exact selected-policy validation: a new guide binding must match the active policy’s current published version; the revision-adoption purpose validates an explicitly supplied historical version without reselection. Both validate complete rules and current unit/binding eligibility in the caller transaction. CP07 supplies the canonical activation operation: exact separate pre/post approvals, review/revision selections and the published ContributionPolicyVersion become one immutable guide binding. It atomically supersedes the explicitly selected prior guide and activates a draft Project. Replay preserves the original binding after supersession or policy retirement; active-guide reads require that custody. Activation no longer uses the superseded economic readiness guard. AUTH-12H supplies explicit live authority for an active Project Manager scoped to that exact project. Shared prepared authorization locks current identity and grant before product resources, binds the complete activation digest and rechecks live authority on replay. Composition without an authority adapter still denies. AUTH-18 exposes POST /api/v1/projects/{project_id}/guides/{guide_id}/activate. The draft post-policy review package supplies activation_context: exact guide, review/revision, predecessor, separately approved post-policy and published CON selectors. Missing selectors remain explicit; the context does not promise readiness. Managers obtain those selectors without Finance privileges, then submit the exact selection with one UUID Idempotency-Key. Save the body and key for receipt replay; the draft context is not an active-guide replay endpoint. Response validation, authority evidence and activation effects commit together. ARCH-03D connects the hidden intake handoff to the exact activated guide. Public intake and controlled revision integration remain separate.

ARCH-03A completes the existing internal PROJECTS context port. New work selects one active activated guide; existing work resolves its exact frozen guide and policy selectors, including after a successor or contribution-policy retirement. The result includes the saved activation receipt, both checker-policy bodies, artifact/effective policy, review/revision semantics and recorded catalogue identities. It never substitutes current policies or reruns inference. CP08 uses that port in the existing TASK writers: screening stamps the activated contribution policy, claim copies it to the assignment, and hidden Submission creation copies the assignment's exact stamp. PostgreSQL rejects mismatched or replaced stamps. New work requires no superseded economic configuration. ARCH-03B1 removes TaskService's private PROJECTS reads: the existing port now returns detached project descriptions and exact historical guide display facts. Draft task creation requires project existence, not an activated guide. ARCH-03B2 adds hidden, project-scoped ready queue facts with bounded live pagination; it exposes no queue endpoint or authority. ARCH-03B3 adds hidden all-state management queues with planning fields and operational queues with IDs/status/timestamps only. ARCH-03B4 adds hidden contributor and management task detail with fixed fields and project/assignment visibility, now exposed through ARCH-03C5 exact Contributor and Manager authority. ARCH-03B5 replaces the existing contributor/manager work-context responses with distinct fixed task facts and exact historical policy identities, without obsolete payment fields or submission flags. ARCH-03B6 supplies distinct locked-context projections through the same historical resolver: management includes the bounded checker summary; operational and audit reads expose only exact policy references. ARCH-03C6 exposes all three through distinct exact-authorized routes and removes the old task-only management route. ARCH-03B7 supplies immutable contributor and management requirements through one historical translator. Its hidden contributor read reuses exact assignment visibility after locking TASK; the retained requirements route and separate Manager route use ARCH-03C5 live exact authority. ARCH-03B8 supplies bounded task evidence, publicly authorized by ARCH-03C7; ARCH-03B9 supplies hidden exact-assignment invalidation with committed cause verification and a same-transaction delivery fence. ARCH-03C1 supplies real fixed-service authority and exact decision receipts; ARCH-03C2 supplies atomic AUTH event publication and production handler registration. ARCH-03C3 replaces the create/screen/release role-only path with exact Project Manager authority, atomic audit evidence and durable replay. ARCH-03C4 exposes separate contributor-ready, manager-planning and Operator-status queues with current scoped grants and signed pagination. ARCH-03C5 exposes separate Contributor/Manager detail and requirements, removing their old role/creator wrappers. ARCH-03C6 exposes separate manager, system-Operator and Audit Authority locked-context reads with exact current grants. ARCH-03C7 exposes bounded task history only to covered Audit Authority and removes the old payload-bearing task-only audit route. AUTH-18 delivers public manager guide activation; ARCH-03D connects hidden intake through final durable intent to canonical TASK/PROJECTS ports, preserving historical guide selection. Public intake remains deferred. ARCH-04B supplies hidden exact verified Submission input with scoped async file access and cleanup. ARCH-04B2 adds hidden typed checker-output storage, byte-free recovery and flush-only verified binding over the generic ART put/verification path. ARCH-04C supplies hidden durable execution, exact request/execution-lease custody, immutable member results and atomic completion events. The structural catalogue produces no output files, so output write/bind authority remains unavailable. ARCH-04D1 validates retained terminal material against canonical ART lineage. ARCH-04D2 supplies fixed-service input, execute and finalize authority, with PostgreSQL enforcement of exact execution/finalization receipts. ARCH-04E1A adds immutable source storage and detached contracts only. Automatic dispatch, routing and acceptance remain ARCH-04E work. AUTH-19A defines inert exact Review/routing source commitments and registers the router as planned. It does not issue or persist source authorization receipts. ARCH-04E1B-A reserves the TASK routing operation and future source identity under caller-owned transactions, with exact current-completion verification and replay. It publishes no source or outcome. ARCH-04E2-A adds strict hidden request/source/consequence matching and a nominal fixed-router adapter through canonical PREP. Because task.post_submit.route remains planned and unavailable, no executable handle, allow, receipt, source write, publication or effect is reachable. The true branch binds only the future TASK evaluation_pending -> review_pending manifest effect, without creating a REV queue dependency. The false branch binds exact TaskAcceptedEffectsRequest values for the shared FinalAcceptance path, without fabricating a Review. CON-07 now supplies the hidden source-neutral submitter participant and complete frozen award-set staging/replay. REV-04C now composes FinalAcceptance, TASK terminal effects and that CON participant in one hidden caller-owned transaction for either source. B5 supplies bounded evaluation content before durable admission; B6 uses it with real record identities in the atomic Submission/dispatch command. B7 adds hidden request delivery; completion routing comes next; the committed request events are not registered for delivery. The mandatory exact AUTH receipt must become required on the same strict input, with no optional/default path, before production consumption; database FinalAcceptance/TASK/CON closure, TASK-before-CHECKERS race proof, shared audit/outbox, fulfillment-root ordinals and activation remain later gates.

v0.1 Success Standard

Workstream v0.1 succeeds only when the complete lifecycle defined at the top of this README runs as a real internal task cycle with real people. The cycle must prevent invalid work from reaching review, preserve exact evidence and authority, support revision without rewriting history, produce trusted contribution facts, and carry payable contributions through conditional award and fulfillment. Runtime reputation projection is not part of this release bar.

Operating Standard

Workstream is built as durable operational infrastructure. Project rules live in versioned guides and policies rather than chat memory. Each active attempt keeps its locked governing context; needs_revision preparation rebases a complete valid context for the next attempt rather than silently mixing old and new rules.

Lifecycle state is a ledger, not a loose label. Submitted artifacts remain immutable and hash-bound to their checks; findings, responses, resolutions, Reviews, and contribution facts remain attributable and auditable. Lessons become governed guide, policy, template, or checker changes before they affect future work. Project activation, task screening, submission quality, review, contribution recognition, and conditional fulfillment remain distinct gates even though they form one end-to-end v0.1 lifecycle.