# 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 > Deliver composed channel posts to a Telegram audience reliably, verifiably, > and without an unreviewed word ever reaching a subscriber. The unit of publication is a **post**, not a hall entry. A post is short, personal and written to travel; a hall entry is a considered first-person account written for someone reading a repository. They are different pieces of writing for different readers, and the second is the source of the first rather than its content. **Composition is not this interface's job.** Turning an entry into a post that is condensed, entertaining and reach-optimized is a probabilistic, editorial task. It happens upstream, before this interface is called. Two reasons, and the first is architectural rather than stylistic: 1. `ArchitectureBlueprint.md` §48.1 names an LLM in the mandatory request path as an anti-pattern. An interface that composed on demand would be non-deterministic at exactly the point where determinism is the whole claim. 2. A composed post speaks about a named person's work in HelixForge's voice. That deserves a human read before it goes out, and a review step in the request path is a review step nobody performs. ### Success looks like - A composed post reaches the channel without a human formatting it for Telegram. - No post reaches a subscriber unreviewed. - Every post is traceable to the entry it was written from, so a claim can be checked against what the person actually said. - Publishing twice does not post twice. - Engagement is attributable to the composition strategy that produced it, so the campaign can learn which writing travels. --- ## 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 composed posts to a Telegram channel (Canon PUB-01). - Rendering a post into Telegram's message forms (Canon PUB-02, MED-02). - Attaching a visual to a post (Canon MED-01). - Publication state: what was published, when, as which message. - Idempotency and correction of previously published posts. - Recording the composition variant a post came from, and reporting engagement against it. - 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 material, such as release notes. - A linked discussion group for comments. - Publishing to more than one channel from one call. ### Out of scope - **Composing post text from a source entry.** This belongs to the campaign that owns the editorial voice, not to the interface that delivers it. See §7. - 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 a composed post becomes a Telegram message. - Delivery: attaching the visual, the source link, the formatting. - Validation: refusing a post that arrives unreviewed, unattributed, or in a form Telegram cannot carry. - Routing: which revision serves a publication request. - Idempotency: recognising a post it has already published. - Attribution of engagement to composition variants. ### 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. | | `pr-hall-of-helix` (planned) | Composing posts, the editorial voice, choosing what is worth publishing, obtaining subject consent | FLUID publishes what it is given and reports how it performed. It does not write, edit or select. | | `hall-of-helix` | Entry content, its correctness, and whether it is finished | FLUID never reads or edits an entry. Its only knowledge of one is the id and URL a post cites. | | OpenBao | Custody of the bot token | FLUID receives a credential. It never stores, logs or forwards one. | Until `pr-hall-of-helix` exists, composition is done by hand as part of `FT-WP-0001`. That is a temporary arrangement, and the boundary above is written for the state it is heading toward rather than the state it is in — so that the campaign, when it is extracted, finds the seam already cut. ### 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; - compose, rewrite, shorten or embellish post text; - publish a post that carries no reviewer; - publish to any chat other than those declared in the routing configuration; - publish a post about a person who has not consented, on either basis in §15. The last two matter most, and they are the reason composition sits outside this interface. A post is a condensation written in HelixForge's voice about a named person's work. It can flatter, it can misstate, and it can put a claim in someone's mouth that their own entry never made — and in the audit trail an unfaithful post looks exactly like a faithful one. The defence is not that the composer is careful. It is that a human read the post, the post names the entry it came from, and both are recorded before anything reaches a subscriber. --- ## 8. Consumer Expectation Model ### Concepts consumers should naturally understand - A **post** is the unit of publication, identified by its own post id. - A post **cites** the hall entry it was written from; it is not that entry. - Publishing is **idempotent** on the post id. A recomposition is a new post, because it is a different piece of writing about the same work. - A **publication** has state: pending, published, failed, superseded. ### Interaction patterns considered natural - Compose a post, have it reviewed, publish it, check its state. - Re-publish the same post id after a correction and get the same message updated. - List publications by composition variant to compare how they performed. ### Expectations that should be discouraged - That Telegram formatting is Markdown. It is not, and posts that assume so will render wrongly. - That a post appears instantly. Rate limits are real. - That this interface will shorten an over-length post. It will refuse it. A composition that does not fit was not condensed, and deciding what to cut is the composer's judgement, not the deliverer's. - That publishing a hall entry is possible. It is not: entries are sources, and posts are what this interface carries. --- ## 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 post published unreviewed or unattributed | Hard guardrail | | Client utility | High | One call publishes one post | The reason the interface exists | | Reliability | High | Publication succeeds or reports why | | | Discoverability | High | A reader can reach the source 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 | post, 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 a post is delivered, not what the interface offers. - Any candidate that would move composition inside this interface is rejected regardless of its complexity score. That boundary is not a budget question. --- ## 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 a post is *delivered* — visual placement, link style, formatting — 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. Note the division of labour. Competitions about **delivery** — does a visual help, does a link preview help — belong to this interface and are run here. Competitions about **composition** — which editorial voice travels — belong to the campaign, and are run on the per-variant engagement this interface reports. Both are legitimate FLUID experiments; only the first is this interface's. ### 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. ### Subject consent A post speaks publicly about a named person's work. Two bases are recognised: - **standing** — the contributor agreed, when they took a seat in the hall, that HelixForge may write about that work publicly. This is the ordinary case and requires the agreement to actually exist, in `hall-of-helix/ENTRY.md`, and to be revocable. - **explicit** — per-post approval from the subject. Required where the post makes a claim the entry does not, quotes the subject, or concerns work they have since asked not to be publicised. `not-required` covers posts about the project itself with no personal subject. A post carrying no basis is refused with 403. Absence of objection is not consent, and the interface must not treat it as such. ### 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 post, which source entry, which reviewer, which revision, which message, and which consumer asked. The bot token appears in no log, error, telemetry event or evidence record. Post *text* is retained in the publication record. It is what was said in HelixForge's name, and an audit that could not reproduce it would be unable to answer the only question that matters when a post is disputed. ### 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 post published without a reviewer and a cited source entry | yes | | Consent | No post about a subject without a recorded basis | yes | | Idempotency | Publishing a post 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 post text, source entry, reviewer, 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 delivers a post. It may not evolve into writing one. The voice belongs to the campaign, the work belongs to the person who did it, and this interface's job is to carry the first without misrepresenting the second.