Initiative workflow¶
How work flows from spark to completion across Conductor's six business lines. Every Initiative follows a path through Portfolio governance, with one or more delivery-line workstreams contributing concurrently.
What an Initiative is¶
An Initiative is the canonical organizational work contract. It records:
- Why the work exists (outcome)
- What completion looks like (definition of done)
- How it's governed (Portfolio priority, review, disposition)
- Who contributes (workstreams across lines)
The Initiative is the spine. Workstreams are the limbs. Adding a workstream never transfers ownership of the Initiative — Portfolio remains accountable from spark to completion.
The four paths¶
Every spark enters through Portfolio Intake. Portfolio Classify routes it to one of four paths depending on what kind of work it is:
Path A — Commercial product¶
text
Portfolio → Product → Software → Operate + Editorial
For revenue-generating products. Product evaluates market viability, scores the opportunity, and gates the build decision. The estate is Portfolio-org (Konstant-Ventures, own website). Software builds, Operate runs it, Editorial publishes the release.
Path B — Lab or tool¶
text
Portfolio → Product → Software → Operate + Editorial
For non-commercial tools, experiments, MCP servers, showcases. Same flow as Path A, but Product decides the estate is Lab (hector-sanchez-eu, catalog entry) or Prototype (local only, no deploy). Same Software → Operate → Editorial tail.
Path C — Content¶
text
Portfolio → Editorial
For writing, research, publications. Portfolio routes directly to Editorial. No Software workstream unless tooling is needed (which loops back through Portfolio → Product → Software).
Path D — Engagement¶
text
Portfolio → Services
For client work, consulting, freelance engagements. Portfolio routes to Services. If the engagement needs billable software, it loops back through Portfolio → Product → Software.
Cross-line loops¶
Work on one line can reveal the need for another. These loops always go back through Portfolio — they never bypass governance:
| Trigger | Loop |
|---|---|
| Services engagement needs billable software | Services → Portfolio → Product → Software |
| Editorial research needs analysis tooling | Editorial → Portfolio → Product → Software |
| Client work reveals a product opportunity | Services → Portfolio → Product (new Initiative) |
| Content implies a market opportunity | Editorial → Portfolio → Product (new Initiative) |
A new market opportunity creates a separate Product Initiative linked with derived_from. It does not repurpose the existing workstream.
The role of each line¶
Portfolio¶
Governance spine. Owns the Initiative from spark to completion. Stages: Intake → Classify → Prioritize → Capacity → Review. Portfolio does not do the work — it governs it.
- Classify decides which path (A, B, C, D) the Initiative takes
- Capacity enforces WIP limits (max 2 active commercial builds)
- Review periodically checks: continue, park, kill, or complete?
Product¶
Evaluation gate for all Software work. Every Software workstream goes through Product — no exceptions. Stages: Discover → Explore → Score → Build-gate → Ship-signal → Archive.
Product decides the estate. During Build-gate, Product determines where the software will live:
| Estate | Decision | Implications |
|---|---|---|
| Portfolio-org | Revenue product | GitHub under Konstant-Ventures, own website, commercial |
| Lab | Tool, showcase, experiment | GitHub under hector-sanchez-eu, catalog entry on /lab, deployed to konstant |
| Prototype | Local exploration | Local git only, no GitHub remote, no deploy, no CI/CD |
The estate decision is a Product responsibility because "should we build?" depends on "where will it live?" A Portfolio-org product needs different infrastructure than a Lab experiment.
Software¶
Builds what Product authorizes. Stages: Frame → Design → Implement → Verify → Promote → Deploy → Document. The estate (chosen by Product) constrains every stage — a Prototype never reaches Deploy, a Portfolio-org product gets an independent website.
Operate¶
Runs what Software deploys. Stages: Run → Observe, branch Change/Incident or Retire. Operate is activated when Software Deploy completes on a shared host. Operate owns shared host health, security, and incident response.
Editorial¶
Publishes the narrative. Stages: Assign → Report → Draft → Edit → Fact-check → Localize → Stage → Publish → Update. Editorial is activated: - For content Initiatives (Path C) — directly from Portfolio - For Software releases — when a Lab or Portfolio-org app deploys, a release piece is required - For research that supports other lines
Services¶
Delivers client engagements. Stages: Offer → Lead → Propose → Contract → Deliver → Invoice → Complete → Archive. Services operates under strict client privacy boundaries.
How to read the registry¶
The project registry (docs/registry/) tracks every active Initiative and its workstreams. Two views:
- Initiatives — the spine. One row per Initiative with outcome, DoD, active workstreams, status.
- Workstreams — the detail. One row per line contribution with stage, estate, evidence, next action.
An Initiative with both Software (Deploy) and Operate (Run) active means the app is deployed and running. An Initiative with only Product (Explore) means evaluation is in progress — no build decision yet.
Tooling note¶
This workflow is agnostic to the tools used to track it. The registry is markdown in the repository. You may also track Initiatives in Notion, Linear, Jira, or any other project management tool. The workflow defines what happens; the tooling defines how it's recorded. Conductor's registry is the canonical reference for what's active and where it stands.