fluid-telegram/TelegramCapabilityCanon.md

# Telegram Capability Canon

**Status:** Draft v0.1  
**Date:** 2026-09-03  
**Purpose:** Canonical capability model for using Telegram as a messaging, publishing, community, application, commerce, and human/agent interaction platform.

---

## 1. Purpose

This canon provides a durable capability model for Telegram.

It is intentionally not organized around the Telegram user interface or a chronological list of product features. Instead, it describes Telegram as a set of reusable platform capabilities that can be mapped to concrete products, communities, businesses, automations, and agentic systems.

The primary questions are:

1. What capability does Telegram provide?
2. Which Telegram surface exposes it?
3. Can it be accessed or controlled programmatically?
4. Can a bot or autonomous agent participate?
5. What are the important operational, security, and commercial constraints?
6. When should Telegram be treated as the system of record, and when should it remain only an interaction surface?

The canon is designed to support projects such as `telegram-edge`, community platforms such as the Coulomb Society, agentic personalities, publishing systems, customer communication, and Telegram-based applications.

---

# 2. Platform Model

Telegram should be treated as six overlapping platforms:

```text
Telegram
│
├── Messaging Platform
│   ├── person ↔ person
│   ├── person ↔ bot
│   ├── group interaction
│   └── voice / video
│
├── Publishing Platform
│   ├── channels
│   ├── stories
│   ├── public posts
│   └── live media
│
├── Community Platform
│   ├── groups
│   ├── topics
│   ├── channels
│   ├── communities
│   └── moderation
│
├── Application Platform
│   ├── bots
│   ├── mini apps
│   ├── identity
│   ├── payments
│   └── external integrations
│
├── Commerce / Business Platform
│   ├── business accounts
│   ├── customer communication
│   ├── payments
│   ├── subscriptions
│   ├── monetization
│   └── advertising
│
└── Human / Agent Interaction Platform
    ├── AI bots
    ├── streaming responses
    ├── guest bots
    ├── managed bots
    ├── bot-to-bot communication
    └── delegated business automation
```

These platforms share identity, messaging, discovery, media, permission, notification, and payment primitives.

---

# 3. Capability Levels

Each capability in this canon can be considered at five implementation levels.

| Level | Meaning |
|---|---|
| **L0 — Human UI** | Available to a normal Telegram user through an official client. |
| **L1 — Bot Accessible** | A Telegram bot can participate using the Bot API. |
| **L2 — Application Accessible** | Mini Apps or external services can integrate with the capability. |
| **L3 — Client/API Accessible** | Full Telegram API / MTProto / TDLib clients can access or implement the capability. |
| **L4 — Agentic** | The capability is suitable for delegated or autonomous software-agent participation. |

A capability may exist at more than one level.

---

# 4. Messaging Capabilities

## MSG-01 — One-to-One Messaging

Telegram provides persistent cloud-based one-to-one conversations.

### Functions

- text messages;
- replies;
- forwarding;
- message editing;
- message deletion;
- reactions;
- rich formatting;
- links;
- media;
- files;
- contacts;
- locations;
- voice messages;
- video messages;
- polls where supported;
- search;
- pinned content;
- scheduled messages;
- repeating scheduled messages.

### Automation

Bots provide a first-class machine participant in private chats.

### Agentic relevance

**High.**

A private bot conversation is one of the cleanest Telegram surfaces for:

- personal assistants;
- AI agents;
- workflow interaction;
- approvals;
- notification delivery;
- command interfaces;
- conversational applications.

### Design note

Telegram should normally be treated as the **interaction surface**, not the sole persistent state store for sophisticated applications.

---

## MSG-02 — Group Messaging

Telegram supports large multi-party conversations.

### Functions

- persistent shared history;
- replies;
- mentions;
- reactions;
- member permissions;
- administrator roles;
- pinned messages;
- media and files;
- polls and quizzes;
- bots;
- topics;
- moderation;
- member tags;
- voice/video sessions;
- join requests;
- invite links.

### Scale

Telegram groups can support very large communities, including supergroups with up to hundreds of thousands of members.

### Agentic relevance

**Very high.**

Groups can host:

- moderator agents;
- research agents;
- question-answering agents;
- community managers;
- workflow bots;
- onboarding assistants;
- summarization agents;
- security and policy enforcement systems.

---

## MSG-03 — Topics / Forum Conversations

Groups may be divided into topic-oriented threaded spaces.

### Uses

- project discussions;
- support cases;
- subject-specific conversations;
- working groups;
- structured community areas;
- agent-specific work contexts.

### Agentic relevance

**High.**

Topics provide a practical scope boundary for context and agent behavior.

---

## MSG-04 — Ephemeral Bot Interaction

Telegram supports bot responses inside groups that are visible only to the invoking user.

### Uses

- private AI summaries;
- account information;
- administrative actions;
- personal recommendations;
- sensitive workflow feedback without polluting the group timeline.

### Agentic relevance

**High.**

This allows shared social spaces to contain private machine interactions without forcing users into a separate chat.

---

# 5. Media Capabilities

## MED-01 — Rich Media Messaging

Telegram supports:

- images;
- video;
- animation;
- audio;
- voice notes;
- video notes;
- arbitrary documents;
- stickers;
- GIFs;
- live photos;
- maps and locations;
- albums and grouped media.

Bots can send and receive many of these media types.

---

## MED-02 — Rich Messages

The 2026 Bot API adds structured rich messages.

Supported constructs include, among others:

- headings;
- paragraphs;
- lists;
- tables;
- quotations;
- expandable sections;
- code/preformatted content;
- mathematical expressions;
- media;
- documents;
- maps;
- audio;
- images;
- video;
- buttons;
- references.

### Agentic relevance

**Very high.**

Rich messages substantially improve Telegram as an output surface for:

- research agents;
- reports;
- dashboards;
- comparisons;
- structured AI answers;
- approvals;
- operational summaries.

---

## MED-03 — Live Response Streaming

Bots can stream text while a response is being generated.

### Uses

- generative AI;
- search;
- analysis;
- long-running workflows;
- interactive research.

### Agentic relevance

**Core capability.**

Streaming reduces the difference between a dedicated AI application and an AI service operating inside Telegram.

---

# 6. Publishing Capabilities

## PUB-01 — Channels

Channels provide one-to-many publishing.

### Characteristics

- potentially unlimited subscriber audience;
- public or private;
- administrator roles;
- persistent post history;
- rich media;
- polls;
- stories;
- comments through linked discussion groups;
- direct messages to channel operators;
- subscriber interaction;
- analytics/statistics;
- monetization capabilities.

### Suitable for

- institutional publishing;
- news;
- product announcements;
- research publication;
- creator content;
- corporate communications.

### Agentic relevance

**High.**

Agents can prepare, schedule, curate, moderate, and—in appropriately governed environments—publish content.

---

## PUB-02 — Long-Form Rich Posts

Telegram's 2026 rich-text editor allows long structured content.

Capabilities include:

- headings;
- lists;
- tables;
- quotes;
- inline media;
- generated text;
- formulas.

Messages can extend substantially beyond conventional chat-message length.

### Consequence

Telegram increasingly overlaps with lightweight:

- blogging;
- newsletters;
- documentation;
- knowledge publishing.

---

## PUB-03 — Stories

Telegram supports temporary story-style publishing.

Possible uses include:

- announcements;
- event coverage;
- informal updates;
- creator communication;
- live experiences.

---

## PUB-04 — Public Discovery

Public Telegram content can be discoverable through platform search.

Relevant entities include:

- users;
- channels;
- groups;
- bots;
- public posts.

### Strategic implication

Telegram is not only a subscribed-content medium. It increasingly provides **content discovery**.

---

# 7. Community Capabilities

## COM-01 — Community Composition

Telegram introduced **Communities** as a mechanism for linking several:

- groups;
- channels;
- bots.

Members can access associated spaces through a coherent community entry.

### Importance

This creates an explicit organizational layer above individual chats.

A conceptual model is:

```text
Community
├── announcement channel
├── general group
├── specialist groups
├── project groups
├── event group
├── service bot
└── community agent
```

### Agentic relevance

**Very high.**

Communities create natural scopes for:

- agent permissions;
- institutional identity;
- moderation;
- workflows;
- specialized service agents.

---

## COM-02 — Membership Management

Telegram provides:

- private/public spaces;
- invite links;
- join requests;
- member permissions;
- administrator permissions;
- ownership;
- member removal;
- restrictions;
- approval workflows.

---

## COM-03 — Moderation

Native and bot-based moderation can include:

- delete messages;
- restrict members;
- ban members;
- approve join requests;
- control media permissions;
- manage topics;
- manage tags;
- enforce community rules.

Telegram has increasingly added AI-related moderation capabilities.

### Architecture rule

High-impact moderation should not depend solely on probabilistic model behavior.

Recommended structure:

```text
AI assessment
      ↓
policy decision
      ↓
deterministic enforcement layer
      ↓
Telegram API action
```

---

## COM-04 — Polls, Quizzes and Collective Decisions

Telegram polls provide lightweight collective interaction.

Uses:

- community decisions;
- surveys;
- event planning;
- knowledge quizzes;
- feedback;
- agent-generated voting proposals.

---

# 8. Bot Platform

## BOT-01 — Bot Identity

Bots are first-class Telegram accounts designed for software.

They:

- have usernames;
- have profiles;
- can receive messages;
- can send messages;
- can belong to groups;
- can administer groups/channels if authorized;
- do not require a phone number for normal bot creation.

Bots execute application logic outside Telegram and communicate through Telegram APIs.

---

## BOT-02 — Commands

Bots may expose commands such as:

```text
/start
/help
/search
/status
/approve
```

Commands can vary by chat context and user scope.

---

## BOT-03 — Interactive Keyboards

Bots support:

- reply keyboards;
- inline keyboards;
- callback buttons;
- links;
- selectors;
- menus.

These allow chat messages to behave like lightweight application interfaces.

---

## BOT-04 — Inline Bots

Bots can be invoked from the message field of other chats.

Conceptually:

```text
@agent query
```

This makes a service available without requiring users to leave their current conversation.

---

## BOT-05 — Deep Linking

Links can open:

- bots;
- specific bot states;
- Mini Apps;
- group invitations;
- channels;
- other Telegram resources.

Deep links enable Telegram to participate in external application workflows.

---

## BOT-06 — Guest Bots

Guest bots can answer invocations in chats even when they are not permanent members of those chats.

### Agentic relevance

This enables a useful pattern:

```text
conversation
   ↓
invoke specialist agent
   ↓
temporary context access
   ↓
result
```

This reduces the need to permanently install every specialist bot into every group.

---

## BOT-07 — Managed Bots

Telegram supports programmatic creation and management of subordinate bots.

### Agentic relevance

**Extremely high.**

Managed bots enable hierarchical agent architectures:

```text
Agent Manager
├── Research Bot
├── Publishing Bot
├── Moderation Bot
├── Event Bot
└── Support Bot
```

A management system can create and administer specialized Telegram identities dynamically.

---

## BOT-08 — Bot-to-Bot Communication

Telegram supports direct coordination between bots.

### Consequence

Telegram can serve not only as a human-agent interaction surface but also as part of an **agent communication topology**.

This should not automatically make Telegram the internal agent message bus; dedicated infrastructure may be more appropriate for high-volume or security-sensitive coordination.

---

## BOT-09 — Business Bots

Business accounts may delegate selected messaging capabilities to bots.

### Uses

- customer support;
- lead qualification;
- automated responses;
- workflow initiation;
- CRM integration;
- booking;
- commerce.

### Governance requirement

Delegated permissions should be explicit and minimal.

---

# 9. Mini App Platform

## APP-01 — Embedded Web Applications

Telegram Mini Apps are HTML/JavaScript applications displayed inside Telegram.

Telegram describes them as capable of replacing conventional websites for many workflows.

### Capabilities

- arbitrary web UI;
- Telegram identity;
- contextual launch;
- local/device storage;
- server integration;
- payment flows;
- push notifications;
- Telegram-aware navigation.

---

## APP-02 — Application Authentication

Mini Apps receive authenticated Telegram context.

### Suitable for

- personalized dashboards;
- account management;
- member portals;
- approvals;
- settings;
- workflow applications.

### Security rule

Telegram identity should usually be mapped to an internal canonical identity rather than used as the only authorization model.

```text
Telegram identity
       ↓
identity mapping
       ↓
internal subject
       ↓
policy / authorization
```

---

## APP-03 — Application UX Extension

Use a Mini App when chat interaction becomes awkward.

Typical threshold:

```text
conversation     → Bot
simple choice    → Buttons
structured form  → Mini App
complex workflow → Mini App / external application
```

---

# 10. Identity Capabilities

## ID-01 — Telegram User Identity

Telegram provides stable platform identities associated with accounts.

Relevant properties may include:

- user ID;
- username;
- profile;
- display name;
- phone-number relationship where authorized.

### Design rule

Do not treat usernames as immutable identifiers.

Use Telegram's numeric IDs for machine identity mapping.

---

## ID-02 — Login with Telegram

External applications can authenticate users through Telegram.

Suitable for:

- community portals;
- companion websites;
- membership applications;
- linked services.

---

## ID-03 — Privacy-Preserving Contact

Users can communicate without revealing their telephone number, depending on privacy configuration.

This is important for public communities and creator/follower relationships.

---

# 11. Business Capabilities

## BUS-01 — Business Profiles

Telegram Business accounts can expose:

- opening hours;
- business location;
- customized start page;
- quick replies;
- greeting messages;
- away messages.

---

## BUS-02 — Automated Customer Conversations

Bots can be attached to business communication.

Possible architecture:

```text
Customer
   ↓
Telegram
   ↓
Business Bot
   ↓
CRM / workflow / agent
   ↓
Business policy
   ↓
response
```

---

## BUS-03 — Direct Customer Interaction

Telegram can function as:

- support channel;
- sales channel;
- account-management channel;
- notification channel;
- service-delivery channel.

---

# 12. Commerce and Monetization

## PAY-01 — Payments

Bots and Mini Apps can support payment flows.

Depending on transaction type and Telegram rules, payment mechanisms may involve:

- external payment providers;
- platform-native payment mechanisms;
- Telegram Stars.

---

## PAY-02 — Digital Goods

Telegram Stars provide Telegram-native payment functionality for digital goods and services.

---

## PAY-03 — Paid Content

Possible models include:

- paid media;
- paid channel access;
- paid subscriptions;
- premium services;
- creator monetization.

---

## PAY-04 — Sponsored / Suggested Content

Telegram provides mechanisms through which channels and creators can monetize audience reach.

This can include:

- sponsored content;
- suggested posts;
- advertising revenue models;
- affiliate-style mechanisms.

---

# 13. Voice, Video and Live Interaction

## RTC-01 — Voice Calls

Telegram supports individual voice calling.

---

## RTC-02 — Video Calls

Telegram supports individual video calling and screen sharing.

---

## RTC-03 — Group Calls

Groups can host interactive voice/video sessions.

Suitable for:

- community meetings;
- office hours;
- events;
- discussions;
- presentations.

---

## RTC-04 — Live Streaming

Channels and other Telegram surfaces can support live broadcast-style interaction.

---

# 14. Notification Capabilities

## NOT-01 — Push Notifications

Telegram provides cross-platform push delivery through its clients.

This makes Telegram useful as a notification edge for external systems.

Examples:

```text
monitoring alert
build result
approval required
event reminder
community announcement
agent completion
security notification
```

---

## NOT-02 — User-Controlled Notification Policy

Users retain significant control over notification behavior.

Therefore:

> Telegram delivery does not guarantee user attention.

Applications requiring guaranteed acknowledgement should implement acknowledgement state externally.

---

# 15. Integration Surfaces

Telegram exposes several distinct integration surfaces.

## INT-01 — Bot API

HTTP API intended for bot applications.

Best suited for:

- chatbots;
- automation;
- notifications;
- community tools;
- agent interfaces;
- lightweight applications.

---

## INT-02 — Mini App API

JavaScript APIs for applications embedded inside Telegram.

Best suited for:

- forms;
- dashboards;
- account portals;
- commerce;
- complex interactions.

---

## INT-03 — Telegram API / MTProto

Provides lower-level access to Telegram's client capabilities.

Best suited for:

- custom clients;
- advanced integration;
- capabilities unavailable through the Bot API.

This surface requires considerably more care than ordinary bot development.

---

## INT-04 — TDLib

Telegram Database Library provides an abstraction for building complete Telegram clients.

Suitable for:

- embedded Telegram clients;
- specialized Telegram applications;
- advanced automation requiring real user/client capabilities.

---

## INT-05 — Web Login

Telegram can provide identity/authentication to external web systems.

---

# 16. Agentic Capability Model

Telegram's 2026 feature set makes it useful to explicitly distinguish five agent roles.

## AGT-01 — Conversational Agent

```text
Human ↔ Agent
```

Examples:

- assistant;
- advisor;
- support bot;
- knowledge agent.

---

## AGT-02 — Group Participant Agent

```text
Human
Human
Agent
Human
```

The agent participates in a shared social context.

Examples:

- community manager;
- moderator;
- researcher;
- facilitator.

---

## AGT-03 — Guest Specialist Agent

```text
Group
  ↓
invoke specialist
  ↓
Guest Bot
```

The agent enters the interaction only when needed.

---

## AGT-04 — Delegated Operator Agent

```text
Human owner
    ↓ authority
Agent
    ↓
Telegram resources
```

The agent may:

- answer messages;
- moderate;
- publish;
- manage workflows.

This requires explicit policy boundaries.

---

## AGT-05 — Multi-Agent System

```text
Coordinator
├── Research Agent
├── Publishing Agent
├── Moderator
├── Concierge
└── Operations Agent
```

Telegram now contains primitives supporting bot-to-bot communication and managed bots.

Telegram can therefore expose a multi-agent system directly to users.

---

# 17. Security Model

## SEC-01 — Cloud Chats

Ordinary Telegram cloud chats are encrypted in transit/client-server architecture but are not end-to-end encrypted in the same way as Secret Chats.

This distinction is important for security-sensitive systems.

---

## SEC-02 — Secret Chats

Secret Chats provide device-specific end-to-end encrypted communication.

They are fundamentally different from cloud chats and have different automation properties.

### Agentic limitation

Secret Chats are not a general-purpose bot interaction environment.

---

## SEC-03 — Account Security

Telegram supports mechanisms such as:

- two-step verification;
- passkeys;
- device/session management;
- local application locks;
- privacy controls.

---

## SEC-04 — Bot Credentials

Bot API tokens are security credentials.

Treat them as secrets.

Required controls should include:

- secret manager storage;
- rotation;
- least access;
- audit;
- environment isolation;
- revocation procedures.

Never embed production bot tokens in source code.

---

# 18. Governance Rules for Agentic Telegram Systems

Telegram permits significant automation, but platform capability should not be confused with governance.

Recommended architecture:

```text
                 Agent / LLM
                     │
                     ▼
               proposed action
                     │
                     ▼
            deterministic policy
                     │
              ┌──────┴──────┐
              │             │
           denied         allowed
                            │
                            ▼
                     Telegram Adapter
                            │
                            ▼
                         Telegram
```

## Core principles

### G-01 — Deterministic authority

Permissions, credential scope, and irreversible operations should be enforced by deterministic systems.

### G-02 — Least privilege

Each bot or agent should receive only the Telegram permissions required for its role.

### G-03 — Separation of identities

Prefer distinct bot identities for materially different responsibilities.

### G-04 — External source of truth

Important operational state should normally be persisted outside Telegram.

### G-05 — Auditability

Agent-initiated actions should carry sufficient metadata to reconstruct:

- who initiated the action;
- which agent executed it;
- which policy authorized it;
- what Telegram action occurred;
- what result was returned.

### G-06 — Bounded autonomy

Autonomous agents should have explicit limits for:

- publishing;
- deleting;
- banning;
- payment operations;
- membership changes;
- credential management.

---

# 19. Telegram as an Edge Architecture

For sophisticated systems, Telegram is best modeled as an **interaction edge**.

```text
                Telegram
                   │
            telegram-edge
                   │
       ┌───────────┼───────────┐
       │           │           │
    Identity    Workflow     Agents
       │           │           │
       └───────────┼───────────┘
                   │
              Core Systems
```

`telegram-edge` should normally own:

- webhook/API integration;
- Telegram identity mapping;
- Telegram entity mapping;
- message normalization;
- outbound rendering;
- Telegram permission translation;
- retry handling;
- rate-limit handling;
- audit correlation;
- attachment handling;
- deep links;
- Mini App launch integration.

It should **not** become the canonical store for business logic that belongs elsewhere.

---

# 20. Canonical Telegram Entity Model

A useful normalized model is:

```text
TelegramPlatform
│
├── User
├── Bot
│
├── Chat
│   ├── PrivateChat
│   ├── Group
│   │   └── Topic
│   └── Channel
│
├── Community
│   └── Chat references
│
├── Message
│   ├── Content
│   ├── Media
│   ├── RichMessage
│   └── Interaction
│
├── MiniApp
│
├── Call / LiveSession
│
├── Payment
│
└── Membership / Permission
```

---

# 21. Capability Selection Guide

| Requirement | Preferred Telegram Primitive |
|---|---|
| Private conversation | Private chat |
| Announcement publishing | Channel |
| Open discussion | Group |
| Structured discussion | Group + Topics |
| Multi-space institution | Community |
| Interactive automation | Bot |
| AI assistant | Bot + streaming/rich messages |
| Specialist invoked anywhere | Guest Bot / Inline Bot |
| Complex interface | Mini App |
| Customer automation | Business Bot |
| Event/live discussion | Group Call / Live Stream |
| Payments | Bot / Mini App + payment capability |
| Human + multiple agents | Community + Bots |
| External authentication | Login with Telegram |
| Full custom Telegram client | TDLib / Telegram API |

---

# 22. Coulomb Society Reference Pattern

A possible Telegram-native structure for the Coulomb Society is:

```text
Coulomb Society Community
│
├── Coulomb Society Channel
│   └── official publishing
│
├── Society Commons
│   └── general discussion
│
├── Research Forum
│   ├── Physics
│   ├── Technology
│   ├── Arts
│   └── Philosophy
│
├── Events
│   └── meetings / lectures / live sessions
│
├── Charles-Augustin de Coulomb Sp.
│   └── community manager / concierge
│
├── Research Agents
│   └── specialist guest bots
│
└── Society Mini App
    ├── membership
    ├── profile
    ├── events
    ├── projects
    └── contribution workflows
```

The important architectural distinction is:

> The **Society exists independently of Telegram**; Telegram is the primary social and communication surface through which the Society is experienced.

This keeps future federation or expansion to other surfaces possible.

---

# 23. Capability Maturity Model

For platform planning, capabilities can be scored:

| Stage | Description |
|---|---|
| **T0 — Manual** | Humans operate Telegram manually. |
| **T1 — Assisted** | Bots provide commands and notifications. |
| **T2 — Integrated** | Telegram is connected to external services. |
| **T3 — Workflow** | Business/community workflows execute through Telegram. |
| **T4 — Agent Assisted** | Agents prepare actions; humans approve. |
| **T5 — Bounded Autonomous** | Agents execute within deterministic policy boundaries. |
| **T6 — Adaptive Multi-Agent** | Multiple specialized agents coordinate while governance remains deterministic. |

The goal should generally not be maximum maturity everywhere.

Each capability should advance only as far as its risk, value, observability, and reversibility justify.

---

# 24. Telegram Strengths

Telegram is particularly strong where a system needs several of the following simultaneously:

- human messaging;
- public publishing;
- large communities;
- notifications;
- programmable bots;
- embedded applications;
- identity;
- payments;
- media;
- AI interaction;
- mobile and desktop availability;
- low-friction onboarding.

This combination is unusual.

---

# 25. Telegram Weaknesses and Boundaries

Telegram should not automatically be used as:

- a canonical enterprise database;
- a high-assurance authorization system;
- a durable workflow engine;
- a general event bus;
- a secret-management system;
- a regulated document archive;
- a guaranteed-delivery notification system;
- an internal high-volume agent coordination backbone.

These responsibilities normally belong to external infrastructure.

Telegram should expose them through interaction adapters.

---

# 26. Strategic Interpretation

Telegram can be understood as:

> **A globally deployed interaction runtime combining identity, messaging, publishing, communities, applications, payments, and increasingly first-class human/agent collaboration.**

Its strategic value is therefore larger than its conventional classification as a messaging application suggests.

For agent-active systems, the most significant capabilities are increasingly:

```text
identity
+ conversation
+ community context
+ rich output
+ streaming
+ embedded applications
+ delegated bots
+ guest agents
+ bot-to-bot communication
+ deterministic external governance
```

Together these allow Telegram to become a practical **social edge for agentic systems**.

---

# 27. Reference Architecture Principle

The canonical integration rule for systems built around Telegram should be:

> **Telegram owns interaction. The application owns truth. The policy layer owns authority. Agents own bounded interpretation and action.**

Expressed architecturally:

```text
Telegram
   │
   ▼
Interaction Edge
   │
   ▼
Identity / Context
   │
   ▼
Agent or Application
   │
   ▼
Deterministic Policy
   │
   ▼
Domain Systems
```

This separation enables sophisticated Telegram-native experiences without making the security, consistency, or longevity of the system dependent on Telegram itself.

---

# 28. Sources

Primary Telegram documentation consulted for this version:

1. Telegram Bot Platform — Introduction  
   https://core.telegram.org/bots

2. Telegram Bot Features  
   https://core.telegram.org/bots/features

3. Telegram Bot API  
   https://core.telegram.org/bots/api

4. Telegram Bot API Changelog  
   https://core.telegram.org/bots/api-changelog

5. Telegram Mini Apps  
   https://core.telegram.org/bots/webapps

6. Telegram API — Bots  
   https://core.telegram.org/api/bots

7. Telegram AI Features for Bots  
   https://core.telegram.org/api/bots/ai

8. Telegram Blog — Communities and Rich Text, July 2026  
   https://telegram.org/blog/communities-editor-invisible-messages

9. Telegram Business  
   https://telegram.org/blog/telegram-business

---

# 29. Canon Maintenance

Telegram evolves quickly.

This document should therefore distinguish:

- **canonical concepts**, which should remain stable;
- **Telegram implementations**, which may change;
- **limits and commercial terms**, which should be periodically revalidated.

Recommended update triggers:

- major Bot API releases;
- new identity or authorization models;
- new community abstractions;
- changes to payment rules;
- significant agent/AI capabilities;
- material changes to API limits;
- changes affecting privacy or security architecture.

---

**End of Telegram Capability Canon v0.1**