fluid-core/INTENT.md

project	product	status	intent_version	date	standard	standard_version
fluid-core	FLUID	draft	0.1.0	2026-09-04	FluidAPIStandards	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.