Technical demonstration · synthetic data
Read-only Data Bridge
/ Exception View
The read layer normalizes data from three sources, hides correct records and shows only cases that require human attention.
●
Demonstrator without writes to source systemsBuilt-in data is synthetic. Processing and export run locally in the browser.
Incremental and event-driven integration
Checkpoint, replay, retry and webhook
Scenarios are deterministic. The checkpoint is saved after a completed page, and business state is updated with an idempotent upsert by source_id. This is not a promise of distributed exactly-once semantics.
Run ID / correlationPASS · RUN-DB-INCREMENTAL_BASELINE
CORR-RUN-DB-INCREMENTAL_BASELINE · mode incremental-baseline · checkpoint: 2026-09-16T08:15:00Z
| Stage | Event | Entity | Evidence |
|---|---|---|---|
| start | RUN_STARTED | run | Deterministic run started. |
| fetch | PAGE_FETCHED | page-1 | 2 records · cursor cursor-1 |
| apply | RECORD_INSERTED | SRC-1001 | version 1 |
| apply | RECORD_INSERTED | SRC-1002 | version 1 |
| checkpoint | CHECKPOINT_SAVED | cursor | 2026-09-16T08:05:00Z · cursor 2026-09-16T08:05:00Z |
| fetch | PAGE_FETCHED | page-2 | 2 records · cursor cursor-2 |
| apply | RECORD_INSERTED | SRC-1003 | version 1 |
| apply | RECORD_INSERTED | SRC-1004 | version 1 |
| checkpoint | CHECKPOINT_SAVED | cursor | 2026-09-16T08:15:00Z · cursor 2026-09-16T08:15:00Z |
| complete | RUN_COMPLETED | run | Baseline import completed. |
Target state and evidence
{
"summary": {
"input": 4,
"inserted": 4,
"updated": 0,
"unchanged": 0,
"rejected": 0,
"duplicatesPrevented": 0
},
"target": [
{
"source_id": "SRC-1001",
"version": 1,
"updated_at": "2026-09-16T08:00:00Z",
"status": "active",
"payload": {
"amount": 120,
"note": "baseline"
}
},
{
"source_id": "SRC-1002",
"version": 1,
"updated_at": "2026-09-16T08:05:00Z",
"status": "active",
"payload": {
"amount": 80,
"note": "baseline"
}
},
{
"source_id": "SRC-1003",
"version": 1,
"updated_at": "2026-09-16T08:10:00Z",
"status": "active",
"payload": {
"amount": 44,
"note": "page-2"
}
},
{
"source_id": "SRC-1004",
"version": 1,
"updated_at": "2026-09-16T08:15:00Z",
"status": "active",
"payload": {
"amount": 68,
"note": "page-2"
}
}
],
"evidence": {
"checkpointRule": "Save the checkpoint after completing a page. Apply records with an idempotent upsert keyed by source_id."
}
}Synthetic order, inventory and shipment records.
Read → normalize → evaluate rules without writing to the source.
Deadline, status, inventory, identifier and shipment.
Exception queue with evidence and recommended actions.
Repeatable dataset: 11 exceptions; filtering and export preserve the result.
01Export / read-only API→
02Normalization→
03Rules→
04Exception queue
Controlled change: shipment tracking number SHP-001 for ORD-001 is removed. The rule points to the exact shipment that needs review.
Demo data
Action queue
30 orders, inventory and shipment statuses with intentionally seeded exceptions.
Normal records are moved out of the way
After running the demo, you see a short exception queue instead of manually reviewing all records.
What this example demonstrates
Small scope from read access to decision
Rules are demonstrative. In a real implementation, their content and source availability must be agreed for the specific process.
3 sources
Orders, inventory and shipments from an export or read-only interface.
Common model
Field names and identifiers are normalized into one structure.
Explicit exceptions
Completeness, statuses, SKU, inventory, duplicates and delays.
Action queue
Priority, source, detected value and recommended next step.
Stable result
All seeded exceptions detected; export matches the view.
Implementation scope
Exception view without rebuilding the system
One selected export or read-only source → agreed rules → exception view → report / export.
The first stage can use a sample, export or read-only access and may not require production write permissions. The access method is chosen for the specific ERP constraints and agreed scope.
Describe the scope