> ## Documentation Index
> Fetch the complete documentation index at: https://ar-528b7fb5.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Ai context

# AI context – lending analytics

This file provides data and model context for the internal AI analytics chatbot at ExampleCorp.
It defines what each table and column represents and how the data should be interpreted.

## Table: applications

Each row represents a single application submitted by a user for a lending product.

### application\_id

Meaning:\
Unique identifier for a single application event.

Relationship:\
applications.application\_id → decisions.application\_id\
applications.application\_id → financial\_signals.application\_id

Constraints:\
Required. Must be unique per application. Must not be null.

### user\_id

Meaning:\
Internal identifier for the user who submitted the application.

Relationship:\
applications.user\_id → users.user\_id

Constraints:\
Required. Must not be null.

### submitted\_at

Meaning:\
Timestamp when the application was submitted.

Relationship:\
None.

Constraints:\
Required. Must be a valid timestamp in UTC.

### product\_type

Meaning:\
Type of lending product the user applied for.

Relationship:\
None.

Constraints:\
Required. Value must be one of the supported product types.

Value range:\
cash\_advance, installment\_loan, credit\_builder

### application\_status

Meaning:\
Current lifecycle status of the application.

Relationship:\
None.

Constraints:\
Required.

Value range:\
submitted, in\_review, completed, cancelled

***

## How column constraints are determined

In a company setting, information such as whether a column can be null or must be unique is determined based on existing data infrastructure and documentation.

In practice, this information usually comes from:

* the database schema and internal data catalog (for nullability and data types)
* transformation and modeling code (for example, dbt tests such as `not_null` and `unique`)
* existing data quality checks and monitoring rules owned by the data platform or BI team
* how the data is used in downstream dashboards, metrics, and joins
* confirmation from subject-matter experts when the behavior is not explicit in code or documentation

The constraints documented in this file follow this same approach.
Because this repository uses synthetic data from a fictional company (ExampleCorp), standard industry assumptions are applied (for example, identifiers are treated as required).