Contract Layer

The contract layer defines what each specialist is expected to produce and consume at every lifecycle stage. It is the public bridge between Adros and whatever is driving the workflow - the native dashboard, Adros CEO, or an external conductor.

How it works

Contracts are keyed by (stage, task_type). Each contract specifies:

Field	Purpose
`produce`	Artifacts the specialist must deliver
`accept`	What the specialist consumes
`recommended_specialist`	Runtime actor ID: `adros_ceo` / `adros_research` / `adros_cmo` / `adros_cd` / `adros_deployer`
`review_gates`	Human checkpoints
`next_stage`	Where the workflow goes after this task completes

Example

("creative", "generate_creatives"): {
    "produce": ["creatives_package", "copy_variants"],
    "accept": ["structure_xlsx", "brand_profile", "business_context"],
    "recommended_specialist": "adros_cd",
    "next_stage": "approved",
    "review_gates": ["Creative review", "Operator approval"],
}

What happens:

Workflow engine queries GET /contract/spec?stage=creative&task_type=generate_creatives
Adros returns the spec
The task is created with the recommended_specialist
When complete, the specialist calls POST /contract/writeback with the produced artifacts
The lifecycle advances to next_stage

REST vs MCP

REST is for your automation and backend workers. MCP is for LLM clients calling Adros via natural language. Both use the same contract definitions.

Task inbox, event timelines, approvals, Strategy Workspace, Files, and deploy handoff use additional routes on the same /api/v1 base - see REST - Dashboard & Orchestration.

Auth

Authorization: Bearer lyr_YOUR_TOKEN

Available specs (package-level view)

Stage	Task type	Owner (`recommended_specialist`)	Approval?
`intake`	`gather_business_context`	`adros_ceo`	No
`intake`	`build_brand_profile`	`adros_ceo`	No
`research`	`keyword_research`	`adros_research`	No
`research`	`market_research`	`adros_research`	Yes
`creative`	`generate_creatives`	`adros_cd`	Yes
`approved`	`launch_campaigns`	`adros_deployer`	No
`live`	`first_week_check`	`adros_cmo`	No
`optimizing`	`weekly_review`	`adros_cmo`	Yes
`optimizing`	`creative_refresh`	`adros_cd`	Yes
`optimizing`	`search_term_audit`	`adros_cmo`	Yes
`optimizing`	`budget_reallocation`	`adros_cmo`	Yes

Package note: Public docs describe research at the package/workflow level. Some research engagements may be delivered in stages, so rely on task status, event timeline, and operator review state rather than assuming the first uploaded file means the whole package is complete.

Endpoints

List specs

GET /contract/specs

Returns all available (stage, task_type) specs with their produce/accept/specialist/next_stage/review_gates.

Get single spec

GET /contract/spec?stage=creative&task_type=generate_creatives

Returns one spec. Useful when your workflow engine needs to know what comes next.

Writeback

POST /contract/writeback
Body: { stage, task_type, client_id, artifacts: {...}, notes: "..." }

The specialist posts produced artifacts. Adros validates required artifacts, stores them, updates lifecycle state, and logs the writeback as a task event.

Design rationale

Why contracts? Without them, each specialist has to know the state machine implicitly - and they get it wrong. Contracts make the workflow deterministic: given the same (stage, task_type), everyone produces and consumes the same things.

Why runtime actor IDs? Display names drift. Actor IDs (adros_ceo, adros_research, adros_cmo, etc.) are stable, machine-readable, and match the assignment fields in the orchestrator.

Related docs

REST - Dashboard & Orchestration - full route map
Onboarding Flows - end-to-end flows using these contracts
Technical Overview - stack and data model

Integration Notes FAQ & Troubleshooting