Skip to content

How it works

One request, one deterministic path, as few paid calls as possible.

Every POST /v1/score walks the same ordered flow within a fixed deadline. Each stage can end the work early; the policy engine always has the last word.

Decision flow

From request to decision

FRAPE decision flowA scoring request is validated, then terminal rules run first; a terminal hit decides immediately with no provider or Decision Core call. Otherwise cached and local data are used first, external providers are called only for missing capabilities, features and second-stage rules are computed, the Decision Core is consulted only when needed, and the deterministic policy engine always makes the final decision.01Validate requestPOST /v1/score · schema · no card numbers02Pre-rules #1terminal hard rulesterminal hit → decide now03Cache & local datacache → local reference dataall local → zero provider calls04External providersmissing capabilities only · paralleltimeout + circuit breaker each05Features + pre-rules #2velocity · identity · signals06Decision Core (advisory)only when rules can’t settle itskipped or unavailable → policy07Policy enginedeterministic · owns the decision08DecisionAPPROVE · CHALLENGE · REVIEW · DECLINE
Solid arrows: the full path. Dotted arrows: short-circuits that avoid provider and Decision Core calls.

Step by step

  1. Validate request — POST /v1/score · schema · no card numbers
  2. Pre-rules #1 — terminal hard rulesterminal hit → decide now
  3. Cache & local data — cache → local reference dataall local → zero provider calls
  4. External providers — missing capabilities only · paralleltimeout + circuit breaker each
  5. Features + pre-rules #2 — velocity · identity · signals
  6. Decision Core (advisory) — only when rules can’t settle itskipped or unavailable → policy
  7. Policy engine — deterministic · owns the decision
  8. Decision — APPROVE · CHALLENGE · REVIEW · DECLINE

Why it is shaped this way

Five gates, each with one job

  1. gate 01

    Rules first

    Pre-rules run before anything costly. Terminal hard rules — a blocklisted device, card fingerprint, email or IP; an unsupported country; known test traffic — return a decision immediately, and the event records that the Decision Core was skipped because of a terminal rule.

  2. gate 02

    Cache first

    The enrichment plan lists the capabilities this event needs. Each is looked up in the cache, then in local reference data. A request served entirely locally performs zero external provider calls.

  3. gate 03

    Conditional enrichment

    Only missing, required capabilities go to external providers — in parallel, each with its own timeout and circuit breaker. A failed provider marks the feature unavailable; scoring continues.

  4. gate 04

    Decision Core only when needed

    The Decision Core is skipped when a terminal rule fired, when rules are already confident, when the organisation disabled it, when its circuit breaker is open or its daily budget is spent. When called, it receives one minimised state and answers in a single request.

  5. gate 05

    Policy owns the decision

    The post-model policy combines facts, rule results and the advisory score through ordered rules and thresholds. If the Decision Core is unavailable, the organisation’s fallback applies — review, challenge, decline or rules-only — never approve.

Resilience

Outages degrade the answer, never the safety

  • Cache downVelocity features become unavailable; scoring continues without treating missing data as safe.
  • Provider downThe capability is marked unavailable, and rules or policy can treat that as a signal in its own right.
  • Decision Core downThe organisation’s configured fallback applies and the event records why the Decision Core was not used.

Design partners

Help shape what FRAPE decides next.

We are working with a small number of teams who score payments, sign-ups, logins or payouts and want decisions they can explain line by line. Bring your rules and your edge cases.

Become a design partnerSee the decision flow