Core pipeline

Timelining ingests Telegram contributions, stores them in Neo4j, and vectorises text for retrieval. That is the core workflow. Dispatch to sibling resolvers is separate — see Resolvers.

Overview


Telegram (_bot* topic)
  → Ingest webhook → Redis → Neo4j Entry
  → Vectorise transcribe → chunk → embed
  → Neo4j (graph + vector index)
       ↳ consumed by evaluate (RAG), visualise APIs, etc.

Chained HTTP (mode=chain) handles the happy path; Vercel crons sweep backlogs and failed queues.

Modules

Page	Stage	Code
Ingest	Webhook, Redis backlog, Neo4j write	`services/ingest/`, `api/story/webhook`
Vectorise	Transcribe, chunk, embed	`services/vectorise/`
Organising config	Topic → sibling routing	`organising.config.ts`
Resolvers	Forward + resolve dispatch	`services/resolve/`, `services/webhook/`

Shared infrastructure: services/pipeline/ (routing, execute, retry), lib/db/neo4j.ts.

Infrastructure

Dependency	Role
Upstash Redis	Backlog + failed queues
Neo4j (Railway)	Graph + embeddings
OpenAI	Whisper + embeddings
Vercel	Serverless routes + crons

Deploy via propagate (app.manifest.yaml).

Evolution from earlier docs

Previous documentation described webhook → Redis worker → Neo4j as a two-step ingest. Purpose unchanged; current version adds inline chaining, vector stages, Neo4j vector indexes, and organising config for sibling integration. Older references to PostgreSQL/pgvector or S3-first storage are superseded.