Roadmap¶
This is the milestone tracker for moving Conductor from vision to a usable single-organization system. Detailed gaps and acceptance criteria live in the vision gap register; this roadmap links to them rather than duplicating them.
Implementation work should receive GitHub issues and PRs when a milestone begins. Link those issues here so this remains a concise portfolio view, not a second execution tracker.
Status vocabulary¶
| Status | Meaning |
|---|---|
definition |
Decisions or contracts are being written; implementation must not start |
review requested |
Remediation complete; waiting for external verification of acceptance conditions |
ready |
Scope and acceptance are sufficient to open implementation issues |
active |
Implementation is in progress |
blocked |
A named decision or dependency prevents progress |
verified |
Exit criteria pass with evidence |
Ready-to-use definition¶
Conductor is usable for the first single-organization workflow when a remote requesting agent can:
- Load current Initiative, workstream, estate, and relevant policy context without relying on local files.
- Discover materially similar existing Assets and prior decisions.
- Submit a proposed plan and resolve only genuinely open questions.
- Receive a compact, version-bound execution authorization.
- Execute with the authorized role and tools.
- Update Notion and production evidence directly.
- Allow a fresh agent on another device to resume from persistent state.
- Submit reusable learning without changing binding policy automatically.
Component readiness¶
| Component | Readiness | Main blocker |
|---|---|---|
| Organization and workstream model | Verified | M2 independently verified all 40 stage contracts |
| MCP preparation layer | Partial | Estate, precedent, freshness, and source queries are unspecified |
| MCP conversation layer | Partial | Plan bundle and authorization envelope remain M3 |
| MCP feedback/proposal layer | Partial | Experience and candidate contracts are unspecified |
| Corpus | Verified for single-organization authority | M2 typed 73 units and enforced dependencies, layers, patterns, and generated consistency |
| Compiler and selector | Partial | Compact-pack budget, relevance explanation, and delta behavior are unspecified |
| Notion state layer | Nine-database schema live; candidate import complete | state-model.md; Gate D evidence and reviewed pilot recorded under docs/estate/ |
| GitHub read layer | Gate C discovery complete via approved gh operator path |
read-access-contract.md; unattended service authentication is an M3 decision |
| Asset registry and estate index | asset-registry.v2 Gate B approved |
asset-registry.md; typed EstateComparison boundary independently reviewed; golden-path candidate follows Gate C discovery |
| Conductor supervisory agent | Boundary defined | Authorization envelope and MCP schemas remain M3 |
| Experience and scheduled learning | Missing | Eligible evidence, storage, privacy, cadence, and candidate rules are undecided |
| Runtime controls | Boundary defined | Credential contracts and degraded mode remain M1/M3 |
| Evaluation | Missing | Real-estate golden-path fixture and baseline measures do not exist |
| Organization portability | Boundary defined | Full onboarding remains M6 |
Milestones¶
| Milestone | Status | Gap references | Primary output | Exit evidence | Issues/PRs |
|---|---|---|---|---|---|
| M0. Vision and component boundary | verified |
G1 | System components, authority model, and organization profile | External review passed all 14 M0 acceptance conditions | — |
| M1. State foundation and estate baseline | verified — independent verification reproduced authority, privacy, unavailable-source, and live gh-operator evidence |
G3, G7, G8, G14 | State model, Asset registry, Read-access, Source Inventory | 48 focused / 86 total tests; 103-repository operator enumeration; decisive caller-forgery chain rejected | #3, #14 |
| M2. Corpus authority alignment | verified — independently verified and merged into the milestone stack |
G5, G6, G9 | Aligned workflows, inventories, patterns, schemas, and generated docs | 73 typed units, 40 complete stages, authority and negative fixtures independently reproduced | #13 |
| M3. Authorization vertical slice | verified — independently reproduced public lifecycle and adversarial controls |
G2, G4, G11, G12 | Preparation, conversation, authorization, and feedback MCP contracts | 28 independently focused / 114 total tests; strict docs and diff checks pass | #15, #21, verification |
| M4. Real-estate golden path | verified — decisive extend, authorized execution, exact writeback, and fresh resume independently reproduced |
G2-G4, G7, G11 | First complete reuse/extend/new decision and authorized execution | Target PR merged; exact Notion completion is idempotent; fresh agent resumed with next action | #22–#27, verification |
| M5. Learning loop | verified — privacy, cursor, deduplication, retention, and governance controls independently reproduced |
G8-G10, G12 | Structured experience feedback and scheduled candidate review | Repeated evidence creates a deduplicated non-binding candidate; no policy changes without governance | #28–#32, verification |
| M6. Portable organization onboarding | verified — second-organization preparation, tenant isolation, authenticated portability, and candidate-only onboarding independently reproduced |
G13-G15 | Organization profile, onboarding interview, adapter/export contracts | A second organization can be represented without an organization-specific core fork | #34–#38, verification |
Verified M0 artifacts¶
External review passed all M0 acceptance conditions on 2026-07-24. Downstream milestones may rely on these boundaries without reopening them:
- system-components.md — component boundaries including identity allocator and split runtime responsibilities
- authority-model.md — one-owner matrix; proposed plan ≠ Conductor review artifacts ≠ authorization; ID mint/persist
- organization-profile.md — core vs organization profile vs adapters vs secret values vs state vs derived index
- connect.md — provider-only secret values (no host
.envfallback) - software-decisions.md — Secrets inventory provider-only Bitwarden
- Line stage IDs aligned to org-map-model.md
- Brief: roadmap/M0-vision-component-boundary/brief.md
Locked downstream inputs:
| Milestone | Locked by M0 (do not reopen) |
|---|---|
| M1 | Conductor is read-only on routine state; executing agents own Notion writeback; Assets ≠ Initiatives; identity allocator mints IDs; Decision/Event ownership; estate index is derived |
| M2 | Core vs organization-profile classification (incl. Prototype/Lab/Portfolio-org as org vocabulary); exact handwritten stage IDs; provider-only secret values; generated mirror is not design authority |
| M3 | Four MCP operations (authorize = plan only); four approval statuses; proposed plan ≠ review artifacts ≠ authorization record; client access uses authenticate / enforce access |
Known out-of-scope drift (not an M0 doc contradiction): service/conductor/integrations/ still contains a write-path orchestrator. Align that implementation with this boundary in a later milestone; do not treat the code as authority.
M1 review artifacts¶
External review: roadmap/M1-state-estate-baseline/review.md. Gate status: gate-status.md. Import plan draft: gate-d-import-plan.md. Candidate stub: estate/candidates.yml.
| Artifact | Status |
|---|---|
| state-model.md | state-model.v2 live; nine databases created and validated |
| asset-registry.md | asset-registry.v2 Gate B approved after final independent EstateComparison review |
| read-access-contract.md | read-access.v1 — Gate C approved; gh operator discovery complete; unattended runtime mode deferred to M3 |
| source-inventory.md | source-inventory.v1 — source-defined discovery scope; golden-path selection follows enumeration |
| Read adapters + retrieval tests | 58 service tests / 42 read-adapter tests; live foundation retrieval passed |
| Reviewed Notion baseline | Six-Asset real-estate pilot complete; 125 Assets remain candidates |
Immediate definition queue¶
These documents and decisions are needed before M1 or M2 can become ready.
| ID | Work item | Status | Result |
|---|---|---|---|
D-01 |
Decide the physical Notion model for Initiatives, Workstreams, Products, Assets, and Decisions/Events | implemented (state-model.v2; Gates A/D) |
state-model.md |
D-02 |
Define Asset identity, capability vocabulary, relationships, freshness, and reuse outcomes | approved (asset-registry.v2, Gate B) |
asset-registry.md |
D-03 |
Inventory authoritative sources: Notion workspaces, GitHub users/orgs, local-only prototypes, and deployed services | approved (Gate C; application boundary discovery complete) |
source-inventory.md |
D-04 |
Define Conductor read authentication, permission filtering, and unavailable/stale-source behavior | approved (Gate C; gh operator mode current, unattended mode deferred to M3) |
read-access-contract.md |
D-05 |
Define plan bundle, authorization envelope, invalidation, and escalation | verified (M3) |
M3 verification |
D-06 |
Choose compact-pack budget and expansion behavior | verified (M3) |
M3 verification |
D-07 |
Define similarity dimensions and evidence required for reuse, extend, new, or insufficient-context |
approved (asset-registry.v2, Gate B); real decisive execution belongs to M4 |
G7 decision contract |
D-08 |
Decide experience eligibility, candidate review cadence, and retention/privacy | verified (M5) |
M5 verification |
D-09 |
Classify organization-specific vocabulary, including Prototype/Lab/Portfolio-org | boundary done (M0) |
Organization profile; full profile schema remains later |
D-10 |
Define corpus packaging, status, dependency, versioning, and organization-overlay rules | verified (M2) |
M2 decision package |
D-11 |
Produce the governed corpus migration plan from the current generated model | verified for M2; M3 feedback boundary prepared |
M2 proposal register |
Estate bootstrap tracker¶
The initial inventory is part of M1. It is not complete when repositories are merely listed.
| Scope | Status | Required evidence |
|---|---|---|
| GitHub repositories | complete for M1 boundary |
103 repositories enumerated through approved gh operator scope |
| Workspace and local-only prototypes | complete for M1 boundary |
29 projects published in the private incubator with original paths preserved |
| Deployed applications and services | explicitly enrichment-only |
No deployment facts fabricated; verified URLs may be added later |
| Real-estate applications | representative pilot complete |
Six reviewed Asset records with comparable capabilities and relationships |
| Historical Initiatives and decisions | explicitly partial |
New Initiatives retrieve correctly; historical backfill is not an M1 prerequisite |
| Duplicate and superseded systems | representative pilot complete |
Human-reviewed real-estate and Fiser dispositions recorded |
Milestone rules¶
- Do not start implementation while the milestone is
definition. - Do not mark a milestone
readywithout its linked gap contracts. - Do not mark a milestone
verifiedwithout evidence from its exit criteria. - Do not broaden to another line or organization to avoid completing the golden path.
- Do not prepopulate unreviewed AI extraction as authoritative state.
- Update this roadmap only at milestone or dependency level; execution progress belongs in linked GitHub issues and PRs.
Next decision¶
M0-M6 are verified. Reconcile the completed roadmap into a release/operations decision: choose the first sustained Conductor usage period, collect the already-defined anti-bureaucracy measures, and create a new milestone only from observed product evidence rather than extending the roadmap by default.