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

docs/observation.md

@@ -0,0 +1,70 @@
+# Cohorts, telemetry and redaction
+
+## Cohorts
+
+Four populations, deliberately coarse. Blueprint §6.3 asks for cohorts stable
+enough to compare over time and no more granular than the analysis requires.
+
+| Cohort | Assigned by | Why it is distinct |
+|---|---|---|
+| `hall-publishing-jobs` | `X-FLUID-Consumer` prefix `hall-` | Batch behaviour; publishes many entries at once |
+| `helix-forge-agents` | `X-FLUID-Consumer` prefix `agent-` | One entry at a time, at session end; the richest pressure signal |
+| `operators` | `X-FLUID-Consumer` prefix `op-` | Rare, deliberate, often corrective |
+| `telegram-subscribers` | Not a caller | An observed population, never an API consumer |
+
+`telegram-subscribers` deserves care. It appears in experiment allocation and in
+engagement metrics, but it never authenticates and never appears as
+`ConsumerRef`. Treating readers as consumers would be the first step toward
+observing them individually.
+
+## Redaction
+
+```
+CohortMinimumSize: 5
+RetentionDays:     365
+AllowRawPayload:   false
+```
+
+Beyond the fluid-core defaults, this interface adds:
+
+- **No Telegram user identity, ever.** Canon ID-01 identities — user ids,
+  usernames, display names of subscribers — must not reach the evidence store
+  in any form, redacted or otherwise. There is no legitimate analysis that
+  needs them, so the safe rule is that they never arrive.
+- **Entry content is not telemetry.** An entry body may appear in a request; it
+  must not appear in a telemetry event. What is recorded is its length, its
+  section count, and whether conversion succeeded.
+- **The bot token appears nowhere.** Not in errors, not in traces, not in
+  redacted form.
+
+## The pseudonymization salt
+
+Generate once, store in OpenBao alongside the bot token, inject as
+`FLUID_REDACTION_SALT`:
+
+```bash
+openssl rand -hex 32
+```
+
+It must never change. Rotating it makes every previously-seen consumer look
+new, which silently invalidates every longitudinal comparison the interface has
+accumulated. If it is ever compromised, the correct response is to accept the
+loss and start a fresh evidence baseline, not to rotate quietly.
+
+## Metrics
+
+| Metric | Role | Source |
+|---|---|---|
+| `read_through_rate` | primary | Telegram channel statistics, aggregate |
+| `messages_per_entry` | guardrail | Adapter |
+| `entry_content_loss` | guardrail | Adapter |
+| `error_rate` | guardrail | Gateway |
+| `reaction_rate` | secondary | Telegram channel statistics, aggregate |
+| `time_to_first_read` | learning | Telegram channel statistics, aggregate |
+
+`read_through_rate` is the one to be careful about. Telegram reports view counts
+per message, not per reader. For the teaser form it is link clicks over views;
+for the serialized form it is views of the last part over views of the first.
+Those are not the same measurement, and comparing them directly is the weakest
+part of the first experiment. Say so in the experiment's amendment record rather
+than letting the comparison look cleaner than it is.