Workstream

Workstream is Flow's task evaluation and contribution infrastructure.

Workstream manages project guides, task queues, submission packets, automated checks, reviewer routing, evaluation sprints, revision loops, contribution records, payment status, and reputation signals.

Workstream is how Flow measures, certifies, and coordinates useful human-agent work.

It is not a workspace and it is not blockchain-first. Operators can work with any local tools, human-agent workflow, or external execution environment. Workstream owns the project guide, task queue, submission packet, automated checks, human review, revision loop, acceptance state, payment ledger, and reputation record.

Workstream is source-agnostic, but v0.1 is manual-first. External origin onboarding, source adapters, automated routing, owner-agent execution workspaces, and on-chain settlement remain later adapters until the internal evaluation loop is proven.

The first 30 days are focused on building serious internal infrastructure that can run real projects end to end:

Project Guide
-> Task Queue
-> Task Record
-> Submission Packet
-> Platform Checkers
-> Human Review
-> Needs Revision / Accepted / Rejected
-> Contribution Record
-> Payment Record
-> Reputation Update
-> Lessons Learned

Core Thesis

Different projects speak different domain languages, but serious task evaluation and contribution systems share the same lifecycle:

• every project has a guide
• every task belongs to a project
• every project has a base amount or payment policy
• every task has acceptance criteria
• every submission has evidence
• every submission passes automated checks before human review
• every review creates a decision
• every revision must close prior feedback
• every accepted task updates payment and reputation

Workstream turns that operating knowledge into reusable infrastructure.

Planning Package

• 30-Day Master Plan
• Roadmap Status
• Week 1 Backend Plan
• Week 2 Checker Framework Specification
• Chunk 6 Checker Contract And Records
• Chunk 7 Checker Runner And Registry
• Day-by-Day Execution Plan
• Implementation Backlog
• Product Principles
• Product Brief
• First User Flows
• Architecture Brief PDF
• 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
• Roles And Permissions
• Payment And Reputation
• Risk Register
• Process Pattern Baseline
• Architecture Lockdown
• Glossary

Review Passes

• 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
• Checker Policy Template
• Task Template
• Preflight 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

Local Backend Database

Workstream uses Postgres locally and in CI. Start the local database with:

docker compose up -d postgres

The default local test URL is:

postgresql+asyncpg://workstream:workstream@localhost:5433/workstream

Week 1 API Demo UI

The Week 1 API demo UI lives in demos/week1_api_demo_ui/. It is a temporary walkthrough client for the Week 1 backend APIs, not the canonical Workstream frontend implementation. It calls the real backend over HTTP through the Vite proxy and uses local Flow-style bearer tokens against the backend flow verifier.

Start the backend for the demo:

cd backend
WORKSTREAM_DATABASE_URL=postgresql+asyncpg://workstream:workstream@localhost:5433/workstream \
WORKSTREAM_AUTH_PROVIDER=flow \
WORKSTREAM_ENVIRONMENT=local \
WORKSTREAM_FLOW_AUTH_ISSUER=https://auth.flow.local/demo \
WORKSTREAM_FLOW_AUTH_AUDIENCE=workstream-demo \
WORKSTREAM_FLOW_AUTH_LOCAL_HMAC_SECRET=workstream-demo-local-secret \
WORKSTREAM_ENABLE_DEMO_ROUTES=true \
.venv/bin/alembic upgrade head

WORKSTREAM_DATABASE_URL=postgresql+asyncpg://workstream:workstream@localhost:5433/workstream \
WORKSTREAM_AUTH_PROVIDER=flow \
WORKSTREAM_ENVIRONMENT=local \
WORKSTREAM_FLOW_AUTH_ISSUER=https://auth.flow.local/demo \
WORKSTREAM_FLOW_AUTH_AUDIENCE=workstream-demo \
WORKSTREAM_FLOW_AUTH_LOCAL_HMAC_SECRET=workstream-demo-local-secret \
WORKSTREAM_ENABLE_DEMO_ROUTES=true \
.venv/bin/python -m uvicorn app.main:create_app --factory --host 127.0.0.1 --port 8000

Start the demo UI:

cd demos/week1_api_demo_ui
npm install
npm run dev -- --port 5173

Open:

http://127.0.0.1:5173/

The demo runs the Week 1 path from project guide to locked submission using real API calls. The local demo worker-profile route is guarded by WORKSTREAM_ENABLE_DEMO_ROUTES=true and local/test environments only.

Day-30 Success Standard

By day 30, Workstream runs a real internal task cycle with real people:

Create project guide
Create task
Assign task
Submit packet
Run checks
Review packet
Record review decision: accept, needs_revision, or reject
Create contribution record for accepted work
Record payment status separately for accepted work
Update reputation from review outcome
Review lessons learned

The system is successful only if it prevents weak work from reaching review, preserves evidence, and gives operators a clear path from task intake to accepted paid output.

Operating Standard

Workstream is built as durable operational infrastructure:

• project rules live in guides and policies, not chat memory
• status is a ledger, not a loose label
• reviews cite evidence and required changes
• revisions replay prior findings one by one
• payments are recorded separately from task acceptance
• every checker result is stored and auditable
• lessons learned become guide updates or new checkers
• submitted artifacts are immutable and hash-bound to checker runs
• accepted work cites evidence before payment exposure is created
• guide and policy versions are locked per task so rules do not drift silently
• accepted work creates an evidence-backed contribution record before payment or reputation updates
• quality gates remain separate: project activation, task screening, and submission quality