fluid-core/spec/FluidAPIStandards.md

FLUID API Standards

Document: FluidAPIStandards.md
Version: 0.1.0
Status: Working Standard
Framework: FLUID — Flow Utilizing Interface Daimon

---

1. Scope

This document defines the normative core of FLUID APIs.

FLUID is a framework for operating deterministic service interfaces inside a governed evolutionary control loop. A FLUID API may observe usage, detect interface pressure, formulate hypotheses, construct candidate interface revisions, evaluate them, and promote or retire revisions according to explicit policy.

FLUID does not require runtime AI inference for normal request processing. The active interface remains deterministic; adaptation occurs around the interface.

This document standardizes:

• core terminology;
• architectural boundaries;
• deterministic runtime invariants;
• interface revisions;
• telemetry and interface pressure;
• consumer cohorts;
• hypothesis-driven evolution;
• fitness and optimization;
• complexity governance;
• compatibility and migration;
• operational authority modes;
• security and auditability;
• backend capability escalation;
• conformance requirements.

The following remain intentionally implementation-defined in v0.1:

• telemetry transport;
• persistence technology;
• scoring algorithms;
• traffic-splitting technology;
• AI model choice;
• deployment platform;
• API protocol or style.

A FLUID interface MAY expose REST, GraphQL, RPC, event, messaging, streaming, tool, or other machine-facing interface styles.

---

2. Normative Language

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, and OPTIONAL are to be interpreted as normative requirements.

Where this standard describes an implementation pattern without using normative language, the text is informative.

---

3. Core Principle

The defining FLUID principle is:

Deterministic execution, adaptive evolution.

A FLUID interface MUST expose one or more identifiable deterministic interface revisions.

The evolutionary system MAY use probabilistic or agentic techniques to:

• analyze telemetry;
• detect patterns;
• generate hypotheses;
• design candidate revisions;
• generate adapter code;
• generate tests;
• evaluate outcomes;
• recommend migration;
• recommend optimization preferences.

Probabilistic mechanisms MUST NOT silently replace deterministic:

• authentication;
• authorization;
• tenancy boundaries;
• policy enforcement;
• contractual API semantics;
• security constraints.

---

4. FLUID Daimon

The FLUID Daimon is the active caretaker of a FLUID interface.

The Daimon is responsible for the interface evolution loop within explicitly granted authority.

A Daimon MAY perform:

1. observation;
2. pressure detection;
3. classification;
4. hypothesis generation;
5. candidate design;
6. implementation generation;
7. verification;
8. controlled experimentation;
9. fitness evaluation;
10. migration planning;
11. backend capability escalation;
12. promotion or retirement where authorized.

The Daimon MUST operate within explicit interface intent and governance constraints.

---

5. Responsibility Boundary

A FLUID interface owns the interface and adapter layer.

It MAY:

• expose backend capabilities;
• compose multiple backend capabilities;
• reshape representations;
• introduce interface-level abstractions;
• improve discoverability;
• improve validation and error feedback;
• optimize adapter implementation;
• create new interface revisions;
• define requirements for unavailable backend capabilities.

A FLUID interface MUST NOT assume authority to modify backend systems merely because the interface requires new capability.

Where a candidate interface requires unavailable backend functionality, the FLUID implementation SHOULD emit a structured backend capability requirement.

The backend remains responsible for accepting, rejecting, constraining, or declaring the request out of scope.

---

6. Interface Intent

Every FLUID interface MUST have declared evolutionary intent.

The parent service or repository MAY use a general INTENT.md. FLUID MUST NOT redefine that schema.

A FLUID interface SHOULD reference a dedicated:

InterfaceEvolutionIntent.md

This document defines the constitutional boundary of interface evolution.

At minimum it SHOULD define:

• mission;
• intended consumers;
• capability domain;
• non-goals;
• responsibility boundaries;
• optimization preferences;
• complexity constraints;
• compatibility policy;
• autonomy policy;
• quality requirements;
• economic constraints.

The Daimon MAY recommend changes to interface intent.

The Daimon MUST NOT silently redefine its own intent.

---

7. Deterministic Runtime Invariant

For a given:

• interface revision;
• request;
• authenticated identity;
• authorization state;
• deterministic configuration;
• relevant backend state;

the interface MUST behave according to its declared contract.

Normal request handling MUST NOT depend on an LLM or other probabilistic mechanism inventing undefined semantics.

Experimental dynamic fulfillment is outside the FLUID v0.1 conformance core.

---

8. Interface Revision

Every production mutation of a FLUID interface MUST result in an identifiable revision.

A revision MUST have:

• revision identifier;
• parent revision or genesis marker;
• contract reference;
• implementation reference;
• creation time;
• provenance;
• compatibility declaration;
• verification status.

A revision SHOULD additionally contain:

• originating hypotheses;
• expected fitness effects;
• measured fitness;
• deployment history;
• consumer cohort exposure;
• promotion state;
• rollback information;
• associated backend requirements;
• complexity impact.

Published revisions SHOULD be immutable.

Corrections SHOULD create successor revisions.

---

9. Concurrent Revisions

A FLUID implementation MAY expose multiple revisions concurrently.

Example:

Revision 21  stable      62% traffic
Revision 22  candidate   28% traffic
Revision 23  experiment  10% traffic

Concurrent revisions MAY be used for:

• controlled experiments;
• cohort-specific interfaces;
• gradual migration;
• compatibility support;
• fitness comparison;
• rollback protection.

Traffic allocation MUST be governed deterministically.

The basis for assigning a consumer to a revision SHOULD be auditable.

---

10. Evolution Velocity

FLUID SHOULD treat the rate of change as a controllable system variable.

Signals that MAY influence evolution velocity include:

• hypothesis success rate;
• regression rate;
• reliability trend;
• support burden;
• adoption rate;
• migration success;
• failed experiments;
• available review capacity;
• economic budget;
• operational risk.

A FLUID implementation MAY accelerate, maintain, slow, or freeze adaptation activity according to policy.

Evolution velocity MUST NOT override deterministic safety constraints.

---

11. Compatibility Model

FLUID v0.1 follows:

Versioned evolution aiming toward managed migration.

Compatibility preservation is important but is not an absolute prohibition against redesign.

A FLUID implementation SHOULD support a lifecycle similar to:

detect weakness
→ formulate replacement
→ introduce successor revision
→ allow coexistence
→ observe adoption
→ guide migration
→ deprecate predecessor
→ retire when justified

Breaking changes MUST be explicit.

Breaking changes MUST NOT silently alter an already published revision.

---

12. Interface Telemetry

FLUID telemetry extends conventional API monitoring.

A FLUID implementation SHOULD be capable of observing relevant signals from:

• successful calls;
• failed calls;
• invalid requests;
• near-miss requests;
• call sequences;
• redundant round trips;
• repeated client-side transformations;
• latency;
• backend failures;
• authorization failures;
• unused capabilities;
• discoverability failures;
• explicit consumer feedback;
• agent/tool usage;
• revision adoption;
• migration behavior.

Telemetry MUST respect:

• privacy constraints;
• tenancy boundaries;
• retention policy;
• data minimization;
• contractual restrictions;
• security policy.

Telemetry collection SHOULD be sufficient to support interface evolution without becoming an unrestricted surveillance layer.

---

13. Interface Pressure

Interface pressure is evidence that the interface differs materially from the needs, expectations, or natural interaction patterns of its consumers.

Initial standard pressure classes are:

1. successful natural usage;
2. successful but inefficient usage;
3. recoverable misunderstanding;
4. repeated expectation mismatch;
5. poor discoverability;
6. missing interface capability;
7. missing backend capability;
8. out-of-scope demand;
9. prohibited demand;
10. implementation failure.

Pressure is evidence, not truth.

Repeated consumer behavior MUST NOT automatically redefine interface intent.

---

14. Consumer Cohorts

FLUID SHOULD support consumer cohort analysis where appropriate.

Possible cohorts include:

• human developers;
• browser applications;
• mobile applications;
• legacy integrations;
• internal services;
• external partners;
• coding agents;
• autonomous agents;
• contract versions;
• commercial plans;
• organizational tenants.

Cohorts SHOULD be sufficiently coarse to avoid unnecessary identification where aggregate analysis is adequate.

Cohort analysis MAY be used to evaluate:

• adoption;
• friction;
• fitness;
• migration;
• feature demand;
• reliability;
• cost;
• commercial product behavior.

Commercial use MUST remain subordinate to privacy, contractual, and governance constraints.

---

15. Explicit Consumer Feedback

A FLUID interface SHOULD support optional structured feedback from consumers.

Feedback MAY express:

• intended goal;
• attempted operation;
• expected capability;
• actual outcome;
• workaround;
• desired capability;
• operational impact.

Example:

{
  "goal": "retrieve the latest invoice",
  "attempt": "GET /customers/4711/invoices/latest",
  "outcome": "capability unavailable",
  "workaround": "query all invoices, sort locally, take first",
  "impact": "extra requests and client-side logic"
}

Explicit feedback MUST be treated as evidence.

It MUST NOT itself authorize interface changes.

---

16. Adaptation Classes

FLUID defines the following initial adaptation classes.

16.1 Presentation Adaptation

Changes how existing capabilities are explained or discovered.

Examples:

• documentation;
• examples;
• error messages;
• schema annotations.

16.2 Contract Adaptation

Changes externally exposed API semantics or surface.

Examples:

• endpoint;
• field;
• operation;
• query;
• mutation;
• resource representation.

16.3 Composition Adaptation

Changes how existing backend capabilities are combined.

16.4 Implementation Adaptation

Changes adapter implementation without intended semantic change.

Examples:

• caching;
• batching;
• routing;
• serialization.

16.5 Requirement Escalation

Defines missing capability that belongs outside the FLUID interface responsibility boundary.

Implementations MAY introduce additional adaptation classes.

---

17. Scientific Adaptation Method

A nontrivial FLUID adaptation SHOULD originate from an explicit hypothesis.

A hypothesis SHOULD define:

• observation;
• problem statement;
• explanatory claim;
• proposed adaptation;
• expected outcome;
• measurement method;
• success criteria;
• guardrails;
• risk;
• complexity impact;
• implementation cost;
• expected learning value.

The adaptation lifecycle SHOULD follow:

observe
→ classify
→ hypothesize
→ prioritize
→ design
→ construct
→ verify
→ experiment
→ measure
→ criticize
→ retain / modify / reject

A hypothesis MUST be falsifiable or otherwise evaluable against explicit evidence.

---

18. Hypothesis Reach

FLUID SHOULD distinguish local fixes from higher-reach hypotheses.

A high-reach hypothesis explains multiple observations through one coherent abstraction.

Example:

Low reach:
Add six convenience endpoints.

Higher reach:
The interface lacks a coherent customer financial context abstraction.

Candidate prioritization MAY consider:

• expected impact;
• confidence;
• explanatory reach;
• implementation cost;
• complexity cost;
• reversibility;
• risk;
• learning value;
• number of affected cohorts.

Reach does not imply correctness.

It is a prioritization signal.

---

19. Competing Hypotheses

FLUID SHOULD support multiple competing hypotheses.

Where practical, hypotheses MAY be compared through:

• offline analysis;
• replay;
• simulation;
• test environments;
• shadow traffic;
• canary traffic;
• parallel revisions;
• consumer studies.

The Daimon SHOULD preserve uncertainty where evidence is insufficient.

---

20. Fitness

Fitness describes how well an interface revision fulfills intended purpose.

Standard fitness dimensions are:

• client utility;
• correctness;
• reliability;
• availability;
• performance;
• discoverability;
• simplicity;
• compatibility;
• security;
• maintainability;
• operational cost;
• implementation cost;
• resource consumption.

Implementations MAY add dimensions.

The standard does not define one universal scalar fitness function.

---

21. Optimization Preferences

A FLUID interface MUST support explicit optimization preferences.

Example:

client utility      HIGH
reliability         HIGH
simplicity          MEDIUM
latency             MEDIUM
cost                LOW

Optimization preferences MAY change by operational phase.

Common regimes MAY include:

• EXPLORATION;
• ADOPTION;
• UTILITY;
• PERFORMANCE;
• RELIABILITY;
• SECURITY;
• COST;
• CONSOLIDATION;
• MIGRATION.

Operator-selected regimes are acceptable.

Mature FLUID implementations SHOULD support automatic optimization recommendations.

Where sufficient evidence and governance exist, automatic optimization SHOULD be the default operational convenience model, subject to operator override.

---

22. Complexity Governance

Complexity is a constrained resource.

Standard complexity dimensions are:

• surface area;
• concept count;
• operation count;
• parameter dimensionality;
• semantic overlap;
• alternative-path count;
• dependency count;
• backend composition count;
• exception count;
• active revision count;
• consumer cognitive load.

Implementations SHOULD measure relevant dimensions.

Implementations MAY define their own scoring functions.

The governing principle is:

Standard dimensions, implementation-defined scoring.

---

23. Complexity Budget

InterfaceEvolutionIntent.md SHOULD define a complexity budget.

A candidate MAY be rejected even when it increases local utility.

Example:

utility gain       +2
complexity cost    +9
decision           reject or redesign

Repeated special-case pressure SHOULD trigger consideration of a higher-reach abstraction.

The Daimon SHOULD prefer the smallest sufficient adaptation.

---

24. Improvement Versus Accretion

Continuous addition is not equivalent to improvement.

The Daimon SHOULD detect:

• duplicate semantics;
• overlapping operations;
• historical exceptions;
• obsolete features;
• redundant representations;
• fragmented abstractions.

Evolution MAY remove or consolidate capability.

The goal is fitness for intent, not maximum API surface.

---

25. Auditability

Auditability is a FLUID core invariant.

A conformant system SHOULD be able to answer:

• What changed?
• Why did it change?
• What evidence triggered it?
• Which hypotheses were considered?
• Which revision implemented it?
• What tests were performed?
• Who or what authorized it?
• Which cohorts received it?
• What happened after deployment?
• Why was it retained, modified, or rejected?
• How can the prior state be restored?

Adaptive behavior without sufficient provenance is non-conformant with FLUID design intent.

---

26. Operational Authority Modes

FLUID modes describe authority, not maturity.

FLUID-0 — Instrumented

Collect telemetry and maintain revision identity.

FLUID-1 — Analytical

Detect and classify interface pressure.

FLUID-2 — Advisory

Propose interface adaptations.

FLUID-3 — Constructive

Generate contracts, adapter implementations, tests, documentation, or migration artifacts.

FLUID-4 — Experimental

Deploy candidates into bounded experiment environments.

FLUID-5 — Bounded Autonomous

Promote qualifying changes according to deterministic policy.

FLUID-6 — Evolutionary

Manage complete revision and migration lifecycles within declared authority.

A high-assurance system MAY deliberately remain at FLUID-2.

A lower-risk internal environment MAY operate at FLUID-5.

---

27. Security Invariants

The Daimon MUST NOT autonomously bypass:

• authentication;
• authorization;
• tenant isolation;
• network policy;
• secret policy;
• data-access policy;
• legal constraints;
• explicit responsibility boundaries.

AI-generated changes MUST pass the same deterministic enforcement mechanisms required of human-generated changes.

Security policy MUST NOT rely solely on probabilistic reasoning.

---

28. Economic Governance

Adaptive intelligence consumes resources.

FLUID SHOULD measure cost attributable to:

• telemetry;
• storage;
• analysis;
• model inference;
• candidate generation;
• testing;
• parallel revisions;
• deployment;
• human review;
• migration.

Economic cost SHOULD be a fitness dimension.

The Daimon SHOULD be able to defer low-value, high-cost exploration.

---

29. Adaptive Compute Budget

A FLUID deployment SHOULD support explicit budgets such as:

• analysis spend per period;
• hypothesis-generation spend;
• candidate-generation spend;
• maximum concurrent experiments;
• maximum autonomous implementation effort.

Exhausting the adaptive budget MUST NOT compromise deterministic runtime operation.

The API MUST continue operating according to its active contract even when adaptive evolution is paused.

---

30. Backend Capability Requirement Protocol

Where required functionality is unavailable from the interface layer, FLUID SHOULD emit a structured capability requirement.

A requirement SHOULD contain:

• requirement identifier;
• originating interface;
• originating revision;
• originating hypothesis;
• requested capability;
• reason;
• expected consumer value;
• expected usage;
• semantic requirements;
• quality requirements;
• security constraints;
• urgency;
• candidate interface dependency.

A backend SHOULD be able to return a disposition such as:

• ACCEPTED;
• PLANNED;
• AVAILABLE;
• PARTIALLY_AVAILABLE;
• OUT_OF_SCOPE;
• REJECTED;
• SUPERSEDED.

Repeated backend rejection MAY provide evidence about the appropriate interface boundary.

---

31. Boundary Learning

Repeated consumer demand outside declared intent MAY indicate:

• consumer misunderstanding;
• weak documentation;
• missing neighboring service;
• wrong interface boundary;
• outdated interface intent;
• genuinely out-of-scope demand.

The Daimon MAY recommend intent revision.

Intent revision SHOULD itself be governed and auditable.

---

32. Adoption as Evidence

Where revisions coexist, adoption MAY be used as a fitness signal.

Adoption MUST NOT be treated as proof of quality.

Adoption may be affected by:

• defaults;
• migration cost;
• novelty;
• lock-in;
• incentives;
• documentation;
• familiarity;
• commercial packaging.

Adoption SHOULD therefore be combined with other fitness signals.

---

33. Experimental Dynamic Fulfillment

Runtime synthesis of undefined API behavior is outside the FLUID v0.1 core.

Future experimental profiles MAY investigate:

unknown request
→ semantic interpretation
→ dynamic capability construction
→ validation
→ response

Such behavior raises unresolved questions regarding:

• determinism;
• latency;
• reproducibility;
• cost;
• authorization;
• security;
• auditability;
• liability.

Production-grade dynamic fulfillment SHOULD NOT be attempted until substantial operational experience exists with deterministic FLUID evolution.

---

34. Modular Architecture

FLUID SHOULD support incremental implementation.

A minimal implementation MAY consist of:

deterministic API
+ interface revision identity
+ telemetry
+ interface evolution intent

Optional modules MAY provide:

• pressure analysis;
• cohort analysis;
• explicit feedback;
• hypothesis management;
• candidate generation;
• automated testing;
• fitness evaluation;
• parallel revisions;
• migration;
• backend requirement escalation;
• autonomous promotion.

Advanced capability MUST NOT be required for basic FLUID adoption.

---

35. Conformance Profiles

The following profiles are informative names for modular packaging.

FLUID Core

Requires:

• deterministic interface;
• revision identity;
• telemetry;
• interface evolution intent;
• auditability.

FLUID Insight

Adds:

• pressure detection;
• consumer cohorts;
• fitness metrics.

FLUID Science

Adds:

• explicit hypotheses;
• experiments;
• candidate comparison;
• outcome evaluation.

FLUID Builder

Adds:

• generated contracts;
• adapter implementation;
• generated tests.

FLUID Evolution

Adds:

• parallel revisions;
• candidate deployment;
• managed promotion;
• migration.

FLUID Autonomous Evolution

Adds:

• policy-bounded autonomous promotion.

These names do not replace operational authority modes.

---

36. Minimal FLUID v0.1 Conformance

An implementation claiming FLUID v0.1 core conformance MUST provide:

1. a deterministic API contract;
2. an identifiable active interface revision;
3. interface telemetry;
4. declared interface evolutionary intent;
5. an auditable link from evidence to proposed change;
6. explicit responsibility boundaries;
7. deterministic security enforcement independent of probabilistic AI decisions.

Autonomous modification is not required.

---

37. Recommended Implementation Sequence

Stage 1 — Observable Interface

Implement:

• deterministic contract;
• revision identity;
• telemetry;
• InterfaceEvolutionIntent.md.

Stage 2 — Interface Pressure

Add:

• pressure taxonomy;
• consumer cohorts;
• fitness dimensions;
• explicit feedback.

Stage 3 — Scientific Evolution

Add:

• hypothesis records;
• candidate comparison;
• experiments;
• outcome evaluation.

Stage 4 — Constructive Daimon

Add:

• AI-assisted interface design;
• adapter generation;
• test generation;
• backend requirement generation.

Stage 5 — Managed Evolution

Add:

• parallel revisions;
• traffic allocation;
• adoption analysis;
• migration lifecycle;
• optimization recommendations.

Stage 6 — Bounded Autonomy

Add:

• policy-driven autonomous experiments;
• bounded promotion;
• automatic optimization.

---

38. Open Standardization Areas

The following are intentionally open in v0.1:

• telemetry schema;
• cohort identity model;
• interface-pressure scoring;
• fitness aggregation;
• complexity scoring;
• hypothesis exchange format;
• experiment protocol;
• revision-routing protocol;
• feedback protocol;
• backend requirement protocol;
• adaptation-risk classification;
• migration mechanics;
• AI cost accounting;
• cross-interface coordination.

FLUID v0.1 standardizes the conceptual and governance core before freezing implementation detail prematurely.

---

39. Canonical Design Principles

1. Deterministic execution, adaptive evolution.
2. Usage is evidence, not truth.
3. Errors can be product signals.
4. Evolution proceeds through explicit hypotheses.
5. Criticism is part of improvement.
6. Prefer hypotheses with useful explanatory reach.
7. Competing hypotheses are legitimate.
8. Complexity is a budget.
9. Improvement may require subtraction.
10. Adaptation does not imply authority propagation.
11. Multiple live revisions may represent legitimate uncertainty.
12. Adoption is evidence, not proof.
13. Convenience is an adoption requirement.
14. Adaptive intelligence has an economic cost.
15. Auditability is essential.
16. Intent constrains evolution.
17. The smallest sufficient adaptation is preferred.
18. Autonomy is a setting, not a maturity score.

---

40. Vision

A conventional API is designed, deployed, monitored, and periodically redesigned.

A FLUID API participates in its own continuous improvement.

Its runtime behavior remains deterministic.

Its understanding of consumer needs becomes empirical.

Its changes become hypotheses.

Its revisions become experiments.

Its telemetry becomes criticism.

Its production history becomes evidence.

Its intent constrains its growth.

Its Daimon continuously cares for its fitness.

The goal is not an API that changes constantly.

The goal is an API that can learn when it should change, why it should change, how to test the change, and whether the result deserves to become part of its evolving contract.