Synthesized Vault Data Simulation Logic
이 문서는 vault-amr-fulfillment-source-world-v0.1 데이터셋이 어떤 simulation logic으로 설계되었는지 설명한다.
핵심은 온톨로지 schema를 먼저 강제하는 것이 아니라, 실제 보수적인 물류 운영 환경에서 발생할 법한 source-system data를 먼저 합성하고, 그 위에서 ontology compiler와 digital twin이 독립적으로 검증될 수 있게 만드는 것이다.
1. 왜 이 synthetic data가 필요한가
현재 단계의 목적은 Colosseum Vault의 실제 데이터를 받기 전에, 우리가 만들 ontology pipeline과 AI-ready infrastructure가 현실적인 물류 데이터의 난잡함을 견딜 수 있는지 검증하는 것이다. 그래서 이 데이터셋은 깨끗한 toy dataset이 아니라, 여러 conservative operation system에서 따로 떨어져 나오는 export를 흉내 낸다.
이 접근이 중요한 이유는 실제 보수적인 물류 환경에서는 하나의 시스템이 모든 진실을 들고 있지 않기 때문이다. WMS는 주문과 재고를 알고, WCS는 작업 실행 상태를 알고, AMR system은 로봇 상태를 알고, TMS는 dock appointment와 carrier 변동을 알고, scan system은 physical movement의 일부만 확인한다. 사람의 note와 approval은 지연되거나 누락된다.
2. 생성 아키텍처
생성기는 하나의 private operational truth에서 시작하지만, 이 truth를 그대로 source export에 노출하지 않는다. private truth는 시뮬레이션을 검증하기 위한 내부 기준이고, 실제 source export는 부분적이고 지연되고 서로 충돌할 수 있게 만든다.
| Layer | 역할 | 현재 파일 |
|---|---|---|
| Private truth | 원인, causal chain, hidden operational state를 보존하는 내부 기준 데이터다. source export가 아니라 validation과 replay를 위한 기준이다. | data/synthetic/.../private_truth/scenario_truth.json |
| Source exports | 실제 Vault 주변 시스템에서 받을 법한 CSV, JSONL, JSON export다. 시스템별 지연, stale snapshot, partial update, local alias를 포함한다. | data/synthetic/.../source_exports/* |
| App fixture | Next.js digital twin이 빠르게 consume할 수 있도록 source-world와 replay metadata를 묶은 runtime fixture다. | src/data/generated/twin-scenario.json |
| Reports | validation, data dictionary, simulation trace를 사람이 검토할 수 있는 HTML로 만든다. | data/synthetic/.../reports/*.html |
Generator: scripts/generate-synthetic-world.mjs
Validator: scripts/validate-synthetic-world.mjs
3. Source world의 운영 범위
현재 synthetic world는 서울권 AMR fulfillment center를 가정한다.
facility id는 SEL-FC-01이고, 시나리오명은 Synthetic Seoul AMR Fulfillment Center다.
범위는 inbound 전체가 아니라 outbound fulfillment incident replay에 집중한다.
Facility zones
facility는 Receiving, Reserve, Pick Face, Cold Zone, Pack Station, Staging Lane, Outbound Dock, Charging Bay, Operations로 나뉜다.
각 location은 source location code, local alias, type, capacity unit, coordinate, allowed asset type, restricted flag를 가진다.
Cold Zone에는 AISLE-COLD-CHOKE라는 병목 aisle segment를 따로 두어 route blockage를 모델링했다.
Asset model
AMR은 일반 lift robot과 cold-capable robot을 분리한다.
AMR-17은 시나리오 peak에서 stale availability와 low battery lock의 충돌을 만드는 핵심 asset이고, AMR-44는 maintenance pending 상태로 fleet capacity를 좁히는 역할을 한다.
charger, pack/stage/dock resources는 단순 배경 장식이 아니라 capacity stress와 3D twin layer에 직접 연결된다.
4. Source export 설계
source export는 한 파일 안에 모든 것을 넣지 않고, 실제 시스템 boundary를 따라 분리했다. 이 분리는 이후 ontology pipeline의 첫 번째 테스트 조건이다. 좋은 ontology compiler라면 각 source의 partial truth를 합쳐야 하지만, 합치기 전에는 각 source의 원래 맥락을 보존해야 한다.
| Export | Source system assumption | 왜 필요한가 |
|---|---|---|
vault_deployment_context.json |
Vault deployment context | facility, operating calendar, integration scope, source system assumptions를 담는다. |
facility_locations.csv, layout_edges.csv |
facility master, routing master | 물류 twin과 graph traversal의 물리적 기반이다. route blockage와 congestion이 edge 단위로 표현된다. |
wms_orders.csv, wms_order_lines.csv |
WMS order allocation | customer promise, service tier, order status, line shortage, hold state를 만든다. |
wms_inventory_positions.csv |
WMS inventory and cycle count | logical inventory와 physical count가 충돌하는 상황을 만든다. |
wcs_work_tasks.csv |
WCS execution task export | pick, move, stage, load work의 status, priority, AMR assignment, route dependency를 표현한다. |
amr_task_events.jsonl, amr_state_snapshots.jsonl |
AMR fleet system | event stream과 low-frequency snapshot을 분리해 stale robot availability 문제를 만든다. |
warehouse_scan_events.jsonl |
handheld scan export | physical movement confirmation, missing scan, late scan, variance를 표현한다. |
tms_outbound_shipments.csv |
TMS and dock appointment | carrier arrival variance, dock slack compression, partial shipment closeout을 만든다. |
exception_and_action_events.jsonl |
operator note and approval log | manual note delay, supervisor intervention, customer notice pending 상태를 표현한다. |
labor_shift_roster.csv |
shift lead roster and labor coverage export | role별 scheduled/available/borrowed headcount, certification, break coverage gap, approval lane capacity를 기록한다. |
resource_capacity_snapshots.csv |
capacity planning or WCS capacity snapshot | labor, station, staging, dock, AMR, supervisor approval capacity를 시간별로 관측한다. |
handling_unit_lineage_events.csv |
movement lineage ledger | carton/tote가 pick, pack, stage, dock을 지나며 late, missing, blocked, inferred 상태가 되는 것을 기록한다. |
source_system_sync_runs.csv |
connector sync telemetry | 각 source export가 event window마다 current, watch, stale, partial 상태인지, lag/retry/rejected row가 어느 정도인지 기록한다. |
source_event_ledger.jsonl |
derived replay spine | 원천 row를 없애지 않고 source file, source record id, scenario event, location/entity refs, freshness window, replay order로 묶는다. |
Source freshness를 별도 export로 둔 이유
실제 운영 환경에서 AI 판단 품질은 record 내용뿐 아니라 source freshness에 크게 좌우된다.
AMR event stream은 current인데 AMR state snapshot은 stale일 수 있고, TMS carrier update는 먼저 들어왔지만 WCS task, labor roster, capacity, lineage export는 늦을 수 있다.
그래서 source_system_sync_runs.csv는 데이터 품질 metadata가 아니라 operational evidence로 취급된다.
Source event ledger를 둔 이유
source_event_ledger.jsonl은 새 원천 시스템이 아니라, WMS/WCS/AMR/TMS/scan/operator/labor/capacity/lineage/sync row를 시간순으로 재생하기 위한 derived spine이다.
중요한 점은 source-system boundary를 병합하지 않는다는 것이다. 각 ledger row는 원래 source_file과 source_record_id를 유지하고, 별도로 scenario_event_id, primary_location_id, entity_refs, freshness_state, sync_lag_min을 붙인다.
따라서 ontology compiler는 raw export를 직접 읽을 수도 있고, 같은 row를 ledger 순서로 replay하면서 incremental ingestion 상황도 테스트할 수 있다.
5. Incident timeline
시나리오는 한 주 동안의 baseline에서 출발해 premium outbound cutoff incident로 압력이 올라갔다가 partial recovery로 끝난다. 각 timeline event는 source refs, affected orders/assets/locations, operational metrics, evidence chain, causal replay에 연결된다.
| Step | Event | Operational meaning | Main source signals |
|---|---|---|---|
T00 |
Facility baseline established | 주문, 재고, AMR, charger, dock, route map이 정상 상태로 보이는 baseline이다. | facility, WMS, WCS, AMR, TMS |
T01 |
SKU-AX100 cycle count disputes pick-face availability | WMS allocation은 충분해 보이지만 handheld count가 pick-face 부족을 드러낸다. | inventory, scan, order line |
T02 |
Cold-zone throat is blocked but source updates arrive late | 물리적 aisle blockage가 먼저 생기고, source system의 route unavailability 반영이 늦어진다. | layout edge, scan, operator note |
T03 |
AMR fleet capacity narrows before premium wave | maintenance pending, charger queue, battery drift 때문에 premium wave 전에 fleet capacity가 좁아진다. | AMR snapshot, WCS task, capacity |
T04 |
AMR-17 is selected from stale availability and then forced to charge | WCS는 오래된 available snapshot을 믿지만, AMR event stream은 low battery lock을 뒤늦게 방출한다. | AMR event, AMR snapshot, task, lineage |
T05 |
Carrier arrives early and dock window moves forward | carrier가 빨리 도착하고 dock appointment가 당겨져, dock/stage/cold AMR constraint가 peak로 올라간다. | TMS, WCS, labor, capacity, lineage, exception |
T06 |
Supervisor splits task chain and resequences premium lines | supervisor가 split/resequence를 승인해 ambient work는 회복하지만 cold-line issue는 남긴다. | operator event, WCS task, scan, labor, capacity |
T07 |
Partial shipment clears while one issue remains open | 일부 premium carton은 출고되지만 한 order와 route blockage ticket은 완전히 닫히지 않는다. | TMS, scan, exception, lineage |
6. Deterministic rules와 planned randomness
이 데이터셋은 완전 random generator가 아니다.
테스트 재현성을 위해 seed는 20260618이고, randomness는 운영상 자연스러운 변동을 만들기 위한 bounded variable로만 사용한다.
사건의 원인과 순서는 deterministic rule로 고정되어 있으며, randomness는 delay, jitter, variance, partial yield 같은 현실감을 만든다.
| Event | Deterministic rule | Planned randomness |
|---|---|---|
T00 |
baseline order, inventory, fleet, route map을 분리 source로 투영한다. | baseline_order_mix, scan_upload_jitter |
T01 |
logical allocation과 physical count가 충돌하면 shortage risk를 만든다. | cycle_count_upload_lag, pick_face_count_error |
T02 |
route blockage는 layout edge에 먼저 반영되고 operator note는 늦게 기록된다. | blocked_edge_duration, operator_note_delay |
T03 |
AMR availability와 capacity가 premium wave 전에 좁아지면 queue pressure를 올린다. | amr_battery_drift, premium_wave_release_jitter |
T04 |
stale AMR snapshot을 믿고 task를 배정하면 low battery lock과 charge diversion이 발생한다. | stale_snapshot_window, charge_lock_threshold |
T05 |
carrier appointment가 당겨지고 unresolved WCS/labor/capacity/lineage가 남아 있으면 cutoff pressure가 peak에 도달한다. | carrier_arrival_variance, standard_wave_interference |
T06 |
supervisor split/resequence 승인 후 일부 work만 회복되고 approval-lane risk는 남는다. | operator_response_time, recovery_task_yield |
T07 |
partial load가 완료되어도 exception과 unit lineage가 완전히 닫히지 않으면 unresolved risk를 carry forward한다. | partial_load_fraction, handoff_note_delay |
7. Capacity stress layer
실제 물류 의사결정은 주문 수와 로봇 수만으로 설명되지 않는다.
같은 주문량이어도 labor pool, pack station, staging lane, dock door, cold-capable AMR pool, supervisor approval lane 중 하나가 막히면 전체 outbound flow가 압축된다.
그래서 별도 export로 resource_capacity_snapshots.csv를 만들었다.
| Capacity type | 의미 | 시뮬레이션에서 하는 역할 |
|---|---|---|
labor_pool |
작업자 또는 shift capacity | 수작업 scan, pack, exception 대응 속도를 제한한다. |
station_group |
pack station capacity | premium line 재포장과 partial recovery 처리량을 제한한다. |
staging_lane |
premium staging lane | dock cutoff peak에서 carton 대기와 lane congestion을 만든다. |
dock_door |
Dock 3 door appointment capacity | carrier early arrival과 dock slack compression을 물리적인 병목으로 만든다. |
amr_pool |
cold-capable AMR capacity | AMR-17 charge diversion과 AMR-44 maintenance pending의 영향을 정량화한다. |
supervisor_lane |
approval and exception resolution capacity | 자동화가 아니라 사람의 승인 병목이 recovery speed를 제한하는 상황을 만든다. |
각 snapshot은 nominal capacity, available capacity, planned load, backlog, utilization, bottleneck rank를 가진다. validation은 utilization 계산이 deterministic하게 재현되는지, 모든 timeline event에 capacity frame이 있는지, T05 peak가 실제 constrained resource에 anchor되는지 확인한다.
8. Labor shift roster source layer
labor_shift_roster.csv는 ontology를 위한 별도 abstraction이 아니라 실제 보수적인 창고에서 받을 법한 shift lead export다.
물류 창고의 병목은 robot, dock, route만으로 생기지 않는다. cold pick associate가 부족하거나, pack operator가 break coverage gap을 갖거나, supervisor approval lane이 하나뿐이면 자동화 시스템이 정상이어도 recovery가 느려진다.
| Field group | Examples | Simulation reason |
|---|---|---|
| Role identity | role_id, labor_role, required_certification |
cold pick, pack, staging, dock, supervisor approval을 mutually exclusive한 운영 역할로 분리한다. |
| Physical anchor | resource_id, home_location_id |
roster row가 3D twin의 cold zone, pack station, staging lane, dock, control room에 직접 붙을 수 있게 한다. |
| Coverage math | scheduled_headcount, available_headcount, borrowed_headcount, absence_count |
단순 "인력 부족" 텍스트가 아니라 계산 가능한 staffing coverage를 만든다. |
| Operational variance | break_coverage_gap_min, variance_code, variance_reason |
shift break, absence, borrowed coverage, approval contention 같은 현실적 지연 원인을 보존한다. |
| Status | covered, watch, constrained |
agent나 twin이 모든 row를 LLM 판단으로 읽지 않고 deterministic threshold로 1차 상태를 판단할 수 있다. |
T05에서는 dock clerk, staging operator, pack operator, supervisor, cold pick associate가 동시에 watch/constrained 상태가 된다. T06에서는 split/resequence가 승인된 뒤에도 supervisor approval lane의 break coverage gap이 남아 recovery를 제한한다. 이 layer를 추가한 이유는 "로봇/시스템 문제"처럼 보이는 사고도 실제 현장에서는 인력 배치와 승인 capacity가 함께 얽혀 있기 때문이다.
9. Handling-unit lineage layer
주문 단위만 보면 물류 실행의 실제 흐름을 놓치기 쉽다.
출고 사고에서는 특정 carton, tote, pallet이 어디에서 멈췄는지, scan이 있었는지, pack이 닫혔는지, dock load가 추론인지 확인해야 한다.
그래서 handling_unit_lineage_events.csv를 별도로 만들었다.
현재 lineage는 pick confirm, pack close, stage scan, dock load milestone을 가진다.
상태값은 confirmed, late, missing, blocked, inferred를 포함한다.
이 상태값들은 3D twin의 unit path, right-rail lineage panel, source evidence overlay에 연결된다.
10. Decision trace, causal replay, evidence chain
source exports만 있으면 데이터가 왜 그렇게 만들어졌는지 알기 어렵다. 그래서 app fixture에는 demo와 validation을 위한 replay metadata가 함께 들어간다. 이 metadata는 ontology 입력값이 아니라, 시뮬레이션이 운영적으로 coherent한지 검토하기 위한 해설 layer다.
| Object | 내용 | 왜 필요한가 |
|---|---|---|
decision_trace |
event별 pressure score, decision mode, primary constraint, source signals, source conflicts, simulated next action | LLM/agent가 나중에 어떤 operational decision context를 받아야 하는지 검증한다. |
causal_replay |
이전 event에서 다음 event로 넘어간 deterministic rules, planned randomness, state delta, replay assertion | 시나리오가 우연한 row collection이 아니라 원인과 결과가 있는 replay인지 검증한다. |
evidence_chains |
각 decision이 어떤 source nodes와 context packet budget으로 구성되는지 설명한다. | 향후 ontology/RAG compiler에서 source evidence selection을 테스트하기 위한 기준이 된다. |
11. Validation gates
생성된 dataset은 scripts/validate-synthetic-world.mjs로 검증된다.
현재 validation status는 passed이며, 124개 check가 통과한다. 핵심 count는 다음과 같다.
검증하는 것
- 필수 source export 파일이 모두 존재하는지 확인한다.
- orders, order lines, locations, layout edges, WCS tasks, AMR events, scans, labor roster, capacity, lineage row budget이 의도 범위 안에 있는지 확인한다.
- edge, order line, inventory, shipment, task, AMR event, scan, lineage가 존재하는 location, order, task, asset을 참조하는지 확인한다.
- source sync run이 모든 timeline event와 source export를 커버하고, current/watch/stale/partial 상태를 포함하는지 확인한다.
- source event ledger가 모든 운영 source export를 커버하고, replay order가 순차적이며 event-time sorted인지 확인한다.
- T05 source event ledger가 dock, execution, labor, capacity, lineage, freshness row를 모두 포함하는지 확인한다.
- T04에서는 AMR task event가 current인데 AMR snapshot은 stale인 mismatch가 명시적으로 존재하는지 확인한다.
- T05에서는 TMS는 current인데 WCS/labor/capacity/lineage가 lagging 상태인 dock-current/execution-lag asymmetry가 존재하는지 확인한다.
- T05 labor roster가 dock, stage, pack, supervisor, cold-pick constraint를 모두 표현하는지 확인한다.
- T06 labor roster가 supervisor approval-lane constraint를 보존하는지 확인한다.
- capacity utilization과 bottleneck rank가 deterministic하게 계산되는지 확인한다.
- handling-unit lineage가 replay-sortable sequence를 가지며, late, missing, blocked, inferred dirty states를 포함하는지 확인한다.
- app fixture가 private truth의 capacity와 lineage frames를 정확히 embed하는지 확인한다.
- causal replay가 seed scope, deterministic rule, planned randomness, replay assertion을 포함하는지 확인한다.
Run: npm run generate:data && npm run validate:data
12. 다음 확장 방향
현재 v0.1은 outbound AMR fulfillment incident에 집중한 최소 현실 범위다. 실제 Colosseum 데이터를 받기 전까지는 아래 확장이 다음 R&D에 유용하다.
- inbound receiving, putaway, replenishment flow를 별도 incident로 추가한다.
- source export별 schema drift를 만든다. 예를 들어 WMS order status code 변경, AMR vendor event code 변경, TMS appointment timezone mismatch가 있다.
- operator note의 한국어 free-text와 약어를 더 현실적으로 만든다.
- facility topology를 더 큰 warehouse로 확장하되, 먼저 현재 validation gates를 유지한다.
- source event ledger를 incremental stream replay API로 확장해 batch export와 event-stream ingestion을 같이 검증한다.
- ontology compiler 테스트를 위해 source-world to ontology transformation scope를 별도 HTML proposal로 만들고 CTO review 후 lock한다.