coulomb/fluid-core
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Establish fluid-core scaffold, intent, and phased workplans

Browse source 
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
This commit is contained in:
tegwick 2026-09-04 01:49:12 +02:00
parent af4bf798c4
commit c2cfe86d88
15 changed files with 5712 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

4
.gitignore vendored Normal file
View file

@ -0,0 +1,4 @@
/bin/
*.db
*.sqlite
.env

85
INTENT.md Normal file
View file

@ -0,0 +1,85 @@
---
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.

3
go.mod Normal file
View file

@ -0,0 +1,3 @@
module github.com/tegwick/fluid-core
go 1.22.2

14
history/260820-ideaFluidInterfaces.md Normal file
View file

@ -0,0 +1,14 @@
Fluid interfaces is a framework to establish a dynamic adaptive interface between services
that integrates self healing and self optimization based on interface telemetrie.
FLUID stands for FlowUtilizingInterfaceDaemon.
The idea is about having an actively developing interface that learns and evolves from mesuring
interface usage and responsibility.
The interface can implent REST, GRAPH or other API flavors and functions as a classic deterministic
API but on error or detection of missing functionality can trigger AI review, planning of the missing
endpoints or endpoint extensions connecting them to backend implementation or even requesting new
backend implementation.

2362
spec/ArchitectureBlueprint.md Executable file
View file

File diff suppressed because it is too large Load diff

1150
spec/FluidAPIStandards.md Executable file
View file

File diff suppressed because it is too large Load diff

773
spec/FluidHypothesisRevisionSchema.md Executable file
View file

@ -0,0 +1,773 @@
# FLUID Hypothesis and Revision Schema
**Document:** `FluidHypothesisRevisionSchema.md`
**Version:** 0.1.0
**Status:** Working Implementation Schema
**Companion to:** `FluidAPIStandards.md`
---
## 1. Purpose
This document defines a concrete persistence and exchange model for two core FLUID artifacts:
1. **Hypothesis Record** — why an interface change should be explored.
2. **Revision Record** — what deterministic interface state was built, verified, exposed, and measured.
The schema is intentionally technology-neutral.
An implementation MAY persist the model as:
- JSON;
- YAML;
- relational tables;
- event streams;
- graph records;
- document storage.
Field names and semantics SHOULD remain stable enough to support tooling interoperability.
---
# Part I — Hypothesis Record
## 2. Hypothesis Lifecycle
A hypothesis progresses through states such as:
```text
DRAFT
→ READY
→ PRIORITIZED
→ DESIGNING
→ EXPERIMENTING
→ EVALUATING
→ ACCEPTED | REJECTED | SUPERSEDED | DEFERRED
```
A hypothesis MAY produce multiple candidate revisions.
Multiple hypotheses MAY compete to explain the same interface pressure.
---
## 3. Hypothesis Record
```yaml
fluid_hypothesis:
schema_version: "0.1"
id: "H-000184"
interface_id: "customer-finance-api"
state: "PRIORITIZED"
created_at: "2026-09-04T12:00:00Z"
created_by:
type: "daimon"
id: "fluid-daimon/customer-finance-api"
model_or_agent: "optional"
title: "Provide direct latest-invoice capability"
observation:
summary: >
A significant consumer cohort retrieves invoice collections,
sorts them by issue date, and discards all but the first item.
evidence_refs:
- "telemetry:invoice-pattern-2026w36"
- "feedback:F-9821"
affected_cohorts:
- "partner-integrations"
- "coding-agents"
observation_window:
start: "2026-08-15T00:00:00Z"
end: "2026-09-01T00:00:00Z"
pressure:
classes:
- "successful_but_inefficient_usage"
- "repeated_expectation_mismatch"
severity: 0.61
confidence: 0.88
explanation:
claim: >
Consumers treat "latest invoice" as a domain-level concept
and the existing generic collection interface does not present
that concept directly.
reach:
score: 0.42
explains:
- "P-1831"
- "P-1834"
notes: >
Medium reach: explains several related request patterns
but not broader financial-context pressure.
proposed_adaptation:
class: "contract"
summary: >
Add an explicit latest-invoice retrieval capability.
candidate_contract:
method: "GET"
path: "/customers/{id}/invoices/latest"
implementation_scope: "interface_only"
backend_requirements:
required: false
requirement_refs: []
expected_outcomes:
- metric: "requests_per_completed_task"
cohort: "all"
baseline: 2.7
target: 1.2
direction: "lower"
- metric: "client_side_sort_workarounds"
cohort: "all"
baseline: 1.0
target: 0.2
direction: "lower"
guardrails:
- metric: "p95_latency_ms"
operator: "<="
threshold: 315
- metric: "authorization_scope_change"
operator: "=="
threshold: false
- metric: "backend_query_count_delta"
operator: "<="
threshold: 0
fitness_dimensions:
expected:
client_utility: 0.70
correctness: 0.00
reliability: 0.00
performance: 0.10
discoverability: 0.65
simplicity: -0.15
compatibility: 0.00
security: 0.00
maintainability: -0.05
operational_cost: 0.00
complexity:
expected_delta:
surface_area: 1
concept_count: 0
operation_count: 1
semantic_overlap: 0.1
cognitive_load: -0.2
score: 0.18
risk:
level: "LOW"
reasons:
- "read-only operation"
- "no authorization expansion"
economics:
estimated_experiment_cost: 18.00
estimated_implementation_cost: 40.00
currency: "EUR"
expected_value_class: "MEDIUM"
learning_value:
score: 0.56
notes: >
Useful signal for whether first-class convenience resources
improve agent and partner integration behavior.
priority:
score: 0.71
decided_by: "optimization-policy-v3"
success_criteria:
expression: >
requests_per_completed_task <= 1.2
AND no hard guardrail violation
failure_criteria:
expression: >
any hard guardrail violation
OR adoption below 5% after 30 days when equally discoverable
candidate_revision_refs:
- "R-000221"
experiment_refs:
- "E-000093"
outcome:
status: null
summary: null
evidence_refs: []
audit:
decision_refs:
- "D-2811"
immutable_event_refs:
- "EV-990218"
```
---
## 4. Required Hypothesis Fields
The following fields SHOULD be treated as mandatory for nontrivial adaptations:
| Field | Purpose |
|---|---|
| `id` | stable hypothesis identity |
| `interface_id` | owning interface |
| `title` | concise human-readable description |
| `observation.summary` | observed pressure |
| `observation.evidence_refs` | traceable evidence |
| `pressure.classes` | pressure taxonomy |
| `explanation.claim` | explanatory theory |
| `proposed_adaptation` | proposed response |
| `expected_outcomes` | measurable prediction |
| `guardrails` | non-negotiable constraints |
| `complexity.expected_delta` | complexity impact |
| `risk.level` | operational risk |
| `success_criteria` | evaluation condition |
| `state` | lifecycle state |
---
## 5. Hypothesis Reach
`explanation.reach` MAY be used to compare hypotheses.
Suggested structure:
```yaml
reach:
score: 0.0 # implementation-defined scale
explains:
- "<pressure-id>"
notes: "<why this hypothesis has broader explanatory power>"
```
Implementations SHOULD NOT equate reach with correctness.
---
## 6. Competing Hypotheses
A hypothesis MAY declare:
```yaml
competition:
group_id: "CG-0017"
alternatives:
- "H-000184"
- "H-000185"
- "H-000186"
```
A competition group represents multiple explanations or candidate designs for substantially the same pressure.
---
# Part II — Revision Record
## 7. Revision Lifecycle
A revision may progress through:
```text
CREATED
→ VERIFIED
→ EXPERIMENT
→ CANDIDATE
→ STABLE
→ DEPRECATED
→ RETIRED
```
A revision SHOULD be immutable once published.
State transitions SHOULD be recorded as events rather than rewriting history.
---
## 8. Revision Record
```yaml
fluid_revision:
schema_version: "0.1"
id: "R-000221"
interface_id: "customer-finance-api"
revision_number: 22
parent_revision: "R-000220"
state: "CANDIDATE"
created_at: "2026-09-04T13:10:00Z"
created_by:
type: "daimon"
id: "fluid-daimon/customer-finance-api"
contract:
type: "openapi"
version: "3.1"
artifact_ref: "artifact:openapi/customer-finance-api/r22"
digest: "sha256:<digest>"
implementation:
artifact_ref: "artifact:adapter/customer-finance-api/r22"
source_ref: "git:<commit>"
build_ref: "build:<id>"
digest: "sha256:<digest>"
interface_evolution_intent:
version: "IEI-7"
artifact_ref: "artifact:intent/customer-finance-api/IEI-7"
originating_hypotheses:
- "H-000184"
backend_requirements:
- id: null
compatibility:
class: "BACKWARD_COMPATIBLE"
breaking_changes: []
deprecations: []
supersedes: []
compatibility_evidence_refs:
- "test:compat-suite-775"
adaptation_classes:
- "contract"
verification:
status: "PASSED"
test_refs:
- "test:unit-12081"
- "test:contract-8821"
- "test:security-610"
- "test:compat-suite-775"
security_check: "PASSED"
policy_check: "PASSED"
complexity:
before:
surface_area: 41
operation_count: 39
after:
surface_area: 42
operation_count: 40
delta_score: 0.18
budget_status: "WITHIN_BUDGET"
deployment:
environments:
- name: "production"
started_at: "2026-09-05T08:00:00Z"
routing_policy_ref: "route-policy:rp-118"
current_exposure:
traffic_share: 0.28
cohorts:
- "partner-integrations"
- "coding-agents"
fitness:
baseline_revision: "R-000220"
measurement_window:
start: "2026-09-05T08:00:00Z"
end: null
metrics:
requests_per_completed_task:
baseline: 2.7
current: 1.15
target: 1.2
p95_latency_ms:
baseline: 300
current: 302
guardrail: 315
error_rate:
baseline: 0.008
current: 0.007
adoption:
eligible_consumers: 412
active_consumers: 119
adoption_rate: 0.289
retained_adoption_rate: null
economics:
build_cost: 38.20
experiment_cost_to_date: 12.40
currency: "EUR"
promotion:
eligible: true
recommended_state: "STABLE"
recommendation_reason: >
Target fitness reached with no guardrail violations.
authorized_by: null
authorized_at: null
rollback:
supported: true
target_revision: "R-000220"
procedure_ref: "runbook:rollback-r22"
provenance:
decision_refs:
- "D-2811"
experiment_refs:
- "E-000093"
telemetry_refs:
- "telemetry:invoice-pattern-2026w36"
audit:
immutable_event_refs:
- "EV-990221"
- "EV-990244"
- "EV-990281"
```
---
## 9. Required Revision Fields
A published revision SHOULD contain:
| Field | Purpose |
|---|---|
| `id` | stable identity |
| `interface_id` | owning interface |
| `revision_number` | human-readable sequence |
| `parent_revision` | lineage |
| `state` | lifecycle state |
| `contract` | deterministic external semantics |
| `implementation` | adapter artifact |
| `interface_evolution_intent` | governing intent |
| `originating_hypotheses` | why it exists |
| `compatibility` | compatibility status |
| `verification` | release evidence |
| `deployment` | exposure |
| `rollback` | restoration path |
| `provenance` | audit chain |
---
## 10. Compatibility Classes
Recommended values:
```text
BACKWARD_COMPATIBLE
FORWARD_COMPATIBLE
ADDITIVE
BEHAVIORAL_CHANGE
BREAKING
MIGRATION_ONLY
INTERNAL_ONLY
```
An implementation MAY use multiple classes where necessary.
---
## 11. Revision States
Recommended states:
### `CREATED`
Artifact exists but has not passed verification.
### `VERIFIED`
Required verification passed.
### `EXPERIMENT`
Revision is exposed only under experimental policy.
### `CANDIDATE`
Revision is eligible for broader production evaluation.
### `STABLE`
Revision is an accepted production interface.
### `DEPRECATED`
Supported but scheduled or expected for retirement.
### `RETIRED`
No longer exposed for normal traffic.
---
## 12. Experiment Record
A minimal experiment record SHOULD connect hypotheses and revisions.
```yaml
fluid_experiment:
schema_version: "0.1"
id: "E-000093"
interface_id: "customer-finance-api"
hypothesis_refs:
- "H-000184"
control_revision: "R-000220"
candidate_revisions:
- "R-000221"
cohorts:
- "partner-integrations"
- "coding-agents"
allocation:
control: 0.72
candidate: 0.28
start_at: "2026-09-05T08:00:00Z"
planned_end_at: "2026-10-05T08:00:00Z"
metrics:
primary:
- "requests_per_completed_task"
guardrails:
- "p95_latency_ms"
- "error_rate"
- "authorization_scope_change"
stop_conditions:
- "hard_guardrail_violation"
- "security_failure"
- "manual_stop"
result:
state: "RUNNING"
preferred_revision: null
evidence_refs: []
```
---
## 13. Pressure Record
A FLUID implementation SHOULD persist material interface-pressure observations.
```yaml
fluid_pressure:
schema_version: "0.1"
id: "P-1831"
interface_id: "customer-finance-api"
class: "successful_but_inefficient_usage"
first_seen: "2026-08-15T10:11:00Z"
last_seen: "2026-09-01T12:15:00Z"
affected_cohorts:
- "partner-integrations"
frequency:
observations: 1740
independent_consumers: 83
summary: >
Consumers repeatedly retrieve complete invoice collections
to determine the latest invoice.
evidence_refs:
- "telemetry:query-pattern-712"
status: "OPEN"
linked_hypotheses:
- "H-000184"
```
---
## 14. Backend Capability Requirement Record
```yaml
fluid_backend_requirement:
schema_version: "0.1"
id: "BR-0041"
originating_interface: "customer-context-api"
originating_revision: "R-0081"
originating_hypothesis: "H-0212"
backend_service: "payments-service"
capability:
title: "Historical payment-state query"
description: >
Retrieve payment state as of a specified timestamp.
semantics:
consistency: "snapshot"
required_fields:
- "payment_id"
- "state"
- "effective_at"
quality:
p95_latency_ms: 250
availability: 0.999
security:
authorization_scope: "payments.read"
tenant_isolation: "required"
expected_usage:
requests_per_day: 120000
disposition:
state: "PLANNED"
reason: null
target_ref: "payments-service/roadmap#412"
```
---
## 15. Event-Sourced Audit Model
FLUID SHOULD preserve material lifecycle transitions as append-only audit events.
Example:
```yaml
fluid_event:
schema_version: "0.1"
id: "EV-990281"
occurred_at: "2026-09-09T11:31:02Z"
entity_type: "revision"
entity_id: "R-000221"
event_type: "PROMOTION_RECOMMENDED"
actor:
type: "daimon"
id: "fluid-daimon/customer-finance-api"
inputs:
- "H-000184"
- "E-000093"
reason: >
Candidate met primary success target and violated no guardrails.
evidence_refs:
- "metrics:E-000093/window-4"
```
The audit event model is strongly recommended because FLUID evolution is itself a system behavior that must remain reconstructable.
---
## 16. Identifier Conventions
Recommended prefixes:
| Artifact | Prefix |
|---|---|
| Hypothesis | `H-` |
| Revision | `R-` |
| Experiment | `E-` |
| Pressure | `P-` |
| Backend requirement | `BR-` |
| Decision | `D-` |
| Audit event | `EV-` |
| Feedback | `F-` |
| Consumer cohort | `C-` |
Implementations MAY use UUIDs or other identifiers internally.
Human-readable prefixes are recommended for operational tooling.
---
## 17. Minimum Persistent Model
An early FLUID implementation can start with only:
```text
Pressure
↓
Hypothesis
↓
Revision
↓
Experiment
↓
Outcome
```
The following minimum relationships SHOULD exist:
```text
Pressure ──supports────► Hypothesis
Hypothesis ──creates───► Revision
Revision ──tested-by───► Experiment
Experiment ──measures─► Revision
Revision ──governed-by► InterfaceEvolutionIntent
```
This is sufficient to implement the first scientific adaptation loop without requiring the full future FLUID ecosystem.
---
## 18. Design Rule
The schema deliberately separates:
```text
what we observed
what we think explains it
what we changed
what happened afterwards
```
These MUST NOT be collapsed into one AI-generated narrative.
Keeping them separate is fundamental to:
- criticism;
- auditability;
- competing hypotheses;
- rollback;
- learning;
- governance;
- reproducibility.
---
## 19. Initial Implementation Recommendation
For the first FLUID implementation, persist:
1. `fluid_pressure`;
2. `fluid_hypothesis`;
3. `fluid_revision`;
4. `fluid_experiment`;
5. `fluid_event`.
Add backend requirements only when cross-service evolution is implemented.
This yields a compact but complete foundation for a deterministic, hypothesis-driven FLUID control loop.

505
spec/InterfaceEvolutionIntent.md Executable file
View file

@ -0,0 +1,505 @@
# Interface Evolution Intent
**Document:** `InterfaceEvolutionIntent.md`
**Version:** 0.1.0
**Status:** Template / Normative Companion to FLUID API Standards
---
## 1. Purpose
This document defines the evolutionary intent and governance boundary of a FLUID interface.
It is subordinate to the parent repository or service `INTENT.md` and MUST NOT redefine the overall mission of that service.
Its purpose is to answer:
> **How may this interface evolve while remaining faithful to the service it represents?**
The FLUID Daimon MUST treat this document as a constitutional constraint.
---
## 2. Parent Intent
**Parent service/repository:**
`<name>`
**Parent intent document:**
`INTENT.md`
**Relevant parent mission excerpt or reference:**
`<reference>`
---
## 3. Interface Identity
**Interface name:**
`<name>`
**Interface identifier:**
`<stable-id>`
**Current operational authority mode:**
`FLUID-0 | FLUID-1 | FLUID-2 | FLUID-3 | FLUID-4 | FLUID-5 | FLUID-6`
**Protocols / interface styles:**
- `<REST>`
- `<GraphQL>`
- `<RPC>`
- `<events>`
- `<other>`
---
## 4. Mission
Describe the outcome the interface exists to enable.
The mission SHOULD focus on consumer outcomes rather than protocol details.
### Mission statement
> `<what useful capability does this interface make conveniently and reliably available?>`
### Success looks like
- `<consumer outcome 1>`
- `<consumer outcome 2>`
- `<consumer outcome 3>`
---
## 5. Intended Consumers
Define the consumers the interface is designed to serve.
### Primary consumer cohorts
| Cohort | Description | Importance | Notes |
|---|---|---:|---|
| `<cohort>` | `<description>` | `<high/medium/low>` | `<notes>` |
### Secondary cohorts
| Cohort | Description | Importance | Notes |
|---|---|---:|---|
| `<cohort>` | `<description>` | `<high/medium/low>` | `<notes>` |
### Explicitly unsupported cohorts
- `<unsupported cohort>`
- `<unsupported cohort>`
---
## 6. Capability Domain
Define which capabilities properly belong inside this interface.
### In scope
- `<capability family>`
- `<capability family>`
- `<capability family>`
### Conditionally in scope
Capabilities that MAY be introduced if evidence justifies them:
- `<conditional capability>`
- `<conditional capability>`
### Out of scope
- `<capability>`
- `<capability>`
---
## 7. Responsibility Boundaries
The FLUID interface owns interface and adapter behavior only.
### Responsibilities owned by this interface
- `<representation>`
- `<composition>`
- `<validation>`
- `<routing>`
- `<other>`
### Responsibilities owned by backend systems
| Backend | Responsibility | Boundary |
|---|---|---|
| `<service>` | `<responsibility>` | `<what FLUID may request but not assume>` |
### Explicit non-authority
The Daimon MUST NOT autonomously:
- `<modify backend domain logic>`
- `<change security policy>`
- `<change tenant boundaries>`
- `<other>`
---
## 8. Consumer Expectation Model
Describe the expectations the interface SHOULD cultivate.
### Concepts consumers should naturally understand
- `<concept>`
- `<concept>`
### Interaction patterns considered natural
- `<pattern>`
- `<pattern>`
### Expectations that should be discouraged
- `<misconception>`
- `<misconception>`
This section provides context when interpreting interface pressure.
---
## 9. Optimization Preferences
The Daimon MUST optimize within declared priorities.
### Active optimization regime
`<EXPLORATION | ADOPTION | UTILITY | PERFORMANCE | RELIABILITY | SECURITY | COST | CONSOLIDATION | MIGRATION | CUSTOM>`
### Fitness priorities
| Dimension | Priority | Target / Constraint | Notes |
|---|---:|---|---|
| Client utility | High | `<target>` | |
| Correctness | High | `<target>` | |
| Reliability | High | `<target>` | |
| Availability | `<...>` | `<target>` | |
| Performance | `<...>` | `<target>` | |
| Discoverability | `<...>` | `<target>` | |
| Simplicity | `<...>` | `<target>` | |
| Compatibility | `<...>` | `<target>` | |
| Security | `<...>` | `<target>` | |
| Maintainability | `<...>` | `<target>` | |
| Operational cost | `<...>` | `<target>` | |
| Implementation cost | `<...>` | `<target>` | |
| Resource consumption | `<...>` | `<target>` | |
### Automatic recommendation policy
`<disabled | advisory | enabled-with-approval | enabled-with-bounded-autonomy>`
---
## 10. Complexity Budget
Complexity is a constrained resource.
### Complexity dimensions
| Dimension | Current | Preferred | Maximum | Scoring method |
|---|---:|---:|---:|---|
| Surface area | | | | |
| Concept count | | | | |
| Operation count | | | | |
| Parameter dimensionality | | | | |
| Semantic overlap | | | | |
| Alternative-path count | | | | |
| Dependency count | | | | |
| Backend composition count | | | | |
| Exception count | | | | |
| Active revision count | | | | |
| Cognitive load | | | | |
### Complexity policy
- New capability SHOULD replace or generalize existing capability where reasonable.
- Semantic duplication SHOULD be rejected unless justified.
- Repeated special-case pressure SHOULD trigger abstraction review.
- Candidates exceeding a hard complexity limit MUST NOT be autonomously promoted.
- Complexity-reducing adaptations MAY be prioritized during consolidation regimes.
---
## 11. Compatibility Policy
### Compatibility posture
`<STRICT | VERSIONED | MANAGED_MIGRATION | CUSTOM>`
### Rules
- Published revision semantics MUST NOT change silently.
- Breaking changes REQUIRE a successor revision.
- `<additional policy>`
- `<additional policy>`
### Coexistence expectations
**Default maximum concurrent major revisions:**
`<number>`
**Default deprecation period:**
`<duration or policy>`
**Migration assistance required:**
`<yes/no + details>`
---
## 12. Revision and Experiment Policy
### Revision classes
- stable;
- candidate;
- experiment;
- deprecated;
- retired.
### Allowed concurrent exposure
| Revision class | Production traffic allowed? | Max share | Approval required? |
|---|---|---:|---|
| stable | yes | 100% | no |
| candidate | `<yes/no>` | `<%>` | `<policy>` |
| experiment | `<yes/no>` | `<%>` | `<policy>` |
| deprecated | yes | `<%>` | no |
| retired | no | 0% | n/a |
### Evolution velocity controls
The Daimon SHOULD slow or freeze promotion when:
- `<regression condition>`
- `<reliability threshold>`
- `<security event>`
- `<budget condition>`
The Daimon MAY accelerate experimentation when:
- `<confidence condition>`
- `<success-rate condition>`
- `<available capacity condition>`
---
## 13. Hypothesis Policy
Nontrivial adaptations SHOULD have explicit hypotheses.
### Minimum evidence for hypothesis creation
- `<threshold>`
- `<cohort diversity requirement>`
- `<observation duration>`
- `<manual exception>`
### Required hypothesis fields
- observation;
- explanation;
- proposed adaptation;
- expected outcome;
- measurement;
- success criteria;
- guardrails;
- complexity impact;
- risk;
- expected learning value.
### Competing hypotheses
`<allowed / encouraged / restricted>`
### Reach preference
Describe whether broad explanatory hypotheses should be favored over local fixes.
`<policy>`
---
## 14. Adaptation Authority
Define what the Daimon may do automatically.
| Adaptation class | Observe | Propose | Generate | Experiment | Promote |
|---|---:|---:|---:|---:|---:|
| Presentation | yes | yes | `<yes/no>` | `<yes/no>` | `<yes/no>` |
| Contract | yes | yes | `<yes/no>` | `<yes/no>` | `<yes/no>` |
| Composition | yes | yes | `<yes/no>` | `<yes/no>` | `<yes/no>` |
| Implementation | yes | yes | `<yes/no>` | `<yes/no>` | `<yes/no>` |
| Requirement escalation | yes | yes | yes | n/a | n/a |
### Absolute prohibitions
The Daimon MUST NOT autonomously:
- expand authorization scope;
- weaken tenant isolation;
- bypass deterministic security controls;
- reinterpret legal constraints;
- create backend authority it does not possess;
- `<additional prohibition>`.
---
## 15. Security Requirements
### Authentication
`<requirements>`
### Authorization
`<requirements>`
### Tenant isolation
`<requirements>`
### Data handling
`<requirements>`
### Logging and provenance
`<requirements>`
### AI boundary
AI-generated changes MUST pass deterministic:
- security policy;
- tests;
- authorization validation;
- tenant-boundary checks;
- release controls.
---
## 16. Quality Requirements
| Quality attribute | Requirement | Hard guardrail? |
|---|---|---:|
| Correctness | `<requirement>` | yes |
| Availability | `<requirement>` | `<yes/no>` |
| Reliability | `<requirement>` | `<yes/no>` |
| p95 latency | `<requirement>` | `<yes/no>` |
| Error rate | `<requirement>` | `<yes/no>` |
| Security | `<requirement>` | yes |
| Auditability | `<requirement>` | yes |
| Rollback | `<requirement>` | yes |
---
## 17. Economic Constraints
### Adaptive compute budget
| Budget | Limit |
|---|---:|
| analysis per day | `<value>` |
| hypothesis generation | `<value>` |
| candidate generation | `<value>` |
| concurrent experiments | `<value>` |
| autonomous implementation effort | `<value>` |
### Cost policy
- Adaptive budget exhaustion MUST NOT affect deterministic runtime availability.
- High-cost / low-value hypotheses SHOULD be deferred.
- `<additional rule>`
---
## 18. Backend Capability Escalation
When a candidate requires backend functionality that is unavailable, the Daimon SHOULD issue a structured capability requirement.
### Preferred requirement destination
`<service / queue / repo / protocol>`
### Required response states
- ACCEPTED;
- PLANNED;
- AVAILABLE;
- PARTIALLY_AVAILABLE;
- OUT_OF_SCOPE;
- REJECTED;
- SUPERSEDED.
### Boundary-learning policy
Repeated `OUT_OF_SCOPE` or `REJECTED` responses SHOULD trigger:
`<intent review / neighboring interface proposal / consumer expectation correction / other>`
---
## 19. Audit and Provenance Policy
For every promoted change the system MUST retain enough evidence to reconstruct:
- originating pressure;
- hypothesis;
- candidate;
- verification;
- approval;
- deployment;
- affected cohorts;
- measured outcome;
- final disposition.
### Retention period
`<duration>`
### Immutable evidence store
`<location / technology / policy>`
---
## 20. Review and Amendment
This document SHOULD be versioned.
Changes to this document SHOULD be treated as governance changes rather than ordinary interface changes.
### Amendment authority
`<role / mechanism>`
### Review cadence
`<cadence>`
### Last reviewed
`<date>`
---
## 21. Summary
The FLUID Daimon SHOULD optimize aggressively **inside** this document and remain conservative **at** its boundaries.
The interface may evolve.
Its intent must remain explicit.

109
workplans/FC-WP-0001-foundations-and-wire-contract.md Normal file
View file

@ -0,0 +1,109 @@
---
id: FC-WP-0001
type: workplan
title: "FLUID foundations and the wire contract"
domain: infotech
repo: fluid-core
status: active
owner: worsch
topic_slug: fluid
created: "2026-09-04"
updated: "2026-09-04"
planning_priority: high
planning_order: 1
related_repos:
- fluid-telegram
- fluid-x
- fluid-substack
---
# FC-WP-0001 - Foundations and the wire contract
Establish the boundary before any code depends on it. fluid-core integrates
out of process, so its contract is a set of on-the-wire artifacts, not a Go
API. Everything downstream assumes these schemas are stable.
Reference: `spec/FluidHypothesisRevisionSchema.md`, `spec/ArchitectureBlueprint.md`
§36 (revision descriptor), §17 (routing policy), §44 (control APIs).
## T01 - Repository scaffold and INTENT
```task
id: FC-WP-0001-T01
status: done
priority: high
```
Go module, directory tree per the plan, `INTENT.md` declaring the wire-contract
boundary and the four invariants this repo defends hardest.
## T02 - Record schemas
```task
id: FC-WP-0001-T02
status: todo
priority: high
```
JSON Schema for `fluid_pressure`, `fluid_hypothesis`, `fluid_revision`,
`fluid_experiment`, `fluid_event`, `fluid_backend_requirement` and the feedback
record. Transcribe field names faithfully from the schema document — they are
the interop surface, per its §1.
## T03 - Descriptor and policy schemas
```task
id: FC-WP-0001-T03
status: todo
priority: high
```
JSON Schema for the revision descriptor (Blueprint §36) and the routing policy
(Blueprint §17). These two are what the gateway consumes at runtime and must be
readable without any fluid-core code.
## T04 - Type generation
```task
id: FC-WP-0001-T04
status: todo
priority: high
```
Generate Go types into `internal/contract/` from `schemas/`. Hand-written record
types are prohibited — drift between spec and implementation must fail CI.
## T05 - Spec examples as fixtures
```task
id: FC-WP-0001-T05
status: todo
priority: high
```
Extract the YAML examples embedded in the spec documents and validate them
against the schemas in CI. If the spec changes and the schema does not, the
build breaks.
## T06 - Build, CI and identifier conventions
```task
id: FC-WP-0001-T06
status: todo
priority: medium
```
Makefile, GitHub Actions (build, vet, test, schema validation), and the
identifier prefix helpers from schema doc §16: `H- R- E- P- BR- D- EV- F- C-`.
## T07 - Architecture decision records
```task
id: FC-WP-0001-T07
status: todo
priority: medium
```
ADRs for: Go as the implementation language; out-of-process attachment; the
wire contract as boundary; SQLite to Postgres evidence store; and the revision
identity scheme, which Blueprint §54 leaves deliberately open.

135
workplans/FC-WP-0002-deterministic-data-plane.md Normal file
View file

@ -0,0 +1,135 @@
---
id: FC-WP-0002
type: workplan
title: "Deterministic data plane (Blueprint Phase A)"
domain: infotech
repo: fluid-core
status: active
owner: worsch
topic_slug: fluid
created: "2026-09-04"
updated: "2026-09-04"
planning_priority: high
planning_order: 2
depends_on:
- FC-WP-0001
---
# FC-WP-0002 - Deterministic data plane
The production request path. No AI, no analysis, no dependency on the control
plane. Blueprint §5 and §34: the gateway must keep serving when everything
above it is dead.
## T01 - Edge gateway
```task
id: FC-WP-0002-T01
status: todo
priority: high
```
Transport termination, correlation IDs, coarse rate limiting, request size and
shape limits. Blueprint §5.1 — the gateway must not invent interface semantics.
## T02 - Revision resolver
```task
id: FC-WP-0002-T02
status: todo
priority: high
```
The §5.2 precedence chain: explicit revision, bound client contract, experiment
assignment, stable default. Every resolution records its reason; resolution
without an auditable reason is a defect.
## T03 - Revision router
```task
id: FC-WP-0002-T03
status: todo
priority: high
```
Map a resolved revision to an adapter upstream. Reject unpublished, failed,
ineligible and retired revisions (§5.3). Allocation rules are deterministic and
read from routing policy the router does not author.
## T04 - Contract validator
```task
id: FC-WP-0002-T04
status: todo
priority: high
```
OpenAPI 3.1 request and response validation (§5.4). The contract digest is part
of the revision artifact and is content-addressed.
## T05 - Backend connector layer
```task
id: FC-WP-0002-T05
status: todo
priority: high
```
Timeout, retry, circuit breaker, error mapping, tenant propagation (§5.6). The
adapter is an upstream process reached over HTTP — this is where the
language-agnostic promise is kept.
## T06 - Response policy
```task
id: FC-WP-0002-T06
status: todo
priority: medium
```
Structured errors carrying a FLUID correlation reference, leaking no backend
detail (§5.7).
## T07 - Telemetry emitter
```task
id: FC-WP-0002-T07
status: todo
priority: high
```
Fire-and-forget emission. Blueprint §34.2 is a hard invariant: telemetry
backpressure must never block or slow a request. Test it under a stalled sink.
## T08 - Evidence store
```task
id: FC-WP-0002-T08
status: todo
priority: high
```
Append-only event storage, SQLite for development and Postgres-ready. Mutable
summaries exist only as derived views (§26).
## T09 - Intent store
```task
id: FC-WP-0002-T09
status: todo
priority: high
```
Bind every revision to an `InterfaceEvolutionIntent` version (§27), so audit can
later answer whether a change was valid under the intent that existed when it
was made.
## T10 - Operator CLI, first commands
```task
id: FC-WP-0002-T10
status: todo
priority: medium
```
`fluid revision create|publish|list`, `fluid intent show`, `fluid events tail`.

93
workplans/FC-WP-0003-publication-and-control-apis.md Normal file
View file

@ -0,0 +1,93 @@
---
id: FC-WP-0003
type: workplan
title: "Revision publication pipeline and control APIs"
domain: infotech
repo: fluid-core
status: active
owner: worsch
topic_slug: fluid
created: "2026-09-04"
updated: "2026-09-04"
planning_priority: high
planning_order: 3
depends_on:
- FC-WP-0002
---
# FC-WP-0003 - Publication and control APIs
Nothing reaches the router unsigned. The deterministic policy gate is built now,
before anything can generate candidates, so a future Daimon has nowhere to
bypass.
## T01 - Publication pipeline
```task
id: FC-WP-0003-T01
status: todo
priority: high
```
Blueprint §35: SOURCE, BUILD, CONTRACT CHECK, TEST, SECURITY CHECK, POLICY
CHECK, SIGN, PUBLISH, ROUTE. Each stage emits an audit event.
## T02 - Descriptor signing and verification
```task
id: FC-WP-0003-T02
status: todo
priority: high
```
The router accepts only signed or otherwise authenticated published revision
descriptors (§35). An unsigned descriptor must be refused, and that refusal
tested.
## T03 - Revision API
```task
id: FC-WP-0003-T03
status: todo
priority: high
```
Blueprint §44.1: create, verify, publish, set state, query lineage.
## T04 - Intent API
```task
id: FC-WP-0003-T04
status: todo
priority: medium
```
Blueprint §44.5: read active intent, read historical intent, validate a
candidate against intent, propose an amendment. Amendment stays separately
governed — the API records a proposal, it does not enact one.
## T05 - Deterministic policy gate
```task
id: FC-WP-0003-T05
status: todo
priority: high
```
Blueprint §28.2. Allowed adaptation class, permitted operational mode,
complexity threshold, security status, test status, compatibility status,
traffic-allocation maximum, budget, approval requirement. This gate is the
architectural boundary that stops agentic reasoning from becoming security
policy.
## T06 - Trust model in the type system
```task
id: FC-WP-0003-T06
status: todo
priority: medium
```
Blueprint §47 made mechanical: generated artifacts are an untrusted candidate
type until verification produces a signed revision. The compiler should make the
unsafe path awkward to write.

122
workplans/FC-WP-0004-fluid-insight.md Normal file
View file

@ -0,0 +1,122 @@
---
id: FC-WP-0004
type: workplan
title: "FLUID Insight - observation plane (Blueprint Phase B)"
domain: infotech
repo: fluid-core
status: active
owner: worsch
topic_slug: fluid
created: "2026-09-04"
updated: "2026-09-04"
planning_priority: high
planning_order: 4
depends_on:
- FC-WP-0003
---
# FC-WP-0004 - FLUID Insight
Turn traffic into evidence. Deterministic heuristics only at this stage — no
model inference anywhere in this workplan.
## T01 - Telemetry ingest and normalizer
```task
id: FC-WP-0004-T01
status: todo
priority: high
```
Request, error, sequence, adoption and explicit-feedback events into one
normalized interaction event (Blueprint §6.1).
## T02 - Redaction and privacy filter
```task
id: FC-WP-0004-T02
status: todo
priority: high
```
Field exclusion, pseudonymization, tenant isolation, retention, cohort minimum
sizes (§6.2). Raw payload capture is off by default and must stay that way —
FLUID learns about the interface, not about people.
## T03 - Cohort engine
```task
id: FC-WP-0004-T03
status: todo
priority: medium
```
Coarse, stable, comparable over time (§6.3). Resist granularity: cohorts should
not be more specific than the analysis requires.
## T04 - Interaction topology analyzer
```task
id: FC-WP-0004-T04
status: todo
priority: high
```
Recurring call-sequence detection (§6.4) — the signal that makes FLUID more than
error counting.
## T05 - Pressure classifier
```task
id: FC-WP-0004-T05
status: todo
priority: high
```
The ten pressure classes from §6.5. Classification retains evidence references
in every case.
## T06 - Pressure registry
```task
id: FC-WP-0004-T06
status: todo
priority: high
```
Deduplication, aggregation, frequency, severity, confidence, and the §9
lifecycle. Pressure may remain unresolved on purpose — not every mismatch
deserves adaptation.
## T07 - Fitness engine
```task
id: FC-WP-0004-T07
status: todo
priority: high
```
Blueprint §18: primary metrics, guardrails, secondary and learning metrics kept
distinct. Baseline and measurement window are retained, never recomputed.
## T08 - Explicit feedback collector
```task
id: FC-WP-0004-T08
status: todo
priority: medium
```
API Standards §15. Accepted over the wire, stored as evidence, and never
treated as authority to change anything.
## T09 - CLI and pressure API
```task
id: FC-WP-0004-T09
status: todo
priority: medium
```
Blueprint §44.2 plus `fluid pressure list|show|dismiss`, `fluid cohort list`,
`fluid fitness compare`.

125
workplans/FC-WP-0005-fluid-science.md Normal file
View file

@ -0,0 +1,125 @@
---
id: FC-WP-0005
type: workplan
title: "FLUID Science - the adaptation loop closes (Blueprint Phase C)"
domain: infotech
repo: fluid-core
status: active
owner: worsch
topic_slug: fluid
created: "2026-09-04"
updated: "2026-09-04"
planning_priority: high
planning_order: 5
depends_on:
- FC-WP-0004
---
# FC-WP-0005 - FLUID Science
Hypotheses, experiments, fitness and promotion. Entirely human-driven — the
Daimon is deliberately absent. Blueprint §50 says the success criterion is
proving this loop works cleanly and safely, not autonomous coding.
## T01 - Hypothesis records and lifecycle
```task
id: FC-WP-0005-T01
status: todo
priority: high
```
Schema doc §2: DRAFT, READY, PRIORITIZED, DESIGNING, EXPERIMENTING, EVALUATING,
then ACCEPTED, REJECTED, SUPERSEDED or DEFERRED. Keep observation, explanation,
prediction, intervention and result separate — schema doc §18 warns that
collapsing them into one narrative destroys criticism and auditability.
## T02 - Competition groups
```task
id: FC-WP-0005-T02
status: todo
priority: medium
```
Rival explanations of one pressure coexist (schema doc §6). Preserving
uncertainty is a feature.
## T03 - Hypothesis API
```task
id: FC-WP-0005-T03
status: todo
priority: medium
```
Blueprint §44.3: create, compare, prioritize, attach candidate, record outcome.
## T04 - Experiment controller
```task
id: FC-WP-0005-T04
status: todo
priority: high
```
Blueprint §16. Declares hypothesis, control, candidate, cohorts, allocation,
metrics, guardrails, start and stop conditions, maximum duration. Per §17 it
must not touch traffic directly: it writes routing policy the router consumes.
Experiments are interruptible.
## T05 - Experiment API
```task
id: FC-WP-0005-T05
status: todo
priority: medium
```
Blueprint §44.4: create, start, change bounded allocation, stop, record metrics,
finalize.
## T06 - Fitness evaluation against hypotheses
```task
id: FC-WP-0005-T06
status: todo
priority: high
```
Wire the fitness engine to experiments. Success criteria may not be changed
after results are visible without recording the amendment (§18).
## T07 - Promotion controller
```task
id: FC-WP-0005-T07
status: todo
priority: high
```
PROMOTE, EXPAND_EXPERIMENT, RETAIN_AS_OPTION, MODIFY, REVERT, ABANDON, DEFER
recorded as decisions with an authorizing actor (§19). Human authority only.
## T08 - Append-only event log
```task
id: FC-WP-0005-T08
status: todo
priority: high
```
Every transition above as a `fluid_event` (schema doc §15). FLUID evolution is
itself a system behavior that must remain reconstructable.
## T09 - Audit trace command
```task
id: FC-WP-0005-T09
status: todo
priority: high
```
`fluid audit trace <revision>` reconstructs pressure, hypothesis, revision,
experiment, fitness and decision, answering all eleven questions in API
Standards §25.

90
workplans/FC-WP-0006-conformance-and-self-validation.md Normal file
View file

@ -0,0 +1,90 @@
---
id: FC-WP-0006
type: workplan
title: "Conformance suite and self-validation"
domain: infotech
repo: fluid-core
status: active
owner: worsch
topic_slug: fluid
created: "2026-09-04"
updated: "2026-09-04"
planning_priority: high
planning_order: 6
depends_on:
- FC-WP-0005
---
# FC-WP-0006 - Conformance and self-validation
Prove the loop mechanically before a real workload depends on it. Everything
here runs in CI with no human steps and no external services.
## T01 - Echo interface fixture
```task
id: FC-WP-0006-T01
status: todo
priority: high
```
`examples/echo-interface` — two revisions, R-1 deliberately inefficient
(list then filter), R-2 the convenience form. This is the smallest honest
reproduction of the Blueprint §33 worked example.
## T02 - Minimal conformance assertions
```task
id: FC-WP-0006-T02
status: todo
priority: high
```
The seven requirements of API Standards §36, asserted as tests rather than
claimed in a README.
## T03 - Architectural invariant checks
```task
id: FC-WP-0006-T03
status: todo
priority: high
```
The mechanically checkable subset of Blueprint §55. Invariant 2 (evolution can
stop without stopping the API) and invariant 9 (AI-generated artifacts untrusted
until verified) matter most and get dedicated tests.
## T04 - Failure containment matrix
```task
id: FC-WP-0006-T04
status: todo
priority: high
```
Blueprint §34. Kill the control plane, the evidence store and the telemetry
pipeline in turn; assert the data plane keeps serving from cached published
configuration each time.
## T05 - End-to-end loop in CI
```task
id: FC-WP-0006-T05
status: todo
priority: high
```
The full §50 vertical slice automated: two revisions, a 90/10 experiment,
fitness comparison, promotion, complete audit trail.
## T06 - Integration guide
```task
id: FC-WP-0006-T06
status: todo
priority: medium
```
`docs/integration-guide.md` — how to put an existing API of any stack behind
fluid-core without modifying it.

142
workplans/FC-WP-0007-fluid-telegram-handover.md Normal file
View file

@ -0,0 +1,142 @@
---
id: FC-WP-0007
type: workplan
title: "Handover: HelixForge Telegram identity and hall-of-helix channel"
domain: infotech
repo: fluid-core
status: active
owner: worsch
topic_slug: fluid
created: "2026-09-04"
updated: "2026-09-04"
planning_priority: high
planning_order: 7
depends_on:
- FC-WP-0006
related_repos:
- fluid-telegram
- helix-forge
- hall-of-helix
---
# FC-WP-0007 - Handover to fluid-telegram
The point of the whole sequence. Establish a Telegram identity for HelixForge
and a channel publishing hall-of-helix entries, as the first real FLUID
interface. Outbound-first: agents and publishing jobs are the consumers,
Telegram is the backend.
Deliverables land in `docs/handover/fluid-telegram.md` here and as `FT-WP-0001`
in the `fluid-telegram` repository.
## T01 - Interface evolution intent
```task
id: FC-WP-0007-T01
status: todo
priority: high
```
Fill the template for `helix-forge-telegram-publishing`. Parent intent is
`helix-forge/INTENT.md`. Initial authority mode FLUID-2 (advisory): the Daimon
may propose and never generate or promote. Out of scope for now: inbound
commands, payments, Mini Apps, moderation. Non-authority: never create Telegram
entities, change membership, or touch credentials.
## T02 - Bot identity
```task
id: FC-WP-0007-T02
status: todo
priority: high
```
**Human step.** Register the HelixForge bot via BotFather (Canon BOT-01). Store
the token in OpenBao per Canon SEC-04, consistent with HF-WP-0002. The token
never enters the repository; the adapter receives only that credential, per
Blueprint §28.1 runtime identity.
## T03 - Channels
```task
id: FC-WP-0007-T03
status: todo
priority: high
```
**Human step.** Create a private test channel first, then the public
hall-of-helix channel (Canon PUB-01). Bot is administrator with post rights
only. All verification runs against the private channel before anything is
published publicly.
## T04 - Revision R-1 contract
```task
id: FC-WP-0007-T04
status: todo
priority: high
```
`POST /v1/hall-entries` (idempotent on entry id) and
`GET /v1/hall-entries/{id}`. OpenAPI plus signed revision descriptor.
## T05 - Telegram adapter and connector contract
```task
id: FC-WP-0007-T05
status: todo
priority: high
```
Map a `hall-of-helix/entries/*.md` file to a Telegram post. The adapter is a
separate process and may be written in whatever suits the platform. Declare the
connector capability contract: identity, auth, timeouts, retry, rate limits,
error mapping.
## T06 - Cohorts, telemetry and redaction
```task
id: FC-WP-0007-T06
status: todo
priority: high
```
Subscriber classes and agent consumers as cohorts. Redaction rules that keep
Telegram user identity (Canon ID-01) out of the evidence store entirely.
## T07 - First competing hypotheses
```task
id: FC-WP-0007-T07
status: todo
priority: high
```
Telegram's 4096-character message limit against long-form entries is the first
genuine pressure. Two presentation adaptations compete: H-A, teaser plus link
back to the hall; H-B, full entry serialized as a multi-part rich post
(Canon PUB-02/MED-02). Blueprint §37 argues presentation is the safest and
highest-value place to start.
## T08 - Live experiment and audit
```task
id: FC-WP-0007-T08
status: todo
priority: high
```
R-2 and R-3 implement H-A and H-B. Run the experiment on real subscriber
traffic, measure read-through and reaction, and confirm `fluid audit trace`
reconstructs the whole chain. This is the §50 slice on a real workload.
## T09 - Runbook and handover package
```task
id: FC-WP-0007-T09
status: todo
priority: medium
```
Token rotation, channel admin recovery, rollback to R-1, and the assembled
handover document.