Cohesive Infra

Cohesive.Infra is the forthcoming Cohesive block for defining application infrastructure as a semantic intermediate representation.

It lets teams describe the infrastructure a system needs - compute, storage, databases, caches, buses, configuration, secrets, service bindings, and runtime topology - without immediately committing those definitions to one deployment tool or platform.

The goal is not to replace infrastructure platforms. The goal is to make infrastructure another interpretation of the same Cohesive system model.

Infrastructure as Semantics
What Cohesive.Infra Defines
Integration with Cohesive.Configuration
Integration with the Cohesive Stack
Capability-Aware Adapters
System Definition, Not Deployment Glue
Example Shape of a System
Lowering Targets
Local development: Aspire
Cloud provisioning: Pulumi
Container orchestration: Kubernetes
Distributed runtime: Orleans
Why It Matters
The Cohesive.Infra Principle

Infrastructure as Semantics

Modern systems often define application behavior in one place and infrastructure behavior somewhere else:

Application configuration in code.
Local development resources in Docker Compose.
Cloud resources in Pulumi or Terraform.
Service discovery in Aspire.
Runtime orchestration in Kubernetes.
Distributed execution in Orleans.
Storage and messaging details in adapter-specific setup.

Cohesive.Infra provides a single semantic layer for describing the resources, dependencies, bindings, and capabilities that make the system run.

That infrastructure model can then be lowered into concrete targets such as:

Aspire for local and cloud-native application composition.
Pulumi for cloud infrastructure provisioning.
Docker Compose for local and lightweight deployment environments.
Kubernetes for container orchestration.
Orleans for distributed application runtime and virtual actor hosting.

Each target becomes an interpreter of the infrastructure IR.

What Cohesive.Infra Defines

Cohesive.Infra models the major infrastructure concerns of an application system:

Compute: services, workers, jobs, processes, sidecars, and runtime roles.
Storage: blob stores, object stores, tables, document stores, search indexes, and event streams.
Databases: relational, document, graph, analytical, and specialized database resources.
Caches: distributed caches, local caches, cache policies, and cache placement.
Buses: queues, topics, subscriptions, event streams, commands, and outbox targets.
Configuration: profiles, environment bindings, secrets, feature switches, and dependency activation.
Networking: service references, endpoints, ingress, internal routes, and exposed ports.
Identity boundaries: tenant scopes, service identities, grants, permissions, and resource access.
Observability: logs, metrics, traces, health checks, and diagnostic surfaces.

The IR describes what the system needs and how the parts relate. Adapters decide how those needs are realized on a specific platform.

Integration with Cohesive.Configuration

Cohesive.Infra is designed to work directly with Cohesive.Configuration.

Configuration profiles can select:

Which infrastructure backend is active.
Which resources are bound in development, test, staging, or production.
Which adapters are activated.
Which dependencies are local, emulated, hosted, or externally supplied.
Which secrets, endpoints, connection strings, and service identities are required.

This makes infrastructure selection part of the same configuration and dependency activation system used by the application.

For example, the same semantic system definition could run with:

Docker Compose resources in local development.
Aspire service composition for inner-loop orchestration.
Pulumi-managed cloud resources in staging and production.
Kubernetes deployment for containerized workloads.
Orleans clustering for distributed entity or process execution.

The system definition remains stable while the interpretation changes by profile and target.

Integration with the Cohesive Stack

Cohesive.Infra becomes more powerful when used with the other Cohesive blocks.

Cohesive.Storage can declare repositories, queries, change feeds, outboxes, and event-sourced models, while Cohesive.Infra declares the backing stores and placement rules.
Cohesive.Identity can define scopes, grants, permissions, service identities, and tenant boundaries that affect resource access and partition placement.
Cohesive.Api can define API surfaces while Cohesive.Infra declares hosting, endpoints, ingress, service discovery, and transport bindings.
Cohesive.Processes can define workflows while Cohesive.Infra declares durable execution backends, queues, timers, and event channels.
Cohesive.Entities can define transitions and effects while Cohesive.Infra declares the buses, stores, caches, and compute targets those effects use.
Cohesive.Presentation can define UI surfaces while Cohesive.Infra declares web hosting, static assets, APIs, and environment bindings.
Cohesive.AI can define training, inference, evaluation, model artifacts, and numerical workloads while Cohesive.Infra declares GPUs, artifact stores, queues, caches, and model-serving targets.
Cohesive.Cli can expose operational commands against the same configured infrastructure model.

Together, these blocks allow a complete system to be defined from semantics outward.

Capability-Aware Adapters

Cohesive.Infra does not flatten every target into the smallest shared feature set.

Each adapter exposes the capabilities of the system it targets:

Aspire can expose service composition, resource references, health checks, and local orchestration capabilities.
Pulumi can expose cloud provider resources, provisioning lifecycle, stack outputs, and infrastructure policy.
Docker Compose can expose containers, volumes, networks, ports, and local dependency graphs.
Kubernetes can expose deployments, services, ingress, config maps, secrets, jobs, autoscaling, and scheduling behavior.
Orleans can expose clustering, grains, streams, reminders, placement, and distributed execution capabilities.

The Cohesive.Infra IR can target shared semantics while still preserving platform-specific power through capability models and adapter extensions.

When a target cannot faithfully support a requested capability, the compiler can emit diagnostics instead of silently lowering the system into an incomplete configuration.

System Definition, Not Deployment Glue

Cohesive.Infra treats infrastructure as part of the system definition.

That means infrastructure is not just a deployment artifact. It is connected to:

The entities that require state.
The transitions that emit effects.
The processes that need durable execution.
The APIs that expose operations.
The identity scopes that control access.
The storage bindings that determine placement.
The configuration profiles that select dependencies.
The AI workflows that require compute and artifact storage.

This gives engineering teams a clearer path from domain model to running system.

Example Shape of a System

A Cohesive.Infra definition might describe a system in terms like this:

public sealed partial class OrderPlatformInfra : InfraDefinition
{
    public override void Define(IInfraBuilder infra)
    {
        var api = infra.Service("orders-api")
            .UsesConfigurationProfile("Production")
            .ExposesHttp(port: 443)
            .RequiresIdentityScope(OrderIdentity.Scopes.Tenant)
            .UsesDatabase("orders-db")
            .UsesCache("orders-cache")
            .PublishesTo("order-events");

        var worker = infra.Service("orders-worker")
            .RunsProcess<OrderFulfillmentProcess>()
            .ConsumesFrom("order-events")
            .UsesDatabase("orders-db")
            .UsesOutbox("orders-outbox");

        infra.CosmosDatabase("orders-db")
            .PartitionedBy(OrderStorage.Placement.TenantAndOrder)
            .SupportsQueries(OrderStorage.Queries.OrderReadModels);

        infra.RedisCache("orders-cache")
            .UsedBy(api)
            .WithProfileOverride("Development", cache => cache.UseLocalContainer());

        infra.Topic("order-events")
            .Carries<OrderSubmitted>()
            .Carries<OrderFulfilled>();
    }
}

The exact authoring syntax will evolve with the module, but the intent is stable: define the system topology semantically, then lower it into the infrastructure target that fits the environment.

Lowering Targets

The same infrastructure IR can support different deployment and orchestration targets.

Local development: Aspire

For local development:

infra.CompileToAspire();
infra.CompileToDockerCompose();

Cloud provisioning: Pulumi

For cloud provisioning:

infra.CompileToPulumi(stack: "production");

Container orchestration: Kubernetes

For container orchestration:

infra.CompileToKubernetes(environment: "production");

Distributed runtime: Orleans

For distributed runtime composition:

infra.CompileToOrleans(cluster: "orders-prod");

The purpose is not to pretend these targets are identical. The purpose is to let one semantic model guide multiple concrete interpretations.

Why It Matters

Cohesive.Infra helps teams avoid a common failure mode: the application model and the infrastructure model slowly becoming separate systems.

When that happens, teams pay for it through:

Fragile deployments.
Duplicated configuration.
Environment drift.
Unclear ownership of resource dependencies.
Hidden coupling between services and infrastructure.
Manual translation between application semantics and platform resources.

Cohesive.Infra addresses that by making infrastructure declarative, capability-aware, and connected to the rest of the Cohesive stack.

The outcome is software that is easier to build, easier to deploy, easier to scale, and easier to evolve.

The Cohesive.Infra Principle

Define the system once.

Describe what it needs to run.

Preserve the capabilities of each infrastructure target.

Lower the semantic model into the platforms that operate it.

Cohesive.Infra turns infrastructure from disconnected deployment glue into a systematic interpretation of the application model.