One engine for every team

Start with one decision.
Reuse the same foundation.

Start with qualification and routing. The same Decision Pack structure is designed for support escalation, approved claims and other company decisions. Builders connect workflows; business owners review the rules; employees need clear findings when supported work is checked.

Sales/Support/Legal/Recruiting/Proposals/Product marketing/Content
Ten primitives underneath every one
01
Actors
Who the decision is about or for
02
Decision criteria
Rules, thresholds and exceptions
03
Source signals
Typed observations from the world
04
Needs and requirements
What a job needs before it runs
05
Evidence and proof
What counts as admissible
06
Boundaries
What’s prohibited or must escalate
07
Output contracts
What a valid output must look like
08
Routing jobs
Which job applies, and where work goes
09
Gaps
What’s missing, stated instead of guessed
10
Evaluations
Test cases for expected Pack behavior
Illustrative examples · same parts, every team
Primitive
Sales
Support
Legal
Recruiting
Actors
Buyer persona
Customer tier
Counterparty
Role level
Decision criteria
Qualification rule
Escalation rule
Clause approval
Hiring bar
Evidence and proof
Approved case study
Known-issue record
Approved precedent
Scorecard
Boundaries
No guaranteed ROI
No refund promises
Non-standard indemnity
Off-limits questions
Developers

One contract.
Connected surfaces.

Planned REST, SDK and MCP interfaces share one decision contract. Keep your workflows and models; connect the decisions you want them to reuse.

TypeScript SDK REST Remote MCP
agent.ts● directional
import { Felspar } from "@felspar/sdk"

const felspar = new Felspar({ authority: "gumdrop-production" })

// Resolve released authority for one job
const decision = await felspar.resolve({
  job: "enterprise_pitch_deck@1",
  input: {
    employee_count: 750,
    account_country: "US",
    initiative_status: "active",
    buyer_role: "vp_revenue_operations"
  }
})

decision.status    // "ready"
decision.release   // "enterprise-sales@1.0.0"
decision.receipt   // "rcpt_7hK2…q9"
Planned SDK · a tool or middleware step in compatible runtimes
terminal● directional
curl https://api.felspar.ai/v1/resolve \
  -H "Authorization: Bearer $FELSPAR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "authority": "gumdrop-production",
    "job": "enterprise_pitch_deck@1",
    "input": { "employee_count": 750, "account_country": "US",
      "initiative_status": "active", "buyer_role": "vp_revenue_operations" }
  }'

# 200 OK
{
  "status": "ready",
  "decision": "enterprise_ready",
  "permitted_jobs": ["enterprise_pitch_deck@1"],
  "release": "enterprise-sales@1.0.0",
  "receipt": "rcpt_7hK2…q9"
}
Planned REST interface · OpenAPI contract for compatible HTTP clients
mcp.json● directional
// Planned configuration for a compatible MCP client
{
  "mcpServers": {
    "felspar": {
      "url": "https://mcp.felspar.ai",
      "auth": "oauth"
    }
  }
}

// In a connected, compatible MCP client
→ felspar.resolve  job=enterprise_pitch_deck@1
← ready · enterprise-sales@1.0.0 · rcpt_7hK2…q9
Planned remote MCP · agent plugin and skills under development

● In development. Interfaces shown are directional, not available production APIs.

Receipts

Know what
was checked.

A resolution receipt records which release applied to which inputs. Checking an exact artifact and gating a downstream action are separate steps, each requiring its own evidence.

AvailableL1

Authorized, connected consumers can access a released Pack. Access alone does not establish use.

ConsultedL2

A resolution receipt ties the decision to the exact release and inputs.

Artifact checkedL3

A separate check binds findings and any recorded approval to an exact artifact revision.

Action gatedL4

Your application must enforce its own gate before sending or publishing.

FELSPAR RECEIPTrcpt_7hK2…q9
jobenterprise_pitch_deck@1
releaseenterprise-sales@1.0.0
sourcerev-17 · sha256:9f3c…e1d8
inputs4 observations · validated
resultready
artifactpitch-deck-v3.pdf · sha256:51ab…7c02
checks3 of 3 passed
approved byMaya Chen · 26 Sep 2026
issued 2026-09-26 14:02 UTCverifiable

Illustrative receipt with synthetic data. A receipt records scoped decisions and checks. It does not prove source truth, model obedience or downstream delivery. Coverage depends on connected consumers and registered artifacts.

Where it fits

Keep your tools. Share the decision.

Source documents
Keep your canonical sources. Felspar is designed to bind reviewed decisions to the revisions your company approved.
Context and retrieval
Keep finding useful evidence. The shared decision defines what counts, what applies, and when more information or review is needed.
Workflow tools
Keep your workflow logic and controls. Test whether sharing a decision across tools reduces repeated implementation and maintenance.
Agents and models
Keep choosing how the work runs. Connected consumers request released decisions and context. Your systems own generation and actions.
An internal build
Shared code can solve this too. The pilot tests whether a maintained service saves enough integration, update and review work to be worth adopting.
Design partners

One decision.
Two workflows. Measured.

Our first focus is qualification and routing across two workflows. Bring a rule your team maintains in more than one place. We’ll test whether sharing it reduces update, review and debugging work.

Build your Decision Pack

Tell us about one decision to start a conversation.

You’re a fit if you have
✓Two workflows or agents using the same decision
✓Sources or policy that change
✓A real cost when judgment goes stale
✓A clear owner for the decision
✓An operator or engineer who can connect both workflows
Six-week founding pilot
Four-week core proof

One decision, two workflows and 20–50 past cases. The six-week term leaves up to two additional weeks for contracting, customer review, acceptance and handoff.

Week 1
Map and baseline

Trace the decision from source to both workflows. Agree the historical cases and baseline.

Week 2
Encode and release

Build and review the Decision Pack. Connect the first workflow in shadow mode.

Week 3
Connect and change

Connect the second workflow, replay past cases, test one controlled change.

Week 4
Measure and decide

Compare total effort and outcomes against baseline. Continue, narrow or stop.

What we measure

Agree success criteria before kickoff. Compare both workflows against the baseline, then decide whether to continue, narrow or stop.

✓Total setup, integration and maintenance effort
✓Time from approved change to observed adoption
✓Both workflows using the intended version
✓Stale or unsupported outputs caught
✓False approvals and unnecessary blocks
✓Change in manual review and rework