LexiPoint API Reference

LexiPoint does not replace your intake system, your case management platform, or your data warehouse. It sits between them — called at the moment of decision, returning a legally defensible determination your systems can act on.

Base URL
https://api.lexipoint.com/v2

All API requests require authentication via API key. Responses are JSON. All timestamps are ISO 8601 in UTC.

Architecture

LexiPoint integrates with your existing systems at a single, well-defined point: the policy evaluation call. Your intake system submits an application payload. LexiPoint evaluates it against your codified policy rules. The decision — with full statute citations and rule trace — is returned to your system and written to LexiPoint's immutable audit log.

────────────────── ────────────────── ────────────────── Client Intake LexiPoint Workflow System (Salesforce, ────────▶ Decision API ────────▶ (ServiceNow, Accela, etc.) POST Event custom, etc.) ◀──────── Statute-backed 200 OK decisions with Human review full audit trail queue for ────────────────── flagged cases │ ────────────────── ▼ ────────────────── Audit Log Immutable Decision Records ──────────────────

Two-layer engine architecture. LexiPoint's core decision engine (engine.ts) is a pure function — zero cloud vendor dependencies. The infrastructure wrapper (index.ts) handles Supabase I/O and audit writes. Deploying into your Azure Government or AWS GovCloud tenant is a configuration exercise, not a rewrite.

Authentication

All API requests must include an API key in the Authorization header. Keys are scoped per tenant and per environment (production, staging, sandbox).

        Request Header
        HTTP
      

Authorization: Bearer lxp_live_a1b2c3d4e5f6...
Content-Type: application/json
X-LexiPoint-Tenant: state-hhs

Key Prefix	Environment	Description
`lxp_live_`	Production	Real decisions written to audit log
`lxp_test_`	Staging	Real evaluation, decisions marked as test
`lxp_sandbox_`	Sandbox	Scenario modeling, no audit log writes

Evaluate Policy

Submit an application payload for policy evaluation. LexiPoint evaluates all applicable rules in dependency order, generates a structured decision with statute citations, and returns the complete result. The decision record is simultaneously written to the immutable audit log.

POST /v2/evaluate

Evaluate an application against a program's codified policy rules.

Batch evaluation available in v2.1. For bulk processing (up to 100 applications per request), contact your account team about batch evaluation — same engine, same audit trail, single HTTP round-trip.

Request Body

Field	Type	Description
`program_id`Required	`string`	The program to evaluate against (e.g., `"cap"`)
`applicant_name`Required	`string`	Full name of the primary applicant. Used in audit log entries and review summaries.
`application`Required	`object`	The application payload. Must include the flat fields the program's rules reference. Optionally includes a `household_members` array; when present, aggregate fields are derived automatically.
`application.household_size`Required	`integer`	Total number of household members
`application.gross_monthly_income`Required	`decimal`	Total gross monthly income across all household members
`application.net_monthly_income`Required	`decimal`	Net monthly income after applicable deductions
`application.total_assets`Optional	`decimal`	Total countable household assets (required if asset test applies)
`application.district`Optional	`string`	Geographic district for regional variation rules. Values: `"A"`, `"B"`
`application.employment_type`Optional	`string`	Primary applicant employment type: `"employed"`, `"self_employed"`, `"unemployed"`, `"exempt"`
`application.receives_ssi`Optional	`boolean`	Whether household receives SSI (triggers categorical eligibility pathway)
`application.receives_tanf`Optional	`boolean`	Whether household receives TANF (triggers categorical eligibility pathway)
`application.has_documentation`Optional	`boolean`	Whether supporting documentation has been provided
`application.crisis_flag`Optional	`boolean`	If `true`, evaluate for expedited processing eligibility
`application.household_members`Optional	`array`	Individual member objects. When provided, aggregate fields (`household_size`, `gross_monthly_income`, etc.) are derived automatically. Explicit flat fields take precedence over derived values.
`documents`Optional	`array`	Documents to score alongside the evaluation. Each item: `{ file_name, file_path, document_type_expected }`. Results appear in `document_assessments[]` in the response.

Household Member Object

Field	Type	Description
`age`Required	`integer`	Member age in years
`name`Optional	`string`	Member full name
`relationship`Optional	`string`	`"self"`, `"spouse"`, `"child"`, `"parent"`, `"other"`
`has_disability`Optional	`boolean`	Whether member has a documented disability
`employment_type`Optional	`string`	`"employed"`, `"self_employed"`, `"unemployed"`, `"retired"`, `"student"`
`earned_income`Optional	`decimal`	Wages, salary, or self-employment net profit (monthly)
`unearned_income`Optional	`decimal`	Social Security, SSI, disability, child support, TANF, or other unearned income (monthly)
`gross_monthly_income`Optional	`decimal`	Total gross monthly income for this member
`net_monthly_income`Optional	`decimal`	Net monthly income for this member after deductions

Example Request

        POST /v2/evaluate
        JSON
      

{
  "program_id": "cap",
  "applicant_name": "Maria Martinez",
  "application": {
    "household_size": 5,
    "gross_monthly_income": 3450.00,
    "net_monthly_income": 2762.00,
    "total_assets": 4200.00,
    "district": "A",
    "employment_type": "employed",
    "receives_ssi": false,
    "receives_tanf": false,
    "has_documentation": true,
    "crisis_flag": false,
    "household_members": [
      {
        "name": "Maria Martinez",
        "relationship": "self",
        "age": 34,
        "employment_type": "employed",
        "earned_income": 1200.00
      },
      {
        "name": "Carlos Martinez",
        "relationship": "spouse",
        "age": 37,
        "employment_type": "self_employed",
        "gross_monthly_income": 1300.00
      },
      {
        "name": "Sofia Martinez",
        "relationship": "child",
        "age": 14,
        "employment_type": "student"
      },
      {
        "name": "Diego Martinez",
        "relationship": "child",
        "age": 4
      },
      {
        "name": "Rosa Martinez",
        "relationship": "parent",
        "age": 68,
        "has_disability": true,
        "unearned_income": 950.00
      }
    ]
  },
  "documents": [
    {
      "file_name": "martinez_pay_stubs.pdf",
      "file_path": "uploads/martinez_pay_stubs.pdf",
      "document_type_expected": "pay_stub"
    },
    {
      "file_name": "rosa_ss_statement.pdf",
      "file_path": "uploads/rosa_ss_statement.pdf",
      "document_type_expected": "social_security_statement"
    }
  ]
}

Response Fields

Field	Type	Description
`decision_id`	`UUID`	Immutable identifier for this decision record
`application_id`	`string`	Application identifier, format `APP-{YYYY}-{seq}`
`outcome`	`string`	`APPROVED`, `DENIED`, `APPROVED_WITH_CONDITIONS`, or `NEEDS_REVIEW`
`summary`	`string`	Human-readable narrative of the determination, including the determining factor for denials
`needs_review_reason`	`string`	Semicolon-separated list of conditions requiring human review (present when `outcome` is `APPROVED_WITH_CONDITIONS` or `NEEDS_REVIEW`)
`blocking_rule`	`string`	The rule ID whose gate failure caused a `DENIED` outcome
`queue_type`	`string`	Routing signal for your workflow system: `"allocation"` (denial processing), `"review"` (caseworker review), or `null` (auto-approved)
`review_summary`	`string`	AI-generated caseworker briefing for review-lane cases — what to verify, what documents to request, statutory basis for each. `null` for non-review outcomes.
`statute_citations`	`string[]`	Deduplicated list of all statute citations from evaluated rules
`rules_evaluated`	`array`	Full rule-by-rule evaluation trace (see below)
`document_assessments`	`array`	Per-document scoring results when `documents` were submitted

Rule Evaluation Result Object

Field	Type	Description
`rule_id`	`UUID`	Rule identifier
`title`	`string`	Human-readable rule name
`category`	`string`	Rule category (e.g., `"income_test"`, `"verification_tier"`)
`rule_type`	`string`	`"gate"`, `"calculation"`, `"conditional"`, `"meta"`, or `"review_trigger"`
`statute_citation`	`string`	The statute this rule enforces
`status`	`string`	`PASSED`, `FAILED`, `SKIPPED`, or `NEEDS_REVIEW`
`skipped_reason`	`string`	Why the rule was skipped (dependency not met, categorical eligibility applies, etc.)
`conditions`	`array`	Per-condition evaluation detail (field, operator, threshold, actual_value, passed, result_if_fail)
`primary_outcome`	`boolean`	Whether this rule's primary trigger evaluated as true — used by downstream dependency resolution

Example Response

The response contains the complete decision — outcome, human-readable summary, statute citations for every rule evaluated, AI caseworker briefing (when review is required), and the full evaluation trace. This response is simultaneously written as an immutable decision record.

        200 OK
        JSON
      

{
  "decision_id": "9f3c2e1b-0d4a-4b8e-a7f2-c1e6d5b4a3f9",
  "application_id": "APP-2026-000047",
  "outcome": "APPROVED_WITH_CONDITIONS",
  "summary": "LexiPoint recommends APPROVAL WITH CONDITIONS. Maria Martinez meets core eligibility requirements for the Community Assistance Program, but case worker verification is required before a final determination can be made. 29 rules passed; 2 rule(s) flagged for human review. Verification required: Self-Employment Documentation (CAP Code § 4.2.1(c)); Identity Verification (CAP Code § 4.7.2)",
  "needs_review_reason": "Self-Employment Documentation: Self-employment income documentation not provided (CAP Code § 4.2.1(c)); Identity Verification: Identity document not provided for Rosa Martinez (CAP Code § 4.7.2)",
  "blocking_rule": null,
  "queue_type": "review",
  "review_summary": "This application requires verification in two areas before a final determination can be made. Carlos Martinez reported self-employment income of $1,300 per month but did not provide supporting documentation. Per CAP Code § 4.2.1(c), tax returns or a profit/loss statement covering the most recent 12-month period must be obtained within 30 days. Rosa Martinez (age 68, disabled household member) did not provide identity documentation as required under § 4.7.2 — request at least one qualifying identity document. Both items are standard verification requests and neither affects the core eligibility determination; the household meets all income and asset thresholds. Once documentation is received and verified, this case can proceed to benefit allocation without further review.",
  "statute_citations": [
    "CAP Code § 4.1.1(a)",
    "CAP Code § 4.1.3",
    "CAP Code § 4.3.1(b)",
    "CAP Code § 4.2.1(c)",
    "CAP Code § 4.7.2",
    "CAP Code § 4.11.1"
  ],
  "rules_evaluated": [
    {
      "rule_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "title": "Primary Applicant Identification",
      "category": "household_composition",
      "rule_type": "gate",
      "statute_citation": "CAP Code § 4.1.1(a)",
      "status": "PASSED",
      "primary_outcome": true,
      "conditions": [
        {
          "field": "household_size",
          "operator": "gte",
          "threshold": "1",
          "actual_value": 5,
          "display_label": "At least one household member present",
          "passed": true,
          "result_if_fail": "BLOCKING"
        }
      ]
    },
    {
      "rule_id": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
      "title": "Net Income Test",
      "category": "income_test",
      "rule_type": "gate",
      "statute_citation": "CAP Code § 4.3.1(b)",
      "status": "PASSED",
      "primary_outcome": true,
      "conditions": [
        {
          "field": "net_monthly_income",
          "operator": "lte",
          "threshold": "3048",
          "actual_value": 2762.00,
          "display_label": "Net monthly income at or below 100% FPL for household size",
          "passed": true,
          "result_if_fail": "BLOCKING"
        }
      ]
    },
    {
      "rule_id": "c3d4e5f6-a7b8-9012-cdef-123456789012",
      "title": "Self-Employment Documentation",
      "category": "verification_tier",
      "rule_type": "review_trigger",
      "statute_citation": "CAP Code § 4.2.1(c)",
      "status": "NEEDS_REVIEW",
      "primary_outcome": false,
      "conditions": [
        {
          "field": "has_documentation",
          "operator": "eq",
          "threshold": "true",
          "actual_value": false,
          "display_label": "Self-employment income documentation not provided",
          "passed": false,
          "result_if_fail": "WARNING"
        }
      ]
    }
  ],
  // ... 28 additional rules in full trace omitted for brevity
  "document_assessments": [
    {
      "file_name": "martinez_pay_stubs.pdf",
      "file_path": "uploads/martinez_pay_stubs.pdf",
      "document_type_expected": "pay_stub",
      "document_type_detected": "pay_stub",
      "confidence_score": 0.94,
      "readable": true,
      "issues": []
    },
    {
      "file_name": "rosa_ss_statement.pdf",
      "file_path": "uploads/rosa_ss_statement.pdf",
      "document_type_expected": "social_security_statement",
      "document_type_detected": "social_security_statement",
      "confidence_score": 0.91,
      "readable": true,
      "issues": []
    }
  ]
}

Benefit amounts are rule outputs. Benefit calculation rules in the rules_evaluated trace carry the computed values (base amounts, supplements, adjustments) as condition thresholds and actual values. Your downstream system reads these from the rule trace to determine payment — LexiPoint's job is the eligibility determination and the audit trail, not benefit disbursement.

Immutable audit trail. Every evaluation writes a permanent decision record. Decision records cannot be modified or deleted. They serve as the legal basis for the determination and must be producible for audit, appeal, or judicial review per your program's regulatory framework.

Response Codes

200 Policy evaluated successfully. Decision record created.

400 Invalid request — missing required fields (program_id, applicant_name, or application) or malformed JSON.

401 Authentication failed — invalid or expired API key.

404 Program not found, or no active rules configured for the specified program.

500 Internal error — evaluation engine failure or persistence failure. No decision record written.

Error Response Format

        400 Bad Request
        JSON
      

{
  "error": "Missing required fields: program_id, application, applicant_name"
}

Get Decision Record

Retrieve a specific decision record by ID. Returns the complete decision including the full rule evaluation trace, statute citations, and review reasons. Decision records are immutable — this endpoint always returns the original evaluation result.

GET /v2/decisions/{decision_id}

Retrieve an immutable decision record for audit, appeal, or review.

Designed for due process. This endpoint is the answer to "why was this application denied?" Every decision record traces back to specific statutes, specific rules, and specific facts from the application — meeting the requirements of Mathews v. Eldridge and OMB M-24-10 for algorithmic decision transparency.

List Decisions

Query decision records with filters. Supports pagination, date ranges, and filtering by outcome, program, and queue type.

GET /v2/decisions

List and filter decision records across programs.

Query Parameters

Parameter	Type	Description
`program_id`	`string`	Filter by program
`outcome`	`string`	`APPROVED`, `APPROVED_WITH_CONDITIONS`, `NEEDS_REVIEW`, `DENIED`
`queue_type`	`string`	Filter to `"review"` or `"allocation"` queue items
`from`	`ISO 8601`	Start of date range
`to`	`ISO 8601`	End of date range
`limit`	`integer`	Results per page (default: 25, max: 100)
`cursor`	`string`	Pagination cursor from previous response

Decision Audit Trail

Returns the complete, chronological audit trail for a decision — from initial evaluation through any subsequent reviews, status changes, or appeals. Every lifecycle event is recorded with actor, timestamp, and detail.

GET /v2/decisions/{decision_id}/audit-trail

Full lifecycle audit trail for a decision record.

Run Scenario

Evaluate a hypothetical application without writing to the audit log. Used for scenario modeling, training, and "what-if" analysis. The evaluation engine runs identically to production — same rules, same dependency resolution — but no permanent record is created.

POST /v2/scenarios/evaluate

Run a hypothetical policy evaluation for scenario modeling.

Same engine, no side effects. Scenario evaluations use the identical decision engine as production. The only difference: no decision record is written to the audit log, and the response includes a "scenario": true flag.

Impact Analysis

Evaluate a proposed rule change against a population dataset to understand its impact before deployment. Submit a modified rule definition and a dataset; LexiPoint evaluates every record under both current and proposed rules and returns a comparison.

POST /v2/impact-analysis

Compare current vs. proposed policy rules across a population dataset.

Response Summary (abbreviated)

        200 OK — Impact Analysis Result
        JSON
      

{
  "analysis_id": "ia_2026_0317_c4e8f1a2",
  "program_id": "cap",
  "population_size": 12847,
  "rule_modified": "Net Income Test",
  "change_description": "Increase net income threshold from 100% to 130% FPL",

  "impact": {
    "newly_eligible": 1423,
    "newly_ineligible": 0,
    "no_change_count": 11424,
    "estimated_monthly_cost_change": 847200.00,
    "estimated_annual_cost_change": 10166400.00
  },

  "demographic_breakdown": {
    "by_household_size": { /* ... */ },
    "by_district": { /* ... */ }
  }
}

List Programs

GET /v2/programs

List all programs configured for this tenant, including rule counts and active status.

Get Rules

GET /v2/programs/{program_id}/rules

Retrieve all rules for a program, including conditions, dependency graph, statute citations, and evaluation order.

Rule Dependencies

GET /v2/programs/{program_id}/rules/dependencies

Returns the full rule dependency graph — which rules depend on which, evaluation order, and dependency type (BLOCKS, PREREQ, INPUT, ACTIVATES).

Platform Extensibility

LexiPoint is designed to extend without code changes. The API contract stays constant; your program rules, application schema, and deployment environment are all configuration.

Custom Application Fields

Any field submitted in the application{} payload is automatically available as a rule condition field — no API change, no code deployment required on your end or ours.

How it works. Rule conditions reference application fields by name (e.g., net_monthly_income, has_documentation). The engine evaluates whatever fields are present in the payload. To add a new eligibility factor, you add the field to your submission and create a rule condition that references it — the API endpoint, the authentication flow, and the audit trail all remain unchanged.

        Example: Custom Field in Application Payload
        JSON
      

// Your intake system begins submitting a new field:
{
  "program_id": "cap",
  "applicant_name": "Maria Martinez",
  "application": {
    "household_size": 5,
    "gross_monthly_income": 3450.00,
    "net_monthly_income": 2762.00,
    // New field — no API change needed:
    "months_continuous_residence": 18
  }
}

// In LexiPoint's rule editor, your policy team creates a new condition:
// field: "months_continuous_residence", operator: "gte", value: "12"
// result_if_fail: "BLOCKING", statute: "CAP Code § 4.1.5(a)"
// That rule is now live for every subsequent evaluation.

Program Onboarding

Adding a new program — a new agency, a new benefit type, a new jurisdiction — is a data exercise, not an engineering engagement. The /v2/evaluate endpoint fetches rules dynamically at evaluation time; no program-specific logic lives in the engine.

Step	What Happens	Who Does It
1. Create tenant + program	Register the agency and program in LexiPoint's ontology	LexiPoint onboarding (or self-serve in v2.1)
2. Author rules	Map statutes to rule conditions in the Ontology Manager UI or via API	Policy team (no-code rule editor)
3. Test with scenarios	Run representative cases through `/v2/scenarios/evaluate`	Policy team + QA
4. Go live	Change rule status to `active` — the endpoint starts serving the new program immediately	Policy team

Tenant Isolation

Every API call is scoped to a tenant. Rules, applications, decision records, and audit logs are isolated by tenant_id at the database layer — tenants cannot see each other's data.

Scope	Isolation Model
Rules	Each program's rules are tenant-owned; policy changes in one tenant never affect another
Applications	Application records and decision records are tenant-scoped with row-level security
Audit log	Audit events are tenant-scoped; your audit log is yours alone
Multi-program	One tenant can run multiple programs — same credentials, different `program_id`

Portable Deployment

LexiPoint's decision engine is a pure function — no cloud vendor dependencies, no proprietary runtime requirements. The infrastructure wrapper handles persistence and integrates with whichever database layer your environment provides.

┌─────────────────────────────────────────────┐ │ Infrastructure Wrapper │ │ index.ts — HTTP handler │ │ Reads rules from database │ │ Writes decision_records + audit_log │ │ ← Swap this layer for your cloud/DB │ └──────────────────────┬──────────────────────┘ │ ┌──────────────────────▼──────────────────────┐ │ Core Decision Engine │ │ engine.ts — pure function │ │ evaluatePolicy(rules, application) │ │ => DecisionResult │ │ ZERO cloud dependencies │ │ Portable to any runtime │ └─────────────────────────────────────────────┘

Deployment target support. The engine layer is runtime-agnostic. Current production runs on Deno (Supabase Edge Functions). Deployment into Azure Government or AWS GovCloud requires replacing the infrastructure wrapper — typically a 1–2 sprint configuration exercise, not a rewrite.

Regulatory Compliance

LexiPoint is designed to meet the following regulatory frameworks for algorithmic decision-making in government:

Framework	Requirement	How LexiPoint Complies
OMB M-24-10	Federal AI audit trail requirements	Every decision produces an immutable record with complete rule trace, inputs, and statute citations
Colorado SB24-205	Algorithmic due-care for high-risk decisions	Full explainability — every determination is traceable to specific rules and legal authority
Mathews v. Eldridge	Constitutional due process for benefits determinations	Decision records support notice, explanation, and appeal by identifying the factual and legal basis for every determination