Categories
Implementation Specs (157)
- specs/AnomalyDetection/TASK1.1.md
- specs/AnomalyDetection/TASK1.2.md
- specs/AnomalyDetection/TASK1.3.md
- specs/AnomalyDetection/TASK1.4.md
- specs/AnomalyDetection/TASK2.1.md
- specs/AnomalyDetection/TASK2.2.md
- specs/AnomalyDetection/TASK3.1.md
- specs/AnomalyDetection/TASK3.2.md
- specs/AnomalyDetection/TASK3.3.md
- specs/AnomalyDetection/TASK4.1.md
- specs/AnomalyDetection/TASK4.2.md
- specs/AnomalyDetection/TASK4.3.md
- specs/AnomalyDetection/TASK4.4.md
- specs/AnomalyDetection/TASK5.1.md
- specs/AnomalyDetection/TASK5.2.md
- specs/AnomalyDetection/TASK5.3.md
- specs/AnomalyDetection/TASK6.1.md
- specs/AnomalyDetection/TASK6.2.md
- specs/AnomalyDetection/TASK6.3.md
- specs/AnomalyDetection/TASKS.md
- specs/ApiServicePostgresTestStability/TASK.md
- specs/BackendDatabaseConsolidation/TASK.md
- specs/BackendDatabaseConsolidation/TASK1.1.md
- specs/BackendDatabaseConsolidation/TASK1.2.md
- specs/BackendDatabaseConsolidation/TASK1.3.md
- specs/BackendDatabaseConsolidation/TASK2.1.md
- specs/BackendDatabaseConsolidation/TASK2.2.md
- specs/BackendDatabaseConsolidation/TASK2.3.md
- specs/BackendDatabaseConsolidation/TASK3.1.md
- specs/BackendDatabaseConsolidation/TASK3.2.md
- specs/BackendDatabaseConsolidation/TASK4.1.md
- specs/BackendDatabaseConsolidation/TASK4.2.md
- specs/BackendDatabaseConsolidation/TASK4.3.md
- specs/BackendDatabaseConsolidation/TASK5.1.md
- specs/BackendDatabaseConsolidation/TASK5.2.md
- specs/BrinkLaborGetShiftsStaging/TASK.md
- specs/BrinkPosOrdersFirstEtlJob/TASK.md
- specs/BrinkPosOrdersFirstEtlJob/TASK0.md
- specs/BrinkPosOrdersFirstEtlJob/TASK1.md
- specs/BrinkPosOrdersFirstEtlJob/TASK2.1.md
- specs/BrinkPosOrdersFirstEtlJob/TASK2.2.md
- specs/BrinkPosOrdersFirstEtlJob/TASK2.3.md
- specs/BrinkPosOrdersFirstEtlJob/TASK2.4.md
- specs/BrinkPosOrdersFirstEtlJob/TASK2.md
- specs/BrinkPosOrdersFirstEtlJob/TASK3.1.md
- specs/BrinkPosOrdersFirstEtlJob/TASK3.2.md
- specs/BrinkPosOrdersFirstEtlJob/TASK3.3.md
- specs/BrinkPosOrdersFirstEtlJob/TASK3.4.md
- specs/BrinkPosOrdersFirstEtlJob/TASK3.md
- specs/BrinkPosOrdersFirstEtlJob/TASK4.1.md
- specs/BrinkPosOrdersFirstEtlJob/TASK4.2.md
- specs/BrinkPosOrdersFirstEtlJob/TASK4.3.md
- specs/BrinkPosOrdersFirstEtlJob/TASK4.4.md
- specs/BrinkPosOrdersFirstEtlJob/TASK4.md
- specs/BrinkPosOrdersFirstEtlJob/TASK5.1.md
- specs/BrinkPosOrdersFirstEtlJob/TASK5.2.md
- specs/BrinkPosOrdersFirstEtlJob/TASK5.3.md
- specs/BrinkPosOrdersFirstEtlJob/TASK5.4.md
- specs/BrinkPosOrdersFirstEtlJob/TASK5.md
- specs/BrinkPosOrdersFirstEtlJob/TASK6.1.md
- specs/BrinkPosOrdersFirstEtlJob/TASK6.2.md
- specs/BrinkPosOrdersFirstEtlJob/TASK6.3.md
- specs/BrinkPosOrdersFirstEtlJob/TASK6.4.md
- specs/BrinkPosOrdersFirstEtlJob/TASK6.md
- specs/BrinkPosOrdersFirstEtlJob/TASK7.md
- specs/BrinkPosOrdersFirstEtlJob/TASK8.md
- specs/BrinkPosOrdersFirstEtlJob/TASK9.md
- specs/BrinkSettings2ToStaging/TASK.MD
- specs/CuratedToS3Stage/TASK.md
- specs/CuratedToS3Stage/TASK0.md
- specs/CuratedToS3Stage/TASK1.md
- specs/CuratedToS3Stage/TASK2.md
- specs/CuratedToS3Stage/TASK3.md
- specs/CuratedToS3Stage/TASK4.md
- specs/CustomerCredentialCustomHeaders/TASK.md
- specs/CustomerCredentialCustomHeaders/TASK1.1.md
- specs/CustomerCredentialCustomHeaders/TASK1.2.md
- specs/CustomerCredentialCustomHeaders/TASK2.1.md
- specs/CustomerCredentialCustomHeaders/TASK2.2.md
- specs/CustomerCredentialCustomHeaders/TASK3.1.md
- specs/CustomerCredentialTriggeredProvisioning/TASK.md
- specs/CustomerCredentialTriggeredProvisioning/TASK1.1.md
- specs/CustomerCredentialTriggeredProvisioning/TASK1.2.md
- specs/CustomerCredentialTriggeredProvisioning/TASK2.1.md
- specs/CustomerCredentialTriggeredProvisioning/TASK2.2.md
- specs/CustomerCredentialTriggeredProvisioning/TASK3.1.md
- specs/CustomerCredentialTriggeredProvisioning/TASK3.2.md
- specs/CustomerCredentialTriggeredProvisioning/TASK4.1.md
- specs/EtlSourceAdapterFramework/TASK.md
- specs/EtlSourceAdapterFramework/TASK0.md
- specs/EtlSourceAdapterFramework/TASK1.md
- specs/EtlSourceAdapterFramework/TASK2.md
- specs/EtlSourceAdapterFramework/TASK3.md
- specs/EtlSourceAdapterFramework/TASK4.md
- specs/EtlSourceAdapterFramework/TASK5.md
- specs/EtlSourceAdapterFramework/TASK6.md
- specs/KdsCdcDebeziumIntegration/TASK.md
- specs/KdsCdcDebeziumIntegration/TASK1.md
- specs/KdsCdcDebeziumIntegration/TASK2.md
- specs/KdsCdcDebeziumIntegration/TASK3.md
- specs/KdsCdcDebeziumIntegration/TASK4.md
- specs/KdsCdcDebeziumIntegration/TASK5.md
- specs/KdsCdcDurableRelationRouting/TASK.md
- specs/KdsCdcDurableRelationRouting/TASK1.md
- specs/KdsCdcDurableRelationRouting/TASK2.md
- specs/KdsCdcDurableRelationRouting/TASK3.md
- specs/KdsCdcDurableRelationRouting/TASK4.md
- specs/KdsCdcDurableRelationRouting/TASK5.md
- specs/KdsCdcIngestion/TASK.md
- specs/KdsCdcIngestion/TASK1.md
- specs/KdsCdcIngestion/TASK2.md
- specs/KdsCdcIngestion/TASK3.md
- specs/KdsCdcIngestion/TASK4.md
- specs/KdsCdcIngestion/TASK5.md
- specs/KdsCdcIngestion/TASK6.md
- specs/KdsCdcIngestion/TASK7.md
- specs/KdsCdcIngestion/TASK8.md
- specs/KdsCdcIngestion/TASK9.md
- specs/KdsCdcReplayExecution/TASK.md
- specs/KdsCdcReplayExecution/TASK1.md
- specs/KdsCdcReplayExecution/TASK2.md
- specs/KdsCdcReplayExecution/TASK3.md
- specs/KdsCdcReplayExecution/TASK4.md
- specs/KdsMonitorServingContractMigration/TASK.md
- specs/KdsMonitorServingContractMigration/TASK1.1.md
- specs/KdsMonitorServingContractMigration/TASK1.2.md
- specs/KdsMonitorServingContractMigration/TASK2.1.md
- specs/KdsMonitorServingContractMigration/TASK2.2.md
- specs/KdsMonitorServingContractMigration/TASK3.1.md
- specs/KdsMonitorServingContractMigration/TASK3.2.md
- specs/RedshiftFoundation/TASK.md
- specs/RedshiftFoundation/TASK1.1.md
- specs/RedshiftFoundation/TASK1.2.md
- specs/RedshiftFoundation/TASK1.3.md
- specs/RedshiftFoundation/TASK1.4.md
- specs/RedshiftFoundation/TASK2.1.md
- specs/RedshiftFoundation/TASK2.2.md
- specs/RedshiftFoundation/TASK3.1.md
- specs/RedshiftFoundation/TASK3.2.md
- specs/RedshiftFoundation/TASK3.3.md
- specs/RedshiftSyntheticDataFeed/TASK.md
- specs/RedshiftSyntheticDataFeed/TASK1.1.md
- specs/RedshiftSyntheticDataFeed/TASK1.2.md
- specs/RedshiftSyntheticDataFeed/TASK1.3.md
- specs/RedshiftSyntheticDataFeed/TASK2.1.md
- specs/RedshiftSyntheticDataFeed/TASK2.2.md
- specs/RedshiftSyntheticDataFeed/TASK3.1.md
- specs/RedshiftSyntheticDataFeed/TASK3.2.md
- specs/SingleStoreRedshiftRuntimeReadPath/TASK.md
- specs/SingleStoreRedshiftRuntimeReadPath/TASK1.1.md
- specs/SingleStoreRedshiftRuntimeReadPath/TASK1.2.md
- specs/SingleStoreRedshiftRuntimeReadPath/TASK2.1.md
- specs/SingleStoreRedshiftRuntimeReadPath/TASK2.2.md
- specs/SingleStoreRedshiftRuntimeReadPath/TASK2.3.md
- specs/SingleStoreRedshiftRuntimeReadPath/TASK3.1.md
- specs/SingleStoreRedshiftRuntimeReadPath/TASK3.2.md
- specs/SingleStoreRedshiftRuntimeReadPath/TASK4.1.md
TASK 4: Update Normalization And Load Path For Debezium Row Images, Native item_bumps, And Curated Rebuild From Staging State
Summary
Update downstream normalization and staging load so KDS CDC works from real Debezium row images, supports native item_bumps, and rebuilds curated state from staging truth.
Current Codebase Findings
Repository analysis shows:
KdsCdcNormalizeLoadJobscurrently reads fields directly fromrecord.Envelope.Payloadas if it were a flat row object.- real Debezium payload nests data under
payload.before/payload.after. - current row mappers for orders, items, item_bumps, and customers are structurally close to the target staging schema, but they read from the wrong JSON level.
- sample payload set includes native
item_bumpsmessage. staging.kds_item_bumpsandcurated.kitchen_item_status_eventsstill exist and must remain supported downstream.- current curated SQL depends on parent rows already being present, which makes child application sensitive to arrival timing.
Dependencies
- TASK 1
- TASK 2
- TASK 3
Source References
../../docs/features/ETL/kds-cdc/payloads/customer_update.json../../docs/features/ETL/kds-cdc/payloads/item_create.json../../docs/features/ETL/kds-cdc/payloads/item_update.json../../docs/features/ETL/kds-cdc/payloads/item_bump_create.json../../docs/features/ETL/kds-cdc/payloads/order_create.json../../docs/features/ETL/kds-cdc/payloads/order_update.json../../docs/features/ETL/kds-cdc/payloads/order_delete.json../../docs/features/ETL/warehouse-data/logic-control-kds-staging-model/kds_item_bumps.md../../docs/features/ETL/warehouse-data/curated-model/kitchen_item_status_events.md
Scope From Breakdown
This task covers:
- row-image-aware normalization,
- entity mapping for order/item/customer/item-bump Debezium messages,
- downstream stage compatibility with existing staging/curated SQL.
- curated rebuild behavior from tenant staging state.
Files to Modify
backend/Kds.Ai.Integrations/KdsCdc/KdsCdcNormalizeLoadJobs.csbackend/Kds.Ai.Integrations/KdsCdc/KdsCdcRowModels.csif needed- any raw record model that should expose effective row image or parsed Debezium metadata
- tests under
backend/tests/Kds.Ai.Integrations.Tests/KdsCdc/
Required Behavior
Row-image-aware mapping
Normalizer must map business columns from selected Debezium row image, not from whole envelope payload.
Required rule:
c,u,ruseafterdusebefore
Required failure behavior:
c,u, orrwith missingafteris invalid for normalization,dwith missingbeforeis invalid for normalization,- unknown extra columns are preserved in raw and ignored by normalizers unless mapped explicitly,
- missing required mapped columns fail with diagnostics rather than producing partial silent rows.
Required primary-key map:
orders:guid,customers:guid,items:guid,item_bumps:guid.
If a supported table lacks its required primary key in the selected row image, normalization must fail as non-retryable for that row and preserve diagnostics/lineage.
Orders, items, customers, item bumps
Normalizer must support at least:
- orders create/update/delete,
- customers update,
- items create/update from current sample shape,
- native item-bumps create from current sample shape.
Native item_bumps
Integration must support source-shaped item_bumps rows directly from native Debezium payloads.
Do not make derived item_bumps the baseline path for this slice.
Curated rebuild from staging state
After staging load succeeds, downstream curated behavior must rebuild affected curated targets from tenant staging state.
This task must lock semantic rule that:
staging_to_curateddoes not treat one current arrival window as final truth,- child entity correctness does not depend on parent arriving first in same intake window,
- join-skipped children are not silently treated as complete success.
Required parent/child disorder behavior:
- if an item or item-bump cannot be promoted because relation state is missing, it remains in landing retry state until relation state is available,
- when the parent order or item later updates relation state, unresolved landing records can promote to tenant RAW,
- once promoted and loaded, curated rebuild reads full tenant staging state, not only tables present in the current load batch,
- a curated target skipped because dependencies are incomplete must leave durable diagnostics/state that can be retried; it must not be reported as final success for that affected child event.
Schema evolution behavior
Debezium payloads may include columns not currently mapped.
Required behavior:
- raw layers preserve the complete original payload,
- normalizers tolerate unknown extra columns,
- required known columns remain enforced per entity,
- diagnostics identify unsupported tables or missing required fields with entity, operation, primary key when available, and source coordinates.
Testing
Add normalization-focused tests for:
- order create payload,
- order update payload,
- order delete payload,
- customer update payload,
- item create payload,
- item update payload,
- native item-bump payload,
- delete semantics selecting
beforeimage correctly, - missing
afterfor create/update/read fails clearly, - missing
beforefor delete fails clearly, - missing primary key fails clearly,
- unknown extra columns do not break normalization,
- curated rebuild behavior for parent/child arrival disorder,
- item arrives before order, remains unresolved, then promotes after order relation index exists,
- item-bump arrives before item relation exists, remains unresolved, then promotes after item relation index exists.
Acceptance Criteria
- [ ] Normalizer reads from Debezium row image, not flat payload root
- [ ] Orders normalize correctly from sample payloads
- [ ] Customers normalize correctly from sample payloads
- [ ] Items normalize correctly from sample payloads
- [ ] Native
item_bumpsnormalize correctly from sample payloads - [ ] Missing selected row image and missing primary key cases fail with clear diagnostics
- [ ] Unknown extra columns are tolerated while raw payload remains preserved
- [ ] Existing staging and curated downstream contracts remain satisfiable
- [ ] Curated rebuild semantics are aligned with staging-state source of truth
- [ ] Parent/child disorder tests prove delayed promotion plus staging-state rebuild correctness
- [ ] Tests cover create/update/delete row-image selection and parent/child consistency behavior
Notes
- Keep stage behavior explicit. Rebuild from staging truth is preferred over fragile intake-time semantics.