fluid-telegram/InterfaceEvolutionIntent.md

# Interface Evolution Intent — helix-forge-telegram-publishing

**Document version:** IEI-1
**Status:** active
**Last reviewed:** 2026-09-04

---

## 1. Purpose

This document defines the evolutionary intent and governance boundary of the
FLUID interface that publishes HelixForge material to Telegram.

It is subordinate to `helix-forge/INTENT.md` and does not redefine HelixForge's
mission. It answers one question:

> 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:** `helix-forge`

**Parent intent document:** `helix-forge/INTENT.md`

**Relevant parent mission:** HelixForge exists to turn intent into structure,
structure into capability, and capability into lasting progress. The Hall of
Helix is where that work's participants are acknowledged. This interface carries
those acknowledgements outward.

---

## 3. Interface Identity

**Interface name:** HelixForge Telegram Publishing

**Interface identifier:** `helix-forge-telegram-publishing`

**Current operational authority mode:** FLUID-2

FLUID-2 (Advisory) is a deliberate choice, not a starting point to be outgrown
on a schedule. The Daimon may observe, classify pressure and propose
adaptations. It may not generate implementations, run experiments unattended, or
promote anything. This interface 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.

Raising the mode is a governance change under §20, not an operational decision.

**Protocols / interface styles:** REST over HTTP (JSON)

---

## 4. Mission

### Mission statement

> Make hall-of-helix entries reliably and faithfully available to a Telegram
> audience, without the people writing them having to think about Telegram.

An entry is written once, as Markdown, in `hall-of-helix/entries/`. Everything
about how it becomes a Telegram post — length, formatting, media, threading —
is this interface's problem and nobody else's.

### Success looks like

- A finished hall entry reaches the channel without a human reformatting it.
- The published form is faithful: no entry is silently truncated, and no
  attribution is lost.
- Publishing twice does not post twice.
- When Telegram's constraints and the entry's shape conflict, the conflict
  surfaces as recorded pressure rather than as a mangled post.

---

## 5. Intended Consumers

### Primary consumer cohorts

| Cohort | Description | Importance | Notes |
|---|---|---|---|
| `hall-publishing-jobs` | Automation in `hall-of-helix` that publishes finished entries | High | The reason this interface exists |
| `helix-forge-agents` | Agent sessions announcing their own completed work | High | Highest-volume caller; supplies the richest pressure signal |
| `operators` | Humans publishing or correcting by hand | Medium | Low volume, high consequence |

### Secondary cohorts

| Cohort | Description | Importance | Notes |
|---|---|---|---|
| `telegram-subscribers` | Readers of the channel | Medium | Not API consumers; observed through engagement, never individually |

### Explicitly unsupported cohorts

- Third-party services outside the HelixForge boundary.
- Anonymous or unauthenticated callers.
- Anything seeking to publish content it did not author.

---

## 6. Capability Domain

### In scope

- Publishing hall-of-helix entries to a Telegram channel (Canon PUB-01).
- Rendering an entry into Telegram's message forms (Canon PUB-02, MED-02).
- Publication state: what was published, when, as which message.
- Idempotency and correction of previously published entries.
- Bot identity presentation (Canon BOT-01).

### Conditionally in scope

Capabilities that may be introduced if evidence justifies them:

- Scheduling a publication for a later time.
- Publishing other HelixForge artifacts, such as release notes.
- Attaching entry visuals as media (Canon MED-01).
- A linked discussion group for comments.

### Out of scope

- Inbound bot commands and conversation (Canon BOT-02, AGT-01). A second
  revision family may add this later; it is not this interface today.
- Payments and paid content (Canon PAY-*).
- Mini Apps (Canon APP-*).
- Moderation and membership management (Canon COM-02, COM-03).
- Any capability requiring a Telegram user account rather than a bot.

---

## 7. Responsibility Boundaries

### Responsibilities owned by this interface

- Representation: how an entry becomes one or more Telegram messages.
- Composition: assembling an entry, its metadata and its visual.
- Validation: refusing an entry that cannot be published faithfully.
- Routing: which revision serves a publication request.
- Idempotency: recognising an entry it has already published.

### Responsibilities owned by backend systems

| Backend | Responsibility | Boundary |
|---|---|---|
| Telegram Bot API | Message delivery, channel state, subscriber identity | FLUID may request delivery. It may not assume a limit will move, and must treat platform constraints as fixed. |
| `hall-of-helix` | Entry content, its correctness, and whether it is finished | FLUID may read entries. It must never edit one to make it publishable. |
| OpenBao | Custody of the bot token | FLUID receives a credential. It never stores, logs or forwards one. |

### Explicit non-authority

The Daimon must not autonomously:

- create, rename or delete Telegram channels, groups or bots;
- change channel membership, administrators or permissions;
- read, rotate or re-scope the bot token;
- edit or truncate a hall-of-helix entry to fit a platform constraint;
- publish to any chat other than those declared in the routing configuration;
- post on behalf of a person who has not asked for it.

The last of these matters most. A hall entry is a first-person account someone
wrote about their own work. Publishing it is an act taken on their behalf, and
that authority comes from their having written it — not from the interface
finding it convenient.

---

## 8. Consumer Expectation Model

### Concepts consumers should naturally understand

- An **entry** is the unit of publication, identified by its hall entry id.
- Publishing is **idempotent** on that id.
- A **publication** has state: pending, published, failed, superseded.

### Interaction patterns considered natural

- Publish one finished entry, then check its state.
- Re-publish the same entry after a correction and get the same message updated.
- List what has been published to reconcile against the hall.

### Expectations that should be discouraged

- That Telegram formatting is Markdown. It is not, and entries that assume so
  will render wrongly.
- That an entry appears instantly. Rate limits are real.
- That a long entry arrives as one message. It cannot, and the interface's job
  is to make that invisible rather than to pretend otherwise.

---

## 9. Optimization Preferences

### Active optimization regime

`ADOPTION` — the channel has no audience yet. Until it does, discoverability and
client utility matter more than efficiency, and cost is negligible at this
volume.

### Fitness priorities

| Dimension | Priority | Target / Constraint | Notes |
|---|---:|---|---|
| Correctness | High | No entry published in a form that loses content | Hard guardrail |
| Client utility | High | One call publishes one entry | The reason the interface exists |
| Reliability | High | Publication succeeds or reports why | |
| Discoverability | High | A reader can reach the full entry | Drives the first experiment |
| Security | High | Token never leaves its custody | Hard guardrail |
| Compatibility | Medium | Versioned evolution | Few consumers, all internal |
| Simplicity | Medium | Prefer one publication concept | |
| Performance | Low | Publication is not latency-sensitive | Minutes are acceptable |
| Operational cost | Low | Negligible at this volume | |

### Automatic recommendation policy

`advisory` — the Daimon may recommend regime changes. It may not enact one.

---

## 10. Complexity Budget

### Complexity dimensions

| Dimension | Current | Preferred | Maximum | Scoring method |
|---|---:|---:|---:|---|
| Surface area (operations) | 3 | 4 | 8 | Count of declared operations |
| Concept count | 2 | 3 | 5 | entry, publication |
| Parameter dimensionality | 4 | 6 | 12 | Declared parameters across operations |
| Semantic overlap | 0 | 0 | 1 | Operations meaning the same thing |
| Alternative-path count | 1 | 1 | 3 | Ways to achieve one outcome |
| Backend composition count | 1 | 2 | 3 | Backends per operation |
| Active revision count | 1 | 2 | 3 | Concurrently routable revisions |

### Complexity policy

- New capability should replace or generalize existing capability where
  reasonable.
- Semantic duplication is rejected unless justified in writing.
- Repeated special-case pressure triggers an abstraction review rather than
  another endpoint.
- A candidate exceeding a hard maximum must not be promoted.
- Presentation adaptations do not consume surface-area budget: they change how
  an entry is rendered, not what the interface offers.

---

## 11. Compatibility Policy

### Compatibility posture

`VERSIONED`

### Rules

- Published revision semantics must not change silently.
- Breaking changes require a successor revision.
- Every consumer is internal and known, so a breaking change is a coordination
  problem rather than a public one — but it is still a successor revision.
- A change to how an entry is *rendered* is a presentation adaptation and does
  not break the contract, even though readers will notice it.

### Coexistence expectations

**Default maximum concurrent major revisions:** 2

**Default deprecation period:** 30 days after the last call from any consumer

**Migration assistance required:** yes — this interface has few enough consumers
that migration means telling their owners directly.

---

## 12. Revision and Experiment Policy

### Allowed concurrent exposure

| Revision class | Production traffic allowed? | Max share | Approval required? |
|---|---|---:|---|
| stable | yes | 100% | no |
| candidate | yes | 30% | yes, human |
| experiment | yes | 20% | yes, human |
| deprecated | yes | 100% | no |
| retired | no | 0% | n/a |

### Evolution velocity controls

The Daimon should slow or freeze promotion when:

- any entry has been published in a form that lost content;
- the bot has been rate-limited by Telegram in the last 24 hours;
- a security event has touched the token;
- an experiment is already running. Concurrency limit: 1.

The Daimon may accelerate experimentation when:

- the channel has more than 100 subscribers, giving experiments real power;
- the last three experiments completed without a guardrail breach.

**Note on experiment power.** At current volume — roughly one entry published
per week — an experiment needs months to reach a decidable sample. The evaluator
will report INCONCLUSIVE, and that is the correct answer. Do not shorten windows
to force a verdict.

---

## 13. Hypothesis Policy

### Minimum evidence for hypothesis creation

- At least 5 independent observations, or one unavoidable structural constraint.
- Observation window of at least 14 days for behavioural pressure.
- A structural constraint (a platform limit) may found a hypothesis immediately;
  it does not need repetition to be real.

### Required hypothesis fields

observation, explanation, proposed adaptation, expected outcome, measurement,
success criteria, guardrails, complexity impact, risk, expected learning value.

### Competing hypotheses

`encouraged` — the first pressure this interface faces has at least two
defensible answers, and choosing between them by argument rather than evidence
is exactly the habit FLUID exists to break.

### Reach preference

Prefer the smallest sufficient adaptation. This interface is small enough that a
high-reach abstraction would be speculative; revisit when there are more than
three distinct kinds of pressure.

---

## 14. Adaptation Authority

| Adaptation class | Observe | Propose | Generate | Experiment | Promote |
|---|---:|---:|---:|---:|---:|
| Presentation | yes | yes | no | no | no |
| Contract | yes | yes | no | no | no |
| Composition | yes | yes | no | no | no |
| Implementation | yes | yes | no | no | no |
| Requirement escalation | yes | yes | yes | n/a | n/a |

Every `Generate`, `Experiment` and `Promote` column is `no`, which is what
FLUID-2 means. Requirement escalation is the exception: the Daimon may write a
structured backend requirement, because that artifact is a request to someone
else and carries no authority of its own.

### 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;
- publish anything to a live channel;
- alter the content of a hall entry.

---

## 15. Security Requirements

### Authentication

Consumers authenticate to the gateway. The bot token authenticates the adapter
to Telegram and is never a consumer credential.

### Authorization

Only declared cohorts may publish. `telegram-subscribers` is an observed
population, not a caller.

### Tenant isolation

Single tenant. The interface serves HelixForge and no one else.

### Data handling

Telegram user identity (Canon ID-01) must not enter the evidence store in any
form. Subscriber engagement is recorded only as aggregate counts, subject to the
cohort minimum size. This is a hard constraint: readers of a public channel have
not consented to individual observation, and a framework built to learn from
consumers must not quietly learn about audiences.

### Logging and provenance

Every publication records which entry, which revision, which message, and which
consumer asked. The bot token appears in no log, error, telemetry event or
evidence record.

### AI boundary

AI-generated changes must pass deterministic security policy, tests,
authorization validation and release controls. At FLUID-2 no AI-generated change
reaches this interface at all.

---

## 16. Quality Requirements

| Quality attribute | Requirement | Hard guardrail? |
|---|---|---:|
| Correctness | No published entry loses content or attribution | yes |
| Idempotency | Publishing an entry twice yields one publication | yes |
| Availability | Best effort; publication may be retried | no |
| Reliability | A failed publication reports why and may be retried safely | yes |
| p95 latency | Under 10s excluding Telegram rate limiting | no |
| Error rate | Under 1% of publication attempts | yes |
| Security | Token never leaves custody | yes |
| Auditability | Every publication traceable to entry, revision and caller | yes |
| Rollback | Any revision can be replaced by its predecessor within one policy generation | yes |

---

## 17. Economic Constraints

### Adaptive compute budget

| Budget | Limit |
|---|---:|
| analysis per day | 1 classification pass |
| hypothesis generation | manual only at FLUID-2 |
| candidate generation | not permitted at FLUID-2 |
| concurrent experiments | 1 |
| autonomous implementation effort | none |

### Cost policy

- Adaptive budget exhaustion must not affect publication.
- The dominant cost here is human attention, not compute. A hypothesis that
  needs more review time than the improvement is worth should be deferred.

---

## 18. Backend Capability Escalation

### Preferred requirement destination

Telegram platform constraints cannot be escalated to anyone — there is no
recipient. A requirement naming a Telegram limitation is recorded as evidence
for **boundary learning** instead, and the interface adapts around the
constraint or declares the demand out of scope.

Requirements against `hall-of-helix` (entry structure, metadata) go to that
repository as an issue referencing the originating hypothesis.

### Required response states

ACCEPTED, PLANNED, AVAILABLE, PARTIALLY_AVAILABLE, OUT_OF_SCOPE, REJECTED,
SUPERSEDED.

### Boundary-learning policy

Repeated OUT_OF_SCOPE or REJECTED responses trigger a review of whether the
demand belongs to a neighbouring interface — most likely `fluid-x` or
`fluid-substack`, which face the same publishing problem under different
platform constraints.

---

## 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 and final disposition.

### Retention period

Evidence: 365 days. Publication records: indefinite, because they are the record
of what was said in HelixForge's name.

### Immutable evidence store

The fluid-core evidence store, append-only at the database.

---

## 20. Review and Amendment

### Amendment authority

Bernd Worsch, as the owner of `helix-forge`. An amendment is a governance change
and is recorded as a new intent version; the previous version stays retrievable
because revisions published under it were governed by it.

### Review cadence

On any of: raising the authority mode, adding a capability family currently out
of scope, the first 100 subscribers, or annually.

### Last reviewed

2026-09-04 (initial)

---

## 21. Summary

The Daimon should optimize aggressively inside this document and remain
conservative at its boundaries.

This interface may evolve in how it presents an entry. It may not evolve in
whose voice it speaks.