Repository Docs & Knowledge Base

Consolidated Spensara documentation repository (722 Markdown & architecture documents in ../repository)

Built Word Documents (.docx): Spensara Overview (.docx) Capability Assessment (.docx) Brink POS Ingestion Analysis (.docx) The Borg Ingestion Architecture (.docx)

Branches (328)

Branch-specific documentation across extract-raw-xml, feature-fleet-import, kds_cdc_improvments, life-cycle, and tenat-admin.

branches/life-cycle/warehouse-model/docs/features/ETL/warehouse-data/curated-model/pos_tables.md 5,451 bytes · Updated Oct 23, 2026 10:44 AM EDT

Raw File

curated.pos_tables

Purpose

This table stores POS table lookup data used by dine-in operations. It provides the business identifiers and presentation fields needed to connect orders or layouts to specific restaurant tables.

It acts as lightweight reference data and is typically joined to more transactional datasets rather than queried on its own.

Warehouse design assessment

DW fit: Good small dimension for dine-in table context as long as the grain remains one row per physical or logical table.
Cross-client contract: Normalize table concepts across vendors because one source may store dining room layout differently from another.
IDs vs business values: id, usernumber, and revcenter help joins, but analysts also need table_name, revenue_center_name, and a readable table style or zone.
AI and business usability: Agents will produce more actionable dine-in insights if they can name the table or area instead of reporting only numeric table references.
Recommended extensions: Add table_key, source_system, source_table_id, table_name, revenue_center_name, zone_name, and style_name.

Detailed modeling guidance

Recommended role: Use this table as the canonical physical-table reference dimension with one row per active logical or physical table.
Key differences from a stronger curated model: The model should clearly represent dining context and not drift into transactional dine-in activity.
What is already useful: Table number, seat count, revenue center, and descriptive labels are directly useful for operations and AI.
What should move later to serving: Occupancy narratives, seating utilization metrics, and layout-driven recommendations belong in serving.

Curated contract columns

Column	Type	Monitor status	Purpose	Monitor rationale
`id`	`INTEGER`	Used by monitors	Table identifier in the POS source.	Join key that links dine-in orders or items back to physical table metadata. Monitors: customer-profiles, segment-customers.
`usernumber`	`INTEGER`	Used by monitors	User-visible table number in the source system.	Useful for grouping dine-in patterns by actual table identity or zone. Monitors: customer-profiles, segment-customers.
`revcenter`	`INTEGER`	Used by monitors	Revenue center associated with the table.	Adds dine-in area or service-zone context to customer segmentation. Monitors: customer-profiles, segment-customers.
`numseats`	`INTEGER`	Used by monitors	Number of seats available at the table.	Useful for inferring party-size tendencies and dine-in behavior. Monitors: customer-profiles, segment-customers.
`ownerid`	`INTEGER`	Available for future monitors	Owning configuration or location identifier.	Can help scope table definitions by site configuration, but current monitors focus on behavioral rather than configuration analysis. Potential monitors: segment-customers.
`desc`	`VARCHAR(20)`	Available for future monitors	Short descriptive label for the table.	Readable table labels improve drill-down and reporting context for dine-in segments. Potential monitors: customer-profiles, segment-customers.
`style`	`INTEGER`	Available for future monitors	Style or layout code for the table.	Could help distinguish bar, booth, patio, or counter experiences if decoded later. Potential monitors: segment-customers.
`table_key`	`BIGINT`	Recommended extension	Stable warehouse key for the table entity.	Recommended to create one canonical table identifier across clients and source systems.
`source_system`	`VARCHAR(100)`	Recommended extension	Canonical name of the source platform that produced the table row.	Recommended to preserve lineage in a shared curated schema.
`source_table_id`	`VARCHAR(199)`	Recommended extension	Original table identifier from the source platform.	Recommended to support traceability back to staging records.
`table_name`	`VARCHAR(255)`	Recommended extension	Readable business name or label for the table.	Recommended because table names are more useful than numeric table identifiers in analysis.
`revenue_center_name`	`VARCHAR(255)`	Recommended extension	Readable revenue center name associated with the table.	Recommended to make dine-in area analysis understandable for business users.
`zone_name`	`VARCHAR(255)`	Recommended extension	Readable dining zone or seating area name for the table.	Recommended to add better layout context than raw identifiers alone.
`style_name`	`VARCHAR(255)`	Recommended extension	Readable business label for the table style.	Recommended because style names are more actionable than style codes in AI and business reporting.
`tenant_key`	`BIGINT`	Recommended extension	Stable warehouse key for the tenant, brand, or client that owns the table.	Recommended because shared curated reference data should preserve explicit client context.
`tenant_name`	`VARCHAR(255)`	Recommended extension	Readable tenant, brand, or client name associated with the table.	Recommended to improve business and AI usability in cross-client dine-in analysis.
`is_active`	`BOOLEAN`	Recommended extension	Canonical flag indicating whether the table is active in the curated model.	Recommended to expose a simple lifecycle state for the table entity.