Prepare the FLUID interface for HelixForge Telegram publishing

Adds the governing intent, the R-1 contract and descriptor, the adapter's
connector contract, the observation and redaction configuration, a
runbook, and the seed evidence for the first experiment: a measured
pressure record and two competing hypotheses about how a long hall entry
should reach a reader.

The interface is declared at FLUID-2 deliberately. It publishes under
HelixForge's name to an audience that did not consent to being
experimented on carelessly, and the cost of a bad post is reputational
rather than recoverable.

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

hypotheses/H-tg-serial.yaml

@@ -0,0 +1,125 @@
+# Competing hypothesis B, in group CG-tg-length.
+fluid_hypothesis:
+  schema_version: "0.1"
+
+  id: "H-tg-serial"
+  interface_id: "helix-forge-telegram-publishing"
+  state: "DRAFT"
+
+  title: "The whole entry in the channel serves readers better than a link"
+
+  observation:
+    summary: >
+      85% of hall entries exceed Telegram's 4096-character message limit, with
+      a median body of 5767 characters. The interface must choose a form for
+      long entries before it can publish at all.
+    evidence_refs:
+      - "measurement:hall-of-helix/entries@2026-09-04"
+      - "pressure:P-tg-length"
+    affected_cohorts:
+      - "telegram-subscribers"
+
+  pressure:
+    classes:
+      - "missing_interface_capability"
+    pressure_refs:
+      - "P-tg-length"
+    severity: 0.85
+    confidence: 1.0
+
+  explanation:
+    claim: >
+      A link out of Telegram is a cost most readers will not pay. Telegram's
+      rich-text posts are built for long-form reading and the audience is
+      already there. Serializing the entry across a small number of linked
+      messages keeps the whole account where the reader is, and the median
+      entry needs only two.
+    reach:
+      score: 0.5
+      explains:
+        - "P-tg-length"
+      notes: >
+        Medium reach. It answers the length constraint natively but does not
+        transfer to platforms with harder limits.
+
+  proposed_adaptation:
+    class: "presentation"
+    summary: >
+      Split the entry at section boundaries into a small number of rich-text
+      messages, each linked to the previous, with the visual attached to the
+      first.
+    implementation_scope: "interface_only"
+
+  backend_requirements:
+    required: false
+    requirement_refs: []
+
+  expected_outcomes:
+    - metric: "read_through_rate"
+      cohort: "telegram-subscribers"
+      target: 0.15
+      direction: "higher"
+    - metric: "messages_per_entry"
+      cohort: "all"
+      baseline: 1.0
+      target: 2.0
+      direction: "higher"
+
+  guardrails:
+    - metric: "entry_content_loss"
+      operator: "=="
+      threshold: false
+    - metric: "error_rate"
+      operator: "<="
+      threshold: 0.01
+    - metric: "messages_per_entry"
+      operator: "<="
+      threshold: 4
+
+  fitness_dimensions:
+    expected:
+      client_utility: 0.5
+      discoverability: 0.3
+      simplicity: -0.2
+      correctness: 0.0
+      security: 0.0
+
+  complexity:
+    expected_delta:
+      operation_count: 0
+      concept_count: 1
+      alternative_path_count: 1
+      cognitive_load: 0.2
+    score: 0.3
+
+  risk:
+    level: "LOW"
+    reasons:
+      - "presentation only"
+      - "splitting can lose meaning at a bad boundary; guarded by content-loss check"
+
+  economics:
+    estimated_experiment_cost: 0.0
+    estimated_implementation_cost: 0.0
+    currency: "EUR"
+    expected_value_class: "MEDIUM"
+
+  learning_value:
+    score: 0.8
+    notes: >
+      Tests whether an audience will read long-form in place, which is the
+      question behind every publishing interface HelixForge will build.
+
+  success_criteria:
+    expression: >
+      read_through_rate >= 0.15 AND messages_per_entry <= 4 AND no guardrail violation
+
+  failure_criteria:
+    expression: >
+      any hard guardrail violation
+      OR read_through_rate below the teaser alternative over the same window
+
+  outcome:
+    status: null
+    summary: null
+    evidence_refs: []

hypotheses/H-tg-teaser.yaml

@@ -0,0 +1,125 @@
+# Competing hypothesis A, in group CG-tg-length.
+#
+# Create with:
+#   fluid hypothesis create --file hypotheses/H-tg-teaser.yaml
+#   fluid hypothesis compete --group CG-tg-length H-tg-teaser H-tg-serial
+fluid_hypothesis:
+  schema_version: "0.1"
+
+  id: "H-tg-teaser"
+  interface_id: "helix-forge-telegram-publishing"
+  state: "DRAFT"
+
+  title: "A teaser and a link serve readers better than the whole entry"
+
+  observation:
+    summary: >
+      85% of hall entries exceed Telegram's 4096-character message limit, with
+      a median body of 5767 characters. The interface must choose a form for
+      long entries before it can publish at all.
+    evidence_refs:
+      - "measurement:hall-of-helix/entries@2026-09-04"
+      - "pressure:P-tg-length"
+    affected_cohorts:
+      - "telegram-subscribers"
+
+  pressure:
+    classes:
+      - "missing_interface_capability"
+    pressure_refs:
+      - "P-tg-length"
+    severity: 0.85
+    confidence: 1.0
+
+  explanation:
+    claim: >
+      A channel post is scanned, not read. A hall entry is a considered
+      first-person account that rewards attention. Presenting an opening and a
+      link lets a reader decide to give it that attention somewhere designed
+      for reading, rather than committing to a wall of text in a feed.
+    reach:
+      score: 0.5
+      explains:
+        - "P-tg-length"
+      notes: >
+        Medium reach. It answers the length constraint and would answer the
+        same constraint on X, but it does not address entries with visuals or
+        entries readers might want to keep in the channel.
+
+  proposed_adaptation:
+    class: "presentation"
+    summary: >
+      Publish the title, the display name, the opening of the entry, and a link
+      to the full entry in hall-of-helix.
+    implementation_scope: "interface_only"
+
+  backend_requirements:
+    required: false
+    requirement_refs: []
+
+  expected_outcomes:
+    - metric: "read_through_rate"
+      cohort: "telegram-subscribers"
+      target: 0.15
+      direction: "higher"
+    - metric: "messages_per_entry"
+      cohort: "all"
+      baseline: 2.0
+      target: 1.0
+      direction: "lower"
+
+  guardrails:
+    - metric: "entry_content_loss"
+      operator: "=="
+      threshold: false
+    - metric: "error_rate"
+      operator: "<="
+      threshold: 0.01
+
+  fitness_dimensions:
+    expected:
+      client_utility: 0.4
+      discoverability: 0.5
+      simplicity: 0.6
+      correctness: 0.0
+      security: 0.0
+
+  complexity:
+    expected_delta:
+      operation_count: 0
+      concept_count: 0
+      cognitive_load: -0.1
+    score: 0.05
+
+  risk:
+    level: "LOW"
+    reasons:
+      - "presentation only; no contract or authorization change"
+      - "fully reversible by replacing the revision"
+
+  economics:
+    estimated_experiment_cost: 0.0
+    estimated_implementation_cost: 0.0
+    currency: "EUR"
+    expected_value_class: "MEDIUM"
+
+  learning_value:
+    score: 0.8
+    notes: >
+      Whichever way this resolves, the answer transfers directly to
+      fluid-x and fluid-substack, which face the same problem under
+      different constraints.
+
+  success_criteria:
+    expression: >
+      read_through_rate >= 0.15 AND no guardrail violation
+
+  failure_criteria:
+    expression: >
+      any hard guardrail violation
+      OR read_through_rate below the serialized alternative over the same window
+
+  outcome:
+    status: null
+    summary: null
+    evidence_refs: []