How it works

The full Felspar flow, from a policy document to a verified decision, in one diagram.

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

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 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 for what is stored and for how long.

Surfaces at a glance