---
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 broad catalog kind 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.

## Catalog kinds vs adapters

Executor separates broad catalog kinds from adapter keys.

Catalog kinds:

- `imported`
- `internal`

Adapters are more specific:

- `openapi`
- `graphql`
- `mcp`
- `google_discovery`
- future `postman_collection`
- future `snippet_bundle`

The important distinction is that execution now belongs to adapters. The shared catalog stays broad and stable, while connect/auth/invoke behavior is described through adapter strategies instead of one top-level runtime family enum.

## 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.