Status: accepted, 2026-08-17 (owner ruling, ../evidence/20260817-source-docs-skeptical-read.md §B)

Context#

The business note asks for one opinionated workflow per customer and no builder; the owner's draft and later answers describe a composable stage graph and a workflow composer. The owner ruled: "Composability should be supported from the get go, even if not built; but standalone should work too", and gave the shape: different coverage for the same purpose (a module does its own research or relies on a prior extractor step; self-reported confidence or a bolt-on judge).

Decision#

The contract carries the composability hooks now: a machine-readable manifest per module with requires/provides in a shared field registry, capability variants with a standalone default, judges as capabilities, and parent_job_id for chaining (../canon/11, ../canon/14, ../contracts/manifest.md). The composer that lets a customer or an agent draw a graph is not built until a second workflow shape actually needs it. The console ships one opinionated workflow per customer first, on this architecture. Every module runs standalone with the same surface.

Rejected alternatives#

• Build the composer now. Business input the owner reads as "asks for a lot but doesn't end up needing it right away"; front-loads UI and orchestration for a shape no customer has asked to draw.
• Fixed pipeline with no manifest. Cheap now, and the first composition request means reading every module's source; the manifest costs one JSON document per module.

Consequences#

• The field registry is a shared artifact needing an owner and a review path.
• Per-tenant "which stages run" is workflow configuration in the console, not an engineering fork (../v6/README.md).