---
project: fluid-core
product: FLUID
status: draft
intent_version: 0.1.0
date: 2026-09-04
standard: FluidAPIStandards
standard_version: 0.1.0
---

# INTENT.md — fluid-core

> **FLUID envisions interfaces that learn when they should change, why, how to
> test the change, and whether the result deserves to become part of their
> evolving contract.**

## 1. Repository intent

`fluid-core` exists to make FLUID — *Flow Utilizing Interface Daimon* —
executable. It is the reference framework for operating deterministic service
interfaces inside a governed evolutionary control loop.

The framework's defining commitment is stated in `spec/FluidAPIStandards.md` §3:

> **Deterministic execution, adaptive evolution.**

The production request path stays deterministic and auditable. Observation,
analysis, hypothesis formation, experimentation and promotion happen *around*
the interface, never inside the request path.

## 2. What this repository owns

- the deterministic data plane: gateway, revision resolver, revision router,
  contract validation, backend connectors, response policy, telemetry emission;
- the observation plane: telemetry ingest, redaction, cohorts, interaction
  topology, pressure classification;
- the evolution control plane through Blueprint Phase C: pressure registry,
  hypothesis records, experiment control, fitness evaluation, promotion
  decisions;
- the evidence, artifact and intent stores;
- the wire contract by which any interface, in any language, becomes FLUID.

## 3. What this repository does not own

- the interfaces themselves — those live in consumer repositories
  (`fluid-telegram`, `fluid-x`, `fluid-substack`);
- backend systems reached through connectors;
- the Daimon's generative capability (Blueprint Phase D), deliberately deferred
  until real telemetry exists for it to learn from.

## 4. The boundary is a wire contract

fluid-core is integrated **out of process**. A target API contributes no code,
imports no library, and may be written in any stack. Integration happens through
four artifacts:

1. the revision descriptor (Blueprint §36);
2. the routing policy (Blueprint §17);
3. the telemetry envelope;
4. the control APIs (Blueprint §44).

Any change that leaks Go types across this boundary is a design failure. This
constraint is what allows adapters, Daimons and future gateways to be written in
whatever language suits them.

## 5. Governing invariants

The sixteen architectural invariants in `spec/ArchitectureBlueprint.md` §55 are
constitutional for this repository. The four that most often get eroded and must
be defended hardest:

- **Runtime behavior remains deterministic.** No LLM in the mandatory request path.
- **Evolution can stop without stopping the API.** Every control-plane component
  must be killable in production with no runtime effect.
- **AI-generated artifacts are untrusted until verified.** The deterministic
  policy gate is not advisory.
- **Backend authority does not leak into the interface Daimon.** Missing backend
  capability is escalated as a structured requirement, never taken.

## 6. Success

`fluid-core` succeeds when an interface owner can put an existing API behind it
without modifying that API, and then answer — from evidence, months later — the
eleven auditability questions in `spec/FluidAPIStandards.md` §25 about any change
the interface underwent.