Capability Closure, Not Lowest Common Denominator

A semantic control plane for existing infrastructure depends on abstraction. Experienced developers have good reason to be skeptical.

Many cross-provider abstractions begin by wrapping several APIs in one interface. The shared surface gradually shrinks to the behavior every provider supports in roughly the same way. Useful differences return as configuration flags, provider casts, or NotSupportedException at runtime.

Cohesive starts with what the user needs the system to do. It expresses a query, operation, or infrastructure need without SQL, an Elasticsearch request, or another provider language, then links possible interpretations and their evidence to the semantic system graph.

The Objection Is Correct About Most Abstractions

Suppose several providers are represented by one interface. The safest shared surface is their intersection. As providers are added, that intersection tends to shrink.

Important behavior then moves outside the abstraction. Transaction scope, ordering, consistency, traversal, replay, durable timers, ranking, idempotency, and provider-specific query behavior end up in adapter code or team memory. The interface still normalizes calls, but it may no longer carry enough meaning to choose or verify a realization.

Interfaces remain useful and can express strong contracts. The problem begins when a provider-shaped method surface becomes the source of meaning. Cohesive keeps the problem language upstream from provider APIs.

Start With What the System Needs

Cohesive defines semantic languages for classes of problems. Queries may describe predicates, relationships, projection, ordering, paging, ranking, and value semantics. Operations describe inputs, outcomes, completion, retries, duplicates, and ambiguous results. The expression carries relevant guarantees and defaults as well as the shape of a successful result. APIs can author or invoke it without becoming the source of meaning.

Each expression creates requirements tied to an exact occurrence and context. A provider name such as Elasticsearch identifies a product family. A target context must identify the relevant version, configuration, environment, and operating boundaries. Its profile supplies versioned capability assertions and evidence. The profile and applicable policy provide the rules for composition.

Capability analysis uses that evidence and declared, policy-permitted rules to issue per-requirement judgements and a closure report. Those decisions can then support a candidate realization. Infrastructure realization also requires lifecycle, placement, and physical evidence that the selected resources match the profile.

In programmer terms, the path is:

semantic expression -> requirements -> evidence + rules -> judgements -> candidate realization

What Capability Closure Does

For each demanded capability, analysis searches for a derivation from target evidence under applicable policy and admitted composition rules, then checks the candidate against the full requirement set, including obligations introduced by the composition. The selected mechanisms must work together with compatible assumptions and boundaries.

The semantic language can express requirements that no current target satisfies. Its vocabulary grows as new distinctions become relevant, while admitted rules derive further capabilities from those a target already supplies.

Closure is always relative to an exact semantic revision, configured target, policy, context, and body of evidence.

The resulting judgement uses a small set of primary outcomes:

A composed realization may also carry constraints. An authorized waiver or change to a requirement can let work proceed, but it does not prove the original requirement.

Cohesive moves integration work into reusable semantic and target definitions. A workload is expressed once, while provider interpretations are maintained by semantic family, target role, and relevant configuration. Stable service APIs can keep a contract stable while internal systems change. Cohesive makes that interpretation relationship explicit and reusable across system boundaries.

Operations Are More Than Methods

A conventional third-party integration often leaves operational behavior in comments, adapter code, and convention. Methods may exist even when a provider cannot preserve their implied behavior.

Cohesive defines an operation as a first-class semantic declaration with a stable identity, schemas, outcomes, and properties such as completion, timeout, retry, duplicate handling, and reconciliation. A provider binding connects a concrete mechanism to that declaration and states the conditions under which it preserves the required behavior.

The capability model can reason about an operation as soon as the required facts are available. Consider an illustrative notification contract: a committed order must leave a durable notification obligation, repeated delivery must apply the receiver's local transition at most once, and uncertain delivery must remain visible for reconciliation.

The producer commits the order and its outbox record together. Retries reuse the same message identity, and the receiver commits its inbox record with the local transition, retaining that record for the permitted replay window. Retry exhaustion leaves a durable unresolved obligation for reconciliation; a timeout alone cannot establish whether the receiver applied the transition.

Declared rules and evidence must justify every step, so a missing prerequisite leaves the requirement open. Longer response-dependent protocols can compose these operations.

A Search Migration Shows the Difference

A repository interface cannot anticipate every useful FindBy... method. A general query language may describe a much larger space using relational, graph, and search semantics.

The motivating historical example was a migration from Azure Search to Elasticsearch. In that work, provider-independent languages captured query and indexing behavior, including predicates, Boolean and string search, projection, ordering, paging, and ranking. The current Relations package does not include an Azure Search target.

For that workload, the Elasticsearch target could realize nearly all of the demanded behavior directly. The reverse move would have exposed missing capabilities or evidence, necessary constraints, possible compositions, and tradeoffs requiring approval. That result is demand-scoped and asymmetric, not a universal ranking of the two providers.

An illustrative query makes the decision concrete: return the first 20 matching records, ordered by priority descending and unique ID ascending, from one consistent snapshot. The following cases assume that filtering and comparison semantics match the query's definitions.

If source completeness is merely undocumented, the judgement is unknown. Accepting a partial result would change the requirement. The original query remains available to targets that can preserve it.

The planner applies feature negotiation and query planning across supported database and search profiles. Its current scope is specific native lowerings and bounded source acquisition or local stages, with each decision tied to the original requirements.

A general language can name null behavior, collation, precision, ranking, graph paths, paging, and snapshot semantics. Naming them does not make every translation valid. A target must provide evidence for the exact behavior, a composition must preserve it, or the result must carry a constraint or gap.

Expressibility, semantic realizability, and operational fitness are separate questions. A semantically valid plan may still move too much data or violate an operating limit. Composition therefore remains subject to explicit bounds, tests, admission policy, and runtime observation.

What the Abstraction Owes You

Capability closure is an engineering discipline with an explicit scope.

• Coverage is explicit. A report analyzes requirements within the modeled scope, including declared and binding-derived requirements. Opaque dependencies and distinctions outside the language remain outside its claim.
• Profiles must earn trust. Evidence is specific to a version, configuration, and boundary. Placement evidence, runtime receipts, and observations establish later facts about selected resources and executions.
• Composition needs controls. Semantic correctness does not establish acceptable latency or cost. Plans need bounds, tests, admission policy, and runtime observation.
• Shared semantics need distributed ownership. Versioned modules, stable identities, and extension rules let domain languages and provider profiles evolve without one central provider switch.
• Analysis does not grant external authority. Deployment and other external mutations require separate authority. Provider-specific escape hatches and waived requirements need explicit policy, and their effect on assurance stays visible.

For each requirement, Cohesive should show the proposed mechanism, the evidence behind it, the conditions that apply, and any gap that remains.