diff --git a/livestack-workshop-transportation/disruption-vector-search/disruption-vector-search.md b/livestack-workshop-transportation/disruption-vector-search/disruption-vector-search.md
new file mode 100644
index 000000000..8088a771a
--- /dev/null
+++ b/livestack-workshop-transportation/disruption-vector-search/disruption-vector-search.md
@@ -0,0 +1,273 @@
+# Review a Semantic Disruption Search
+
+## Introduction
+
+Gilly is the AI engineer helping network operators find disruption and demand signals even when the source text does not repeat their search words. A keyword search for *capacity risk* can miss a shipper update about missed pickups, terminal congestion, or urgent rerouting. That makes it harder for the control tower to see related evidence early enough to respond.
+
+Oracle AI Vector Search represents meaning as embeddings and compares those vectors where the governed service and signal data already lives. The source text, business identifiers, urgency, severity, and reach remain attached to every semantic match; Seer Transport does not need to export operational text to a separate vector service and reconcile the result later.
+
+The image below shows the Disruption & Demand Signals page used by transportation planners and network operators. Notice the semantic service search beside the operational signal feed. The SQL in this lab recreates that ranking from governed service and signal rows so you can see why an item appears in the review queue.
+
+
+
+
+
+### Objectives
+
+- Inspect the stored vector sources used by the in-database embedding model.
+- Rank transportation services and signals by meaning.
+- Interpret similarity as review evidence rather than certainty.
+
+Estimated Time: **10 minutes**
+
+### Hands-on Scenario
+
+| Step | Transportation focus |
+| --- | --- |
+| Business Problem | Exact words do not capture every disruption or demand signal |
+| Technical Challenge | Search meaning without moving signal text to a separate vector service |
+| Persona Focus | Gilly, the AI engineer, creates a reviewable semantic ranking |
+| What You Will Do | Embed a question and compare it with stored vectors |
+| Database Capability | AI Vector Search, `VECTOR_EMBEDDING`, and `VECTOR_DISTANCE` |
+| Outcome | Operators discover relevant signals with their source rows intact |
+
+
+Key terms: embedding, vector distance, and similarity
+
+> - An **embedding** is a numeric representation of meaning. Services and signal text with similar meanings have vectors that are close together. `VECTOR_EMBEDDING` turns the phrase from the operator into a vector using the approved in-database model.
+>
+> - `VECTOR_DISTANCE` compares two vectors. With cosine distance, a smaller value means the text meanings are closer.
+>
+> - The workshop uses `1 - VECTOR_DISTANCE(...)` as a **similarity score**, where a higher value means a closer semantic match. It is a ranking transformation, not a probability, percentage, or calibrated confidence. The score prioritizes evidence for human review; it does not prove that a disruption exists or prescribe an operational action.
+
+
+
+> **SQL Worksheet reminder:** Return to [Getting Started Task 2](?lab=getting-started#Task2:OpenSQLWorksheet) if you need the SQL Worksheet steps.
+
+## Task 1: Verify the vector-search path
+
+Seer Transport stores one vector row for each prepared service description and operational signal. Before you run a semantic comparison, verify the approved embedding model, the vector dimensions and storage format, and the vector-index status. The deterministic baseline contains 31 service vectors and 5,000 signal vectors; the vectors remain connected to the business records that later queries join by identifier.
+
+1. Run the verification query.
+
+ ```sql
+
+ SELECT 'EMBEDDING MODEL' AS asset_type,
+ model_name AS asset_name,
+ mining_function || ' / ' || algorithm AS detail
+ FROM all_mining_models
+ WHERE owner = 'ADMIN'
+ AND model_name = 'ALL_MINILM_L12_V2'
+ UNION ALL
+ SELECT 'VECTOR SOURCE',
+ 'PRODUCT_EMBEDDINGS',
+ TO_CHAR(COUNT(*)) || ' rows / ' ||
+ TO_CHAR(MIN(VECTOR_DIMENSION_COUNT(embedding))) || ' dimensions / ' ||
+ MIN(VECTOR_DIMENSION_FORMAT(embedding))
+ FROM product_embeddings
+ UNION ALL
+ SELECT 'VECTOR SOURCE',
+ 'SIGNAL_EMBEDDINGS',
+ TO_CHAR(COUNT(*)) || ' rows / ' ||
+ TO_CHAR(MIN(VECTOR_DIMENSION_COUNT(embedding))) || ' dimensions / ' ||
+ MIN(VECTOR_DIMENSION_FORMAT(embedding))
+ FROM signal_embeddings
+ UNION ALL
+ SELECT 'VECTOR INDEX',
+ index_name,
+ table_name || ' / ' || status
+ FROM user_indexes
+ WHERE index_name IN ('IDX_PRODUCT_VEC', 'IDX_POST_VEC')
+ ORDER BY asset_type, asset_name;
+
+ ```
+
+ **Expected output: Vector Search Readiness**
+
+ | Asset Type | Asset Name | Detail |
+ | --- | --- | --- |
+ | Embedding model | ALL_MINILM_L12_V2 | EMBEDDING / ONNX |
+ | Vector source | PRODUCT_EMBEDDINGS | 31 rows / 384 dimensions / FLOAT32 |
+ | Vector source | SIGNAL_EMBEDDINGS | 5000 rows / 384 dimensions / FLOAT32 |
+ | Vector index | IDX_PRODUCT_VEC | PRODUCT_EMBEDDINGS / VALID |
+ | Vector index | IDX_POST_VEC | POST_EMBEDDINGS / VALID |
+
+The model row confirms that Oracle Autonomous AI Database can generate embeddings with the approved ONNX model. The source rows confirm that the stored vectors have the required 384-dimensional `FLOAT32` format. The two valid indexes support approximate cosine search: `IDX_POST_VEC` indexes the physical `POST_EMBEDDINGS` table exposed to the lab as `SIGNAL_EMBEDDINGS`.
+
+## Task 2: Rank services for an operational question
+
+This query embeds one operational question once in the `query_vector` common table expression (CTE), then compares that vector with stored service-description embeddings. `ADMIN.ALL_MINILM_L12_V2` is the in-database embedding model used to turn the phrase into a vector. `VECTOR_DISTANCE(..., COSINE)` compares that question vector with each service vector, and `1 - distance` converts the result into a higher-is-closer score. The join to `TRANSPORT_SERVICES_V`, a saved business-ready view, keeps every score attached to a recognizable service and category. `FETCH APPROX` requests an approximate nearest-neighbor search using the cosine vector index when the optimizer selects an eligible path.
+
+1. Run the semantic service search.
+
+ ```sql
+
+ WITH query_vector AS (
+ SELECT VECTOR_EMBEDDING(
+ ADMIN.ALL_MINILM_L12_V2
+ USING 'urgent white glove capacity and missed pickup recovery' AS DATA
+ ) AS embedding
+ FROM dual
+ )
+ SELECT ts.transport_service_name,
+ ts.service_category,
+ ROUND(1 - VECTOR_DISTANCE(
+ pe.embedding,
+ qv.embedding,
+ COSINE
+ ), 4) AS similarity_score
+ FROM product_embeddings pe
+ JOIN transport_services_v ts
+ ON ts.transport_service_id = pe.product_id
+ CROSS JOIN query_vector qv
+ ORDER BY VECTOR_DISTANCE(
+ pe.embedding,
+ qv.embedding,
+ COSINE
+ ),
+ ts.transport_service_id
+ FETCH APPROX FIRST 5 ROWS ONLY;
+
+ ```
+
+ **Expected output: Semantic Service Ranking**
+
+ | Transport Service Name | Service Category | Similarity Score |
+ | --- | --- | ---: |
+ | White Glove Delivery Crew or a closely related recovery service | Transportation category | Dynamic; higher ranks first |
+
+Read the first rows as a review queue. A high score means the service description is semantically close to the question; it does not by itself show current disruption. Because this is an approximate nearest-neighbor search, very close neighbors can move in or out of the top five as the index or query conditions change. Gilly uses the service name and category to decide which operational signal evidence to inspect next.
+
+## Task 3: Review the matching signal text
+
+The second search ranks source signal text instead of service descriptions. `SIGNAL_EMBEDDINGS` stores the vectors, while `SHIPPER_SIGNAL_POSTS_V` is a saved SQL view that supplies the original text and business measures. The `query_vector` CTE creates the query embedding once. The `current_window` CTE anchors the review period to the maximum loaded `SIGNAL_TIME`, so the demonstration stays reproducible. The `WHERE` clause retains signals from the most recent 30 loaded days that are urgent or have viral momentum. Look for current high-priority rows whose wording relates to congestion or rerouting, including semantically related language.
+
+1. Run the signal search.
+
+ ```sql
+
+ WITH query_vector AS (
+ SELECT VECTOR_EMBEDDING(
+ ADMIN.ALL_MINILM_L12_V2
+ USING 'terminal congestion causing urgent rerouting' AS DATA
+ ) AS embedding
+ FROM dual
+ ),
+ current_window AS (
+ SELECT MAX(signal_time) AS latest_signal_time
+ FROM shipper_signal_posts_v
+ )
+ SELECT ss.signal_id,
+ ss.signal_channel,
+ ss.signal_time,
+ ss.severity_band,
+ ss.urgency_score,
+ ss.reach_count,
+ SUBSTR(ss.signal_text, 1, 120) AS signal_excerpt,
+ ROUND(1 - VECTOR_DISTANCE(
+ se.embedding,
+ qv.embedding,
+ COSINE
+ ), 4) AS similarity_score
+ FROM signal_embeddings se
+ JOIN shipper_signal_posts_v ss
+ ON ss.signal_id = se.post_id
+ CROSS JOIN query_vector qv
+ CROSS JOIN current_window cw
+ WHERE ss.signal_time >= cw.latest_signal_time - INTERVAL '30' DAY
+ AND (ss.urgency_score >= 70 OR ss.severity_band IN ('viral', 'mega_viral'))
+ ORDER BY VECTOR_DISTANCE(
+ se.embedding,
+ qv.embedding,
+ COSINE
+ ),
+ ss.signal_id
+ FETCH APPROX FIRST 10 ROWS ONLY;
+
+ ```
+
+ **Expected output: Ranked Disruption Evidence**
+
+ | Signal ID | Signal Time | Severity Band | Signal Excerpt | Similarity Score |
+ | ---: | --- | --- | --- | ---: |
+ | A loaded signal ID | Within the last 30 loaded days | viral or mega\_viral, or urgency at least 70 | Current high-priority signal about congestion, capacity, pickup, or rerouting | Dynamic |
+
+ The image below shows the ranked result in the application. Network operators use the excerpts and business measures to understand why a signal is relevant; the SQL result exposes the same evidence instead of returning an unexplained AI answer.
+
+ 
+
+The similarity score orders the evidence, while urgency, severity, reach, and source text provide the operational context. `SIGNAL_ID` is the stable secondary ordering key when distances tie. Multiple source posts can share an excerpt when the same operational update appears on different channels; `SIGNAL_ID` identifies the distinct source row. `FETCH APPROX` trades exactness for performance when an eligible vector-index plan is selected, so a dispatcher should review the returned operational evidence before escalating or rerouting work.
+
+🎯 **Interactive challenge: Change the recovery question.**
+
+Replace the phrase with `weather delay affecting time-critical freight`. Which services or signals move into the top results, and what evidence would you send to a human dispatcher for review?
+
+**Expected output: Weather and Time-Critical Evidence Ranking**
+
+| Signal ID | Signal Channel | Severity Band | Signal Excerpt | Similarity Score |
+| ---: | --- | --- | --- | ---: |
+| A loaded signal ID | Current loaded channel | viral or mega\_viral, or urgency at least 70 | Current signal semantically related to weather, delay, or time-critical freight | Dynamic |
+
+
+Challenge answer: Rank evidence before deciding
+
+Run this query with the revised recovery question:
+
+ ```sql
+
+ WITH query_vector AS (
+ SELECT VECTOR_EMBEDDING(
+ ADMIN.ALL_MINILM_L12_V2
+ USING 'weather delay affecting time-critical freight' AS DATA
+ ) AS embedding
+ FROM dual
+ ),
+ current_window AS (
+ SELECT MAX(signal_time) AS latest_signal_time
+ FROM shipper_signal_posts_v
+ )
+ SELECT ss.signal_id,
+ ss.signal_channel,
+ ss.signal_time,
+ ss.severity_band,
+ ss.urgency_score,
+ ss.reach_count,
+ SUBSTR(ss.signal_text, 1, 120) AS signal_excerpt,
+ ROUND(1 - VECTOR_DISTANCE(
+ se.embedding,
+ qv.embedding,
+ COSINE
+ ), 4) AS similarity_score
+ FROM signal_embeddings se
+ JOIN shipper_signal_posts_v ss
+ ON ss.signal_id = se.post_id
+ CROSS JOIN query_vector qv
+ CROSS JOIN current_window cw
+ WHERE ss.signal_time >= cw.latest_signal_time - INTERVAL '30' DAY
+ AND (ss.urgency_score >= 70 OR ss.severity_band IN ('viral', 'mega_viral'))
+ ORDER BY VECTOR_DISTANCE(
+ se.embedding,
+ qv.embedding,
+ COSINE
+ ),
+ ss.signal_id
+ FETCH APPROX FIRST 10 ROWS ONLY;
+
+ ```
+
+The top rows should shift toward time-critical, airport, weather, or recovery language among the current high-priority signals. The CTE calculates the query vector once, and `SIGNAL_ID` resolves equal-distance ties. Approximate nearest-neighbor search trades exactness for performance; urgency and the source text still provide the operational evidence needed for judgment.
+
+
+
+## Conclusion
+
+Gilly used in-database embeddings to search meaning while keeping vectors attached to governed service and signal rows. Operators can change the question without exporting sensitive operational text to a disconnected search index. The result is faster discovery with fewer data copies, consistent database security, and source evidence that a human reviewer can inspect.
+
+## Next Steps
+
+Continue with Property Graph to investigate how a disruption can propagate through the transportation network. For deeper practice with embeddings and semantic search, open the [AI Vector Search LiveLabs workshop](https://livelabs.oracle.com/ords/r/dbpm/livelabs/view-workshop?clear=RR,180&wid=4166).
+
+## Acknowledgements
+
+* **Author** - Oracle Database Product Management
+* **Last Updated By/Date** - Oracle Database Product Management, September 2026
diff --git a/livestack-workshop-transportation/disruption-vector-search/images/disruption-demand-signals.png b/livestack-workshop-transportation/disruption-vector-search/images/disruption-demand-signals.png
new file mode 100644
index 000000000..aeb218ec1
Binary files /dev/null and b/livestack-workshop-transportation/disruption-vector-search/images/disruption-demand-signals.png differ
diff --git a/livestack-workshop-transportation/disruption-vector-search/images/gilly-transportation.svg b/livestack-workshop-transportation/disruption-vector-search/images/gilly-transportation.svg
new file mode 100644
index 000000000..ad1adaa17
--- /dev/null
+++ b/livestack-workshop-transportation/disruption-vector-search/images/gilly-transportation.svg
@@ -0,0 +1,10 @@
+
diff --git a/livestack-workshop-transportation/disruption-vector-search/images/gilly.png b/livestack-workshop-transportation/disruption-vector-search/images/gilly.png
new file mode 100644
index 000000000..518a5816b
Binary files /dev/null and b/livestack-workshop-transportation/disruption-vector-search/images/gilly.png differ
diff --git a/livestack-workshop-transportation/disruption-vector-search/images/operational-signal-feed.png b/livestack-workshop-transportation/disruption-vector-search/images/operational-signal-feed.png
new file mode 100644
index 000000000..f62af0ae7
Binary files /dev/null and b/livestack-workshop-transportation/disruption-vector-search/images/operational-signal-feed.png differ
diff --git a/livestack-workshop-transportation/disruption-vector-search/images/service-vector-search-results.png b/livestack-workshop-transportation/disruption-vector-search/images/service-vector-search-results.png
new file mode 100644
index 000000000..cdafacf40
Binary files /dev/null and b/livestack-workshop-transportation/disruption-vector-search/images/service-vector-search-results.png differ
diff --git a/livestack-workshop-transportation/disruption-vector-search/images/signal-search-results.png b/livestack-workshop-transportation/disruption-vector-search/images/signal-search-results.png
new file mode 100644
index 000000000..805e5ca9c
Binary files /dev/null and b/livestack-workshop-transportation/disruption-vector-search/images/signal-search-results.png differ
diff --git a/livestack-workshop-transportation/final-quiz/images/badge-transportation.svg b/livestack-workshop-transportation/final-quiz/images/badge-transportation.svg
new file mode 100644
index 000000000..977383721
--- /dev/null
+++ b/livestack-workshop-transportation/final-quiz/images/badge-transportation.svg
@@ -0,0 +1,23 @@
+
diff --git a/livestack-workshop-transportation/fleet-operations-dashboard/fleet-operations-dashboard.md b/livestack-workshop-transportation/fleet-operations-dashboard/fleet-operations-dashboard.md
new file mode 100644
index 000000000..b76cab974
--- /dev/null
+++ b/livestack-workshop-transportation/fleet-operations-dashboard/fleet-operations-dashboard.md
@@ -0,0 +1,346 @@
+# Build a Converged Fleet Operations Query
+
+## Introduction
+
+Jessica Chan is the database administrator responsible for keeping operational data at Seer Transport reliable and useful. Every morning, the control-tower team asks her a practical question: **which service needs attention first, and where can the network respond?**
+
+The answer crosses several forms of evidence. Service records and signal measures are relational rows. Shipment activity is available as JSON documents. Semantic similarity ranks services by meaning, and spatial geometry describes the terminal network. If those data types lived in separate products, Jessica would have to reconcile extracts, search indexes, document copies, and mapping systems before she could explain one dashboard row.
+
+Oracle Autonomous AI Database provides a converged foundation for the investigation. Relational, vector, JSON-Relational Duality View, and spatial operations can run together over the governed transportation data. In this lab, you take the role of Jessica and build the SQL behind the Fleet Risk & Operations Dashboard, then drill from a ranked service to the signals and capacity that operations teams can review.
+
+The image below shows the Fleet Risk & Operations Dashboard used by transportation leaders, dispatch planners, and service operations managers. Notice the **White Glove Delivery Crew** row, the signal-velocity measures, and the path from summary cards to service detail. The SQL in this lab recreates the governed evidence behind that review queue.
+
+
+
+
+
+### Objectives
+
+- Explain the transportation data foundation behind the dashboard.
+- Combine relational, vector, JSON, and spatial evidence in one query.
+- Drill from a service-level summary to signal and capacity rows.
+
+Estimated Time: **10 minutes**
+
+### Hands-on Scenario
+
+| Step | Transportation focus |
+| --- | --- |
+| Business Problem | Operations teams need to identify a pressured service and a practical network response |
+| Technical Challenge | The evidence crosses services, signals, shipment documents, and terminal geography |
+| Persona Focus | Jessica, the DBA, builds the traceable query behind the dashboard |
+| What You Will Do | Run a converged service investigation and drill into its evidence |
+| Database Capability | Relational SQL, AI Vector Search, JSON-Relational Duality View, and Oracle Spatial |
+| Outcome | A ranked service queue that stays connected to operational detail |
+
+Persona focus: You are Jessica. Your job is to give operations leaders one answer they can inspect and repeat.
+
+Before Jessica builds the query, the Data Foundation page confirms the live transportation footprint that supports the journey: services, signals, shipment orders, terminals, demand forecasts, embeddings, models, and agent history. The first task inventories the matching database objects rather than relying only on the application counts.
+
+
+
+
+Key terms: business-ready view and converged query
+
+> - A **business-ready view** is a saved SQL query that presents inherited physical tables with transportation-ready names. `TRANSPORT_SERVICES_V`, `SHIPPER_SIGNAL_POSTS_V`, and `LOGISTICS_TERMINALS_V` make the business meaning explicit while hiding lower-level naming and joins.
+>
+> - A **converged query** combines multiple data models in one governed SQL path. It reduces data copies and lets the learner trace a summary to the same source records.
+
+
+
+The before-and-after graphic shows the architectural choice behind the workshop. Separate specialist stores add copies, integration pipelines, and security boundaries. A converged Oracle Autonomous AI Database keeps different data models connected so the dashboard can trace a summary back to the same governed records.
+
+
+
+> **SQL Worksheet reminder:** Need a reminder on how to open and use SQL Worksheet? Return to [Getting Started Task 2: Open SQL Worksheet](?lab=getting-started#Task2:OpenSQLWorksheet).
+
+## Task 1: Inventory the connected transportation foundation
+
+This query inventories the objects used in this Lab 1 investigation and representative objects used later in the connected journey. The Oracle `USER_*` catalog views list the views, tables, property graphs, duality views, and mining models owned by `LLUSER`; `ALL_MINING_MODELS` confirms the approved embedding-model prerequisite that `LLUSER` uses through its granted model access. The result should include the service, signal, terminal-capacity, order, and embedding views; the demand-region table; both vector indexes; the shipment duality view; and the embedding model.
+
+1. Run the object inventory.
+
+ ```sql
+
+ SELECT 'VIEW' AS object_type, view_name AS object_name
+ FROM user_views
+ WHERE view_name IN (
+ 'TRANSPORT_SERVICES_V', 'SHIPPER_SIGNAL_POSTS_V',
+ 'LOGISTICS_TERMINALS_V', 'TERMINAL_CAPACITY_V',
+ 'TRANSPORT_ORDERS_V',
+ 'SIGNAL_EMBEDDINGS', 'OML_DEMAND_SURGE_TRAINING_V'
+ )
+ UNION ALL
+ SELECT 'JSON RELATIONAL DUALITY VIEW', view_name
+ FROM user_json_duality_views
+ WHERE view_name = 'ORDERS_DV'
+ UNION ALL
+ SELECT 'PROPERTY GRAPH', graph_name
+ FROM user_property_graphs
+ WHERE graph_name = 'TRANSPORT_SIGNAL_NETWORK'
+ UNION ALL
+ SELECT 'TABLE', table_name
+ FROM user_tables
+ WHERE table_name IN ('PRODUCT_EMBEDDINGS', 'DEMAND_REGIONS')
+ UNION ALL
+ SELECT 'VECTOR INDEX', index_name
+ FROM user_indexes
+ WHERE index_name IN ('IDX_PRODUCT_VEC', 'IDX_POST_VEC')
+ UNION ALL
+ SELECT 'EMBEDDING MODEL', model_name
+ FROM all_mining_models
+ WHERE owner = 'ADMIN'
+ AND model_name = 'ALL_MINILM_L12_V2'
+ UNION ALL
+ SELECT 'MINING MODEL', model_name
+ FROM user_mining_models
+ WHERE model_name = 'DEMAND_SURGE_MODEL'
+ ORDER BY object_type, object_name;
+
+ ```
+
+ **Expected output: Workshop Object Inventory**
+
+ | Object Type | Representative Object |
+ | --- | --- |
+ | VIEW | TRANSPORT\_SERVICES\_V |
+ | VIEW | TERMINAL\_CAPACITY\_V |
+ | TABLE | DEMAND\_REGIONS |
+ | JSON RELATIONAL DUALITY VIEW | ORDERS\_DV |
+ | Embedding model | ALL\_MINILM\_L12\_V2 |
+ | Vector index | IDX\_PRODUCT\_VEC and IDX\_POST\_VEC |
+ | PROPERTY GRAPH | TRANSPORT\_SIGNAL\_NETWORK |
+ | MINING MODEL | DEMAND\_SURGE\_MODEL |
+
+The exact catalog label for a specialized object can vary by database release. `ALL_MINILM_L12_V2` must exist in `ADMIN` and be granted to `LLUSER`; the platform loader treats that model as an explicit prerequisite. Focus on the object names: each one supplies evidence used by this lab or a later persona.
+
+## Task 2: Run the converged fleet investigation
+
+This query creates the ranked service view behind the dashboard used by Jessica. Read it in five parts:
+
+- `service_pressure` joins business-ready transportation views with the signal-to-service bridge table, then aggregates urgent signals, average urgency, and reach. A bridge table connects a signal to the business service it mentions.
+- `query_vector` creates the investigation embedding once. `semantic_match` then uses `VECTOR_DISTANCE` to compare that one query vector with stored service embeddings, where a higher similarity score means a closer semantic match.
+- `shipment_activity` reads `ORDERS_DV` as JSON and uses `JSON_TABLE` to project nested shipment items into SQL rows.
+- `service_terminal_capacity` joins each service to its own active terminal capacity, retains terminals with positive unreserved capacity, and calculates each terminal's distance to the Northeast Corridor boundary.
+- `ranked_terminal` ranks those capacity-eligible terminals independently for each service. The closest terminal is selected first; unreserved capacity and terminal ID make ties deterministic.
+
+The final `SELECT` joins the independently aggregated or ranked results. A candidate terminal is therefore relevant to the selected service operationally (it has positive unreserved capacity for that service) and geographically (it is the closest eligible terminal to the region). It does not treat a multiplied signal-by-capacity row set as one causal record.
+
+1. Run the query.
+
+ ```sql
+
+ WITH query_vector AS (
+ SELECT VECTOR_EMBEDDING(
+ ADMIN.ALL_MINILM_L12_V2
+ USING 'capacity pressure missed pickup and urgent rerouting' AS DATA
+ ) AS embedding
+ FROM dual
+ ),
+ service_pressure AS (
+ SELECT ts.transport_service_id,
+ ts.transport_service_name,
+ ts.service_category,
+ COUNT(DISTINCT ss.signal_id) AS urgent_signals,
+ ROUND(AVG(ss.urgency_score), 1) AS avg_urgency,
+ SUM(ss.reach_count) AS signal_reach
+ FROM transport_services_v ts
+ JOIN post_product_mentions ppm
+ ON ppm.product_id = ts.transport_service_id
+ JOIN shipper_signal_posts_v ss
+ ON ss.signal_id = ppm.post_id
+ WHERE ss.urgency_score >= 70
+ GROUP BY ts.transport_service_id,
+ ts.transport_service_name,
+ ts.service_category
+ ),
+ semantic_match AS (
+ SELECT pe.product_id AS transport_service_id,
+ ROUND(1 - VECTOR_DISTANCE(
+ pe.embedding,
+ qv.embedding,
+ COSINE
+ ), 4) AS semantic_similarity
+ FROM product_embeddings pe
+ CROSS JOIN query_vector qv
+ ),
+ shipment_activity AS (
+ SELECT jt.product_id AS transport_service_id,
+ COUNT(DISTINCT jt.order_id) AS active_orders,
+ SUM(jt.quantity) AS requested_units
+ FROM orders_dv od
+ CROSS APPLY JSON_TABLE(
+ od.data, '$'
+ COLUMNS (
+ order_id NUMBER PATH '$._id',
+ order_status VARCHAR2(30) PATH '$.status',
+ NESTED PATH '$.items[*]' COLUMNS (
+ product_id NUMBER PATH '$.productId',
+ quantity NUMBER PATH '$.quantity'
+ )
+ )
+ ) jt
+ WHERE jt.order_status IN ('pending', 'confirmed', 'processing')
+ GROUP BY jt.product_id
+ ),
+ service_terminal_capacity AS (
+ SELECT tc.transport_service_id,
+ lt.terminal_id,
+ lt.terminal_name,
+ lt.city,
+ lt.state_province,
+ tc.available_capacity,
+ tc.reserved_capacity,
+ tc.available_capacity - tc.reserved_capacity AS unreserved_capacity,
+ ROUND(SDO_GEOM.SDO_DISTANCE(
+ lt.location, dr.boundary, 0.005, 'unit=KM'
+ ), 2) AS distance_km
+ FROM terminal_capacity_v tc
+ JOIN logistics_terminals_v lt
+ ON lt.terminal_id = tc.terminal_id
+ CROSS JOIN demand_regions dr
+ WHERE dr.region_name = 'Northeast Corridor'
+ AND lt.is_active = 1
+ AND tc.available_capacity > tc.reserved_capacity
+ ),
+ ranked_terminal AS (
+ SELECT stc.*,
+ ROW_NUMBER() OVER (
+ PARTITION BY stc.transport_service_id
+ ORDER BY stc.distance_km ASC,
+ stc.unreserved_capacity DESC,
+ stc.terminal_id ASC
+ ) AS terminal_rank
+ FROM service_terminal_capacity stc
+ )
+ SELECT sp.transport_service_name,
+ sp.service_category,
+ sp.urgent_signals,
+ sp.avg_urgency,
+ sp.signal_reach,
+ sm.semantic_similarity,
+ NVL(sa.active_orders, 0) AS active_orders,
+ NVL(sa.requested_units, 0) AS requested_units,
+ rt.terminal_name AS selected_terminal,
+ rt.city || ', ' || rt.state_province AS terminal_location,
+ rt.distance_km AS terminal_distance_km,
+ rt.unreserved_capacity
+ FROM service_pressure sp
+ JOIN semantic_match sm
+ ON sm.transport_service_id = sp.transport_service_id
+ LEFT JOIN shipment_activity sa
+ ON sa.transport_service_id = sp.transport_service_id
+ JOIN ranked_terminal rt
+ ON rt.transport_service_id = sp.transport_service_id
+ AND rt.terminal_rank = 1
+ ORDER BY sm.semantic_similarity DESC,
+ sp.signal_reach DESC,
+ sp.urgent_signals DESC,
+ sp.transport_service_id ASC
+ FETCH FIRST 10 ROWS ONLY;
+
+ ```
+
+ **Expected output: Ranked Fleet Review**
+
+ | Transport Service Name | Urgent Signals | Semantic Similarity | Selected Terminal |
+ | --- | ---: | ---: | --- |
+ | White Glove Delivery Crew | At least one | Dynamic score; higher is more relevant | Closest capacity-eligible terminal for that service |
+
+Vector similarity can vary within a small range with the installed embedding model. The stable interpretation is the ordering: the services whose descriptions are closest to the investigation phrase rise to the top, with signal reach, urgent-signal count, and service ID resolving ties. The relational counts explain current pressure, shipment activity shows possible operational exposure, and the selected terminal is both capacity-eligible for that service and geographically closest to the Northeast Corridor among those eligible terminals.
+
+## Task 3: Drill into a service
+
+The dashboard total is useful only when an operator can review the evidence. The following two queries return signal evidence and terminal-capacity evidence separately for **White Glove Delivery Crew**. This avoids multiplying a service's signal rows by its capacity rows and avoids implying that a particular signal caused a particular terminal-capacity condition.
+
+1. Run the signal-evidence query.
+
+ ```sql
+
+ SELECT ts.transport_service_name,
+ ss.severity_band,
+ ss.urgency_score,
+ ss.reach_count,
+ SUBSTR(ss.signal_text, 1, 100) AS signal_excerpt
+ FROM transport_services_v ts
+ JOIN post_product_mentions ppm
+ ON ppm.product_id = ts.transport_service_id
+ JOIN shipper_signal_posts_v ss
+ ON ss.signal_id = ppm.post_id
+ WHERE ts.transport_service_name = 'White Glove Delivery Crew'
+ ORDER BY ss.urgency_score DESC,
+ ss.reach_count DESC,
+ ss.signal_id ASC
+ FETCH FIRST 10 ROWS ONLY;
+
+ ```
+
+ **Expected output: White Glove Signal Evidence**
+
+ | Transport Service Name | Severity Band | Signal Excerpt |
+ | --- | --- | --- |
+ | White Glove Delivery Crew | rising, viral, or mega\_viral | Transportation-specific pressure evidence |
+
+2. Run the terminal-capacity query. It ranks active terminals that have positive unreserved capacity for the selected service, then displays the top capacity-eligible terminal closest to the Northeast Corridor.
+
+ ```sql
+
+ WITH capacity_candidates AS (
+ SELECT lt.terminal_id,
+ lt.terminal_name,
+ lt.city,
+ lt.state_province,
+ tc.available_capacity,
+ tc.reserved_capacity,
+ tc.available_capacity - tc.reserved_capacity AS unreserved_capacity,
+ ROUND(SDO_GEOM.SDO_DISTANCE(
+ lt.location, dr.boundary, 0.005, 'unit=KM'
+ ), 2) AS distance_km
+ FROM transport_services_v ts
+ JOIN terminal_capacity_v tc
+ ON tc.transport_service_id = ts.transport_service_id
+ JOIN logistics_terminals_v lt
+ ON lt.terminal_id = tc.terminal_id
+ CROSS JOIN demand_regions dr
+ WHERE ts.transport_service_name = 'White Glove Delivery Crew'
+ AND dr.region_name = 'Northeast Corridor'
+ AND lt.is_active = 1
+ AND tc.available_capacity > tc.reserved_capacity
+ )
+ SELECT terminal_name,
+ city,
+ state_province,
+ available_capacity,
+ reserved_capacity,
+ unreserved_capacity,
+ distance_km
+ FROM capacity_candidates
+ ORDER BY distance_km ASC,
+ unreserved_capacity DESC,
+ terminal_id ASC
+ FETCH FIRST 1 ROW ONLY;
+
+ ```
+
+ **Expected output: White Glove Capacity Evidence**
+
+ | Terminal Name | Unreserved Capacity | Distance to Northeast Corridor |
+ | --- | ---: | ---: |
+ | A current logistics terminal | Positive value | Closest capacity-eligible result |
+
+For production dashboard speed, Jessica would index common join and filter columns. A materialized view could refresh a stable summary repeatedly. This lab uses direct SQL so every measure remains transparent.
+
+Read the two result sets together, not as matched causal pairs. Signals explain why the service merits review. Capacity rows show where that specific service may have operationally usable terminal capacity near the region. An operator still confirms routing rules, actual availability, and dispatch constraints before taking action.
+
+## Conclusion
+
+Jessica connected service pressure, semantic relevance, shipment activity, and terminal geography without copying the data into four separate systems. The dashboard is now a traceable starting point for investigation rather than an isolated scorecard: an operations leader can move from a ranked service to the signal and capacity rows behind it while the data remains under one security and governance model.
+
+## Next Steps
+
+Continue with the JSON-Relational Duality View to serve the same shipment records as application documents.
+
+## Acknowledgements
+
+* **Author** - Oracle Database Product Management
+* **Last Updated By/Date** - Oracle Database Product Management, September 2026
diff --git a/livestack-workshop-transportation/fleet-operations-dashboard/images/before-after-transportation-data-architecture.svg b/livestack-workshop-transportation/fleet-operations-dashboard/images/before-after-transportation-data-architecture.svg
new file mode 100644
index 000000000..eb73353ca
--- /dev/null
+++ b/livestack-workshop-transportation/fleet-operations-dashboard/images/before-after-transportation-data-architecture.svg
@@ -0,0 +1,99 @@
+
diff --git a/livestack-workshop-transportation/fleet-operations-dashboard/images/data-foundation.png b/livestack-workshop-transportation/fleet-operations-dashboard/images/data-foundation.png
new file mode 100644
index 000000000..66b371a7a
Binary files /dev/null and b/livestack-workshop-transportation/fleet-operations-dashboard/images/data-foundation.png differ
diff --git a/livestack-workshop-transportation/fleet-operations-dashboard/images/fleet-risk-operations-dashboard.png b/livestack-workshop-transportation/fleet-operations-dashboard/images/fleet-risk-operations-dashboard.png
new file mode 100644
index 000000000..c65ab4181
Binary files /dev/null and b/livestack-workshop-transportation/fleet-operations-dashboard/images/fleet-risk-operations-dashboard.png differ
diff --git a/livestack-workshop-transportation/fleet-operations-dashboard/images/jessica-transportation.svg b/livestack-workshop-transportation/fleet-operations-dashboard/images/jessica-transportation.svg
new file mode 100644
index 000000000..a2b6d1ce0
--- /dev/null
+++ b/livestack-workshop-transportation/fleet-operations-dashboard/images/jessica-transportation.svg
@@ -0,0 +1,10 @@
+
diff --git a/livestack-workshop-transportation/fleet-operations-dashboard/images/jessica.png b/livestack-workshop-transportation/fleet-operations-dashboard/images/jessica.png
new file mode 100644
index 000000000..ee4cc6f6d
Binary files /dev/null and b/livestack-workshop-transportation/fleet-operations-dashboard/images/jessica.png differ
diff --git a/livestack-workshop-transportation/fleet-operations-dashboard/images/services-at-surge-risk.png b/livestack-workshop-transportation/fleet-operations-dashboard/images/services-at-surge-risk.png
new file mode 100644
index 000000000..7dfed8837
Binary files /dev/null and b/livestack-workshop-transportation/fleet-operations-dashboard/images/services-at-surge-risk.png differ
diff --git a/livestack-workshop-transportation/fleet-operations-dashboard/images/transport-service-detail.png b/livestack-workshop-transportation/fleet-operations-dashboard/images/transport-service-detail.png
new file mode 100644
index 000000000..78c70d01b
Binary files /dev/null and b/livestack-workshop-transportation/fleet-operations-dashboard/images/transport-service-detail.png differ
diff --git a/livestack-workshop-transportation/fleet-operations-dashboard/images/transport-service-json-duality.png b/livestack-workshop-transportation/fleet-operations-dashboard/images/transport-service-json-duality.png
new file mode 100644
index 000000000..613a9721f
Binary files /dev/null and b/livestack-workshop-transportation/fleet-operations-dashboard/images/transport-service-json-duality.png differ
diff --git a/livestack-workshop-transportation/getting-started/images/database-actions-development-sql.svg b/livestack-workshop-transportation/getting-started/images/database-actions-development-sql.svg
new file mode 100644
index 000000000..6c18e1a4c
--- /dev/null
+++ b/livestack-workshop-transportation/getting-started/images/database-actions-development-sql.svg
@@ -0,0 +1,84 @@
+
diff --git a/livestack-workshop-transportation/getting-started/images/database-actions-login-main-user.svg b/livestack-workshop-transportation/getting-started/images/database-actions-login-main-user.svg
new file mode 100644
index 000000000..72ed9ebfc
--- /dev/null
+++ b/livestack-workshop-transportation/getting-started/images/database-actions-login-main-user.svg
@@ -0,0 +1,24 @@
+
diff --git a/livestack-workshop-transportation/getting-started/images/reservation-login-copy-password.svg b/livestack-workshop-transportation/getting-started/images/reservation-login-copy-password.svg
new file mode 100644
index 000000000..102c4140f
--- /dev/null
+++ b/livestack-workshop-transportation/getting-started/images/reservation-login-copy-password.svg
@@ -0,0 +1,62 @@
+
diff --git a/livestack-workshop-transportation/getting-started/images/reservation-login-info.svg b/livestack-workshop-transportation/getting-started/images/reservation-login-info.svg
new file mode 100644
index 000000000..20ed980b9
--- /dev/null
+++ b/livestack-workshop-transportation/getting-started/images/reservation-login-info.svg
@@ -0,0 +1,61 @@
+
diff --git a/livestack-workshop-transportation/getting-started/images/reservation-login-open-link.svg b/livestack-workshop-transportation/getting-started/images/reservation-login-open-link.svg
new file mode 100644
index 000000000..25ff7138e
--- /dev/null
+++ b/livestack-workshop-transportation/getting-started/images/reservation-login-open-link.svg
@@ -0,0 +1,62 @@
+
diff --git a/livestack-workshop-transportation/getting-started/images/sql-worksheet-orientation-transportation.svg b/livestack-workshop-transportation/getting-started/images/sql-worksheet-orientation-transportation.svg
new file mode 100644
index 000000000..30793d0b9
--- /dev/null
+++ b/livestack-workshop-transportation/getting-started/images/sql-worksheet-orientation-transportation.svg
@@ -0,0 +1,181 @@
+
diff --git a/livestack-workshop-transportation/introduction/images/details-accordion-expand-flow.png b/livestack-workshop-transportation/introduction/images/details-accordion-expand-flow.png
new file mode 100644
index 000000000..1c84632bf
Binary files /dev/null and b/livestack-workshop-transportation/introduction/images/details-accordion-expand-flow.png differ
diff --git a/livestack-workshop-transportation/introduction/images/welcome-and-demo-orientation.png b/livestack-workshop-transportation/introduction/images/welcome-and-demo-orientation.png
new file mode 100644
index 000000000..43ae916d3
Binary files /dev/null and b/livestack-workshop-transportation/introduction/images/welcome-and-demo-orientation.png differ
diff --git a/livestack-workshop-transportation/network-capacity-spatial/images/capacity-alert-data-point.png b/livestack-workshop-transportation/network-capacity-spatial/images/capacity-alert-data-point.png
new file mode 100644
index 000000000..7b01febc6
Binary files /dev/null and b/livestack-workshop-transportation/network-capacity-spatial/images/capacity-alert-data-point.png differ
diff --git a/livestack-workshop-transportation/network-capacity-spatial/images/moon-transportation.svg b/livestack-workshop-transportation/network-capacity-spatial/images/moon-transportation.svg
new file mode 100644
index 000000000..53ba0920a
--- /dev/null
+++ b/livestack-workshop-transportation/network-capacity-spatial/images/moon-transportation.svg
@@ -0,0 +1,10 @@
+
diff --git a/livestack-workshop-transportation/network-capacity-spatial/images/moon.png b/livestack-workshop-transportation/network-capacity-spatial/images/moon.png
new file mode 100644
index 000000000..4e8af6f28
Binary files /dev/null and b/livestack-workshop-transportation/network-capacity-spatial/images/moon.png differ
diff --git a/livestack-workshop-transportation/network-capacity-spatial/images/network-capacity-rerouting.png b/livestack-workshop-transportation/network-capacity-spatial/images/network-capacity-rerouting.png
new file mode 100644
index 000000000..93ab603bf
Binary files /dev/null and b/livestack-workshop-transportation/network-capacity-spatial/images/network-capacity-rerouting.png differ
diff --git a/livestack-workshop-transportation/network-capacity-spatial/images/spatial-demand-layers.png b/livestack-workshop-transportation/network-capacity-spatial/images/spatial-demand-layers.png
new file mode 100644
index 000000000..06b97f301
Binary files /dev/null and b/livestack-workshop-transportation/network-capacity-spatial/images/spatial-demand-layers.png differ
diff --git a/livestack-workshop-transportation/network-capacity-spatial/images/terminal-capacity-table.png b/livestack-workshop-transportation/network-capacity-spatial/images/terminal-capacity-table.png
new file mode 100644
index 000000000..80ebf482f
Binary files /dev/null and b/livestack-workshop-transportation/network-capacity-spatial/images/terminal-capacity-table.png differ
diff --git a/livestack-workshop-transportation/network-capacity-spatial/network-capacity-spatial.md b/livestack-workshop-transportation/network-capacity-spatial/network-capacity-spatial.md
new file mode 100644
index 000000000..c64cb6868
--- /dev/null
+++ b/livestack-workshop-transportation/network-capacity-spatial/network-capacity-spatial.md
@@ -0,0 +1,224 @@
+# Rank Candidate Terminals for Review
+
+## Introduction
+
+Moon is the spatial expert supporting dispatch planners during an active shipment exception. The closest terminal is not automatically the best candidate: it must be active, support the affected service, have allocation slots left after reservations, and operate at a reviewable utilization level. When maps and capacity records live in separate systems, planners lose time reconciling locations with current operational availability.
+
+Oracle Spatial keeps terminal points beside the service and capacity rows in Oracle Autonomous AI Database. Moon can use the spatial index to find the nearest terminals to an affected shipper site, calculate straight-line distance, and return candidate-terminal evidence under the same governance model.
+
+The image below shows the Network Capacity & Rerouting workspace used by dispatch planners, terminal managers, and network-operations teams. Notice the demand-region layer, terminal markers, routes, and capacity measures. The SQL in this lab recreates the location-and-capacity evidence behind the map so a planner can explain why a terminal appears as a candidate.
+
+
+
+
+
+### Objectives
+
+- Inspect terminal points, daily operating utilization, and the spatial reference.
+- Use indexed nearest-neighbor search from an affected shipment's shipper site.
+- Combine straight-line distance with service allocation slots for candidate review.
+
+Estimated Time: **10 minutes**
+
+### Hands-on Scenario
+
+| Step | Transportation focus |
+| --- | --- |
+| Business Problem | A dispatcher needs nearby terminals to review for an affected shipment |
+| Technical Challenge | Maps, capacity, and service inventory must stay synchronized |
+| Persona Focus | Moon, the spatial expert, turns location into reviewable candidate evidence |
+| What You Will Do | Find nearby terminals and compare distance, utilization, and service slots |
+| Database Capability | Oracle Spatial `SDO_GEOMETRY`, `SDO_NN`, and `SDO_DISTANCE` |
+| Outcome | Dispatchers rank candidate terminals for human review |
+
+
+Key terms: point, GeoJSON, SRID, nearest neighbor, and distance
+
+> - A **point** stores one longitude and latitude, such as a terminal location.
+>
+> - **GeoJSON** is a JSON format for geographic shapes. The application can display this location data on a map while Oracle Spatial uses governed geometry for calculations.
+>
+> - A **spatial reference identifier (SRID)** identifies the coordinate system. The workshop uses World Geodetic System 1984 (WGS 84), represented by SRID `4326`, so Oracle interprets terminal and shipper-site coordinates consistently.
+>
+> - `SDO_NN` is the indexed nearest-neighbor operator. It finds nearby terminal points from the affected shipper-site point through `IDX_FC_SPATIAL`.
+>
+> - `SDO_GEOM.SDO_DISTANCE` calculates the minimum distance between compatible geometries. In this lab both geometries are points, so it reports straight-line distance in kilometers. It is not driving distance, travel time, or a route recommendation.
+
+
+
+> **SQL Worksheet reminder:** Return to [Getting Started Task 2](?lab=getting-started#Task2:OpenSQLWorksheet) if you need the SQL Worksheet steps.
+
+## Task 1: Inspect the spatial objects
+
+`LOGISTICS_TERMINALS_V` is a saved SQL view that presents the terminal table with transportation-ready names, coordinates, activity status, daily processing capacity, and daily utilization. This query returns active terminal points and confirms that their geometry uses SRID 4326. `PROCESSING_CAPACITY_UNITS_PER_OPERATING_DAY` is facility throughput for one operating day; it is not added to or subtracted from the service-allocation slots used later. Look for recognizable terminal names, nonzero utilization, and consistent spatial-reference values before comparing locations.
+
+1. Run the point inventory.
+
+ ```sql
+
+ SELECT lt.terminal_name,
+ lt.city,
+ lt.state_province,
+ lt.latitude,
+ lt.longitude,
+ lt.location.sdo_srid AS srid,
+ lt.processing_capacity AS processing_capacity_units_per_operating_day,
+ lt.utilization_pct AS planned_operating_day_utilization_pct
+ FROM logistics_terminals_v lt
+ WHERE lt.is_active = 1
+ ORDER BY lt.terminal_name;
+
+ ```
+
+ **Expected output: Active Terminal Points**
+
+ | Terminal Name | City | SRID | Planned Operating-Day Utilization |
+ | --- | --- | ---: | ---: |
+ | NYC Intermodal Gateway | Edison | 4326 | 82.5% |
+ | Additional active terminals | Current city | 4326 | Seeded percentage greater than 0 |
+
+Each row combines a map-ready point with operational context. Because the geometry and terminal measures remain in Oracle Autonomous AI Database, the next query can use the terminal spatial index without exporting coordinates to a separate mapping service.
+
+## Task 2: Find indexed nearest terminals to the affected shipment
+
+Shipment `649` is a confirmed shipment for Ashley Murphy in New York with a high loaded urgency score. This query uses that shipper site's point as the incident reference geometry. `SDO_NN` uses the `IDX_FC_SPATIAL` index to return five active terminal candidates. `SDO_NN_DISTANCE(1)` reports the indexed nearest-neighbor distance, while `SDO_GEOM.SDO_DISTANCE` independently reports the same straight-line point-to-point distance in kilometers. `TERMINAL_ID` makes tied distances deterministic. Look for the smallest straight-line distance, then use the next task to review utilization and service-specific slots.
+
+1. Run the indexed nearest-neighbor query.
+
+ ```sql
+
+ WITH affected_shipment AS (
+ SELECT o.transport_order_id,
+ o.transport_order_status,
+ s.shipper_name,
+ s.city AS shipper_city,
+ s.state_province AS shipper_state,
+ s.location AS incident_location
+ FROM transport_orders_v o
+ JOIN shippers_v s
+ ON s.shipper_id = o.shipper_id
+ WHERE o.transport_order_id = 649
+ )
+ SELECT a.transport_order_id,
+ a.transport_order_status,
+ a.shipper_name,
+ a.shipper_city,
+ a.shipper_state,
+ lt.terminal_name,
+ lt.city,
+ lt.state_province,
+ ROUND(SDO_NN_DISTANCE(1), 2) AS indexed_nearest_neighbor_distance_km,
+ ROUND(SDO_GEOM.SDO_DISTANCE(
+ lt.location, a.incident_location, 0.005, 'unit=KM'
+ ), 2) AS straight_line_distance_km,
+ lt.utilization_pct AS planned_operating_day_utilization_pct
+ FROM logistics_terminals_v lt
+ CROSS JOIN affected_shipment a
+ WHERE lt.is_active = 1
+ AND SDO_NN(
+ lt.location,
+ a.incident_location,
+ 'sdo_num_res=5 unit=KM',
+ 1
+ ) = 'TRUE'
+ ORDER BY straight_line_distance_km, lt.terminal_id;
+
+ ```
+
+ **Expected output: Indexed Nearest-Terminal Candidates**
+
+ | Shipment | Shipper Site | Terminal Name | Straight-Line Distance KM |
+ | ---: | --- | --- | ---: |
+ | 649 | New York, New York | NYC Intermodal Gateway | 41.51 |
+
+The distance values reflect the loaded point geometries and the spatial tolerance; the business interpretation is nearest-to-farthest by straight line. The candidate set does not describe a road route or travel time. Proximity narrows the review list, but utilization and service allocation determine whether a planner should investigate a candidate further.
+
+## Task 3: Add capacity evidence to the candidate review
+
+The nearest location may not have usable capacity. Shipment `649` includes two **Refrigerated Truckload Slot** service-allocation units. `TERMINAL_CAPACITY_V` provides service-specific allocation slots for the next 24-hour dispatch horizon: `AVAILABLE` is the total allocatable service slots, `RESERVED` is the committed portion, and `UNRESERVED` is the remaining allocatable slots. Those slots are a different measure from facility processing capacity per operating day, so the query displays rather than combines the two measures. It filters out a terminal that cannot cover the two requested units and ranks remaining candidates by straight-line distance, lower planned utilization, then remaining slots. Look for a nearby terminal with enough unreserved slots and a utilization level worth a planner's review.
+
+1. Run the capacity-aware ranking.
+
+ ```sql
+
+ WITH affected_shipment AS (
+ SELECT o.transport_order_id,
+ o.transport_order_status,
+ s.shipper_name,
+ s.location AS incident_location
+ FROM transport_orders_v o
+ JOIN shippers_v s
+ ON s.shipper_id = o.shipper_id
+ WHERE o.transport_order_id = 649
+ ),
+ service_requirement AS (
+ SELECT oi.order_id AS transport_order_id,
+ ts.transport_service_id,
+ ts.transport_service_name,
+ SUM(oi.quantity) AS requested_service_allocation_slots_24h
+ FROM order_items oi
+ JOIN transport_services_v ts
+ ON ts.transport_service_id = oi.product_id
+ WHERE oi.order_id = 649
+ AND ts.transport_service_name = 'Refrigerated Truckload Slot'
+ GROUP BY oi.order_id,
+ ts.transport_service_id,
+ ts.transport_service_name
+ )
+ SELECT a.transport_order_id,
+ a.transport_order_status,
+ a.shipper_name,
+ sr.transport_service_name,
+ sr.requested_service_allocation_slots_24h,
+ lt.terminal_name,
+ lt.city,
+ ROUND(SDO_GEOM.SDO_DISTANCE(
+ lt.location, a.incident_location, 0.005, 'unit=KM'
+ ), 2) AS straight_line_distance_km,
+ lt.processing_capacity AS processing_capacity_units_per_operating_day,
+ lt.utilization_pct AS planned_operating_day_utilization_pct,
+ tc.available_capacity AS available_service_allocation_slots_24h,
+ tc.reserved_capacity AS reserved_service_allocation_slots_24h,
+ tc.available_capacity - tc.reserved_capacity
+ AS unreserved_service_allocation_slots_24h
+ FROM affected_shipment a
+ CROSS JOIN service_requirement sr
+ JOIN terminal_capacity_v tc
+ ON tc.transport_service_id = sr.transport_service_id
+ JOIN logistics_terminals_v lt
+ ON lt.terminal_id = tc.terminal_id
+ WHERE lt.is_active = 1
+ AND tc.available_capacity - tc.reserved_capacity
+ >= sr.requested_service_allocation_slots_24h
+ ORDER BY straight_line_distance_km,
+ planned_operating_day_utilization_pct,
+ unreserved_service_allocation_slots_24h DESC,
+ lt.terminal_id
+ FETCH FIRST 5 ROWS ONLY;
+
+ ```
+
+ **Expected output: Capacity-Aware Terminal Candidates**
+
+ | Shipment | Transport Service Name | Terminal Name | Straight-Line Distance KM | Unreserved 24-Hour Service Slots |
+ | ---: | --- | --- | ---: | ---: |
+ | 649 | Refrigerated Truckload Slot | Chicago Midwest Rail Hub | 1186.18 | 161 |
+
+ The image below shows the terminal-capacity rows used beside the application map. Dispatch planners use the table to compare the spatial candidate with available and reserved capacity; the SQL makes the same calculation explicit.
+
+ 
+
+The first row is a candidate for human review, not an automatic routing command. Moon can explain the evidence: the terminal is straight-line close to the affected shipper site, has enough 24-hour service slots after reservations, and shows its planned operating-day utilization. A dispatcher must still account for road routing, travel time, equipment compatibility, operating constraints, and live conditions.
+
+## Conclusion
+
+Moon combined indexed nearest-neighbor search with operational capacity evidence in one query path. The map and terminal table no longer need separate reconciliation before a dispatcher can rank terminals for review. Location remains connected to service allocation data, so the team gets faster decisions, fewer geographic data copies, and a repeatable SQL explanation for each candidate.
+
+## Next Steps
+
+Continue with Oracle Machine Learning for SQL to evaluate which services may need capacity attention next. For deeper practice with points, polygons, and spatial analysis, open the [Oracle Spatial LiveLabs workshop](https://livelabs.oracle.com/ords/r/dbpm/livelabs/view-workshop?clear=RR,180&wid=800).
+
+## Acknowledgements
+
+* **Author** - Oracle Database Product Management
+* **Last Updated By/Date** - Oracle Database Product Management, September 2026
diff --git a/livestack-workshop-transportation/predictive-service-oml/images/capacity-intelligence-data-point.png b/livestack-workshop-transportation/predictive-service-oml/images/capacity-intelligence-data-point.png
new file mode 100644
index 000000000..640d042d1
Binary files /dev/null and b/livestack-workshop-transportation/predictive-service-oml/images/capacity-intelligence-data-point.png differ
diff --git a/livestack-workshop-transportation/predictive-service-oml/images/demand-surge-data-point.png b/livestack-workshop-transportation/predictive-service-oml/images/demand-surge-data-point.png
new file mode 100644
index 000000000..95f0efc51
Binary files /dev/null and b/livestack-workshop-transportation/predictive-service-oml/images/demand-surge-data-point.png differ
diff --git a/livestack-workshop-transportation/predictive-service-oml/images/freight-value-forecast-action.png b/livestack-workshop-transportation/predictive-service-oml/images/freight-value-forecast-action.png
new file mode 100644
index 000000000..97c6591ae
Binary files /dev/null and b/livestack-workshop-transportation/predictive-service-oml/images/freight-value-forecast-action.png differ
diff --git a/livestack-workshop-transportation/predictive-service-oml/images/otto-transportation.svg b/livestack-workshop-transportation/predictive-service-oml/images/otto-transportation.svg
new file mode 100644
index 000000000..ca503354c
--- /dev/null
+++ b/livestack-workshop-transportation/predictive-service-oml/images/otto-transportation.svg
@@ -0,0 +1,10 @@
+
diff --git a/livestack-workshop-transportation/predictive-service-oml/images/otto.png b/livestack-workshop-transportation/predictive-service-oml/images/otto.png
new file mode 100644
index 000000000..259c88e32
Binary files /dev/null and b/livestack-workshop-transportation/predictive-service-oml/images/otto.png differ
diff --git a/livestack-workshop-transportation/predictive-service-oml/images/predictive-service-risk-capacity-overview.png b/livestack-workshop-transportation/predictive-service-oml/images/predictive-service-risk-capacity-overview.png
new file mode 100644
index 000000000..efe6b74ad
Binary files /dev/null and b/livestack-workshop-transportation/predictive-service-oml/images/predictive-service-risk-capacity-overview.png differ
diff --git a/livestack-workshop-transportation/predictive-service-oml/images/service-clusters-action.png b/livestack-workshop-transportation/predictive-service-oml/images/service-clusters-action.png
new file mode 100644
index 000000000..a463612bb
Binary files /dev/null and b/livestack-workshop-transportation/predictive-service-oml/images/service-clusters-action.png differ
diff --git a/livestack-workshop-transportation/predictive-service-oml/images/shipper-health-filter.png b/livestack-workshop-transportation/predictive-service-oml/images/shipper-health-filter.png
new file mode 100644
index 000000000..cf1175a86
Binary files /dev/null and b/livestack-workshop-transportation/predictive-service-oml/images/shipper-health-filter.png differ
diff --git a/livestack-workshop-transportation/predictive-service-oml/predictive-service-oml.md b/livestack-workshop-transportation/predictive-service-oml/predictive-service-oml.md
new file mode 100644
index 000000000..1059e3399
--- /dev/null
+++ b/livestack-workshop-transportation/predictive-service-oml/predictive-service-oml.md
@@ -0,0 +1,224 @@
+# Evaluate a Service Demand-Surge Prototype with Oracle Machine Learning for SQL
+
+## Introduction
+
+Otto is the data scientist helping capacity planners test whether recent transportation activity can predict a near-term demand surge. A useful evaluation must keep the timeline straight: features come from one observation week, while the known outcome comes from the following week. It must also test the model on cases that were not used for training.
+
+Oracle Machine Learning for SQL builds, scores, and evaluates the prototype inside Oracle Autonomous AI Database, where the governed service and order data already lives. In this lab, Otto uses earlier service-week cases for training and later cases for held-out evaluation. The exercise demonstrates an Oracle-standard evaluation workflow; the small synthetic history is not evidence that the model is ready for operational capacity decisions.
+
+The concept graphic below follows the complete evaluation path. Notice the separate training and test periods. SQL scores held-out rows, and Otto judges the result with a confusion matrix and class-specific metrics before anyone considers using it.
+
+
+
+### Objectives
+
+- Inspect deterministic service-week cases and the time-based training/test split.
+- Confirm the persisted Oracle Machine Learning for SQL classification model.
+- Score held-out rows with `PREDICTION` and `PREDICTION_PROBABILITY`.
+- Evaluate held-out results with a confusion matrix, precision, recall, and F1 score.
+
+Estimated Time: **10 minutes**
+
+### Hands-on Scenario
+
+| Step | Transportation focus |
+| --- | --- |
+| Business Problem | Planners need evidence that a demand-surge prototype works on later data before using its output |
+| Technical Challenge | Observation features must precede the target, and test cases must remain outside model training |
+| Persona Focus | Otto, the data scientist, evaluates the prototype and explains its limitations |
+| What You Will Do | Inspect the time split, score held-out rows, and read class-specific evaluation metrics |
+| Database Capability | Oracle Machine Learning for SQL; `DBMS_DATA_MINING` for PL/SQL model creation, batch scoring, and evaluation; SQL scoring functions for row-level predictions |
+| Outcome | A traceable decision about whether the prototype is ready for an operational watchlist |
+
+
+Key terms: observation window, outcome window, held-out data, and class probability
+
+> - An **observation window** supplies the model features. Here it covers the seven days before the `OBSERVATION_END` date for each case.
+>
+> - An **outcome window** is the later period used to define the target. Here `SURGE` means that service units in the following seven days increased by more than 15 percent.
+>
+> - **Held-out data** contains labeled cases excluded from model training. Otto uses the final two service weeks to check behavior on data the model did not learn from.
+>
+> - `PREDICTION_PROBABILITY(..., 'SURGE')` returns an estimated class probability for `SURGE` for one row. It does not express certainty or an automatically calibrated business-risk measure.
+
+
+
+> **SQL Worksheet reminder:** Return to [Getting Started Task 2](?lab=getting-started#Task2:OpenSQLWorksheet) if you need the SQL Worksheet steps.
+
+## Task 1: Inspect the service-week split
+
+`OML_DEMAND_PERIOD_CASES_V` is a saved SQL query that creates seven cases for each active transportation service. Every case uses order count, units, and freight value from one observation week. The loader derives its label only from units in the following week, so the target does not leak into the model inputs. The first five periods are training data and the final two remain outside training for testing.
+
+1. Summarize the split and confirm that training excludes the later test periods.
+
+ ```sql
+
+ SELECT data_split,
+ COUNT(*) AS case_count,
+ SUM(CASE WHEN demand_class = 'SURGE' THEN 1 ELSE 0 END) AS surge_cases,
+ TO_CHAR(MIN(observation_start), 'YYYY-MM-DD') AS first_observation,
+ TO_CHAR(MAX(observation_end), 'YYYY-MM-DD') AS last_observation
+ FROM oml_demand_period_cases_v
+ GROUP BY data_split
+ ORDER BY data_split;
+
+ ```
+
+ **Expected output: Time-Based Evaluation Split**
+
+ | Data Split | Case Count | Surge Cases | First Observation | Last Observation |
+ | --- | ---: | ---: | --- | --- |
+ | TEST | 62 | 24 | 2026-04-20 | 2026-05-04 |
+ | TRAIN | 155 | 55 | 2026-03-16 | 2026-04-20 |
+
+The 217 service-week cases are more informative than one lifetime aggregate per service. The training view exposes only the case identifier, predictors, and label; product identifiers, dates, future units, and the split flag are not model predictors.
+
+## Task 2: Confirm the persisted model
+
+The workshop loader uses the `DBMS_DATA_MINING.CREATE_MODEL` PL/SQL procedure to build `DEMAND_SURGE_MODEL` from `OML_DEMAND_SURGE_TRAINING_V`. `USER_MINING_MODELS` is the learner-facing catalog for models owned by `LLUSER`.
+
+1. Check the model name, mining function, and algorithm.
+
+ ```sql
+
+ SELECT model_name,
+ mining_function,
+ algorithm
+ FROM user_mining_models
+ WHERE model_name = 'DEMAND_SURGE_MODEL';
+
+ ```
+
+ **Expected output: Oracle Machine Learning for SQL Model Inventory**
+
+ | Model Name | Mining Function | Algorithm |
+ | --- | --- | --- |
+ | DEMAND\_SURGE\_MODEL | CLASSIFICATION | Random Forest algorithm label for the installed database release |
+
+`CLASSIFICATION` means the model selects one of the known labels. The seeded Random Forest settings make this workshop build repeatable.
+
+## Task 3: Score held-out service weeks
+
+This query applies the model only to cases marked `TEST`. Read it in three parts:
+
+1. `PREDICTION` returns the selected class for each held-out service-week case.
+2. `PREDICTION_PROBABILITY(..., 'SURGE')` returns the estimated class probability for `SURGE`, whether or not `SURGE` is the selected prediction.
+3. The query orders by that probability so Otto can inspect the strongest prototype signals together with the observed and following-week units.
+
+1. Score the held-out cases.
+
+ ```sql
+
+ SELECT ts.transport_service_name,
+ TO_CHAR(c.observation_end, 'YYYY-MM-DD') AS as_of_date,
+ c.demand_class AS actual_label,
+ PREDICTION(DEMAND_SURGE_MODEL USING
+ c.category AS category,
+ c.unit_price AS unit_price,
+ c.observed_order_count AS observed_order_count,
+ c.observed_units AS observed_units,
+ c.observed_revenue AS observed_revenue
+ ) AS predicted_label,
+ ROUND(PREDICTION_PROBABILITY(
+ DEMAND_SURGE_MODEL, 'SURGE' USING
+ c.category AS category,
+ c.unit_price AS unit_price,
+ c.observed_order_count AS observed_order_count,
+ c.observed_units AS observed_units,
+ c.observed_revenue AS observed_revenue
+ ), 4) AS surge_probability,
+ c.observed_units,
+ c.outcome_units
+ FROM oml_demand_period_cases_v c
+ JOIN transport_services_v ts
+ ON ts.transport_service_id = c.product_id
+ WHERE c.data_split = 'TEST'
+ ORDER BY surge_probability DESC, c.case_id
+ FETCH FIRST 8 ROWS ONLY;
+
+ ```
+
+ **Expected output: Held-Out Prototype Scores**
+
+ | Transport Service Name | As Of Date | Actual Label | Predicted Label | Surge Probability | Observed Units | Outcome Units |
+ | --- | --- | --- | --- | ---: | ---: | ---: |
+ | Trailer Yard Starter Kit | 2026-04-27 | STABLE | SURGE | 0.8405 | 45 | 45 |
+ | School Route Capacity Review | 2026-04-27 | SURGE | SURGE | 0.8247 | 40 | 63 |
+ | Expedited Dock-to-Dock Transfer | 2026-04-27 | SURGE | SURGE | 0.8197 | 27 | 72 |
+ | Rail ETA Visibility Kit | 2026-05-04 | STABLE | SURGE | 0.8085 | 43 | 39 |
+ | Intermodal Ramp Transfer | 2026-04-27 | SURGE | SURGE | 0.8074 | 49 | 67 |
+ | Contract Lane Rebid | 2026-04-27 | SURGE | SURGE | 0.8050 | 37 | 76 |
+ | Carrier Exception Follow-Up | 2026-04-27 | SURGE | SURGE | 0.8028 | 44 | 51 |
+ | Hazmat Documentation Review | 2026-04-27 | STABLE | SURGE | 0.8020 | 43 | 49 |
+
+The ranking includes both correct and incorrect `SURGE` predictions. Do not present a probability-ordered list as an accepted operational watchlist without held-out evaluation and business review.
+
+## Task 4: Evaluate the held-out predictions
+
+The loader uses `DBMS_DATA_MINING.APPLY` to score all 62 held-out cases and `DBMS_DATA_MINING.COMPUTE_CONFUSION_MATRIX` to compare predictions with known labels. This is evaluation evidence from later data, not agreement on the rows used to train the model.
+
+1. Read the confusion matrix. Diagonal rows are correct classifications; off-diagonal rows are errors.
+
+ ```sql
+
+ SELECT actual_target_value AS actual_label,
+ predicted_target_value AS predicted_label,
+ value AS case_count
+ FROM oml_demand_surge_confusion
+ ORDER BY actual_target_value, predicted_target_value;
+
+ ```
+
+ **Expected output: Held-Out Confusion Matrix**
+
+ | Actual Label | Predicted Label | Case Count |
+ | --- | --- | ---: |
+ | STABLE | STABLE | 29 |
+ | STABLE | SURGE | 9 |
+ | SURGE | STABLE | 11 |
+ | SURGE | SURGE | 13 |
+
+2. Inspect precision, recall, and F1 for each class. The query also derives overall held-out accuracy from the same confusion matrix.
+
+ ```sql
+
+ SELECT m.class_label,
+ m.true_positive,
+ m.false_positive,
+ m.false_negative,
+ m.precision,
+ m.recall,
+ m.f1_score,
+ ROUND(
+ (SELECT SUM(CASE WHEN actual_target_value = predicted_target_value
+ THEN value ELSE 0 END)
+ FROM oml_demand_surge_confusion) /
+ (SELECT SUM(value) FROM oml_demand_surge_confusion),
+ 4
+ ) AS overall_accuracy
+ FROM oml_demand_surge_metrics_v m
+ ORDER BY m.class_label;
+
+ ```
+
+ **Expected output: Held-Out Class Metrics**
+
+ | Class Label | True Positive | False Positive | False Negative | Precision | Recall | F1 Score | Overall Accuracy |
+ | --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: |
+ | STABLE | 29 | 11 | 9 | 0.7250 | 0.7632 | 0.7436 | 0.6774 |
+ | SURGE | 13 | 9 | 11 | 0.5909 | 0.5417 | 0.5652 | 0.6774 |
+
+For the `SURGE` class, the prototype correctly identifies 13 of 24 held-out surge cases and misses 11. Its overall accuracy of 0.6774 is only modestly above the 0.6129 majority-class baseline. The correct workshop decision is to keep this as an Oracle Machine Learning for SQL mechanics and evaluation prototype, add more historical periods and useful pre-outcome predictors, and reevaluate before creating an operational capacity watchlist.
+
+## Conclusion
+
+Otto separated observation features from later outcomes, trained on earlier service weeks, and evaluated the model on 62 held-out cases. SQL `PREDICTION` and `PREDICTION_PROBABILITY` produced row-level scores, while the `DBMS_DATA_MINING` PL/SQL package created, batch-scored, and evaluated the model. The held-out result makes the limitation visible: this prototype teaches a sound Oracle Machine Learning for SQL workflow, but its `SURGE` recall and short history do not support operational deployment.
+
+## Next Steps
+
+Continue with Select AI to turn a transportation question into SQL that Nina can inspect and run. For deeper practice with in-database model training and scoring, open the [Oracle Machine Learning LiveLabs workshop](https://livelabs.oracle.com/ords/r/dbpm/livelabs/view-workshop?clear=RR,180&wid=922).
+
+## Acknowledgements
+
+* **Author** - Oracle Database Product Management
+* **Last Updated By/Date** - Oracle Database Product Management, September 2026
diff --git a/livestack-workshop-transportation/selectai-agent/images/agent-action-audit-trail.png b/livestack-workshop-transportation/selectai-agent/images/agent-action-audit-trail.png
new file mode 100644
index 000000000..a1a683d21
Binary files /dev/null and b/livestack-workshop-transportation/selectai-agent/images/agent-action-audit-trail.png differ
diff --git a/livestack-workshop-transportation/selectai-agent/images/agent-demand-surge-response.png b/livestack-workshop-transportation/selectai-agent/images/agent-demand-surge-response.png
new file mode 100644
index 000000000..83c2babcb
Binary files /dev/null and b/livestack-workshop-transportation/selectai-agent/images/agent-demand-surge-response.png differ
diff --git a/livestack-workshop-transportation/selectai-agent/images/nina-transportation.svg b/livestack-workshop-transportation/selectai-agent/images/nina-transportation.svg
new file mode 100644
index 000000000..d4a7a5f76
--- /dev/null
+++ b/livestack-workshop-transportation/selectai-agent/images/nina-transportation.svg
@@ -0,0 +1,10 @@
+
diff --git a/livestack-workshop-transportation/selectai-agent/images/operations-agent-console-overview.png b/livestack-workshop-transportation/selectai-agent/images/operations-agent-console-overview.png
new file mode 100644
index 000000000..aec5a70c6
Binary files /dev/null and b/livestack-workshop-transportation/selectai-agent/images/operations-agent-console-overview.png differ
diff --git a/livestack-workshop-transportation/selectai/images/ask-seer-transport-data-overview.png b/livestack-workshop-transportation/selectai/images/ask-seer-transport-data-overview.png
new file mode 100644
index 000000000..750837706
Binary files /dev/null and b/livestack-workshop-transportation/selectai/images/ask-seer-transport-data-overview.png differ
diff --git a/livestack-workshop-transportation/selectai/images/ask-seer-transport-generated-sql.png b/livestack-workshop-transportation/selectai/images/ask-seer-transport-generated-sql.png
new file mode 100644
index 000000000..15c656288
Binary files /dev/null and b/livestack-workshop-transportation/selectai/images/ask-seer-transport-generated-sql.png differ
diff --git a/livestack-workshop-transportation/selectai/images/ask-seer-transport-run-sql-results.png b/livestack-workshop-transportation/selectai/images/ask-seer-transport-run-sql-results.png
new file mode 100644
index 000000000..f0d311fc6
Binary files /dev/null and b/livestack-workshop-transportation/selectai/images/ask-seer-transport-run-sql-results.png differ
diff --git a/livestack-workshop-transportation/selectai/images/nina-transportation.svg b/livestack-workshop-transportation/selectai/images/nina-transportation.svg
new file mode 100644
index 000000000..fb7c48824
--- /dev/null
+++ b/livestack-workshop-transportation/selectai/images/nina-transportation.svg
@@ -0,0 +1,10 @@
+
diff --git a/livestack-workshop-transportation/shipment-json-duality/images/shipment-order-detail.png b/livestack-workshop-transportation/shipment-json-duality/images/shipment-order-detail.png
new file mode 100644
index 000000000..4653f1f13
Binary files /dev/null and b/livestack-workshop-transportation/shipment-json-duality/images/shipment-order-detail.png differ
diff --git a/livestack-workshop-transportation/shipment-json-duality/images/shipment-order-json-duality.png b/livestack-workshop-transportation/shipment-json-duality/images/shipment-order-json-duality.png
new file mode 100644
index 000000000..e584599ff
Binary files /dev/null and b/livestack-workshop-transportation/shipment-json-duality/images/shipment-order-json-duality.png differ
diff --git a/livestack-workshop-transportation/shipment-json-duality/images/shipment-orders-exceptions.png b/livestack-workshop-transportation/shipment-json-duality/images/shipment-orders-exceptions.png
new file mode 100644
index 000000000..97237280f
Binary files /dev/null and b/livestack-workshop-transportation/shipment-json-duality/images/shipment-orders-exceptions.png differ
diff --git a/livestack-workshop-transportation/shipment-json-duality/images/shipment-route-context.png b/livestack-workshop-transportation/shipment-json-duality/images/shipment-route-context.png
new file mode 100644
index 000000000..3c04acf19
Binary files /dev/null and b/livestack-workshop-transportation/shipment-json-duality/images/shipment-route-context.png differ
diff --git a/livestack-workshop-transportation/shipment-json-duality/images/thomas-transportation.svg b/livestack-workshop-transportation/shipment-json-duality/images/thomas-transportation.svg
new file mode 100644
index 000000000..3a529f378
--- /dev/null
+++ b/livestack-workshop-transportation/shipment-json-duality/images/thomas-transportation.svg
@@ -0,0 +1,10 @@
+
diff --git a/livestack-workshop-transportation/shipment-json-duality/images/thomas.png b/livestack-workshop-transportation/shipment-json-duality/images/thomas.png
new file mode 100644
index 000000000..3fd716b5d
Binary files /dev/null and b/livestack-workshop-transportation/shipment-json-duality/images/thomas.png differ
diff --git a/livestack-workshop-transportation/shipment-json-duality/shipment-json-duality.md b/livestack-workshop-transportation/shipment-json-duality/shipment-json-duality.md
new file mode 100644
index 000000000..1f2926961
--- /dev/null
+++ b/livestack-workshop-transportation/shipment-json-duality/shipment-json-duality.md
@@ -0,0 +1,309 @@
+# Build a Shipment JSON Application Model
+
+## Introduction
+
+Thomas is the application developer building the shipment-detail experience used by Seer Transport operations teams. He needs flexible screen settings, a saved dispatch-review document, and an API-ready shipment payload. Those needs look similar in an application, but the business ownership is different: screen settings belong to the application, a saved review belongs to the application workflow, and the shipment itself remains governed operational data.
+
+Oracle Autonomous AI Database supports all three JSON patterns without requiring a second shipment database. Thomas first reads optional application settings from a native `JSON` column. He then reviews one application-owned JSON Collection Table document. Finally, he reads the governed shipment through the JSON-Relational Duality View `ORDERS_DV`, where relational `ORDERS` and `ORDER_ITEMS` remain the source of truth.
+
+The image below shows the Shipment Orders & Exceptions detail used by dispatch and service-operations teams. Notice order `49651`, its current status, order total, and line-item context. The SQL in this lab reads the same order as a JSON document, then projects selected document fields back into SQL columns for analysis.
+
+Order `49651` and review document `DISPATCH-49651` are intentional, deterministic workshop fixtures. Reusable application SQL should accept identifiers through bind variables such as `:transport_order_id` rather than embedding literal values.
+
+
+
+
+
+### Objectives
+
+- Read flexible shipment-screen attributes from a native JSON column.
+- Query an application-owned JSON Collection Table and explain its ETag.
+- Inspect, read, and project a governed shipment through `ORDERS_DV`.
+- Choose the appropriate JSON pattern based on data ownership.
+
+Estimated Time: **15 minutes**
+
+### Hands-on Scenario
+
+| Step | Transportation focus |
+| --- | --- |
+| Business Problem | A shipment application needs flexible settings, review documents, and governed shipment data |
+| Technical Challenge | Each need has a different owner; copying operational shipments would create synchronization risk |
+| Persona Focus | Thomas, the application developer, chooses the JSON pattern that fits each feature |
+| What You Will Do | Read native JSON, a document collection, and a JSON-Relational Duality View |
+| Database Capability | Native JSON, JSON Collection Tables, SQL/JSON, and JSON-Relational Duality Views |
+| Outcome | Thomas can serve application JSON without creating a disconnected copy of a shipment |
+
+
+Key terms: JSON columns, JSON collections, and JSON-Relational Duality Views
+
+> - A **native JSON column** stores a JSON value beside normal relational keys and constraints. Thomas uses `THOMAS_SHIPMENT_APP_DATA.APP_DATA` for optional screen settings that can evolve without adding a column for every setting.
+>
+> - A **JSON Collection Table** stores application-owned documents in its `DATA` column. `THOMAS_DISPATCH_REVIEW_DOCS` stores a saved dispatch-review draft, not a second copy of the governed shipment.
+>
+> - A **JSON-Relational Duality View** exposes relational rows as a JSON document and can support governed document writes when its definition allows them. `ORDERS_DV` maps `ORDERS` to the document root and `ORDER_ITEMS` to its nested `items` array while those tables remain the relational source.
+>
+> - **Projection** selects fields from JSON and returns them as SQL columns. `JSON_VALUE` projects one scalar field, while `JSON_TABLE` turns an array into rows. This lets analysts query the document shape without abandoning relational operations.
+>
+> - An **ETag** is an opaque database-generated version value. An application can send the ETag it read with an update; a changed ETag tells it that another request has already changed the document. This is optimistic concurrency, not a business shipment attribute.
+
+
+
+> **SQL Worksheet reminder:** Return to [Getting Started Task 2](?lab=getting-started#Task2:OpenSQLWorksheet) if you need the SQL Worksheet steps.
+
+## Task 1: Read flexible application settings from native JSON
+
+Thomas starts with settings owned by the shipment-detail feature. The relational `ORDER_ID` identifies which shipment screen the setting applies to; the native JSON `APP_DATA` holds flexible fields such as the screen name, a display flag, and enabled features. These settings are not part of the shipment record itself.
+
+1. Read the seeded application settings.
+
+ ```sql
+
+ SELECT order_id,
+ JSON_VALUE(app_data, '$.screen' RETURNING VARCHAR2(30) ERROR ON ERROR) AS screen_name,
+ JSON_VALUE(app_data, '$.showLiveStatus' RETURNING BOOLEAN ERROR ON ERROR) AS show_live_status,
+ JSON_QUERY(app_data, '$.features' RETURNING VARCHAR2(200) ERROR ON ERROR) AS app_features
+ FROM thomas_shipment_app_data
+ WHERE order_id = 49651;
+
+ ```
+
+ **Expected output: Shipment Detail Settings**
+
+ | Order ID | Screen Name | Show Live Status | App Features |
+ | ---: | --- | --- | --- |
+ | 49651 | shipment-detail | true | exception-alerts and terminal-capacity |
+
+ `ORDER_ID` remains a typed relational key, while `APP_DATA` can gain an optional application setting without altering the operational shipment model.
+
+2. Optionally add Thomas as the last viewer. This isolated, rerunnable update affects only the workshop application-settings fixture. It does not change `ORDERS`, `ORDER_ITEMS`, or `ORDERS_DV`.
+
+ ```sql
+
+ UPDATE thomas_shipment_app_data
+ SET app_data = JSON_TRANSFORM(app_data, SET '$.lastViewedBy' = 'Thomas')
+ WHERE order_id = 49651
+ AND JSON_VALUE(app_data, '$.lastViewedBy' RETURNING VARCHAR2(30) NULL ON EMPTY) IS NULL;
+
+ COMMIT;
+
+ SELECT order_id,
+ JSON_VALUE(app_data, '$.lastViewedBy' RETURNING VARCHAR2(30) ERROR ON ERROR) AS last_viewed_by
+ FROM thomas_shipment_app_data
+ WHERE order_id = 49651;
+
+ ```
+
+ **Expected output: Application Setting Updated**
+
+ | Order ID | Last Viewed By |
+ | ---: | --- |
+ | 49651 | Thomas |
+
+The first run updates one row; later runs update zero rows and still return `Thomas`. This is application-owned JSON, so it is appropriate for a screen-setting change.
+
+## Task 2: Review an application-owned JSON collection document
+
+The dispatch-review draft is a separate, application-owned document. It records workflow context that Thomas's feature needs: its review state and requested actions. It references shipment order `49651`, but it is not a competing shipment system of record.
+
+1. Query the deterministic dispatch-review document.
+
+ ```sql
+
+ SELECT JSON_VALUE(data, '$._id' RETURNING VARCHAR2(30) ERROR ON ERROR) AS document_id,
+ JSON_VALUE(data, '$._metadata.etag' RETURNING VARCHAR2(64) ERROR ON ERROR) AS document_etag,
+ JSON_VALUE(data, '$.reviewState' RETURNING VARCHAR2(20) ERROR ON ERROR) AS review_state,
+ JSON_QUERY(data, '$.requestedActions' RETURNING VARCHAR2(200) ERROR ON ERROR) AS requested_actions
+ FROM thomas_dispatch_review_docs
+ WHERE JSON_VALUE(data, '$._id' RETURNING VARCHAR2(30) ERROR ON ERROR) = 'DISPATCH-49651';
+
+ ```
+
+ **Expected output: Dispatch Review Document**
+
+ | Document ID | Review State | Requested Actions |
+ | --- | --- | --- |
+ | DISPATCH-49651 | open | review terminal capacity; monitor port drayage |
+
+ `THOMAS_DISPATCH_REVIEW_DOCS` was created `WITH ETAG`, so Oracle provides the generated document ETag in `_metadata`. Its exact hexadecimal value is intentionally dynamic. A service should retain the ETag it read and compare it before accepting an update, so a stale request does not silently overwrite a newer dispatch review.
+
+2. Inspect the complete document if you want to see the database-managed metadata with the application fields.
+
+ ```sql
+
+ SELECT JSON_SERIALIZE(data PRETTY) AS dispatch_review_document
+ FROM thomas_dispatch_review_docs
+ WHERE JSON_VALUE(data, '$._id' RETURNING VARCHAR2(30) ERROR ON ERROR) = 'DISPATCH-49651';
+
+ ```
+
+ **Expected output: Dispatch Review JSON**
+
+ | JSON contains |
+ | --- |
+ | `_id`, `_metadata.etag`, `transportOrderId`, `reviewState`, and `requestedActions` |
+
+## Task 3: Confirm the governed shipment document contract
+
+`USER_JSON_DUALITY_VIEWS` is the learner-facing catalog for JSON-Relational Duality Views owned by the current schema. Query it to find the `ORDERS_DV` application contract and confirm that Oracle Autonomous AI Database recognizes it as valid.
+
+1. Inspect the actual document capabilities.
+
+ ```sql
+
+ SELECT view_name,
+ status,
+ allow_insert,
+ allow_update,
+ allow_delete
+ FROM user_json_duality_views
+ WHERE view_name = 'ORDERS_DV';
+
+ ```
+
+ **Expected output: Shipment Duality View Capabilities**
+
+ | View Name | Status | Allow Insert | Allow Update | Allow Delete |
+ | --- | --- | --- | --- | --- |
+ | ORDERS\_DV | VALID | true | true | false |
+
+ `ORDERS_DV` permits document inserts and updates for this workshop's order and nested item rows. It does not permit document deletion. Those annotations are specific to this view; they are not a general grant of table privileges or an authorization boundary by themselves.
+
+2. Inspect the view definition and its actual write annotations.
+
+ ```sql
+
+ SELECT text AS duality_view_definition
+ FROM user_views
+ WHERE view_name = 'ORDERS_DV';
+
+ ```
+
+ **Expected output: Duality View Definition**
+
+ | Relational Source | Annotation in `ORDERS_DV` |
+ | --- | --- |
+ | `ORDERS` root | `WITH INSERT UPDATE` |
+ | `ORDER_ITEMS` nested `items` array | `WITH INSERT UPDATE` |
+
+Unlike the native JSON settings and collection document, the governed shipment already belongs in relational tables. The duality view assembles an application document from those rows; it does not create a second shipment copy.
+
+## Task 4: Read the named shipment document
+
+The JSON-Relational Duality View exposes each document through its `DATA` column. `JSON_VALUE` locates order `49651` by its `_id`, and `JSON_SERIALIZE(... PRETTY)` formats the full document for review. `ERROR ON ERROR` makes a missing or malformed required `_id` a query error instead of silently returning `NULL`. Look for the order header fields, the database-managed `_metadata` object, and the nested `items` array.
+
+1. Read the JSON document.
+
+ ```sql
+
+ SELECT JSON_SERIALIZE(data PRETTY) AS shipment_document
+ FROM orders_dv
+ WHERE JSON_VALUE(data, '$._id' RETURNING NUMBER ERROR ON ERROR) = 49651;
+
+ ```
+
+ **Expected output: Shipment Document 49651**
+
+ | Shipment Document |
+ | --- |
+ | JSON with `_id`, `_metadata`, `customerId`, `status`, `total`, `shippingCost`, `demandScore`, and nested `items` |
+
+ The image below shows how the same order appears in the JSON-Relational Duality View panel for the application. Thomas uses this view to inspect the document contract; the SQL result lets you see that governed database rows directly supply the document.
+
+ 
+
+`_metadata` is maintained by the duality view and includes document-version information such as an ETag and an as-of value; it is not a business shipment attribute. The ETag is an opaque, generated value used for optimistic concurrency: an application sends back the ETag it read when it updates a document, and Oracle rejects a stale update rather than overwriting a newer one. The document shape helps an application because the header and line items arrive together. It also helps database teams because the relational order model supplies each business field without a disconnected copy.
+
+## Task 5: Project document fields into SQL
+
+This query projects application-document fields into a business-readable result. Read it in three parts:
+
+- `JSON_VALUE` extracts the required order identifier, status, and order total from the document root. `ERROR ON ERROR` makes a malformed or missing required field visible during this contract check.
+- `JSON_TABLE` turns every member of the nested `items` array into a SQL row containing an item identifier, service identifier, and quantity. Its `ERROR ON ERROR` clauses apply the same fail-fast behavior to required item fields.
+- `TRANSPORT_SERVICES_V` is a saved SQL query that supplies the transportation-ready service name for each identifier.
+
+Look for one row per service leg in order `49651`. Thomas and an operations analyst can now discuss the same shipment without exchanging or reconciling exports.
+
+1. Project the shipment header and line items.
+
+ ```sql
+
+ SELECT JSON_VALUE(od.data, '$._id' RETURNING NUMBER ERROR ON ERROR) AS transport_order_id,
+ JSON_VALUE(od.data, '$.status' RETURNING VARCHAR2(30) ERROR ON ERROR) AS order_status,
+ JSON_VALUE(od.data, '$.total' RETURNING NUMBER ERROR ON ERROR) AS order_total,
+ jt.item_id AS order_item_id,
+ jt.product_id AS transport_service_id,
+ ts.transport_service_name,
+ jt.quantity
+ FROM orders_dv od
+ CROSS APPLY JSON_TABLE(
+ od.data, '$.items[*]' ERROR ON ERROR
+ COLUMNS (
+ item_id NUMBER PATH '$.itemId' ERROR ON ERROR,
+ product_id NUMBER PATH '$.productId' ERROR ON ERROR,
+ quantity NUMBER PATH '$.quantity' ERROR ON ERROR
+ )
+ ) jt
+ JOIN transport_services_v ts
+ ON ts.transport_service_id = jt.product_id
+ WHERE JSON_VALUE(od.data, '$._id' RETURNING NUMBER ERROR ON ERROR) = 49651
+ ORDER BY jt.product_id, jt.item_id;
+
+ ```
+
+ **Expected output: Projected Shipment Items**
+
+ | Transport Order ID | Order Status | Order Total | Transport Service Name | Quantity |
+ | ---: | --- | ---: | --- | ---: |
+ | 49651 | delivered | 4840 | Contract Lane Rebid, Oversize Permit Coordination, Heavy Equipment Recovery Bundle, Regional Pool Distribution, and Port Drayage Appointment | 1, 2, or 3 |
+
+The repeated order identifier shows that each nested item became a relational result row. The service names make the document useful for an operations review rather than exposing only internal identifiers.
+
+## Task 6: Compare the relational and document views
+
+This comparison joins `TRANSPORT_ORDERS_V`, a saved business-ready view of the order rows, to `ORDERS_DV`. It compares status and order total in the relational and document shapes for the same order. Look for matching values in both pairs of columns. This is a read-time comparison of two access shapes, not a synchronization test between copied data: both sides resolve from the relational source managed by Oracle Autonomous AI Database.
+
+1. Run the comparison.
+
+ ```sql
+
+ SELECT o.transport_order_id,
+ o.transport_order_status AS relational_status,
+ JSON_VALUE(d.data, '$.status' RETURNING VARCHAR2(30) ERROR ON ERROR) AS document_status,
+ o.service_value AS relational_order_total,
+ JSON_VALUE(d.data, '$.total' RETURNING NUMBER ERROR ON ERROR) AS document_order_total
+ FROM transport_orders_v o
+ JOIN orders_dv d
+ ON JSON_VALUE(d.data, '$._id' RETURNING NUMBER ERROR ON ERROR) = o.transport_order_id
+ WHERE o.transport_order_id = 49651;
+
+ ```
+
+ **Expected output: Shared Shipment Values**
+
+ | Transport Order ID | Relational Status | Document Status | Relational Order Total | Document Order Total |
+ | ---: | --- | --- | ---: | ---: |
+ | 49651 | delivered | delivered | 4840 | 4840 |
+
+Matching values show that the application and the analyst are reading two representations of the same governed shipment. A status change does not require a separate document-sync job before both users can see it.
+
+## Conclusion: Choose the right JSON approach
+
+Thomas does not need one JSON pattern for every application feature. He chooses based on who owns the data and whether the application needs an independent document or a document assembled from relational rows.
+
+| Approach | Use it when | Transportation example | Where the data lives |
+| --- | --- | --- | --- |
+| Native JSON column | A relational record needs optional or changing application attributes | Shipment-detail screen settings and feature flags | `THOMAS_SHIPMENT_APP_DATA.APP_DATA` beside a relational `ORDER_ID` |
+| JSON Collection Table | The application owns a set of documents and needs document-style access | Saved dispatch-review drafts with requested actions | One document per `DATA` row in `THOMAS_DISPATCH_REVIEW_DOCS` |
+| JSON-Relational Duality View | Governed data already lives in relational tables but the application needs one JSON document | Shipment header and service legs for the order-detail API | `ORDERS` and `ORDER_ITEMS`; `ORDERS_DV` defines the JSON shape |
+
+For the shipment-detail API, `ORDERS_DV` is the right choice because the order and its service legs already have relational keys, joins, and operational controls. The native JSON setting and collection document remain useful for application-owned data, but neither replaces the governed shipment record.
+
+## Next Steps
+
+Continue with AI Vector Search to rank disruption evidence by meaning. For deeper practice with application documents backed by relational rows, open the [JSON-Relational Duality View LiveLabs workshop](https://livelabs.oracle.com/ords/r/dbpm/livelabs/view-workshop?clear=RR,180&wid=3797).
+
+## Acknowledgements
+
+* **Author** - Oracle Database Product Management
+* **Last Updated By/Date** - Oracle Database Product Management, September 2026
diff --git a/livestack-workshop-transportation/transportation-risk-network/images/bob-transportation.svg b/livestack-workshop-transportation/transportation-risk-network/images/bob-transportation.svg
new file mode 100644
index 000000000..76ec24529
--- /dev/null
+++ b/livestack-workshop-transportation/transportation-risk-network/images/bob-transportation.svg
@@ -0,0 +1,10 @@
+
diff --git a/livestack-workshop-transportation/transportation-risk-network/images/bob.png b/livestack-workshop-transportation/transportation-risk-network/images/bob.png
new file mode 100644
index 000000000..24d2caf00
Binary files /dev/null and b/livestack-workshop-transportation/transportation-risk-network/images/bob.png differ
diff --git a/livestack-workshop-transportation/transportation-risk-network/images/network-entity-data-point.png b/livestack-workshop-transportation/transportation-risk-network/images/network-entity-data-point.png
new file mode 100644
index 000000000..f69a1728c
Binary files /dev/null and b/livestack-workshop-transportation/transportation-risk-network/images/network-entity-data-point.png differ
diff --git a/livestack-workshop-transportation/transportation-risk-network/images/risk-network-query-results.png b/livestack-workshop-transportation/transportation-risk-network/images/risk-network-query-results.png
new file mode 100644
index 000000000..414b45c5e
Binary files /dev/null and b/livestack-workshop-transportation/transportation-risk-network/images/risk-network-query-results.png differ
diff --git a/livestack-workshop-transportation/transportation-risk-network/images/transportation-risk-network.png b/livestack-workshop-transportation/transportation-risk-network/images/transportation-risk-network.png
new file mode 100644
index 000000000..62fdc0a7c
Binary files /dev/null and b/livestack-workshop-transportation/transportation-risk-network/images/transportation-risk-network.png differ
diff --git a/livestack-workshop-transportation/transportation-risk-network/transportation-risk-network.md b/livestack-workshop-transportation/transportation-risk-network/transportation-risk-network.md
new file mode 100644
index 000000000..bec22ba67
--- /dev/null
+++ b/livestack-workshop-transportation/transportation-risk-network/transportation-risk-network.md
@@ -0,0 +1,266 @@
+# Investigate a Transportation Risk Network
+
+## Introduction
+
+Bob is the graph specialist investigating how disruption risk can move through ports, terminals, lanes, carriers, brokers, and equipment pools. One exception can affect several services because they share the same hub or operating dependency. Repeated relational self-joins become difficult to read and maintain as the number of relationship hops grows.
+
+Oracle Property Graph lets Bob describe the relationship pattern directly while the vertices and edges remain backed by governed relational tables. He can start with one named entity, control how far the investigation expands, and return a table of reached entities for review without copying sensitive network data into a separate graph store.
+
+The image below shows the Transportation Risk Network workspace used by network investigators and operations leaders. It begins with a readable depth around a selected entity and allows the investigator to expand only when the business question requires it. The SQL/Property Graph Queries (SQL/PGQ) in this lab produce the table evidence behind that visualization.
+
+
+
+
+
+### Objectives
+
+- Inspect the transportation graph and its source tables.
+- Start with one named exception case and trace its linked entities through two directed network hops.
+- Find high-risk entities in that case that share a terminal, yard, or port.
+
+Estimated Time: **10 minutes**
+
+### Hands-on Scenario
+
+| Step | Transportation focus |
+| --- | --- |
+| Business Problem | An exception can propagate across shared transportation dependencies |
+| Technical Challenge | Multi-hop relationships are hard to review with repeated joins |
+| Persona Focus | Bob, the graph specialist, exposes the connected evidence |
+| What You Will Do | Start from `CASE-PORT-2026-041`, trace relationship evidence, and compare shared hubs |
+| Database Capability | Oracle Property Graph and SQL/PGQ `GRAPH_TABLE` |
+| Outcome | Investigators prioritize connected risk for human review |
+
+
+Key terms: seed entity, hop, vertex, and edge
+
+> - The **seed entity** is the port, terminal, carrier, or other node where an investigation starts. In Task 2, `CASE-PORT-2026-041` supplies the case context and `PORT-LAX-DRAY` is one linked seed entity.
+>
+> - A **hop** crosses one relationship. A one-hop result connects directly to the seed; a two-hop result crosses one intermediate dependency.
+>
+> - A **vertex** represents an entity or exception case. An **edge** records a relationship such as `contains_entity`, `shares_terminal`, or `rerouted_through`. These relationships matter because two services can share operational risk even when their tabular records are not adjacent.
+
+
+
+> **SQL Worksheet reminder:** Return to [Getting Started Task 2](?lab=getting-started#Task2:OpenSQLWorksheet) if you need the SQL Worksheet steps.
+
+## Task 1: Inspect the graph sources
+
+`TRANSPORT_SIGNAL_NETWORK` is the property graph used in this lab. It is a query layer over relational entity, relationship, and exception-case views, not a disconnected graph copy. Count those source rows first so you know what business evidence is available to the traversal.
+
+1. Run the source summary.
+
+ ```sql
+
+ SELECT 'ENTITIES' AS graph_component, COUNT(*) AS row_count
+ FROM transport_network_entities_v
+ UNION ALL
+ SELECT 'RELATIONSHIPS', COUNT(*)
+ FROM transport_network_relationships_v
+ UNION ALL
+ SELECT 'EXCEPTION_CASES', COUNT(*)
+ FROM transport_exception_cases_v;
+
+ ```
+
+ **Expected output: Graph Source Summary**
+
+ | Graph Component | Row Count |
+ | --- | ---: |
+ | ENTITIES | Greater than 0 |
+ | RELATIONSHIPS | Greater than 0 |
+ | EXCEPTION\_CASES | Greater than 0 |
+
+The three counts represent the graph building blocks: the entities under review, their relationships, and the operational exceptions that give those connections business meaning.
+
+## Task 2: Trace the named exception through the network
+
+This query starts at the named port-congestion exception, follows `contains_entity` to one of its linked transportation entities, and then follows exactly two directed `related_to` network relationships. Each output row is one full path, so repeated endpoints remain visible when the case reaches the same entity through different evidence paths. Read the graph syntax in five parts:
+
+- `case_vertex IS exception_case` identifies the case, and the `WHERE` clause fixes it at `CASE-PORT-2026-041`.
+- `-[case_edge IS contains_entity]->` makes the case-to-entity evidence explicit, including its case role and evidence score.
+- `-[hop_1 IS related_to]->` and `-[hop_2 IS related_to]->` form a bounded, directed two-hop path.
+- `COLUMNS` projects both relationship types and the intermediate entity, so the result shows the actual path rather than only its endpoint.
+- `ONE ROW PER MATCH` keeps one row for each complete path; it deliberately does not hide alternative paths with `DISTINCT`.
+
+Look for the case role, the two edge types, and the intermediate entity before interpreting the reached entity's risk. This is relationship evidence for review, not proof that the endpoint caused the exception.
+
+1. Run the traversal.
+
+ ```sql
+
+ SELECT exception_case,
+ seed_entity,
+ case_role,
+ case_evidence_score,
+ 2 AS network_hops,
+ hop_1_relationship,
+ intermediate_entity,
+ hop_2_relationship,
+ reached_entity,
+ reached_type,
+ reached_risk,
+ reached_risk_level
+ FROM GRAPH_TABLE (
+ transport_signal_network
+ MATCH (case_vertex IS exception_case)
+ -[case_edge IS contains_entity]->
+ (seed IS entity)
+ -[hop_1 IS related_to]->
+ (intermediate IS entity)
+ -[hop_2 IS related_to]->
+ (reached IS entity)
+ WHERE case_vertex.case_ref = 'CASE-PORT-2026-041'
+ ONE ROW PER MATCH
+ COLUMNS (
+ case_vertex.case_ref AS exception_case,
+ seed.entity_key AS seed_entity,
+ case_edge.role AS case_role,
+ case_edge.evidence_score AS case_evidence_score,
+ hop_1.relationship_type AS hop_1_relationship,
+ intermediate.entity_key AS intermediate_entity,
+ hop_2.relationship_type AS hop_2_relationship,
+ reached.entity_key AS reached_entity,
+ reached.entity_type AS reached_type,
+ reached.risk_score AS reached_risk,
+ reached.risk_level AS reached_risk_level
+ )
+ )
+ ORDER BY reached_risk DESC,
+ seed_entity,
+ intermediate_entity,
+ reached_entity
+ FETCH FIRST 25 ROWS ONLY;
+
+ ```
+
+ **Expected output: Case-to-Network Paths**
+
+ | Exception Case | Seed Entity | Network Hops | Relationship Evidence | Reached Entity |
+ | --- | --- | ---: | --- | --- |
+ | CASE-PORT-2026-041 | PORT-LAX-DRAY or another case-linked entity | 2 | Two recorded `related_to` types and the intermediate entity | A transportation entity reached by that path |
+
+ The image below shows the SQL/PGQ result behind the network view. Bob uses the table to review exact entity keys and scores before expanding the visual investigation.
+
+ 
+
+The traversal does not prove that every reached entity caused the disruption. It gives Bob a bounded review set with the case membership, relationship types, hop count, and intermediate entity visible on each path.
+
+## Task 3: Find shared constrained hubs
+
+After tracing the named exception, Bob uses this separate, network-wide pattern to find high-risk entities that connect to the same terminal, yard, or port. In the `MATCH` pattern, `a` and `b` are the reviewed entities and `shared` is their common hub. The relationship types remain in the result so Bob can see how each entity reaches the hub. Both sides must have risk at least 75, which makes the resulting average at least 75. Each returned row is a distinct pair-of-edges evidence pattern; no `DISTINCT` suppresses additional paths. The score is a prioritization aid, not proof of cause or an automatic enforcement decision.
+
+1. Run the shared-hub query.
+
+ ```sql
+
+ SELECT source_entity,
+ shared_terminal,
+ shared_type,
+ source_relationship,
+ related_entity,
+ related_relationship,
+ source_risk,
+ related_risk,
+ ROUND((source_risk + related_risk) / 2, 1) AS combined_risk
+ FROM GRAPH_TABLE (
+ transport_signal_network
+ MATCH (a IS entity)
+ -[e1 IS related_to]-> (shared IS entity)
+ <-[e2 IS related_to]- (b IS entity)
+ WHERE a.entity_id < b.entity_id
+ AND shared.entity_type IN ('terminal', 'yard', 'port')
+ AND a.risk_score >= 75
+ AND b.risk_score >= 75
+ COLUMNS (
+ a.entity_key AS source_entity,
+ shared.entity_key AS shared_terminal,
+ shared.entity_type AS shared_type,
+ e1.relationship_type AS source_relationship,
+ b.entity_key AS related_entity,
+ e2.relationship_type AS related_relationship,
+ a.risk_score AS source_risk,
+ b.risk_score AS related_risk
+ )
+ )
+ ORDER BY combined_risk DESC, shared_terminal
+ FETCH FIRST 25 ROWS ONLY;
+
+ ```
+
+ **Expected output: Shared Hub Review**
+
+ | Source Entity | Shared Terminal | Related Entity | Combined Risk |
+ | --- | --- | --- | ---: |
+ | High-risk transportation entity | Terminal, yard, or port key | Connected high-risk entity | 75 or higher |
+
+The shared hub and the two relationship types explain *why* the entities appear together. That relationship evidence gives an investigator a defensible reason to review the pair instead of relying on a score with no visible path.
+
+🎯 **Interactive challenge: Trace a one-hop case path.**
+
+Remove the second `related_to` relationship in Task 2. Which direct network dependencies appear after the case-linked seed entity, and what relationship type connects each one?
+
+**Expected output: Direct Case Dependencies**
+
+| Exception Case | Seed Entity | Relationship Type | Direct Entity |
+| --- | --- | --- | --- |
+| CASE-PORT-2026-041 | A case-linked entity | Recorded `related_to` type | Entity directly connected to the seed |
+
+
+Challenge answer: Review the direct case path
+
+Run the direct network-hop traversal:
+
+ ```sql
+
+ SELECT exception_case,
+ seed_entity,
+ case_role,
+ network_relationship,
+ reached_entity,
+ reached_type,
+ reached_risk,
+ reached_risk_level
+ FROM GRAPH_TABLE (
+ transport_signal_network
+ MATCH (case_vertex IS exception_case)
+ -[case_edge IS contains_entity]->
+ (seed IS entity)
+ -[network_edge IS related_to]->
+ (reached IS entity)
+ WHERE case_vertex.case_ref = 'CASE-PORT-2026-041'
+ ONE ROW PER MATCH
+ COLUMNS (
+ case_vertex.case_ref AS exception_case,
+ seed.entity_key AS seed_entity,
+ case_edge.role AS case_role,
+ network_edge.relationship_type AS network_relationship,
+ reached.entity_key AS reached_entity,
+ reached.entity_type AS reached_type,
+ reached.risk_score AS reached_risk,
+ reached.risk_level AS reached_risk_level
+ )
+ )
+ ORDER BY reached_risk DESC,
+ seed_entity,
+ reached_entity
+ FETCH FIRST 25 ROWS ONLY;
+
+ ```
+
+One network hop gives the clearest direct dependencies. Compare these rows with the two-hop paths from Task 2: the second task adds a named intermediate entity and a second relationship type. Expanding to two hops can reveal propagation, but it can also widen the review queue, so inspect the direct evidence first.
+
+
+
+## Conclusion
+
+Bob described transportation relationships directly with SQL/PGQ while the source entities and edges remained in Oracle Autonomous AI Database. The graph makes multi-hop evidence easier to express, while database governance and the relational source remain intact. Seer Transport gains a focused investigation path without creating another copy of network-sensitive data.
+
+## Next Steps
+
+Continue with Oracle Spatial to add candidate-terminal evidence to a transportation review. For deeper practice with property graphs and relationship analysis, open the [Property Graph LiveLabs workshop](https://livelabs.oracle.com/ords/r/dbpm/livelabs/view-workshop?clear=RR,180&wid=3978).
+
+## Acknowledgements
+
+* **Author** - Oracle Database Product Management
+* **Last Updated By/Date** - Oracle Database Product Management, September 2026
diff --git a/livestack-workshop-transportation/workshops/sandbox/index.html b/livestack-workshop-transportation/workshops/sandbox/index.html
index 6e101c219..9c63554f4 100644
--- a/livestack-workshop-transportation/workshops/sandbox/index.html
+++ b/livestack-workshop-transportation/workshops/sandbox/index.html
@@ -1,72 +1,72 @@
-
-
-
-
-
-
-
- Oracle LiveLabs
-
-
-
-
-
-
-
-
-
-
-
-
-
-