Organization model¶
How Conductor's organization is structured: the hierarchy, the Initiative contract, the Workstream model, and cross-line coordination rules.
Part of the canonical org model. See Product for what Conductor does.
Organization¶
text
President (Hector)
└── Portfolio Office # Initiative spine and cross-line attention
├── Product Evaluation # venture + bootstrap
├── Software # build / promote / deploy
├── Editorial # newsroom / writing
├── Services # consulting / freelance
└── Operate # shared runtime / platform
Career and job-search work is out of scope until explicitly promoted.
Initiative¶
An Initiative is the canonical organizational work contract. It records why work exists, what completion means, and how Portfolio governs it. The authoritative record is the Notion Initiative.
| Field | Requirement | Meaning |
|---|---|---|
initiative_id |
Always | Stable identifier minted by Conductor |
title |
Always | Human-readable name |
outcome |
Always | Result the Initiative is intended to produce |
definition_of_done |
Always | Observable completion criteria |
owner |
Always | Accountable role |
priority |
Always | Portfolio priority |
portfolio_status |
Always | intake \| active \| parked \| done \| killed |
review_date |
Active or parked | Next Portfolio review |
archetype |
After classify | software-product \| content-product \| services-product |
relationships |
When applicable | Parent, child, enabling, or derived Initiative links |
workstreams |
Always | Persistent Portfolio workstream plus zero or more delivery-line workstreams |
Every spark creates an Initiative with a Portfolio workstream at Intake. Product Discover is the Product workstream entry stage after Portfolio classifies a product bet, not a second organization-wide inbox.
Workstream¶
A workstream is one line's contribution to an Initiative. Multiple workstreams may execute concurrently against the same Initiative.
| Field | Requirement | Meaning |
|---|---|---|
workstream_id |
Always | Stable identifier within the Initiative |
line |
Always | portfolio \| product \| software \| editorial \| services \| operate |
stage |
Always | Current stage ID from the line workflow |
active_role |
While active | One role responsible for the current stage pack |
status |
Always | planned \| active \| blocked \| waiting \| done \| cancelled |
next_action |
While active or blocked | Concrete next action |
bindings |
Stage-dependent | Selected inventory options and inherited context |
evidence |
Stage-dependent | Artifacts proving transition conditions |
Portfolio is a persistent governance workstream, not an attending-line flag. It remains responsible for the Initiative through portfolio_status, priority, capacity, and review. Participation is represented by workstreams, not by active_line or attending_lines fields.
Workstream or child Initiative¶
Add a workstream when another line contributes to the same outcome. Examples include Editorial needing an analysis app, Services needing billable software, or Software needing Operate support for first deployment.
Create a related child Initiative only when the new work has an independently governable outcome or lifecycle. If client or editorial work reveals a market opportunity, create a separate Product Initiative linked with derived_from.
Cross-line coordination¶
Cross-line coordination changes workstream state or adds a workstream to the same Initiative. It does not transfer exclusive ownership of the Initiative.
| Need | Result |
|---|---|
| Product passes build gate | Add or activate a Software workstream |
| Editorial needs analysis tooling | Add a Software workstream with Editorial bindings |
| Services needs billable software | Add a Software workstream with engagement and privacy bindings |
| Software reaches first deployment | Add or activate an Operate workstream |
| Lab URL is verified | Add or activate an Editorial release workstream |
| Work reveals a separate market opportunity | Create a related Product Initiative |
Each workstream records its own stage, role, status, next action, bindings, and evidence. Outcomes relevant to another workstream are recorded as dated events or evidence on the Initiative.
Authority¶
Full ownership, operations, and documentation precedence: authority model. Core versus organization bindings: organization profile.
- Notion Initiative: authoritative organizational work contract and workstream state.
- Product record: authoritative Product evaluation details linked to an Initiative.
- Asset registry: authoritative descriptions of enduring systems (distinct from Initiatives).
- GitHub repository: authoritative software source, branches, commits, PRs, checks, releases, and deployments.
- Editorial tools: authoritative publication artifacts.
- Services client folders: authoritative private engagement artifacts.
- Operate runbooks and runtime tools: authoritative operational artifacts.
- Conductor docs and governed assets: authoritative organizational guidance.
GitHub Issues are optional repository-local artifacts. They are never the Initiative contract and are not required for a Software workstream. GitHub Projects must not become the Portfolio spine.
Authorization statuses validated, authorized, human-approved, and executed are distinct. Conductor may authorize ordinary plans; Hector alone issues human-approved for exceptions and policy.