Vision gap register¶

Status as of 2026-07-24. This is an assessment and planning document, not binding compiler policy.

Target outcome¶

Conductor is a portable organizational context layer for ephemeral AI agents. It should let a person discuss the novel part of the work while reusing established decisions about process, architecture, tooling, secrets, deployment, evidence, and state management.

For a specific Initiative, Conductor should:

Discover relevant organizational policy, prior work, and unresolved context.
Review an agent-proposed plan or document bundle against that context.
Authorize and compile a compact execution pack for one workstream stage and one role.
Require durable state and evidence updates after execution.
Capture reusable experience without automatically turning every experience into policy.
Surface evidence-backed improvement candidates through governed review.

The initial instance is Hector's organization. The underlying model should separate reusable Conductor structure from organization-specific policy so another organization can be onboarded later without rewriting the compiler.

Current position¶

Capability	Status	Current coverage	Main gap
Initiative and concurrent workstream model	Strong	Notion Initiative, persistent Portfolio workstream, concurrent line workstreams	Physical Notion schema and history contract are not defined
Stage-specific guardrail packs	Strong	One Initiative, workstream, stage, and active role	No explicit compactness or expansion contract
Workflow and inventory modularity	Strong	Stable stages plus selectable inventory options	Many stage contracts and inventories remain incomplete
Governed policy improvement	Partial	Proposal, Hector approval, and PR	No structured experience-to-candidate learning loop
Portable agent access	Partial	Remote MCP and versioned consultation	Organization configuration and context remain Hector/environment-specific
Plan and document review	Partial	Conductor can validate bindings and report gaps	No Initiative-level plan bundle or structured review result
Persistent cross-agent state	Partial	Notion is authoritative and transitions require writeback	No completion record, event schema, or writeback recovery contract
Prior-work and similar-project discovery	Weak	Software estates and linked artifacts exist conceptually	No similarity index, retrieval tool, or precedent explanation
Known-pattern reuse with novel exploration	Weak	Inventories express established options	No explicit `known`, `adapt`, or `novel` mode
Token and context efficiency	Weak	Stage and role scope reduce retrieval	No output budget, delta pack, or progressive disclosure contract
Scheduled improvement review	Missing	Governed proposals exist	No experience source, scheduler, review cadence, or candidate schema
Multi-organization onboarding	Missing	Roles and organization concepts are reusable in principle	No organization profile, tenant boundary, onboarding interview, or export/import contract

Product decisions and remaining conflicts¶

C1. Compiler boundary versus durable lifecycle¶

The compiler should not become a general-purpose project orchestrator. The vision still requires agents to persist results and experiences after work.

Decided boundary:

Conductor reads context, reviews plans, and authorizes execution packs.
Notion remains authoritative for Initiative and workstream state.
Production tools remain authoritative for artifacts.
The executing agent performs state writeback directly in Notion.
Conductor may read Notion and production systems to govern and supervise agents.
Conductor stores structured reusable experiences and improvement candidates, not routine project state.
Conductor detects missing or stale writeback on the next consultation but does not silently repair it.

Routine completion reporting is not a Conductor MCP mutation. The authorized plan must tell the executing agent what state and evidence to update.

C2. Execution authorization versus human authority¶

Conductor is a specialized supervisory AI agent with delegated authority to approve ordinary execution plans. Its authorization is the hard gate for the requesting agent.

Authorization vocabulary:

Status	Meaning
`validated`	Optional deterministic checks pass; this accelerates review but is not required
`authorized`	Conductor approved the exact versioned execution plan
`human-approved`	Hector approved an exception, policy change, override, or declared human judgment gate
`executed`	The authorized action occurred and evidence was recorded

Conductor may produce authorized only after deterministic validation and an exact capability grant compiled from live decided corpus, in addition to supervisory review. Authorization must identify the plan digest, Initiative, workstream, stage, role, corpus and context versions, scope, conditions, and authorization ID. Material changes require a new authorization. authorized must never be represented as human-approved.

C3. Initiative planning versus stage execution¶

A narrow stage pack is token-efficient but cannot by itself check whether the whole plan covers the Initiative outcome or conflicts with concurrent workstreams.

Recommended separation:

Planning review: read-only, Initiative-wide reconciliation of a proposed plan or document bundle.
Execution pack: Conductor-authorized plan for one workstream, one stage, one active role, and only the context needed now.

Planning discussion does not grant execution permission until Conductor issues the current authorized stage pack.

C4. Standardization versus exploration¶

Treating every gap as a stop condition can force novel work into an unsuitable pattern. Treating every gap as freedom causes repeated rediscovery.

Recommended binding:

yaml pattern_mode: known | adapt | novel

known: apply an accepted pattern and report deviations.
adapt: reuse a precedent with explicit differences and validation.
novel: preserve design freedom, record assumptions and evidence, and avoid premature promotion to policy.

Successful repetition may justify a candidate pattern. One successful use does not.

C5. Portable client versus portable organization¶

Remote MCP access solves use from another computer or phone. It does not yet make the organization model portable to another user or employer.

Decided first-release layering:

text Conductor core model + organization profile and policy corpus + environment adapters and credentials + Initiative/workstream state + compiled pack

The first release supports portable clients against Hector's hosted instance and current providers. Core schemas remain adapter-ready and must not encode Hector-specific IDs, domains, estate names, or approval identities as universal concepts.

C6. Organizational memory versus copied artifacts¶

Conductor needs searchable history without becoming a duplicate document store.

Recommended approach: maintain a privacy-safe event and decision index that points to authoritative artifacts. Do not copy repositories, client files, or complete publications into Conductor.

C7. MCP tool families¶

The three families remain:

Preparation: deterministic discovery and optional fast-path validation.
Conversation: plan review, refinement, and execution authorization.
Feedback/proposal: reusable experiences, improvement candidates, and governed policy proposals.

The executing agent updates authoritative state and production evidence directly. It then calls Conductor's completion-verification operation with the external receipt; Conductor verifies and records feedback but does not perform the state write.

Prioritized gaps¶

P0: required before the vision is implementation-ready¶

G1. Context architecture and authority¶

Define the boundary among Conductor core, organization policy, Initiative state, production artifacts, and environment adapters.

M0 status: verified on 2026-07-24 after external review of all 14 acceptance conditions. authority-model.md, organization-profile.md, and system-components.md are locked downstream inputs. Physical schemas and adapters remain M1+.

Acceptance:

Every fact and artifact type has a decision owner, authoritative store, reader, and writer.
Every MCP operation is classified as read, validate, authorize, or propose.
Organization-specific values are distinguishable from core model fields.
The four approval statuses in C2 cannot be conflated.

G2. Plan bundle, review, and authorization contract¶

Define the input an agent submits before execution and the structured findings Conductor returns.

Acceptance:

Bundle identifies Initiative, context version, workstreams, proposed artifacts, assumptions, dependencies, tests, rollout, documentation, and state-update plan as applicable.
Review checks outcome and definition-of-done coverage, known policy, prior relevant work, cross-workstream impact, missing decisions, and unnecessary work.
Findings have severity, evidence, and exact policy citations.
An authorized result binds the exact plan digest, Initiative, workstream, stage, role, corpus version, context version, scope, and conditions.
Material bundle or context changes invalidate prior authorization.

G3. Agent completion record and state writeback¶

Define how an ephemeral agent leaves durable state after completed, interrupted, or failed work.

Acceptance:

The authorized plan names the exact Notion and production-evidence updates required from the executing agent.
The Notion completion record includes Initiative and workstream IDs, agent, authorization ID, pack and context versions, actions, evidence links, decisions, unresolved items, and next action.
Writeback is idempotent.
Success is not reported until Notion state is updated or a partial-failure result is explicit.
A new agent on another device can retrieve enough state to continue.
Conductor may read and verify the record but does not write it.

G4. Compact pack contract¶

Make token efficiency an enforceable product requirement.

Acceptance:

Default pack contains only current outcome/DoD context, stage, role, constraints, material prior decisions, next action, evidence requirements, gaps, and prohibitions.
Supporting units and templates are references that can be expanded on demand.
The protocol defines a configurable token or byte budget.
Unchanged context can be represented by version and delta rather than repeated prose.
Pack generation reports why each included unit is relevant.

G5. Complete stage contracts¶

Finish the contract required by org-map-model.md for every active stage.

Acceptance:

Entry, bindings, permitted roles, artifacts, evidence, exit, next stages, deterministic or judgment status, and rollback behavior are defined.
Incomplete stages emit a gap and cannot claim deterministic validation.
Stage identifiers are consistent across docs, corpus, schemas, examples, and tools.

G6. Align corpus and generated documentation¶

The current generated mirror still expresses superseded orchestration, single-line, and mandatory GitHub Issue policy.

Acceptance:

No active unit requires active_line, attending_lines, or a GitHub issue work contract.
Workstream concurrency and optional GitHub Issues match the canonical model.
Generated documentation is deterministic and returns to the main docs navigation.
A consistency check detects contradictions against designated model invariants.

P1: required for the full single-organization product¶

G7. Prior-work and similar-project discovery¶

Acceptance:

Preparation tools search Initiatives, repositories, decisions, patterns, failures, and estates using privacy-filtered metadata.
Results explain why each precedent is relevant and distinguish accepted policy from descriptive history.
no suitable precedent is a valid result.
The agent must consider surfaced precedents before proposing a novel solution.

G8. Experience and decision history¶

Acceptance:

Immutable events record actor, time, Initiative/workstream, event type, source pack, evidence, provenance, privacy class, and supersession.
History queries support timeline, decisions, prior resolutions, failures, and changes since a context version.
Authoritative artifacts remain links rather than copied content.

G9. Pattern selection and novel-work path¶

Acceptance:

Every material pattern choice is known, adapt, or novel.
Adaptation records differences from precedent.
Novel work records assumptions, risks, experiments, and review points without inheriting unrelated constraints.
Repeated supported outcomes may create a non-binding candidate; failures remain searchable evidence.

G10. Experience-to-improvement loop¶

Acceptance:

Agents can submit structured success, failure, workaround, repeated-question, rework, exception, and pattern-mismatch experiences.
A scheduled process reviews only new experiences from a stable cursor, deduplicates them, and creates evidence-backed candidates.
Background review cannot activate policy or edit governed assets.
Private context is permission-filtered and redacted before analysis.
Candidates still require proposal, Hector approval, and PR.

G11. Bidirectional plan reconciliation¶

Acceptance:

Review performs a top-down pass from outcome, DoD, policy, and downstream constraints.
Review performs a bottom-up pass from proposed tasks and artifacts.
Output identifies uncovered DoD items, unnecessary work, dependency conflicts, likely rework, duplicate estate, and affected workstreams.
Material upstream changes identify which packs require recompilation.

G12. MCP capability completion¶

Acceptance:

Tool manifest groups preparation, conversation, and feedback/proposal operations.
Preparation includes similar-project, estate, prior-decision, and context-freshness queries.
Feedback distinguishes experience reports, candidate improvements, and governed policy proposals; routine completion remains in Notion.
Tools state whether they read, validate, authorize, or propose.

P2: preserve the path to broader adoption¶

G13. Organization onboarding profile¶

Acceptance:

A structured onboarding interview captures organization roles, systems of record, workflows, standards, environments, approval model, and privacy boundaries.
Answers create an organization profile and candidate policy corpus without modifying Conductor core.
Unanswered questions remain explicit gaps.

G14. Environment adapters and export¶

Acceptance:

Notion, GitHub, secrets, and runtime integrations have explicit adapter contracts.
Export/import preserves stable IDs, versions, relationships, authority, and provenance.
Moving to a new computer requires credentials and MCP configuration, not copied project instruction folders.

G15. Multi-organization authorization¶

Acceptance:

Core data includes an organization boundary.
Policy, history, secrets, and search results cannot cross that boundary accidentally.
Delegated approval and role-based visibility can be added without changing Initiative or pack identity.
Initial single-user operation may keep delegation disabled.

Anti-bureaucracy measures¶

Conductor should be evaluated on whether it removes repeated thinking and rework, not on how much policy it contains. Initial measures:

Median conversation turns and elapsed time from request to authorization.
Median execution-pack tokens and percentage of packs requiring expansion.
Percentage of completed work with current Notion state and evidence.
Recurrence of blockers that Conductor has already seen.
Rework caused by missed known constraints or undiscovered prior work.
Percentage of surfaced precedents that materially influenced the plan.
Authorization invalidations caused by material context changes.
Candidate improvements accepted, rejected, or merged as duplicates.

Targets should be set only after the first golden path establishes a baseline. Any required process that does not prevent a known failure, establish authority, preserve evidence, or support a downstream decision is a removal candidate.

Recommended sequence¶

Specify G1 through G4 before expanding implementation.
Align the corpus through G6 so the compiler has one authority model.
Complete one end-to-end golden path, including plan review, authorization, execution evidence, agent-owned Notion writeback, and a fresh-agent resume.
Add precedent discovery and experience capture before scheduled learning.
Introduce background candidate review only after evidence and privacy contracts exist.
Preserve organization boundaries now; defer full multi-user implementation until the single-organization loop is proven.

Open decisions¶

What default pack budget should apply: tokens, bytes, sections, or a combination?
Which metadata dimensions define a similar project: outcome, archetype, line, estate, stack, host, client type, failure pattern, or all with weighted relevance?
Which experiences are eligible for background review, and what review cadence should apply?
Should Prototype, Lab, and Portfolio-org remain Hector's organization policy rather than Conductor core vocabulary?