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
70 lines
2.9 KiB
Markdown
70 lines
2.9 KiB
Markdown
# 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.
|