Thin Boundary

Share governed capabilities while letting teams compose the behaviour their work requires.

Context.

A procurement team wants to add delivery-history evidence to a contract assessment. The organisation already supplies model access, retrieval, identity, validation, and lineage. Today, adding one evidence source means asking the central AI team to alter a shared endpoint and schedule a release.

The shared infrastructure is useful. The release dependency is the problem. Procurement knows why delivery history matters; the platform team knows how to secure and meter access. Neither team should have to absorb the other's entire job.

Problem.

A boundary becomes thick when it owns both reusable infrastructure and every local workflow decision. Prompts, retrieval choices, task ordering, and domain rules accumulate behind one endpoint. Teams cannot improve their work without joining the same queue, so exceptions and private integrations multiply.

Simply distributing credentials would remove the queue by removing governance. The useful alternative is to distribute composition while retaining enforceable limits on data, models, costs, and effects. Thin describes the amount of shared business behaviour a team must negotiate, not the strength of the boundary.

Forces.

• Shared identity, approved model access, metering, and evidence capture have economies of scale.
• Domain knowledge and workflow changes belong close to the people doing the work.
• Local autonomy must not permit weaker access controls, omitted lineage, or bypassed mutation gates.
• Capabilities evolve independently; consumers need compatibility rules and time to migrate.
• A composition can multiply calls and failure paths even when each capability is individually well behaved.

Pattern.

Expose a small set of governed capabilities with explicit contracts. Examples include authorised retrieval, bounded model invocation, proposal validation, and approved mutation. A domain team composes these into Steps and States using its own versioned workflow definition. The centre owns the primitives and minimum constraints; the team owns the task and its domain behaviour.

Treat the Control Plane as a responsibility distributed across trusted components, not necessarily a central workflow designer. A team can choose among allowed models or evidence sources in its configuration. Trusted enforcement decides whether that choice is permitted for the caller, tenant, and data classification. No local configuration can grant authority it does not possess.

Keep common invariants in capability contracts: identity propagation, data scope, policy enforcement, lineage references, resource limits, and explicit errors. Put domain-specific questions in domain code. A shared inference capability need not know what makes a delivery clause acceptable. It must know how to invoke an allowed model within the authorised budget and return a candidate under the declared output contract.

This follows service contracts and separation of concerns. David Parnas's 1972 paper on decomposing systems into modules argues for hiding design decisions behind module boundaries. Applied here, the model adapter hides provider mechanics while the local workflow owns business decisions. The runtime/control separation illustrated by Istio also shows why shared policy need not imply a single component executing all work.

Implementation.

Give procurement a retrieval capability scoped to approved vendor records. This illustrative YAML is the published contract and grant for that capability. It is not a complete access-control implementation, and the example limits require measurement.

capability: procurement.evidence.read
contract_version: 2
provider_owner: data-platform
consumer_owner: procurement
input_schema: VendorEvidenceRequest.v2
output_schema: VendorEvidenceBundle.v2
grant:
  audience: procurement-workflows
  tenant_binding: caller
  sources: [contract_clauses, delivery_history]
  fields: [vendor_id, clause_text, delivery_date, delay_days]
  maximum_records: 20
  direct_credentials: false
policy:
  baseline: enterprise-data.v5
  domain: procurement-access.v3
  local_rules_may_only_restrict: true
lineage:
  required: [workflow_id, step_id, parent_event_ids]
  return: [event_id, evidence_manifest_ref]
limits:
  deadline_ms: 250
  maximum_calls_per_workflow: 3
  on_exhaustion: explicit_failure
errors: [denied, unavailable, deadline_exceeded, incompatible]
compatibility:
  supported_major_versions: [2]
  breaking_change: new_major_version

The procurement team changes its local workflow from revision 7 to revision 8. Revision 8 requests delivery history through this contract, compiles it with contract clauses, and invokes the existing assessment capability. The retrieval service authenticates the caller, checks vendor scope, applies both baseline and domain policy, and returns an evidence manifest with its lineage event. A declared source in YAML does not itself confer access.

The team updates its prompt and semantic validator together, then evaluates the new workflow using retained examples with external effects disabled. It records the retrieval contract, workflow, template, validator, and policy versions. If results justify deployment, the team can release its composition without changing the central endpoint. A request for a new source or broader field access remains an explicit grant change owned by the appropriate authority.

The platform provides contract checks and a reference client, but the server enforces mandatory controls. Consumers that bypass the client still face the same authorisation and budgets. Capability discovery returns only authorised choices; it does not expose unrestricted credentials. The domain team may add stricter checks, never remove the baseline airlock.

Define compatibility beyond field shape. Changing an evidence field from calendar days to business days changes meaning even if its type remains a number. Publish a new major contract where semantics break, support a declared overlap window, and identify consumers through lineage. Emergency revocation can override that window; document who can invoke it and what callers receive.

Budget the composition as well as each capability. A retrieval deadline of 250 milliseconds does not make three sequential calls fit a 250-millisecond workflow. Propagate the remaining deadline and reserve limits across concurrent branches. Stop retries when the workflow budget is spent. Return unavailable or incomplete explicitly instead of quietly dropping required evidence.

Agree incident ownership before deployment. The capability owner restores shared service; the domain owner decides whether its workflow can operate with reduced optional evidence. Mandatory evidence or policy failures stop the affected step. A fallback model must already meet the same data and contract requirements.

Consequences.

Teams gain a shorter path from a domain insight to a tested workflow change. Shared infrastructure stays reusable because it does not absorb every local exception. The organisation can govern which capabilities exist while teams decide how to arrange the capabilities they are allowed to use.

The price is explicit coordination. Contract migrations, grant reviews, and incident boundaries create organisational friction. More capability calls can add network latency and repeated validation. Each composition produces lineage and version metadata that consumes storage. Platform operators need compatibility checks, usage visibility, and fair capacity allocation; domain teams need ownership of their evaluations and rollback procedures.

Too many tiny capabilities make composition harder to understand and operate. Group operations around useful, stable responsibilities, then measure the whole workflow. A thin boundary is successful when ordinary domain changes remain local while changes in authority remain visible and deliberate.

Anti-patterns.

The universal endpoint. Every workflow option becomes another central parameter. Expose stable capabilities and move the sequence of domain decisions into owned compositions.

Bring your own governance. Local teams receive provider keys and promise to record evidence later. Enforce identity, lineage, budgets, and airlocks at the capability service.

The shared library mandate. Every consumer must upgrade immediately whenever the platform changes. Version the service contract and give consumers a defined migration path.

Test.

Ask a domain team to change a prompt, reorder permitted steps, and add an already authorised evidence source without modifying a central endpoint. Then ask it to bypass lineage, read another tenant's records, or weaken a mutation gate. The first set should be a local evaluated release; the second should fail under service enforcement. If either side behaves otherwise, the boundary needs work.

Related.

Thin Boundary names the alternative to the central bottleneck in The AI Mainframe Trap. It distributes the composition of Vertical AI Foundation while preserving Control Plane vs. Execution Plane, AI Airlocks, and Causal Lineage. Shared capability ownership and local workflow ownership are complementary duties of stewardship.