Platform Model

Gestalt has a small number of primitives, but they compose into a full integration platform. The easiest way to understand gestaltd is to follow the startup path from configuration to invocation.

The Core Model

At the highest level, gestaltd loads a declarative config file, bootstraps the platform components that config names, builds providers from providers:, and exposes those providers through shared request surfaces.

The Main Primitives

Bootstrap Order

This is the actual shape of startup:

1. Load YAML from the resolved config path.
2. Expand ${ENV_VAR} placeholders.
3. Apply defaults such as server.port: 8080 and secrets.provider: env.
4. Resolve connection auth and inherited parameters.
5. Fill redirect URLs from server.base_url when possible.
6. Resolve relative paths against the config file directory.
7. Validate the config.
8. Build the secret manager.
9. Resolve secret://... references.
10. Build the platform auth provider.
11. Build the datastore.
12. Build providers from providers.
13. Build the shared invocation broker.
14. Build bindings.
15. Start the HTTP server, then start bindings once providers are ready.

Integrations Become Providers

An integration is a declarative definition. A provider is the executable object built from it.

That distinction matters:

• you edit providers.<name> in YAML
• gestaltd turns that entry into a provider at startup
• every request surface invokes the provider, not the raw YAML

Providers come from three sources:

A packaged plugin can also layer in spec-backed surfaces, which is how hybrid providers work.

Connection Resolution

Gestalt resolves credentials through connections.default plus any optional named connections.

• connections.default is the primary connection
• connections.<name> defines additional named connections
• only connections.default can carry params and discovery
• each configured surface chooses its connection explicitly when needed

Each connection has one mode:

If an integration has more than one stored connection for the chosen subject, callers must specify an instance. If there is exactly one, Gestalt selects it automatically.

The Shared Invocation Broker

Every execution path in Gestalt goes through the same invocation broker.

The broker is responsible for:

• locating the target provider and operation
• resolving credentials based on connection mode
• choosing an instance when multiple connections exist
• refreshing expiring OAuth tokens
• injecting connection metadata into execution context
• returning normalized operation results

Because this broker is shared, the same token and policy behavior applies whether the caller is the web UI, a direct HTTP client, an MCP client hitting /mcp, a webhook binding, or a proxy binding.

Surfaces Built On Top

Once providers exist, gestaltd projects them into several surfaces:

What You Actually Program Against

As a Gestalt operator, you compose top-level config blocks, provider definitions, connection definitions, surface definitions, binding definitions, egress rules, and optional plugin manifests and packages. Everything else is a consequence of those inputs.