2026-09-04 11:09:02 +02:00
|
|
|
---
|
|
|
|
|
repo: fluid-telegram
|
|
|
|
|
updated: "2026-09-04"
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
# INTENT
|
|
|
|
|
|
|
|
|
|
## Why it exists
|
|
|
|
|
|
2026-09-04 19:21:08 +02:00
|
|
|
`fluid-telegram` is the FLUID interface `helix-forge-telegram-publishing`: the
|
|
|
|
|
deterministic outbound surface through which HelixForge material reaches
|
|
|
|
|
Telegram.
|
2026-09-04 11:09:02 +02:00
|
|
|
|
2026-09-04 19:21:08 +02:00
|
|
|
It exists because publishing under an organisation's name to an audience of
|
|
|
|
|
strangers is a governed act, not a side effect of having a bot token. The
|
|
|
|
|
interface makes that act legible: every publication carries a named reviewer, a
|
|
|
|
|
recorded consent basis, and a citation to the work it describes, and every one
|
|
|
|
|
of them is reconstructible afterwards from the evidence store.
|
|
|
|
|
|
|
|
|
|
## What it is not
|
|
|
|
|
|
|
|
|
|
**It is not a content system.** The channel does not republish hall entries. A
|
|
|
|
|
hall entry is a considered first-person account written for a colleague reading
|
|
|
|
|
a repository; a channel post is short, personal and written to travel. The post
|
|
|
|
|
is composed *from* the entry and is a different piece of writing.
|
|
|
|
|
|
|
|
|
|
Composition therefore happens **before** this interface is called, and belongs
|
|
|
|
|
to the campaign repository `pr-hall-of-helix`. The boundary is architectural —
|
|
|
|
|
`ArchitectureBlueprint.md` §48.1 forbids an LLM in the mandatory request path —
|
|
|
|
|
and editorial, because a post speaks about a named person's work in HelixForge's
|
|
|
|
|
voice and deserves a human read before it goes out.
|
|
|
|
|
|
|
|
|
|
This repository renders and delivers what it is given. It never writes, selects,
|
|
|
|
|
shortens or embellishes. A post that will not fit is refused, not truncated.
|
2026-09-04 11:09:02 +02:00
|
|
|
|
|
|
|
|
## Governing principle
|
|
|
|
|
|
2026-09-04 19:21:08 +02:00
|
|
|
`InterfaceEvolutionIntent.md` (IEI-1) is the constitutional constraint on this
|
|
|
|
|
interface and takes precedence over this file where they touch. It is
|
|
|
|
|
subordinate in turn to `helix-forge/INTENT.md`.
|
|
|
|
|
|
|
|
|
|
Operational authority is **FLUID-2 (Advisory)** by deliberate choice: the Daimon
|
|
|
|
|
may observe, classify pressure and propose adaptations, but may not generate
|
|
|
|
|
implementations, run experiments unattended, or promote anything. Raising that
|
|
|
|
|
mode is a governance change under IEI-1 §20, not an operational decision.
|
|
|
|
|
|
|
|
|
|
Work that changes this repository's authority, ownership boundaries, or
|
|
|
|
|
operational promises is captured in a workplan before implementation.
|
2026-09-04 11:09:02 +02:00
|
|
|
|
|
|
|
|
## What it enables
|
|
|
|
|
|
2026-09-04 19:21:08 +02:00
|
|
|
- HelixForge can publish to Telegram under a stated intent, with a contract, a
|
|
|
|
|
revision history, and an audit trail that reconstructs any publication.
|
|
|
|
|
- A campaign (`pr-hall-of-helix`) can publish through a delivery surface it does
|
|
|
|
|
not have to own, and receive per-variant engagement back.
|
|
|
|
|
- Delivery questions — attach a portrait or not, which form travels further —
|
|
|
|
|
can be settled by experiment rather than by preference.
|
|
|
|
|
- The interface is reusable by any HelixForge campaign, not only the Hall of
|
|
|
|
|
Helix.
|