Organization profile¶
Boundary between reusable Conductor core and organization-specific
configuration. M0 established the classification; M6 implements the full
onboarding and multi-organization contracts in
its decision package
and the organization-profile.v1 schema.
See Authority model and System components.
Layering¶
text
Conductor core model
+ organization profile and organization policy corpus
+ environment adapters and credentials
+ Initiative / workstream / Asset / Product state
+ derived indexes (estate, search, caches)
+ compiled pack
| Layer | What it holds | Who changes it |
|---|---|---|
| Conductor core | Reusable concepts, contracts, and compiler semantics | Product architecture; governed core releases |
| Organization profile | How this organization maps onto core, including required secret names and provider bindings | Hector through governed configuration |
| Environment adapters | Provider endpoints, host wiring, and runtime connection to the secret provider | Platform configuration; not packs |
| Secret values | Actual credential material | Secret provider only; resolved at runtime with least privilege |
| State | Live Initiatives, workstreams, Products, Assets, events | Executing agents and humans in authoritative stores |
| Derived index | Searchable projections with provenance | Indexer only; never system of record |
Organization overlays may specialize core defaults. They must not silently redefine core semantics. Unresolved onboarding questions remain explicit gaps.
Classification matrix¶
| Concern | Layer | Notes |
|---|---|---|
| Initiative, workstream, stage, inventory, pack, authorization concepts | Core | Universal Conductor model |
| Lines as abstract departments (Portfolio, Product, Software, Editorial, Services, Operate) | Core | Structure is reusable |
| Concrete role IDs and tooling matrix entries for Hector's org | Organization profile + org corpus | May differ for another org |
| Hector identity and approver GitHub logins | Organization profile | Not core vocabulary |
Approval comment protocol shape (Conductor-Approval: approve) |
Core pattern | Allowlisted identities are organization profile |
| Notion as Initiative SoR pattern | Core (adapter-ready) | Provider workspace IDs and DB IDs are organization / adapter |
| GitHub as software evidence SoR pattern | Core (adapter-ready) | Org names (hector-sanchez-eu, Konstant-Ventures) are organization profile |
| Specific repositories and estate membership | State (Assets) + organization source inventory | Profile names allowed orgs; Assets name repos |
| Secret provider pattern | Core | How Conductor asks for secrets by name |
| Required secret names and provider bindings | Organization profile / adapter configuration | Configuration references only |
| Secret values | Secret provider only | Never in corpus, packs, state, indexes, or profile docs |
Domains, hosts, deploy defaults (*.hectorsanchez.eu, VPS, Tailscale) |
Organization profile | Core must stay host-agnostic |
| Prototype / Lab / Portfolio-org estate vocabulary | Organization profile | Core may speak of “estate class”; labels are org-specific |
| WIP limits and review cadence | Organization profile / org policy | Core defines that Portfolio can set them |
| Privacy classes and redaction rules | Core concepts; org assigns classes to data | Services privacy boundaries are org policy |
| Calendar for timed attention | Core pattern | Calendar account is adapter |
| Bitwarden project and machine account wiring | Environment adapters | Values stay in the secret provider |
| MCP auth token name and runtime URLs | Organization profile / adapter config | Token value is secret-provider only |
| Experience and candidate store schemas | Core | Retention and review cadence defaults may be org profile |
Generated docs under docs/generated/ |
Derived | Not profile; not authority |
Secret names versus secret values¶
| Item | Authoritative place | May appear in packs/docs/state? |
|---|---|---|
Secret name (e.g. CONDUCTOR_MCP_AUTH_TOKEN) |
Organization profile or adapter configuration | Yes, as a reference |
| Provider binding (which vault/project) | Organization profile or adapter configuration | Yes, as a reference |
| Secret value | Secret provider only | Never |
Runtime secret resolution loads values with least privilege when a permitted component needs them. Missing values fail explicitly.
Core must not encode¶
As universal Conductor concepts, core schemas and contracts must not hard-require:
- Hector's name or GitHub login as the only possible approver identity
- Specific GitHub organization or repository names
- Specific Notion workspace or database IDs
- Specific domains, hosts, or VPS addresses
- Prototype / Lab / Portfolio-org as the only possible estate taxonomy
- Workspace monorepo paths or
AGENTS.mdtrees outside Conductor - Secret values
Those belong in the organization profile, adapters, secret provider, or state.
Overlay rules¶
- Specialize, do not replace. An overlay may constrain options (for example, allowed estate classes) without removing the core estate concept.
- Explicit gaps. If the profile lacks a required binding (approver list, Notion parent, GitHub org inventory, required secret names), Conductor reports a gap; it does not invent values from local machine context.
- No silent authority upgrade. Organization policy cannot turn
authorizedintohuman-approved, or turn the estate index into the Asset system of record. - Corpus split. Reusable workflow shapes may live in core-oriented units; Hector-specific defaults and inventories live in organization corpus or profile. M2 defines packaging details (D-10).
- First release. Portable clients talk to Hector's hosted Conductor instance. Portability of the organization to a second employer is deferred to M6; boundaries here keep that path open.
Minimum profile fields¶
The organization-profile.v1 schema and M6 interview now implement these
categories. Missing required answers remain typed blocking gaps.
- Approver identities and human judgment contacts
- Role and line bindings in use
- Notion provider and Initiative/Product/Asset location references
- GitHub provider, allowed users/orgs, and default estate mapping rules
- Secret provider and required secret names (not values)
- Default domains, hosts, and deployment posture
- Estate class vocabulary (for Hector: Prototype, Lab, Portfolio-org)
- Portfolio WIP and review-cadence defaults
- Privacy classes and which roles may see which classes
Unresolved items stay gaps¶
Until filled, the following remain explicit gaps rather than implied from a developer laptop:
- Approved GitHub enumeration scope (D-03)
- Physical Notion database layout (D-01)
- Read-credential permission matrix (D-04)
- Per-client production authentication mapping to
organization_id; the current shared-token MCP surface remains candidate-only for onboarding
Downstream use (after external M0 verification)¶
Until M0 is externally verified, treat this document as provisional remediation. After verification:
- M1 stores Assets and Initiatives as state; estate class labels come from this org's vocabulary.
- M2 migrates corpus without promoting Hector-specific IDs into core.
- M3 tools accept organization profile as configuration, not as hard-coded constants in core logic.