M0 implementation brief: Vision and component boundary¶

Work contract¶

Field	Value
Milestone	`M0`
Status at handoff	`completed` — externally verified on 2026-07-24
Work type	Documentation and architecture decisions only
Primary gap	`G1` — Context architecture and authority
Repository	`hector-sanchez-eu/conductor`
Allowed scope	`docs/` only
Prohibited scope	Application code, runtime configuration, schemas, corpus sources, generated corpus pages, integrations, deployments

Objective¶

Lock the boundaries among the Conductor supervisory agent, compiler, MCP layer, corpus, organization profile, state systems, estate index, requesting agents, learning system, governance, and runtime controls.

The result must give later agents enough authority and ownership information to design M1 state access, M2 corpus migration, and M3 authorization tools without reopening the same architectural questions.

Final acceptance matrix¶

Externally verified on 2026-07-24. Generated corpus drift remains expected M2 work and was not treated as M0 authority.

Condition	Result	Citation
1. Clear component responsibilities	Pass	system-components.md — identity allocator and six runtime components
2. Complete ownership matrix	Pass	authority-model.md — proposed plan, Conductor review artifacts, and authorization records as separate rows
3. Non-overlapping operations	Pass	authority-model.md — `authorize` reserved for plans; runtime uses `authenticate` / `enforce access`
4. Non-conflated statuses	Pass	authority-model.md — `validated` / `authorized` / `human-approved` / `executed`
5. Hard gate without Conductor state writes	Pass	authority-model.md, integration-contract.md, system-components.md
6. Core/profile/adapter/state/index separation	Pass	organization-profile.md; connect.md — provider-only secret values
7. Documentation precedence	Pass	authority-model.md — hierarchy and conflict handling
8. M1 authority settled	Pass	authority-model.md — ID mint/persist table; Decision/Event ownership split
9. M2 boundary settled	Pass	org-map-model.md stage IDs; software-decisions.md Secrets inventory is provider-only Bitwarden
10. M3 authority settled	Pass	Proposed plan ≠ review artifacts ≠ authorization; `authorize` ≠ client access
11. No handwritten contradiction	Pass	Review-artifact ownership and Software secret policy aligned
12. Generated drift identified	Pass	Generated mirror is not design authority; M2 migration
13. Strict docs build	Pass	External review: `python -m mkdocs build --strict`
14. Diff check	Pass	External review: `git diff --check -- docs`; line-ending warnings only

Historical remediation (do not treat as current status)¶

Third review (incomplete before FR1–FR3)¶

RR1-RR4 resolved the prior ownership, identifier, runtime-access, stage, and host-secret defects. External validation also passed. Two normative corrections remained until FR1–FR3.

Third-review acceptance result (historical):

Condition	Result	Remaining issue
1. Clear component responsibilities	Pass	—
2. Complete ownership matrix	Fail	Conductor-authored review questions, findings, and refusals lack their own authority row
3. Non-overlapping operations	Pass	—
4. Non-conflated statuses	Pass	—
5. Hard gate without Conductor state writes	Pass	—
6. Core/profile/adapter/state/index separation	Pass	—
7. Documentation precedence	Pass	—
8. M1 authority settled	Pass	—
9. M2 boundary settled	Fail	Software decisions still present GitHub/Vercel environment storage as an unresolved alternative to provider-only secrets
10. M3 authority settled	Pass	—
11. No handwritten contradiction	Fail	Review-artifact ownership and Software secret policy conflict remain
12. Generated drift identified	Pass	—
13. Strict docs build	Pass	External review ran `python -m mkdocs build --strict` successfully on 2026-07-24
14. Diff check	Pass	External review ran `git diff --check -- docs`; line-ending warnings only

Final residual remediation (FR1–FR3) — applied¶

FR1. Define Conductor review-artifact authority¶

Separate requesting-agent input from Conductor-authored review output:

Rename the proposed-plan store so it does not imply that the requesting agent owns all conversation artifacts.
Add an authority row for Conductor review artifacts: questions, findings, refusals, revision requests, and escalations produced before authorization.
Name exactly one decision owner, authoritative store, permitted readers, permitted writer, and conflict rule.
Align docs/system-components.md and docs/integration-contract.md with the new row.
Keep authorization records separate and immutable as already defined.

Recommended boundary:

Proposed plan or document bundle: owner/writer Requesting agent; store Versioned proposed-plan store.
Conductor review artifact: owner/writer Conductor supervisory agent; store Conductor review/conversation store.
Authorization record: owner/writer Conductor supervisory agent; store Authorization record/pack store.

FR2. Align Software secret inventory with provider-only authority¶

Update docs/software-decisions.md so the implied Secrets inventory does not present GitHub or Vercel environment stores as alternate authoritative secret-value locations.

The row should express:

Bitwarden is the authoritative value provider.
Host adapters may define provider-resolved runtime injection.
A missing injection mechanism is a later inventory gap, not permission to create a second durable source of truth.

Review the remainder of handwritten Software docs for similar alternate-store wording.

FR3. Current verification and review request¶

After FR1-FR2:

Replace this third-review matrix with a current all-pass matrix or move it into historical review.
Re-run strict build, diff check, and contradiction searches.
Report review requested; external review alone marks M0 verified.

The modified generated corpus files predate the M0 remediation and remain expected M2 drift. Do not edit or revert them as part of M0.

Acceptance matrix after RR1–RR4 (historical; superseded by FR1–FR3)¶

Provisional matrix recorded before FR1–FR3:

Condition	Result	Citation
1. Clear component responsibilities	Pass	system-components.md — identity allocator and six runtime components
2. Complete ownership matrix	Pass	authority-model.md — one owner per row; separate line vs Portfolio Decision/Event; separate audit content vs retention
3. Non-overlapping operations	Pass	authority-model.md — `authorize` reserved for plans; runtime uses `authenticate` / `enforce access`
4. Non-conflated statuses	Pass	authority-model.md — `validated` / `authorized` / `human-approved` / `executed`
5. Hard gate without Conductor state writes	Pass	authority-model.md, integration-contract.md, system-components.md
6. Core/profile/adapter/state/index separation	Pass	organization-profile.md; connect.md — provider-only secret values
7. Documentation precedence	Pass	authority-model.md — hierarchy and conflict handling
8. M1 authority settled	Pass	authority-model.md — ID mint/persist table; Decision/Event ownership split
9. M2 boundary settled	Pass	org-map-model.md plus aligned lines/ stage IDs
10. M3 authority settled	Pass	Proposed plan vs authorization rows; `authorize` ≠ client access
11. No handwritten contradiction	Pass	Operate no longer `Joint`; Product Manager ≠ Initiative owner; connect has no host `.env` secret source
12. Generated drift identified	Pass	Generated mirror is not design authority; M2 migration
13. Strict docs build	Pass	Re-run after RR1–RR4 (see implementing-agent handoff)
14. Diff check	Pass	Re-run after RR1–RR4 (see implementing-agent handoff)

Second review (incomplete before RR1–RR4)¶

The first remediation substantially improved M0: runtime responsibilities were separated, stage IDs aligned, plan and authorization artifacts distinct, and secret names separated from values in authority/profile documents. Four acceptance areas remained unresolved until RR1–RR4.

Second-review acceptance result (historical):

Condition	Result	Remaining issue
1. Clear component responsibilities	Pass	—
2. Complete ownership matrix	Fail	Conditional/multiple owners remain for Decision/Event and authorization-audit records
3. Non-overlapping operations	Pass	—
4. Non-conflated statuses	Pass	—
5. Hard gate without Conductor state writes	Pass	—
6. Core/profile/adapter/state/index separation	Fail	`connect.md` still documents a host `.env` file as an alternate secret-value source
7. Documentation precedence	Pass	—
8. M1 authority settled	Fail	ID allocator/persister wording and Decision/Event ownership remain ambiguous
9. M2 boundary settled	Pass	—
10. M3 authority settled	Pass	—
11. No handwritten contradiction	Fail	Residual ownership and secret-source contradictions remain
12. Generated drift identified	Pass	—
13. Strict docs build	Pass	External review ran `python -m mkdocs build --strict` successfully on 2026-07-24
14. Diff check	Pass	External review ran `git diff --check -- docs`; line-ending warnings only

Residual remediation required (RR1–RR4) — applied¶

RR1. Enforce one owner per artifact class¶

Update docs/authority-model.md:

Split Decision/Event content into separate rows for line-workstream events (owner: the one current active_role) and Portfolio dispositions (owner: Portfolio Manager).
Split plan-authorization audit content from audit-retention policy. Conductor supervisory agent owns audit-event content; Platform Engineer owns retention policy. Do not combine them in one owner cell.
Keep escalation and delegated writers in their dedicated columns.

Update docs/integration-contract.md to use the same separate ownership classes instead of “Current active_role or Portfolio Manager.”

Update remaining handwritten ownership wording:

In docs/lines/operate.md, replace Joint ownership with separate accountable concerns. Platform Engineer owns shared platform/cert wiring; Engineering Lead owns app-repository deploy wiring. Concurrent workstreams may collaborate without shared accountability.
In docs/roles-and-tooling.md, clarify that Product Manager owns the Product evaluation outcome, not the canonical Initiative outcome owned by Portfolio Manager.

RR2. Make identifier allocation unambiguous¶

Update the identifier table in docs/authority-model.md:

initiative_id is persisted by the executing agent acting for Portfolio Manager; remove slash-separated alternatives.
Authorization IDs are minted by the Conductor identity allocator only. The supervisory agent requests the ID and emits the authorization record; it is not a co-allocator.
Review every identifier row for one allocator, one persisting actor, and one authoritative store.

RR3. Remove the alternate host secret source¶

Align docs/connect.md with the provider-only secret-value rule:

Remove the host .env file as a fallback source for retrieving CONDUCTOR_MCP_AUTH_TOKEN.
Remove instructions that use a host-file value to recreate the Bitwarden secret.
If the provider secret is missing, stop with an explicit operator action; do not treat another persistent location as authoritative.
Runtime injection may resolve a provider value into process memory, but documentation must not establish a second durable secret source.

RR4. Replace stale review evidence¶

After RR1-RR3:

Replace the historical failing matrix below with a concise remediation history or move it under a clearly historical heading.
Add one current post-remediation 14-condition matrix with exact citations.
Run the required build, diff check, and contradiction searches.
Report review requested; do not mark the roadmap verified.

Do not create the M1 brief until external review verifies the current matrix.

First review history¶

The first implementation created the required component, authority, and organization-profile documents, and both required validation commands pass. M0 is not complete because seven architectural acceptance conditions remain unresolved.

First-review acceptance result (historical):

Condition	Result	Remaining issue
1. Clear component responsibilities	Fail	Runtime controls aggregate identity, access enforcement, secrets, privacy, audit, and observability
2. Complete ownership matrix	Fail	Proposed plans and authorization records are conflated; several rows have multiple or indeterminate decision owners
3. Non-overlapping operations	Fail	Runtime client access uses the reserved plan operation term `authorize`
4. Non-conflated statuses	Pass	—
5. Hard gate without Conductor state writes	Pass	—
6. Core/profile/adapter/state/index separation	Fail	Secret names and secret values have contradictory authority
7. Documentation precedence	Pass	—
8. M1 authority settled	Fail	Identifier allocation and Decision/Event ownership are unassigned
9. M2 boundary settled	Fail	Exact stage IDs disagree across canonical and line documents
10. M3 authority settled	Fail	Plan ownership and client access terminology remain ambiguous
11. No handwritten contradiction	Fail	Product, Editorial, Services, and Operate workflow identifiers/topology conflict
12. Generated drift identified	Pass	—
13. Strict docs build	Pass	`python -m mkdocs build --strict` passed on 2026-07-24
14. Diff check	Pass	`git diff --check -- docs` passed on 2026-07-24; line-ending warnings only

Do not create the M1 brief or mark M0 verified until the remediation below passes external review.

Required remediation (R1–R7) — applied in first remediation pass¶

R1. Separate proposed plans from authorization records¶

Update docs/authority-model.md with distinct ownership rows:

Proposed plan or document bundle: authored and written by the requesting agent; reviewed by Conductor; stored as a versioned plan/conversation artifact.
Authorization record / authorized pack: decided and emitted by the Conductor supervisory agent; immutable after issue; superseded only by a new authorization.

Every ownership row must name one accountable decision owner. Replace or, broad plural role groups, and slash-separated owners with one owner plus an explicit escalation or delegated-writer rule. Hector is an escalation authority, not a co-owner of ordinary state.

R2. Assign identifier and Decision/Event authority¶

Define who allocates initiative_id, workstream_id, product_id, asset_id, event IDs, and authorization IDs.

The minimal boundary should preserve existing decisions:

A Conductor identity allocator may mint stable IDs without becoming the state writer.
The executing agent persists the minted ID in the authoritative store.
The responsible role owns the Decision/Event content.
Notion is authoritative for Initiative/workstream Decision/Event records.
Runtime authorization audit IDs and records remain control-plane artifacts, not Initiative state.

Add the identity allocator as a component or assign the responsibility explicitly to an existing component. Add Decision/Event records to the ownership matrix with one owner, store, readers, writers, and conflict rule.

R3. Separate plan authorization from runtime access control¶

Reserve authorize exclusively for Conductor approval of an exact execution plan.

Replace runtime phrases such as “authorization of clients” with authenticate and enforce access, or similarly unambiguous access-control vocabulary. Split the current Runtime Controls aggregate into clearly bounded responsibilities, at minimum:

Client identity and authentication.
Access-policy enforcement.
Secret resolution.
Privacy filtering.
Authorization audit.
Operational observability.

These may share one runtime implementation later, but the architecture must state separate inputs, outputs, writes, dependencies, and non-responsibilities.

R4. Separate secret names from secret values¶

Update docs/authority-model.md and docs/organization-profile.md consistently:

Required secret names and provider bindings are organization-profile or adapter configuration.
Secret values are authoritative only in the secret provider.
Runtime may resolve values with least privilege.
Packs, corpus, state, indexes, and profile docs never contain secret values.

Use separate authority rows for configuration references and secret values.

R5. Normalize exact stage identifiers and topology¶

The canonical IDs in docs/org-map-model.md are the M0 authority. Align handwritten line workflows to them without filling the detailed G5 stage contracts:

Product: Discover → Explore → Score → Build-gate → Ship-signal → Archive; Graduation is a disposition/transition, not Archive / Graduate as one stage.
Editorial: Assign → Report → Draft → Edit → Fact-check → Localize → Stage → Publish → Update; Research is work within Report and Archive is a disposition, not compound stage IDs.
Services: Offer → Lead → Propose → Contract → Deliver → Invoice → Complete → Archive; catalog is an Offer binding and Retrospective is work within Complete.
Operate: show Change and Incident as branches from an active runtime, with explicit return to Run; do not display Run → Observe → Change → Incident → Retire as a sequential ladder.

Review all other handwritten docs for these exact IDs. M2 may later align corpus sources, but it must not have to decide which handwritten stage name wins.

R6. Correct roadmap claims¶

Keep M0 at definition until an external review confirms all conditions. M1 and M2 remain blocked by M0. M0 artifacts may be labeled provisional, not completed. Do not claim downstream milestones may rely on them yet.

R7. Re-run and record verification¶

After remediation:

Run both required validation commands.
Run targeted searches across handwritten normative docs.
Confirm all 14 acceptance conditions with citations.
Report M0 as review requested; do not self-mark it verified.

Why this milestone exists¶

The vision is documented, but several responsibilities remain distributed across multiple pages. Without one consistent boundary:

M1 may make Conductor a state writer even though executing agents own writeback.
M2 may encode Hector-specific policy as universal Conductor behavior.
M3 may confuse deterministic validation, execution authorization, and human approval.
Similar-project discovery may create a duplicate system of record.
The generated corpus may be mistaken for current design authority.

M0 resolves those ambiguities before implementation begins.

Authoritative references¶

Read these before proposing edits:

org-map-model.md — canonical product and organization model.
system-components.md — proposed component map and state layers.
integration-contract.md — context, authorization, state, and production boundaries.
tooling-map.md — tool responsibilities and prohibitions.
roles-and-tooling.md — role and pack scope.
connect.md — external MCP behavior and tool families.
vision-gap-register.md — G1 acceptance criteria and later gaps.
roadmap.md — milestone dependencies and exit evidence.

Use docs/generated/corpus/ only to identify drift. Generated pages are not M0 design authority and must not be edited manually.

Decisions already made¶

The implementing agent must preserve these decisions:

Conductor is a specialized supervisory AI and governed instruction compiler.
Conductor authorization is the hard gate before a requesting agent executes an ordinary plan.
Authorization is bound to an exact Initiative, workstream, stage, active role, plan digest, corpus version, and context version.
Deterministic preparation and validation accelerate review but are not required for Conductor to authorize a plan conversationally.
Hector remains the authority for policy changes, exceptions, overrides, and declared human judgment gates.
Conductor does not execute the authorized work or write routine project state.
The executing agent updates Notion and production evidence as part of the authorized plan.
Conductor may read Notion, GitHub, and approved systems to supervise and discover context.
Notion is authoritative for Initiative and workstream state.
GitHub is authoritative for software repositories and delivery evidence; GitHub Issues are optional.
Multiple line workstreams may execute concurrently on one Initiative.
One execution pack covers one workstream stage and one active role.
Assets are enduring systems and are distinct from Initiatives that create or change them.
Conductor stores reusable experiences and improvement candidates, not routine project state.
The first release targets portable clients against Hector's hosted instance while keeping the core adapter-ready.
The three MCP families are preparation, conversation, and feedback/proposal.
Behavior-bearing changes remain governed through proposal, Hector approval, and PR.

Changing any decision above is outside M0 implementation authority. Record a blocking finding instead.

Required deliverables¶

1. Final component boundary¶

Update system-components.md so every component has:

Purpose.
Inputs and outputs.
Read and write permissions.
Authoritative dependencies.
Explicit non-responsibilities.
Organization-specific versus reusable classification.

Components must include at least:

Requesting agent.
MCP gateway and all three tool families.
Conductor supervisory agent.
Compiler and selector.
Corpus.
Organization profile.
Notion and GitHub read adapters.
Asset registry and estate index.
Experience store and scheduled reviewer.
Governance.
Runtime identity, secrets, privacy, audit, and observability.

2. Authority model¶

Create docs/authority-model.md containing:

Decision owner, authoritative store, permitted readers, permitted writers, and conflict rule for each fact or artifact class.
Exact definitions of read, validate, authorize, and propose.
Exact distinction among validated, authorized, human-approved, and executed.
Authorization scope, invalidation, escalation, and audit requirements at the architecture level.
Rule that access to a tool does not confer decision authority.
Rule that derived indexes and caches cannot override source systems.

The authority model must cover:

Initiative and workstream state.
Product evaluation state.
Assets and estate descriptions.
Software delivery evidence.
Editorial, Services, and Operate artifacts.
Plans and authorization records.
Completion records.
Experiences and improvement candidates.
Corpus units, schemas, templates, compiler configuration, and generated documentation.
Runtime credentials and audit events.

3. Core and organization-profile boundary¶

Create docs/organization-profile.md containing:

What belongs to reusable Conductor core.
What belongs to an organization profile.
What belongs to environment adapters and secret configuration.
What belongs to Initiative or Asset state.
How organization overlays may specialize core without silently replacing it.
How unresolved onboarding questions remain explicit gaps.

Classify at least:

Hector and approver identities.
Roles and lines.
Notion and GitHub providers.
GitHub organizations and repositories.
Secret provider and secret names.
Domains, hosts, and deployment defaults.
Prototype, Lab, and Portfolio-org estate vocabulary.
WIP limits and review cadence.
Privacy classes.

M0 defines the boundary, not the complete onboarding schema tracked by G13-G15.

4. Documentation authority hierarchy¶

Add a concise authority section to the appropriate existing document, or to docs/authority-model.md, defining precedence among:

Hector-approved behavior-bearing policy.
Canonical model and authority contracts.
Organization profile.
Line and software decision documents.
Generated corpus mirror.
Examples and descriptive history.
Archived material.

Define how conflicts are surfaced. Do not silently choose whichever document is newest.

5. Normative consistency pass¶

Review and minimally update these documents where needed:

docs/org-map-model.md
docs/system-components.md
docs/integration-contract.md
docs/tooling-map.md
docs/roles-and-tooling.md
docs/connect.md
docs/index.md
docs/.pages

Remove or correct normative wording that conflicts with the locked decisions. Do not expand line workflows, define the Notion schema, migrate corpus units, or implement tools.

6. Downstream prerequisites¶

Update the M0 section of roadmap.md with concise links to the completed M0 artifacts. Identify the exact inputs M1, M2, and M3 may now rely on.

Do not duplicate the gap register's acceptance criteria or create later milestone briefs.

Required execution sequence¶

Read every authoritative reference and inventory the terms used for authority, state, authorization, and policy.
Produce a conflict list before editing.
Draft the component and authority matrices.
Classify core, organization-profile, adapter, state, and derived-index concerns.
Create the two required documents.
Apply the smallest consistency edits to existing normative docs.
Add navigation and roadmap links.
Run documentation validation and targeted contradiction searches.
Review the final diff only for docs/.
Report M0 as review requested only if every acceptance condition passes; external review marks it verified.

Non-goals¶

Do not create or modify Notion databases.
Do not request or configure credentials.
Do not access GitHub or inventory repositories.
Do not create the Asset registry.
Do not prepopulate any estate records.
Do not modify corpus/, schemas/, service/, integrations/, templates, or deployment files.
Do not edit files under docs/generated/ except an index warning if navigation requires it.
Do not design complete MCP request or response schemas.
Do not implement the compiler, adapters, authorization engine, or scheduled reviewer.
Do not create M1-M6 briefs.

Acceptance conditions¶

M0 may move from definition to verified only after external review confirms:

Every component has one clear responsibility and explicit non-responsibilities.
Every important fact or artifact class has a decision owner, authoritative store, reader, writer, and conflict rule.
read, validate, authorize, and propose are non-overlapping operations.
validated, authorized, human-approved, and executed cannot be conflated.
Conductor authorization remains a hard execution gate without making Conductor a project-state writer.
Core, organization profile, environment adapter, state, and derived index are distinguishable.
Documentation precedence and conflict handling are explicit.
M1 can design state and estate storage without deciding Conductor's authority.
M2 can migrate the corpus without deciding what belongs to core versus organization policy.
M3 can design MCP contracts without deciding who may authorize or mutate state.
No known contradiction remains among the normative handwritten docs.
The generated corpus drift remains clearly identified as a later governed migration.
python -m mkdocs build --strict passes.
git diff --check -- docs reports no errors.

Required verification¶

Run:

powershell python -m mkdocs build --strict git diff --check -- docs git status --short -- docs

Search normative handwritten docs for superseded concepts, including:

Conductor writing routine Notion state.
Mandatory GitHub Issues.
A single active line or attending_lines model.
Multi-role execution packs.
Authorization being equivalent to Hector approval.
Generated corpus being described as current design authority.
Deterministic validation being mandatory before conversation.

Matches that explicitly prohibit or document superseded concepts are acceptable. Generated mirror matches are expected and belong to M2.

Stop conditions¶

Stop and report a blocking decision instead of guessing when:

A locked decision must change to make the model coherent.
Two authoritative sources cannot be reconciled by precedence.
A deliverable would require changes outside docs/.
A core-versus-organization classification has material security or multi-tenant consequences not covered by current decisions.
Existing uncommitted changes directly conflict with the required edit.

Final handoff¶

The implementing agent's final response must include:

Files created and materially updated.
Decisions clarified without restating all documentation.
Remaining blockers or explicit confirmation that none remain.
Validation commands and results.
M0 status and evidence.
Recommended first input for M1.

Do not mark M0 verified. Report review requested when the acceptance evidence is complete; verification requires a separate review of every condition above.