Context and integration contract¶
This contract defines what Conductor may read, what it may authorize, what it may emit, and where authority remains. Conductor is an instruction and guardrail compiler with delegated plan-authorization authority, not a cross-system state orchestrator.
Canonical ownership vocabulary, MCP operations (read / validate / authorize / propose), and approval statuses live in the authority model. Core versus organization layering lives in the organization profile.
See also Org model, System components, and Tooling map.
Principles¶
- The Notion Initiative is the canonical organizational work contract.
- Each line keeps its production artifacts in its own authoritative system.
- Conductor reads context, reviews plans, and authorizes execution; it does not mutate production state.
- An authorized pack is scoped to one Initiative, one workstream, one stage, one active role, and one exact plan version.
- Authorization does not replace production-tool access controls or satisfy missing evidence.
- Exceptions, policy changes, and declared human judgment gates still require Hector.
- Optional links to line artifacts do not create a second work contract.
Context input¶
A compilation request must identify:
yaml
initiative_id: init.<id>
organization_id: org.<id>
workstream_id: ws.<id>
stage: <exact stage id>
active_role: role.<id>
repositories:
- https://github.com/<owner>/<repo>
bindings: {}
evidence: []
Conductor loads the remaining Initiative and workstream context from Notion or accepts a versioned snapshot supplied by a trusted adapter. The response must identify the context version used so stale packs can be detected.
For repository.modify-files.v1, authoritative workstream state must bind the
exact active role and repository URL. Estate discovery, tool availability, and
requester text do not establish mutation authority.
Authorization and output contract¶
An authorized pack contains:
- Initiative outcome and definition of done needed for the stage.
- Workstream line, stage, status, and next action.
- Exactly one active role and its permitted tools.
- Resolved standards, units, bindings, and template references.
- Stage entry and exit conditions.
- Required evidence.
- Permitted deterministic transitions.
- Judgment gates requiring Hector.
- Gaps, conflicts, and prohibitions.
- Corpus version and context version.
- Plan or bundle digest.
- Authorization ID, scope, conditions, and issuance time.
The pack is the hard execution gate for the requesting agent. A result without explicit authorization is feedback, not permission to proceed.
The pack does not update Notion, create GitHub issues, move stages, deploy software, publish content, or alter runtime infrastructure. The authorized agent performs the plan using its own permitted production tools and records state and evidence directly in the authoritative system.
Authorization is invalid when the Initiative, workstream, stage, active role, material context, or plan digest changes. The agent must return to Conductor for a new review.
Authority matrix¶
Summary for integration boundaries. The full reader/writer/conflict table, including proposed plan, Conductor review artifacts, and authorization record, is in the authority model.
| Information or artifact | Decision owner | Authoritative store | Conductor's role |
|---|---|---|---|
| Initiative outcome, status, priority, relationships | Portfolio Manager (escalate Hector) | Notion Initiative | read and validate |
| Workstream line, stage, role, status, bindings | Current active_role (Portfolio Manager for cross-workstream conflicts) |
Notion workstream state | read and compile |
| Product evidence, score, and gate result | Product Manager | Notion Product | read and validate deterministic rules |
| Asset and estate descriptions | Portfolio Manager | Notion Asset registry | read; reuse guidance via conversation |
| Line-workstream Decision/Event content | Current active_role |
Notion Decision/Event | read / verify |
| Portfolio disposition Decision/Event content | Portfolio Manager | Notion Decision/Event | read / verify |
| Plan-authorization audit event content | Conductor supervisory agent | Authorization audit store | Emit via plan authorize path |
| Authorization-audit retention policy | Platform Engineer | Runtime retention configuration | None (control-plane) |
| Source code, PRs, checks, releases, deployments | Engineering Lead | GitHub repository | read as evidence |
| Publication artifacts | Editor-in-Chief | Editorial production tools | read as evidence |
| Client artifacts | Engagement Manager | Private client folders | read privacy-safe metadata only |
| Runtime state and runbooks | Platform Engineer | Runtime tools and runbooks | read as evidence |
| Timed attention | Portfolio Manager | Calendar | No project-state authority |
| Proposed plan or document bundle | Requesting agent | Versioned proposed-plan store | Review; does not own |
| Conductor review artifacts (questions, findings, refusals, revision requests, escalations) | Conductor supervisory agent | Conductor review / conversation store | Emit during conversation; not execution permission |
| Authorization record / authorized pack | Conductor supervisory agent | Authorization record / pack store | authorize (plan only) |
| Compilation policy | Hector | Conductor governed assets | Select and compile |
| Exception, override, or policy change | Hector | Decision or governed-change record | Detect and escalate |
| Completion / writeback record | Current active_role |
Notion | read / verify; never silent repair |
| Secret names / provider bindings | Hector | Organization profile / adapter config | Resolve by name via secret resolution |
| Secret values | Secret provider | Secret provider only | Never include in packs |
GitHub boundary¶
GitHub is the Software production system, not the organizational tracker.
- Repositories, branches, commits, PRs, checks, releases, and deployments may be linked as workstream evidence.
- GitHub Issues are optional for repository-local defects or implementation discussion.
- An issue is not required to start or complete a Software stage.
- Closing an issue does not change Initiative or workstream state.
- Failed required checks block a transition when the stage contract names those checks.
- GitHub Projects must not duplicate the Initiative portfolio.
Recording transitions¶
When an agent completes authorized work or a transition:
- Verify every declared exit condition against authoritative evidence.
- Confirm that the action remains within the authorized plan and conditions.
- Perform the production action with the role's permitted tool.
- Record evidence, decisions, status, and next action in Notion.
- Return to Conductor for a new pack when the stage, role, plan, or material context changes.
The canonical MCP operation for step 4 verification is
complete_authorized_work. The executing agent performs the actual write and
supplies the authoritative system, record ID, stable operation ID, verification
time, evidence references, and next action. A configured server-side adapter
must read the record back and attest the reference before Conductor atomically
records feedback and completion. Without an adapter the operation fails closed;
Conductor never performs or silently repairs the state write.
If any write fails, report the partial result and stop. Do not claim atomicity across independent systems. Retried writes must use stable operation identifiers where supported.
Privacy¶
Initiatives and packs contain links and privacy-safe summaries, not client secrets or unnecessary personal data. Services artifacts remain in private client storage. Conductor must omit or redact context that the active role is not permitted to access.