Feason Context

Source-grounded Christian evidence for AI agents, with passage provenance, tradition attribution, coverage boundaries, and citation verification.

View on feason.com

Hosted MCP Server

npx add-mcp 'https://www.feason.com/api/mcp'

Installs into Claude Code, Codex, Cursor and more

Documentation

Feason Context · REST API 1.3

Christian context API.Ready for your model.

Give an AI application inspectable Scripture, historical sources, named theological perspectives, and citations it can verify. Feason retrieves the evidence. Your product decides how to use it.

Contextualize endpoint https://www.feason.com/api/context/v1/contextualize

Explore the platform

One context layer.Every way to use it.

Start with the job your product needs to do. Every path uses the same versioned Christian source corpus, stable citations, tradition attribution, and explicit coverage boundaries.

01

Ground answers

Christian AI grounding

Turn a question into model-ready context drawn from Scripture, creeds, councils, historical theology, and named Christian traditions.

Contextualize Search

Explore grounding

02

Test assertions

Theological claim checking

Separate supporting, contradicting, qualifying, contextual, and unclassified evidence without treating silence as disagreement.

Evaluate claim Claim proof

Explore claim checking

03

Research deeply

Evidence discovery

Search exact passages or assemble a structured research packet with positions, provenance, historical context, caveats, and confidence.

Search Evidence packet

See research operations

04

Show your work

Citation integrity

Verify quotations against an immutable release and expose the corpus version behind every answer your application produces.

Verify citation Manifest

See verification operations

05

Prove issuance

Signed proof verification

Authenticate a complete claim graph with Ed25519, a separately published trust key, and an append-only Merkle-log receipt.

Signed envelope Transparency receipt

Open proof verifier

Choose your connection

From first request to production.

Decision guides

Choose the evidence layer before the model.

Compare product categories by source identity, provenance, coverage, verification, and the work your team still owns.

Feason Context vs. generic theology RAG

Compare corpus ownership, provenance, tradition coverage, citation verification, and operational responsibility.

Read the guide →

APIs for grounding Christian AI

Choose among Scripture text, source search, theological evidence, and current-web APIs by evidence contract.

Read the guide →

Bible API vs. theological evidence API

Separate canonical reading needs from historical, doctrinal, and tradition-aware research needs.

Read the guide →

Verify theological AI citations

Resolve, compare, contextualize, and audit quotations before an AI-generated answer is published.

Read the guide →

Quickstart

One call.Grounded context.

Send the user’s question with a prompt budget. The response’s context field can be placed directly before the question in your model input. Citation metadata remains separate and inspectable.

  • The key is scoped to read-only canonical context.
  • The response never claims that missing coverage means a tradition has no teaching.
  • Disputed positions stay attributed to their source or tradition.

Request POST /contextualize

curl https://www.feason.com/api/context/v1/contextualize \
  -H "Authorization: Bearer $FEASON_CONTEXT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "How did early Christians speak about grace?",
    "traditions": ["catholic", "orthodox", "reformed"],
    "maxTokens": 2000,
    "maxSources": 12
  }'

Response application/json

{
  "corpusVersion": "theology-v7.0.0",
  "context": "# Feason Context\n...",
  "citations": [{ "label": "E1", "passageId": "..." }],
  "coverage": {
    "representedTraditions": ["catholic", "orthodox"],
    "missingTraditions": ["reformed"]
  },
  "usage": { "estimatedTokens": 1842, "truncated": false }
}

Claim checking

Test a claim.Keep the nuance.

Feason matches the wording to a curated claim definition, retrieves relevant passages, and groups only human-annotated stances. Your interface can show the evidence behind each category instead of presenting an unexplained verdict.

  • Supporting and contradicting passages remain inspectable.
  • Qualifying evidence stays distinct from opposition.
  • Silence, missing retrieval, and unclassified passages never become negative proof.

Request POST /evaluate-claim

curl https://www.feason.com/api/context/v1/evaluate-claim \
  -H "Authorization: Bearer $FEASON_CONTEXT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "claim": "Children of believers may be baptized.",
    "limitPerStance": 5
  }'

Response shape application/json

{
  "normalizedClaim": "infants-may-be-baptized",
  "supportingEvidence": [],
  "contradictingEvidence": [{ "passageId": "..." }],
  "qualifyingEvidence": [{ "passageId": "..." }],
  "contextualEvidence": [],
  "unclassifiedEvidence": [],
  "confidence": 0.92,
  "negativeEvidencePolicy": "Only explicitly opposing annotations..."
}

REST surface

Seven operations with clear jobs.

All operations use bearer authentication, concrete JSON contracts, per-client limits, and the same immutable Context corpus behind Feason’s MCP server.

POST /api/context/v1/contextualize

Build model-ready context

One call returns a token-budgeted evidence block, stable citation labels, and explicit tradition coverage.

POST /api/context/v1/evaluate-claim

Check a theological claim

Group retrieved passages by curated stance, with explicit caveats and no false negative inference from silence.

POST /api/context/v1/claim-proof

Build a claim proof

Commit exact evidence, disclosed rules, validation checks, and a bounded result to an unsigned SHA-256 Merkle root.

POST /api/context/v1/search

Search exact passages

Run lexical, semantic, or hybrid retrieval over the versioned corpus with source and tradition filters.

POST /api/context/v1/evidence-packet

Assemble research evidence

Retrieve Scripture, primary sources, historical context, positions, provenance, caveats, and confidence.

POST /api/context/v1/verify-citation

Verify a quotation

Check a passage or exact quote against an immutable corpus release snapshot.

GET /api/context/v1/manifest

Inspect the active release

Read the active corpus version, source counts, relationships, claims, and verification distribution.

Developer access

Create a scoped key.

Self-service keys can read only the shared canonical corpus. Access to a member’s private study context uses OAuth and explicit consent instead.

Checking your Feason session…

Product boundary

Evidence in. Verdicts out.

Feason improves what a model can inspect without claiming that retrieval itself settles interpretation.

Source-first

Every included passage carries a stable ID, reference, provenance URL, license, and verification status.

Tradition-aware

Differences are named and sourced. Missing corpus coverage remains visible instead of becoming synthetic consensus.

Prompt-bounded

The context block respects the requested budget and reports when evidence was omitted or shortened.

Questions

Christian Context API FAQ.

What developers need to know before grounding an AI product in Christian sources.

What is a Christian context API?

A Christian context API retrieves relevant Scripture and theological sources for an application. Feason returns exact passages, provenance, citations, named tradition coverage, and explicit caveats so AI-generated answers can be inspected.

Can Feason Context be used with any AI model?

Yes. The REST API returns provider-neutral JSON and prompt-ready Markdown. Applications can use the context with OpenAI, Anthropic, Google, open-source, or other language models.

Does the API favor one Christian denomination?

No. Feason is non-denominational and source-grounded. Disputed views are attributed to their sources and traditions, while missing corpus coverage is reported instead of treated as absence of teaching.

How do developers authenticate?

Signed-in Feason members can create scoped, read-only developer keys. Each key expires after 90 days, can be revoked, and cannot access a member’s private study context.