> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fapost.in/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

> What FaPost Core is, and who each part of this documentation is for.

<Note>
  **This documentation is being written.** Self-hosting, Developers and Reference
  are current and describe the platform as it stands. **The user guide is not
  written yet** — it covers the admin screens and the flow canvas, and describing
  an interface from the outside is how documentation drifts from the product. It
  follows once each screen can be walked through.
</Note>

**FaPost Core is a platform for building conversational assistants.** An assistant
connects to messaging channels such as Telegram and WhatsApp, holds conversations
with contacts, and runs them through flows designed on a visual canvas — with
contacts, segments, broadcasts, and conversation history around it.

This repository is Core: the platform itself, without vertical product packages.

<Accordion title="What is a flow?">
  A flow is a directed graph, stored as JSON, that describes a conversation. Each
  node does one thing — send a message, wait for a reply, branch on a condition,
  call an HTTP endpoint, query a knowledge base — and edges connect a node's
  outcomes to whatever comes next.

  At runtime an engine walks that graph for one contact, resolving each node's
  handler by the pair `(type, version)` and keeping the conversation's state
  between steps. A node handler never decides which node runs next: it reports
  which outcome occurred, and the graph decides where that leads.

  That separation is what makes a flow editable by someone who does not write
  code, and a node reusable in flows its author never saw.
</Accordion>

## What you can build

Most installations start as a bot that answers questions on one channel. The
platform is not limited to that: an assistant can qualify leads, run a
multi-step intake form, notify a team, look up records in another system through
an HTTP call, or broadcast to a segment of contacts on a schedule.

Tenancy is not a layer bolted on top — it is a coordinate of the runtime. One
installation serves many independent organisations, each with its own assistants,
contacts, channels, and data, isolated in its own schema.

## Where to go

<CardGroup cols={2}>
  <Card title="User guide" href="/using/concepts" icon="wand-magic-sparkles">
    Build an assistant, design flows, manage contacts and broadcasts. For the
    people who run it day to day.
  </Card>

  <Card title="Self-hosting" href="/self-hosting/overview" icon="server">
    Install, run, and upgrade FaPost on your own infrastructure. For whoever
    keeps the servers.
  </Card>

  <Card title="Developers" href="/contributing/overview" icon="code">
    Build a Solution or Plugin, or work on Core itself — including the local
    development environment and what the platform is made of.
  </Card>

  <Card title="Reference" href="/reference/foundation-contracts" icon="book">
    Contracts, schemas, queues, commands.
  </Card>
</CardGroup>

## What happens when someone writes

A contact sends a message. The assistant looks up which flow should handle it and
starts a **session** — one contact moving through one flow. The session runs from
node to node until the flow ends or reaches a node that waits for a reply.

While it waits, the session stays open. When the contact answers, it picks up
exactly where it stopped, with everything collected so far still in place.

Two consequences are worth knowing before you build anything:

**A published flow is a snapshot.** A session holds the version of the flow it
started with. Publishing a change affects the next conversation, not the ones
already in progress — so nobody finds the questions changing underneath them
mid-conversation.

**A broadcast never delays a reply.** Large sends are paced separately from
conversation traffic, so a mailout to fifty thousand contacts does not put the
person who just asked a question behind a queue.

## Status

The platform is pre-1.0 and in active development. Where a feature is not
finished, these pages say so rather than describing an intention as a fact — and
the user guide names the screens it has not been written for yet.
