System components
This document identifies the parts required to make the Conductor vision usable. It defines responsibilities and boundaries. Ownership vocabulary lives in the authority model. Core versus organization layering lives in the organization profile. Detailed missing contracts remain in the vision gap register.
Primary flow
text
Requesting agent
│
├── preparation queries
│ └── policy + state + estate + precedent
│
└── proposed plan / document bundle
│
▼
Conductor supervisory agent
│
├── asks only unresolved questions
├── reviews against current context
└── authorizes an exact plan
│
▼
Requesting agent executes
│
├── updates Notion state
├── updates production evidence
└── submits reusable learning when warranted
Conductor reads organizational and production state but does not write routine project state. The executing agent owns the Notion and production updates required by the authorized plan.
Component boundaries
Each component below is classified as core (reusable Conductor), organization (profile or org policy), adapter (environment wiring), state (live records in SoR), or derived (index/cache).
Requesting agent
| Aspect |
Definition |
| Purpose |
Propose work, obtain authorization, execute the authorized plan, persist state and evidence |
| Inputs |
User intent; authorized pack; permitted production tools |
| Outputs |
Production artifacts; Notion updates; optional experience or proposal submissions |
| Reads |
Authorized pack; tools granted by role |
| Writes |
Notion state and production artifacts; feedback submissions |
| Depends on |
MCP gateway; authoritative production systems |
| Non-responsibilities |
Issuing authorization; changing governed corpus; acting as Initiative SoR |
| Classification |
External actor (not Conductor core) |
MCP gateway
| Aspect |
Definition |
| Purpose |
Portable authenticated interface to Conductor tool families |
| Inputs |
Authenticated client requests |
| Outputs |
Versioned tool responses |
| Reads |
Auth configuration; routes to tool layers |
| Writes |
Nothing in project state; may emit audit via authorization audit and observability components |
| Depends on |
Client identity and authentication; access-policy enforcement |
| Non-responsibilities |
Compilation policy; Notion writes; production mutations |
| Classification |
Core interface; endpoint and tokens are adapter/org |
| Aspect |
Definition |
| Purpose |
Deterministic discovery and optional fast-path validate |
| Inputs |
Line, stage, bindings, Initiative/workstream identifiers, query parameters |
| Outputs |
Lists, context summaries, validation findings (validated or gap findings) |
| Reads |
Corpus; organization profile; Notion/GitHub read adapters; estate index |
| Writes |
Preparation results only |
| Depends on |
Corpus; read adapters; estate index |
| Non-responsibilities |
Authorization; policy activation; mandatory gate before conversation |
| Classification |
Core |
| Aspect |
Definition |
| Purpose |
Plan review, refinement, and authorize of an exact plan |
| Inputs |
Messages; proposed plan or document bundle; thread context |
| Outputs |
Questions; findings; refusals; revision requests; escalations; authorized pack when issued |
| Reads |
Preparation results; corpus; organization profile; state snapshots; proposed-plan store |
| Writes |
Conductor review artifacts and authorization records only — not proposed plans, not Notion project state |
| Depends on |
Supervisory agent; compiler and selector |
| Non-responsibilities |
Executing work; Hector approval for exceptions; routine writeback |
| Classification |
Core |
| Aspect |
Definition |
| Purpose |
Accept reusable experiences, improvement candidates, and governed policy proposals (propose) |
| Inputs |
Structured experience or proposal payloads |
| Outputs |
Stored experience/candidate references; proposal issue or PR linkage |
| Reads |
Linked evidence metadata; corpus allowlists |
| Writes |
Experience store; candidate store; proposal records — not live Initiative state |
| Depends on |
Governance layer; experience store |
| Non-responsibilities |
Activating policy; completing Initiatives |
| Classification |
Core |
Conductor supervisory agent
| Aspect |
Definition |
| Purpose |
Review, question, reconcile, and authorize ordinary execution plans within delegated policy |
| Inputs |
Proposed bundle; preparation context; corpus; organization profile |
| Outputs |
Authorization or findings; review artifacts; escalation when human approval is required |
| Reads |
All preparation and policy inputs; proposed plan from requesting agent |
| Writes |
Conductor review artifacts and authorization records only — not proposed plans; not Notion project state |
| Depends on |
Compiler; corpus; organization profile; read adapters |
| Non-responsibilities |
Writing routine Notion/project state; replacing Hector for policy/exceptions; multi-role packs |
| Classification |
Core |
Compiler and selector
| Aspect |
Definition |
| Purpose |
Select the smallest relevant policy and context set for one stage and role |
| Inputs |
Initiative/workstream snapshot; stage; role; bindings; corpus version |
| Outputs |
Versioned execution pack content (with authorization metadata when issued) |
| Reads |
Corpus; organization profile; state snapshot |
| Writes |
Pack artifacts only |
| Depends on |
Corpus; organization profile |
| Non-responsibilities |
Discovering estate alone; mutating SoR; inventing missing bindings |
| Classification |
Core |
Corpus
| Aspect |
Definition |
| Purpose |
Store governed workflows, inventories, standards, roles, patterns, and templates |
| Inputs |
Approved PRs from governance |
| Outputs |
Units consumed by compiler and preparation |
| Reads |
Approved policy sources |
| Writes |
Only through proposal → Hector approval → PR |
| Depends on |
Governance layer |
| Non-responsibilities |
Holding live Initiative state; replacing organization profile for host-specific IDs |
| Classification |
Core shapes plus organization policy units (see organization profile) |
Organization profile
| Aspect |
Definition |
| Purpose |
Bind reusable Conductor concepts to this organization's roles, tools, providers, vocabulary, and approval model |
| Inputs |
Hector's organization decisions |
| Outputs |
Configuration consumed by runtime and compiler |
| Reads |
Organization decisions |
| Writes |
Governed configuration only |
| Depends on |
Authority model layering |
| Non-responsibilities |
Redefining core semantics; storing secret values; acting as Asset registry |
| Classification |
Organization |
Notion read adapter
| Aspect |
Definition |
| Purpose |
Retrieve Initiative, workstream, Product, Asset, decision, and event state |
| Inputs |
Stable IDs; query filters; role permission context |
| Outputs |
Versioned state snapshots with provenance and freshness |
| Reads |
Notion |
| Writes |
Nothing |
| Depends on |
Adapter credentials; organization Notion location references |
| Non-responsibilities |
Creating or updating Notion pages; owning completion writeback |
| Classification |
Core adapter contract; wiring is environment adapter |
GitHub read adapter
| Aspect |
Definition |
| Purpose |
Retrieve repositories and software delivery evidence |
| Inputs |
Repo identity; PR/check/release queries |
| Outputs |
Evidence metadata with timestamps and provenance |
| Reads |
GitHub |
| Writes |
Nothing |
| Depends on |
Adapter credentials; organization-allowed orgs/repos |
| Non-responsibilities |
Creating issues/PRs; owning Initiative state; replacing Asset registry |
| Classification |
Core adapter contract; wiring is environment adapter |
Asset registry
| Aspect |
Definition |
| Purpose |
Authoritative descriptions of enduring systems (applications, services, sites, tools, prototypes) |
| Inputs |
Human-reviewed Asset records; linked provenance |
| Outputs |
Capability and relationship data for reuse decisions |
| Reads |
Via Notion read adapter |
| Writes |
Agents/humans with Asset permission — not the Conductor compiler |
| Depends on |
Notion as organizational state layer |
| Non-responsibilities |
Being a second GitHub; storing full source trees |
| Classification |
State (schema designed in M1) |
Estate index
| Aspect |
Definition |
| Purpose |
Normalize searchable metadata across Notion Assets, GitHub, and approved sources for retrieval speed |
| Inputs |
Registry and adapter reads |
| Outputs |
Ranked search hits with relevance explanation and source pointers |
| Reads |
Notion registry, GitHub, other approved sources |
| Writes |
Derived cache or index only |
| Depends on |
Asset registry; read adapters |
| Non-responsibilities |
System of record; silent merge of duplicates; overriding reviewed Asset text |
| Classification |
Derived |
Experience store and scheduled reviewer
| Aspect |
Definition |
| Purpose |
Persist reusable experiences; periodically create non-binding improvement candidates from new evidence |
| Inputs |
Feedback submissions; review cursor |
| Outputs |
Experience records; candidate improvements |
| Reads |
New structured experiences only within privacy rules |
| Writes |
Experience and candidate stores — never live corpus activation |
| Depends on |
Feedback layer; privacy classes from organization profile |
| Non-responsibilities |
Editing governed assets; authorizing execution; writing Notion Initiative state |
| Classification |
Core stores; cadence defaults may be organization |
Governance layer
| Aspect |
Definition |
| Purpose |
Protect behavior-bearing changes through proposal, Hector approval, and PR |
| Inputs |
Proposals and candidate evidence |
| Outputs |
Approved merges; rejection or duplicate closure |
| Reads |
Proposal and candidate evidence |
| Writes |
Approved PR content only; no automatic activation without merge |
| Depends on |
Approver identities from organization profile |
| Non-responsibilities |
Ordinary plan authorization; project management |
| Classification |
Core process; approver list is organization |
Conductor identity allocator
| Aspect |
Definition |
| Purpose |
Mint stable identifiers for Initiatives, workstreams, Products, Assets, Decision/Events, and authorization records |
| Inputs |
Allocation request type and minimal context needed for uniqueness |
| Outputs |
Fresh initiative_id, workstream_id, product_id, asset_id, event ID, or authorization ID |
| Reads |
Existing ID registries / uniqueness stores as required |
| Writes |
Allocator registry entries only — never Notion Initiative/Product/Asset project fields |
| Depends on |
Runtime identity of the requesting client |
| Non-responsibilities |
Persisting IDs into Notion or production SoR; deciding Initiative content; issuing plan authorization |
| Classification |
Core |
The identity allocator is the sole minting component for every ID above, including authorization IDs. The Conductor supervisory agent may request an authorization ID and then emit it inside the authorization record; it does not co-allocate. The executing agent acting for the responsible decision owner persists Initiative, workstream, Product, Asset, and Decision/Event IDs into the authoritative store. Minting alone is not project-state writeback.
Client identity and authentication
| Aspect |
Definition |
| Purpose |
Establish who the calling client is (authenticate) |
| Inputs |
Credentials or tokens presented by the client |
| Outputs |
Authenticated client identity or rejection |
| Reads |
Auth configuration; secret references for token verification |
| Writes |
Authentication events to the runtime authN store |
| Depends on |
Secret resolution; organization endpoint configuration |
| Non-responsibilities |
Plan authorize; Initiative outcomes; privacy redaction of pack content |
| Classification |
Core controls; credential wiring is adapter/org |
Access-policy enforcement
| Aspect |
Definition |
| Purpose |
Decide whether an authenticated client may invoke a tool or see a resource (enforce access) |
| Inputs |
Authenticated identity; requested operation; resource metadata |
| Outputs |
Allow or deny with reason |
| Reads |
Access policy configuration; organization profile permission bindings |
| Writes |
Access-decision logs |
| Depends on |
Client identity and authentication |
| Non-responsibilities |
Plan authorize; corpus edits; Notion writeback |
| Classification |
Core controls |
Secret resolution
| Aspect |
Definition |
| Purpose |
Resolve configured secret names to secret values at runtime with least privilege |
| Inputs |
Secret name / binding from organization profile or adapter config |
| Outputs |
Ephemeral secret value to the caller that needs it; or explicit missing-secret failure |
| Reads |
Secret provider |
| Writes |
Nothing in project state; may write resolution failure telemetry |
| Depends on |
Secret provider; organization secret-name bindings |
| Non-responsibilities |
Choosing which secret names exist (profile); storing values in packs, corpus, docs, or state |
| Classification |
Core controls; provider account is adapter |
Privacy filtering
| Aspect |
Definition |
| Purpose |
Omit or redact context the active role or client must not see |
| Inputs |
Candidate context; privacy class; active role / client identity |
| Outputs |
Filtered context or explicit redaction markers |
| Reads |
Privacy class assignments from organization profile; state and adapter payloads |
| Writes |
Nothing in authoritative SoR |
| Depends on |
Access-policy enforcement; organization privacy classes |
| Non-responsibilities |
Deciding Initiative outcomes; plan authorize |
| Classification |
Core controls; class assignments are organization |
Authorization audit
| Aspect |
Definition |
| Purpose |
Persist attributable records of plan authorization, refusal, and escalation |
| Inputs |
Authorization or escalation events from the supervisory agent |
| Outputs |
Immutable audit entries (authorization ID, digest, versions, outcome, time) |
| Reads |
Supervisory agent outputs |
| Writes |
Authorization audit store only |
| Depends on |
Conductor supervisory agent; identity allocator for authorization IDs |
| Non-responsibilities |
Notion Decision/Event content; client authenticate; mutating packs after issue |
| Classification |
Core controls |
Operational observability
| Aspect |
Definition |
| Purpose |
Emit health, latency, error, and operational telemetry for the Conductor runtime |
| Inputs |
Runtime metrics and logs |
| Outputs |
Telemetry streams and dashboards |
| Reads |
Runtime process signals |
| Writes |
Observability store |
| Depends on |
Runtime hosts |
| Non-responsibilities |
Initiative state; estate truth; plan authorization decisions |
| Classification |
Core controls; hosts are adapter/org |
These six runtime responsibilities may share one deployment later. Architecture treats them as separate inputs, outputs, writes, dependencies, and non-responsibilities. None of them performs MCP authorize.
Knowledge layers
Conductor must keep different kinds of knowledge separate because they have different authority and lifecycles.
| Layer |
Example |
Authority |
| Core model |
Workstream, stage, inventory, authorization |
Conductor architecture |
| Organization policy |
Secret management, deployment defaults, approval roles |
Hector-approved corpus/profile |
| Initiative state |
Outcome, active workstreams, next action, evidence |
Notion |
| Software delivery state |
Repository, PR, checks, release, deployment |
GitHub |
| Estate description |
Existing app purpose, capabilities, lifecycle, links |
Notion asset registry with source provenance |
| Descriptive history |
What happened and why |
Notion events plus authoritative artifact links |
| Experience |
Blocker, workaround, failure, repeated question |
Conductor feedback store |
| Candidate policy |
Possible new or changed pattern |
Non-binding until governed approval |
State model
Notion
Notion is the organizational state layer. The minimum proposed model is:
| Record |
Purpose |
| Initiative |
Why work exists, outcome, definition of done, priority, relationships |
| Workstream |
One line's stage, role, status, bindings, evidence, and next action |
| Product |
Product evaluation, scorecards, gates, and ship signals |
| Asset |
Enduring system, application, service, site, tool, or prototype that already exists |
| Decision/Event |
Durable evidence of transitions, decisions, exceptions, and outcomes |
Whether Workstreams and Decisions are separate databases or structured children of an Initiative is decided for M1 in state-model.md: five separate databases (Gate A draft). Assets must remain distinct from Initiatives: an Initiative is work with an outcome; an Asset persists and may be changed by many Initiatives.
GitHub
GitHub is authoritative for software production evidence:
- Repository identity and source.
- Branches, commits, and pull requests.
- Required checks and test outcomes.
- Releases and deployment evidence.
- Optional repository-local issues.
GitHub does not contain the canonical Initiative or estate description. A README may be evidence, but it is not guaranteed to answer why an asset exists, which need it serves, or whether it overlaps another asset.
Asset registry fields
The Asset registry enables the central checkpoint: before authorizing new work, Conductor must determine whether an existing system can satisfy the need, should be extended, or is materially different.
Minimum Asset metadata:
| Field |
Purpose |
asset_id |
Stable identity independent of repository or machine |
| name and aliases |
Discovery across renamed or duplicate projects |
| purpose |
Why the asset exists |
| users and needs |
Who it serves and what problem it addresses |
| capabilities |
What it currently does, in comparable terms |
| lifecycle status |
Proposed, prototype, active, maintained, superseded, archived |
| estate |
Organization-specific classification such as Prototype, Lab, Portfolio-org |
| repositories |
GitHub and any exceptional local-only source references |
| environments and URLs |
Where verified instances run |
| stack and deployment shape |
Technical comparison and reuse constraints |
| related Initiatives and Assets |
Provenance, replacements, forks, dependencies, and overlap |
| privacy and access class |
What Conductor and requesting agents may see |
| last verified and evidence |
Freshness and source links |
Capability descriptions matter more than names or stacks. The three real-estate applications may use different technologies while still solving substantially the same user need.
Read access and indexing
Conductor requires read access to Notion and GitHub wherever it runs. Secret values remain only in the configured secret provider and are never included in a pack. Secret names and provider bindings come from the organization profile or adapter configuration.
The read path must provide:
- Organization and user identity.
- Permission-filtered queries.
- Source timestamps or versions.
- Stable identifiers and provenance.
- Explicit stale, unavailable, and partial results.
- No assumption that the local machine contains the full estate.
The estate index is derived for retrieval speed. It is not a new system of record. Search results must point back to Notion, GitHub, or another authoritative source and state why each result is relevant.
Initial prepopulation
Conductor cannot prevent duplicate work until the current estate is represented. Bootstrap requires a one-time, reviewable inventory process (M1):
- Enumerate repositories from the approved GitHub users and organizations.
- Enumerate known local-only prototypes, workspace pointers, and deployed services not represented by GitHub.
- Create candidate Asset records with source provenance.
- Extract candidate purpose, users, capabilities, stack, deployments, and relationships.
- Group likely duplicates and related systems for human review.
- Confirm, merge, or distinguish records and add missing capability descriptions.
- Link Assets to historical and active Initiatives where known.
- Record a verified baseline date and unresolved inventory gaps.
Automated extraction may prepare candidate records; it must not silently decide that two systems are equivalent or overwrite reviewed descriptions.
Reuse decision
Before authorizing a new Asset or substantial implementation, Conductor should return one of:
| Result |
Meaning |
reuse |
Existing capability already satisfies the need |
extend |
An existing Asset is the best base and the delta is justified |
new |
No existing Asset sufficiently fits and a new one is justified |
insufficient-context |
Estate or requirement evidence is too weak to decide |
The result must cite compared Assets, overlap, material differences, freshness, and the evidence used. new is not valid merely because the requesting agent did not know another project existed.
Contracts still required
The components above depend on contracts already tracked in the gap register:
- Authority and adapter boundaries: G1 (M0 verified; authority-model.md, organization-profile.md).
- Plan bundle and authorization: G2.
- Agent-owned Notion writeback: G3 (state-model.md draft).
- Compact pack selection: G4.
- Complete stage behavior: G5.
- Corpus alignment: G6.
- Estate and precedent discovery: G7 (asset-registry.md draft).
- History and experience: G8-G10.
- Reconciliation and MCP tools: G11-G12.
- Organization portability: G13-G15 (read-access-contract.md draft for G14 adapters).
This document must not restate those acceptance criteria. The gap register remains their source.