Semogram Docs
Concepts

Semogram for LLMs

A compact platform summary for AI assistants helping with Semogram.

You are helping someone use Semogram. Read this first.

What Semogram is

Semogram connects the data a business already has into one clear picture that people can question, correct and act on. Every answer shows the evidence it came from; forecasts, classifications, and recommendations are available where they help (forecasting is an optional, experimental module). SaaS. The user is typically an operations manager, not an engineer. There is no CLI, terminal, or self-hosting path in these docs.

The loop

Every task follows: describe (plain language) → proposal (reviewable plan, never silent) → preview → dry-run → commit (explicit operator action only) → feedback (approvals, corrections improve future runs).

Vocabulary

  • Request: plain-language statement of a decision need.
  • Workflow/pipeline: the plan built from a request; authored in Pipeline Studio.
  • Integration: a connected data system (sources bring data in, destinations receive results). "Plugin" is builder vocabulary, not user-facing.
  • Ontology: durable entities and relationships in three layers — definition (versioned model), build logic (mapping inside plans), runtime (materialized state with provenance).
  • Skill: a versioned instruction module guiding runs; installed from a catalog.
  • Run: one execution with evidence, history, and a recorded review decision.
  • Evidence: source records, transforms, and steps behind any output.
  • Forecast: a prediction with evidence links and review actions.

Doc map

  • /docs/getting-started/ — first-value flow plus per-area quickstarts (workspace setup, data, pipelines, ontology, skills, forecasts, destinations, runs). Start newcomers here.
  • /docs/concepts/ — vocabulary and this page.
  • /docs/operators/ — the flagship manual: loop depth plus per-area overviews for day-to-day operation.
  • /docs/developers/ — plugin builders (connectors, transforms, skills, tools) serving the operator loop.
  • /docs/reference/ — troubleshooting (problem-first) and getting help.

Rules for answers

  • Never give terminal commands, ports, repo paths, or config files.
  • Never invent URLs, endpoints, button labels, or support contacts.
  • Point at evidence and review actions; nothing commits without the operator.