Facts and Schema

A Context's schema defines what data it collects. There are three kinds of facts: base facts (the raw data you submit), derived facts (computed automatically), and one special identity fact (what uniquely identifies each instance).

Base Facts

Base facts are the data points you collect—things like credit_score, annual_income, or employment_verified. They come from API calls, webhooks, user input, or anywhere else in your system.

Each fact has a type (string, number, boolean, date, list, or object) and can be marked as:

• Required — Must be present before rules can execute
• Output only — Can only be written by rules, not submitted externally
• Track history — Stores previous values for temporal queries

The Identity Fact

One fact must be the identity fact—the unique identifier for each context instance. For a loan application context, this might be application_id. For order processing, order_id.

The identity appears in your API URLs:

POST /api/v1/contexts/loan-application/APP-12345
                                       ↑ identity value

Derived Facts

Derived facts compute automatically from other facts using expressions:

// Debt-to-income ratio
monthly_debt / (annual_income / 12)
 
// Risk category based on score
ifelse(credit_score >= 750, 'low',
  ifelse(credit_score >= 650, 'medium', 'high'))
 
// Aggregate from related contexts
sum($relations.orders, 'total')

They update whenever their dependencies change—no manual recalculation needed.

Available Functions

Aggregation: sum, avg, min, max, count, first, last

History (when tracking enabled): previous(field), changed_in_last(field, n, 'days'), history(field)

Utility: coalesce, ifelse, contains, round

Solvability

A context instance is "solvable" when all required facts are present. The API always tells you where you stand:

{
  "status": "pending",
  "have": ["application_id", "credit_score"],
  "need": ["annual_income", "employment_verified"]
}

When need is empty, status becomes complete and bound rules can execute.