# ADR-0002 — Out-of-process attachment

**Status:** accepted · **Date:** 2026-09-04

## Context

A FLUID interface has to be able to wrap an existing API. The question is
whether fluid-core is a library that API imports, or a process that sits in
front of it.

Blueprint §42 already answers this implicitly: `gateway`, `revision-router` and
`adapter-r41`/`adapter-r42` are separate deployments. That is process-level
integration, not library-level.

## Decision

fluid-core attaches out of process. The gateway and router run in front of
adapter processes reached over the network. The target API contributes no code,
imports no library, and may be written in any stack.

An in-process SDK is explicitly deferred, not rejected. It would buy richer
signal — call-sequence correlation and structured consumer feedback that a
proxy cannot see from outside — at the cost of SDK versioning across languages.

## Rationale

Minimal conformance (`FluidAPIStandards.md` §36) requires a deterministic
contract, revision identity, telemetry, declared intent, an evidence link,
responsibility boundaries and deterministic security. Every one of those is
observable from the proxy. Nothing in the conformance core needs to be inside
the target process.

The language-agnostic promise is only credible if the framework never asks for
an import. Making the SDK optional from the start, rather than retrofitting the
proxy later, is what keeps that true.

## Consequences

- The revision descriptor carries `runtime.upstream`: the adapter's address.
- Interaction topology (Blueprint §6.4) is reconstructed from correlation IDs
  observed at the gateway, not reported by the consumer.
- Explicit feedback (`FluidAPIStandards.md` §15) arrives over the wire as its
  own endpoint rather than through an SDK call.