tegwick
49b7458dfe
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
2.9 KiB
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:
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.