# Warehouse Data

## Purpose

This folder contains warehouse data model documentation for ETL-owned serving schemas.

It is meant to be the human-readable reference for what the tenant warehouse exposes after ETL publication, starting with the `curated` schema.

## Contents

- `brinkPos-staging-model/` - Brink POS source-shaped staging tables, one document per raw API operation
- `brinkPos-curated-model-mapps/` - one document per `curated` table mapping curated columns to Brink staging sources
- `curated-model/` - one document per `curated` table, with table purpose and column-level descriptions
- `logic-control-aloha-staging-model/` - source-shaped Aloha staging tables from the current SQL bootstrap
- `logic-control-kds-staging-model/` - source-shaped KDS staging tables from the current SQL bootstrap
- `logic-control-pos-staging-model/` - source-shaped Labpos and POS staging tables from the current SQL bootstrap

## Current Brink XML -> Parquet -> Redshift validation scope

Validated in the current iteration:

- `Sales2.GetOrders`
- `Labor.GetShifts`
- `Settings2.GetItems`
- `Settings2.GetEmployees`
- `Settings2.GetJobs`

For the current Brink `staging -> curated` implementation, the active curated targets are:

- `curated.pos_orders`
- `curated.pos_order_items`
- `curated.pos_menu_items`
- `curated.employees`
- `curated.pos_jobs`
- `curated.labor_shifts`
- `curated.pos_destinations`

`Settings2.GetDestinations` staging data is used as a lookup join in `curated.pos_orders` for `order_type`, `destination`, `service_channel`, and `fulfillment_channel`, but the standalone extract-to-staging flow is not yet independently scheduled.

Explicitly deferred to the next iteration:

- `Settings2.GetTables`
- `Settings2.GetKitchenQueues`
- `Settings2.GetTaxes`
- `Settings.GetTenders`