tegwick
c2cfe86d88
Adds the repository structure, INTENT.md declaring the wire-contract boundary, and seven workplans covering Blueprint Phases A-C plus the fluid-telegram handover. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014KmVxhJ35tCo7rE7UnLwWu Assistant: claude-code Assistant-Model: opus Assistant-Process: 1116572@bnt-lap001 Assistant-Session: 8ba9bb93-a72a-4883-b189-2499cce5c400
85 lines
3.3 KiB
Markdown
85 lines
3.3 KiB
Markdown
---
|
|
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.
|