Policy YAML Deep Dive

Every Lending Rule Lives in YAML

How policy files define what the decision engine enforces

Evaluation Pipeline

YAML Rule

Predicate Match

Stage Evaluation

Pass / Fail

Policy Layers

Dispatch

Routes loans to the correct policy set

Manifest

Declares stages and their execution order

Definitions

Reusable predicates and requirement blocks

Dispatch schema→marketplace/lc/engines/decision/schema/dispatch.py

Manifest schema→marketplace/lc/engines/decision/schema/manifest.py

Policy schema→marketplace/lc/engines/decision/schema/policy.py

Scope

Per-Company

Each company folder holds its own dispatch, manifests, and definitions

Example→marketplace/lc/engines/decision/policies/

Three Layers Route Every Lending Decision

Each company folder holds a dispatch file, manifests, and shared definition files

Dispatch

First-match routing to the right manifest

Manifest

Ordered list of stages for one workflow

Definitions

The actual rules — one file per stage

ℹ️

Stages share definition files across manifests — most rules are written once

Source Files

Dispatch file→marketplace/lc/engines/decision/policies/AAA_FAKE_LENDER/dispatch.yaml

Routing→marketplace/lc/engines/decision/api.py

TOE manifest→marketplace/lc/engines/decision/policies/AAA_FAKE_LENDER/toe.yaml

FastTrack manifest→marketplace/lc/engines/decision/policies/AAA_FAKE_LENDER/fasttrack.yaml

Definitions folder→marketplace/lc/engines/decision/policies/AAA_FAKE_LENDER/definitions/

Each Stage Carries Its Own Policy

Each manifest stage links to a definition file and optional pricing

Stage

The named checkpoint in the workflow

Definition File

Points to the YAML file containing the actual rules for this stage

Price

Optional fee charged when this stage passes — only on prequal and intent

Notifications

Whether passing this stage triggers a decision notification to the lender

Application

Prequal

Credit

Intent

Underwriting

Complete

ℹ️

A loan must pass every stage in order — failure at any stage halts the pipeline

Source Files

Stage struct→marketplace/lc/engines/decision/schema/manifest.py

StageEnum→marketplace/lc/engines/decision/enums.py

Example manifest→marketplace/lc/engines/decision/policies/AAA_FAKE_LENDER/toe.yaml

Anatomy of a Requirement

Satisfy code + gate predicate + auto-satisfy logic + remediation strategy

Prequal stage — coborrower requirement

1- satisfy_code: coborrower_info_present
2  when:                                    # only applies if true
3    type: coborrower_exists
4  satisfied_when:                          # auto-satisfied if all pass
5    type: all
6    all:
7      - { type: has_value, field: coborrower_dob }
8      - { type: has_value, field: coborrower_ssn }
9  strategies:                              # automation when unsatisfied
10    - strategy: { type: order_credit, method: meridianlink_soft_pull }
11      when: { type: has_value, field: borrower_ssn }

satisfy_code

What to check

when

Gate predicate

satisfied_when

Auto-satisfy logic

strategies

Remediation action

Source Files

Struct→marketplace/lc/engines/decision/schema/policy.py

Codes→marketplace/lc/engines/decision/enums.py

Example→policies/AAA_FAKE_LENDER/definitions/toe_application.yaml

Eval→marketplace/lc/engines/decision/eval/eval_req.py

Strategy schema→marketplace/lc/engines/decision/schema/strategy.py

Predicates Are the Building Blocks

Every when and satisfied_when expression is built from typed predicates

Field Presence

Check whether a value exists on the file

has_value→field exists

field_is_true→boolean check

Numeric Threshold

Compare scores, amounts, and ratios

credit_score_gte→minimum score

cltv_lte→max ratio

Categorical Match

Test property type, state, loan type, occupancy

state_in→allowed states

purpose_is→loan purpose

Special

Coborrower, flood zone, lien position, origin

coborrower_exists→has coborrower

is_special_flood_hazard_area→flood zone

Condition Queries

Check whether an external condition has completed

condition_complete→done

condition_not_requested→skipped

Logical Operators

Compose predicates into complex expressions

all→AND

any→OR

not→negate

Source Files

Schema→decision/schema/expr.py

FieldEnum→decision/enums.py

Eval→decision/eval/eval_expr.py

ConditionTypes→decision/enums.py

ℹ️

Every predicate returns tri-logic: True, False, or Unknown — missing data never causes a crash

Each Stage Has a Different Character

Complexity grows as the loan moves through the pipeline

Application

Heaviest stage — collects all borrower fields and validates presence

has_value field_is_true

Prequal

Eligibility gates — checks thresholds like credit score and CLTV

Thresholds Categorical

Credit Verification

Single requirement — confirms credit source is acceptable

credit_source_in

Intent to Proceed

Single requirement — confirms borrower has signed intent

has_value

Underwriting

Most complex — every requirement has a remediation strategy

Conditions Strategies

Complete

Terminal stage — no requirements, marks the loan as fully approved

Terminal

Definition Files

Application→definitions/toe_application.yaml

Prequal→definitions/ft_prequal.yaml

Credit→definitions/ft_credit_verification.yaml

Intent→definitions/ft_intent_to_proceed.yaml

Underwriting→definitions/ft_initial_underwriting.yaml

Complete→definitions/ft_complete.yaml

Three Patterns for Extending Policy

Adding a new requirement, guarding against duplicates, and gating on borrower context

Add a Requirement

Define the satisfy code, choose predicates for when/satisfied_when, and optionally add a strategy

satisfy_code satisfied_when strategies

Guard Against Duplicates

Use condition_not_requested to prevent re-ordering — the strategy only fires if no prior order exists

condition_not_requested First match wins

Gate on Context

Use a when predicate to make the requirement conditional — it's skipped entirely if the gate is false

coborrower_exists flood_hazard_area + more

Source Files

Strategy logic→decision/eval/eval_req.py

Guard pattern→definitions/ft_initial_underwriting.yaml

Context gates→definitions/ft_initial_underwriting.yaml

Policy YAML — Key Takeaways

The three layers that define every lending rule

Declarative

Requirements are data — four optional fields compose into any lending rule

Composable

Typed predicates combine with AND, OR, NOT into complex eligibility logic

Extensible

New rules, companies, and stages are added by writing YAML — no code changes

Test Coverage

YAML validation→tests/engines/decision/test_validate_all_yaml_files.py

Stage tests→tests/engines/decision/test_toe_application.py

Navigation

Next: Cognito Auth

Decision Engine

Every Lending Rule Lives in YAML

Three Layers Route Every Lending Decision

Each Stage Carries Its Own Policy

Anatomy of a Requirement

Predicates Are the Building Blocks

Each Stage Has a Different Character

Three Patterns for Extending Policy

Policy YAML — Key Takeaways

Keyboard Shortcuts