---title: "Core Model"description: "The main data and runtime concepts in executor today."--- The most important thing to understand about executor is that it does **not** model the system as one flat `source` row. The current model has a few separate concepts that each exist for a different reason. ## The primary concepts ### Source binding A source is the workspace-local installation record. It answers: - what is this integration called in this workspace?- is it enabled?- what namespace should its tools use?- what install-local config does it have? This is why a source carries local concerns like name, namespace, enabled state, binding config, and status. ### Recipe A recipe is the shareable integration identity. It answers: - what integration definition is this?- what adapter produced it?- what family does it belong to? A recipe is meant to converge across workspaces when the underlying integration definition is the same. ### Revision / materialization A recipe revision is the compiled result of an import. It answers: - what source config produced this compiled shape?- what manifest, documents, schema bundles, and operations belong to it? This is the durable execution artifact layer. ### Operation IR Operations are the canonical callable tool index. They answer: - what tools exist?- how should they be searched and described?- how does invocation find the right persisted operation quickly? The operation layer exists because raw upstream documents are not a good direct query surface for search, policy, and invocation lookup. ### Credential Credentials are private auth bindings. They answer: - who can authenticate for this binding?- for which slot?- using what auth kind and secret refs? Credentials are actor-scoped by default because two users in the same workspace may connect different identities to the same source. ## Why the split matters This split fixes a few old problems: - shareable definition is no longer confused with workspace-local installation- auth is no longer implicitly one-token-per-source- materialized tool content is no longer stored directly under one workspace source- provider-specific import details do not need to become universal top-level columns ## Binding config Source-specific connection config now lives in adapter-owned binding payloads: - `bindingVersion`- `binding` That means the core model does not need built-in fields forever for every provider-specific connection knob. Examples: - OpenAPI binding can carry `specUrl` and `defaultHeaders`- MCP binding can carry `transport`, `queryParams`, and `headers`- internal bindings can be empty The adapter owns serialization, decoding, defaults, and validation for that payload. ## Families vs adapters Executor separates broad runtime families from adapter keys. Broad families: - `http_api`- `mcp`- `internal` Adapters are more specific: - `openapi`- `graphql`- `mcp`- future `google_discovery`- future `postman_collection`- future `snippet_bundle` This distinction keeps the runtime model broad and stable while still allowing importer-specific behavior. ## Why this is the right shape The current model is designed so that new support usually means: - add or evolve an adapter- compile into the same recipe/revision/operation layers and not: - redesign how source persistence fundamentally works That is the main goal of the current architecture.