---
title: How it works
description: The full Felspar flow, from a policy document to a verified decision, in one diagram.
sidebar:
  order: 2
---

Felspar has two sides. People turn a policy into an approved pack. Agents use the released pack to get decisions.

```mermaid
flowchart LR
  subgraph People["People: author, review, release"]
    Doc["Policy in Google Docs"] --> Draft["Draft in ChatGPT or Claude<br/>(Felspar plugin)"]
    Draft --> Check["check_pack:<br/>quotes, rules, tests"]
    Check --> Proposal["Proposal"]
    Proposal --> Backtest["Backtest on<br/>recent real cases"]
    Backtest --> Approve["Approve and release<br/>on app.felspar.ai"]
  end
  Approve --> Release[("Released Decision Pack<br/>immutable")]
  subgraph Agents["Agents: decide, then act"]
    Ask["get_job_requirements"] --> Gather["Gather evidence:<br/>exact quotes"]
    Gather --> Decide["get_job_decision"]
    Decide --> Result["Outcome, why,<br/>next step, receipt"]
    Result --> Gate["Pre-action gate:<br/>verify receipt"]
    Gate --> Act["Your tool acts"]
  end
  Release --> Ask
  Release --> Decide
  Doc -. "edited" .-> Watch["Source watching"]
  Watch -. "changed" .-> Draft
```

## The authoring side

1. **Connect the document.** On the Felspar web app, each person connects their own Google Drive and picks the Docs that define a decision. Felspar reads the exact version and keeps it as a **source**.
2. **Draft a pack.** In ChatGPT or Claude, with the Felspar plugin, an assistant reads the source and writes a pack draft: the questions an agent must answer, what each answer means (quoted from the document), the rules that pick an outcome, each outcome's next step, and test cases.
3. **Check it.** `check_pack` locates every quote in the document, compiles the rules and runs the tests. It also reports gaps, such as an answer with no definition.
4. **Propose it.** `propose_pack` saves the draft as a proposal. A proposal changes nothing for agents.
5. **Backtest it.** `backtest` re-decides the job's recent real cases under the proposal and under the current release, and lists what would change.
6. **Approve and release.** An approver opens the proposal on the web app, reviews the meaning and test results, approves that exact proposal, and releases it. Agents that follow the job get the new release on their next call.

## The agent side

1. **Ask what the job needs.** `get_job_requirements` returns every question, what each answer means, where to look for evidence, each outcome's next step, and the exact request format.
2. **Gather evidence.** The agent reads its sources (a website, a CRM record, a ticket) and copies the exact words that answer each question.
3. **Ask for the decision.** `get_job_decision` sends those excerpts. Felspar reads numbers and dates exactly, classifies text against the released definitions, and applies the rules.
4. **Act on the result.** The result is a decided outcome with its next step, or "not decided yet" with exactly what is missing and whether to retry or escalate. Either way it carries a receipt.
5. **Verify before acting.** Before a tool writes anything (an email draft, a CRM update), the [pre-action gate](/guides/pre-action-gate) asks Felspar to replay the decision and confirm it.

## Where models are used, and where they aren't

Felspar uses a model in exactly one place: to read a text excerpt and say which of the pack's defined answers it matches. That classification is bounded. It only chooses among answers your policy defines, it must clear the pack's confidence threshold, and anything below the threshold comes back as "needs evidence", not a guess.

Everything else is code:

- Numbers and dates are read exactly from the text, with no model.
- Rules, outcomes and next steps are applied deterministically.
- Replaying a decision to verify its receipt uses the recorded classifications and calls no model.

Your own models do the open-ended work: searching, reading, writing and acting.

## Where Felspar runs

The Felspar web app (`app.felspar.ai`), REST API (`api.felspar.ai`) and MCP server (`mcp.felspar.ai`) run on Cloudflare's network. Workspace data is kept in a PostgreSQL database with row-level security and in private object storage. The marketing site at `felspar.ai` is separate. See [Security, privacy and data](/security) for what is stored and for how long.

## Surfaces at a glance

| Surface | Who uses it | What for |
| --- | --- | --- |
| Web app, `app.felspar.ai` | Owners, approvers, members | Connect sources, review, approve, release, register agents, manage people |
| MCP for people, `mcp.felspar.ai/mcp` with your sign-in | Members, approvers, owners in ChatGPT or Claude | Read sources, draft, check, propose, backtest |
| MCP for agents, same address with an agent key | Registered company agents | `list_jobs`, `get_job_requirements`, `get_job_decision`, `check_output` |
| REST API, `api.felspar.ai` | Agents, automations, your code | Job lists, briefs, decisions, output checks, receipt verification |
| Felspar plugin | People in ChatGPT, Claude, Codex | The people MCP plus six skills that guide authoring |
| TypeScript SDK, `@felspar/sdk` | Builders | The two-line Eve connection, a typed REST client, the pre-action gate and the agent skill |