@wowok/skills 1.1.9 → 1.1.11

package/examples/Travel/Travel.md

@@ -2,108 +2,18 @@
 
 A complete example demonstrating how to create an Iceland travel service using WoWok protocol. This service integrates weather-dependent activities, insurance sub-orders, and multi-node workflow management.
 
-> **View Actual Execution Results**: See [Travel_TestResults.md](Travel_TestResults.md) for real testnet execution results with actual object addresses and transaction outputs.
-
 ---
 
 ## Core Requirements & Features
 
 | Requirement | Description | Implementation |
 |-------------|-------------|----------------|
-| **Weather-Dependent Activities** | Ice scooting requires sunny weather | Guard queries weather Repository for the activity date |
-| **Insurance Sub-Order** | Travel provider purchases insurance as supply chain sub-order | Machine forward creates insurance Order via Progress |
+| **Weather Data Query** | Demonstrate querying weather Repository | Guard checks if weather data exists for a given date |
 | **Multi-Node Workflow** | Start -> Buy Insurance -> SPA -> Ice Scooting -> Complete | Machine with 5 nodes and conditional paths |
 | **Time-Lock Completion** | Prevent premature order completion | Guard using Order + convert_witness(TypeOrderProgress) |
-| **Cancellation Support** | Allow order cancellation before completion | Cancel forward with permission-based access |
+| **Cancellation Support** | Allow order cancellation from Ice Scooting node | Cancel forward with permission-based access |
 | **Arbitration** | Dispute resolution for order conflicts | Arbitration object bound to Service |
-
-### Key Design Decisions
-
-1. **Weather Data via Repository**: Weather conditions are stored in a Repository object with policy "Condition". Each day's weather is keyed by UTC timestamp (converted to Address via `convert_number_address`).
-2. **Insurance as Sub-Order**: The "Buy Insurance" node creates a sub-order on the insurance service, linking the two workflows.
-3. **Time-Lock via Witness Conversion**: The Complete node Guard uses `convert_witness: 100` (TypeOrderProgress) to access Progress data from the submitted Order.
-4. **Dynamic Time Calculation**: Weather data timestamps are calculated dynamically based on current time, ensuring the example is always testable.
-
----
-
-## Overview
-
-This example demonstrates:
-
-- **Travel Service Setup**: Permission, Arbitration, Guards, Machine, and Service creation
-- **Weather Data Management**: Repository with weather conditions for activity validation
-- **Insurance Integration**: Supply chain sub-order for insurance purchase
-- **Multi-Node Workflow**: Complex workflow with weather-dependent paths
-- **Time-Lock Guards**: Using Order + convert_witness for Progress data access
-
----
-
-## Architecture
-
-### System Components
-
-```
-+--------------------------------------------------------------------------+
-|                        Iceland Travel Service System                      |
-+--------------------------------------------------------------------------+
-|                                                                          |
-|  +--------------+  +--------------+  +--------------+  +--------------+  |
-|  |  Permission  |  |  Arbitration |  |   Guards     |  |  Repository  |  |
-|  |  (travel_    |  |  (travel_    |  |  (weather_   |  |  (weather_   |  |
-|  |   permission)|  |   arbitration)|  |   check,     |  |   repo)      |  |
-|  +------+-------+  +------+-------+  |   complete,  |  +------+-------+  |
-|         |                |           |   cancel)    |         |          |
-|         v                v           +------+-------+         |          |
-|  +--------------+  +--------------+         |                 |          |
-|  |   Machine    |  |   Service    |         |                 |          |
-|  |  (travel_    |<-|  (travel_    |         |                 |          |
-|  |   machine)   |  |   service)   |         |                 |          |
-|  +--------------+  +--------------+         |                 |          |
-|                                              |                 |          |
-|  Workflow:                                   |                 |          |
-|  Start -> Buy Insurance -> SPA -> Ice Scooting |                 |          |
-|                                    |         |                 |          |
-|                         +----------+---------+----------+      |          |
-|                         |                               |      |          |
-|                         v                               v      |          |
-|                    +----------+                   +----------+ |          |
-|                    | Complete |                   |  Cancel  | |          |
-|                    |(TimeLock)|                   |          | |          |
-|                    +----------+                   +----------+ |          |
-|                                                                          |
-+--------------------------------------------------------------------------+
-```
-
-### Workflow Diagram
-
-```
-                              +-------------+
-                              |    Start    |
-                              +------+------+
-                                     |
-                                     v
-                              +-------------+
-                              |Buy Insurance| ---> Creates sub-order on insurance service
-                              +------+------+
-                                     |
-                                     v
-                              +-------------+
-                              |     SPA     |
-                              +------+------+
-                                     |
-                                     v
-                              +-------------+
-                              |Ice Scooting | ---> Weather check Guard (sunny required)
-                              +------+------+
-                                     |
-                         +-----------+-----------+
-                         |                       |
-                         v                       v
-                  +-------------+         +-------------+
-                  |  Complete   |         |   Cancel    |
-                  | (Time-Lock) |         |             |
-                  +-------------+         +-------------+
-```
+| **Revenue Allocation** | Distribute funds based on progress state | Three allocation Guards for different refund scenarios |
 
 ---
 
@@ -111,11 +21,10 @@ This example demonstrates:
 
 Before running this example, ensure you have:
 
-1. An account named `travel_provider_v1` with sufficient WOW tokens
-2. An account named `weather_provider_v1` with sufficient WOW tokens
-3. An account named `alice_v1` (test customer) with sufficient WOW tokens
-4. The Insurance service from [Insurance/Insurance.md](../Insurance/Insurance.md) already deployed
-5. Access to the WoWok MCP server
+1. An account named `travel_provider` with sufficient WOW tokens
+2. An account named `weather_provider` with sufficient WOW tokens
+3. An account named `alice` (test customer) with sufficient WOW tokens
+4. Access to the WoWok MCP server
 
 ### Create Accounts
 
@@ -124,7 +33,7 @@ Before running this example, ensure you have:
 ```json
 {
   "gen": {
-    "name": "travel_provider_v1",
+    "name": "travel_provider",
     "replaceExistName": true
   }
 }
@@ -133,7 +42,7 @@ Before running this example, ensure you have:
 ```json
 {
   "gen": {
-    "name": "weather_provider_v1",
+    "name": "weather_provider",
     "replaceExistName": true
   }
 }
@@ -142,7 +51,7 @@ Before running this example, ensure you have:
 ```json
 {
   "gen": {
-    "name": "alice_v1",
+    "name": "alice",
     "replaceExistName": true
   }
 }
@@ -156,7 +65,7 @@ Before running this example, ensure you have:
 {
   "faucet": {
     "network": "testnet",
-    "name_or_address": "travel_provider_v1"
+    "name_or_address": "travel_provider"
   }
 }
 ```
@@ -165,7 +74,7 @@ Before running this example, ensure you have:
 {
   "faucet": {
     "network": "testnet",
-    "name_or_address": "weather_provider_v1"
+    "name_or_address": "weather_provider"
   }
 }
 ```
@@ -174,7 +83,7 @@ Before running this example, ensure you have:
 {
   "faucet": {
     "network": "testnet",
-    "name_or_address": "alice_v1"
+    "name_or_address": "alice"
   }
 }
 ```
@@ -183,41 +92,53 @@ Before running this example, ensure you have:
 
 ## Step 0: Setup Weather Data
 
-Before creating the travel service, set up the weather Repository with recent 5-day weather data.
+Before creating the travel service, set up the weather Repository with the next 5 days of weather data. The weather data is keyed by timestamp, and the `weather_check_guard` (Step 3.1) will query this repository at runtime when the customer enters the "Ice Scooting" node (Step 7.3). You must use timestamps that are valid at the time you run this example.
 
 ### 0.1 Calculate Weather Timestamps
 
-Use the following JavaScript to calculate recent 5-day UTC timestamps:
+The weather record `id` is a UTC timestamp (in milliseconds). It must be **aligned to UTC 00:00:00** so that the same timestamp can be reproduced and submitted later in Step 7.3. Run the following JavaScript (also available as `calc-weather-timestamps.js` in this example folder):
 
 ```js
-const DAY_MS = 86400000;
+const DAY_MS = 86400000; // 24 * 60 * 60 * 1000
 const now = Date.now();
+// Align to UTC 00:00:00 of today, then compute the next 5 days.
+// Repository data is keyed by timestamp, so the submitted activity date
+// must match exactly the id used when adding weather data.
 const todayStart = Math.floor(now / DAY_MS) * DAY_MS;
-// Recent 5 days UTC day start timestamps (from 4 days ago to today)
-for (let i = 4; i >= 0; i--) {
-  const ts = todayStart - i * DAY_MS;
-  console.log(`Day ${5-i}: ${ts} (${new Date(ts).toISOString()})`);
+for (let i = 1; i <= 5; i++) {
+  const ts = todayStart + i * DAY_MS;
+  console.log(`Day ${i}: ${ts} (${new Date(ts).toISOString()})`);
 }
 ```
 
-### 0.2 Create Weather Permission
+**Sample output** (run on 2026-07-08 — re-run the script to get current values for your test time):
 
-First, create a Permission object for the weather repository.
+```
+Day 1: 1783555200000 (2026-07-09T00:00:00.000Z)
+Day 2: 1783641600000 (2026-07-10T00:00:00.000Z)
+Day 3: 1783728000000 (2026-07-11T00:00:00.000Z)
+Day 4: 1783814400000 (2026-07-12T00:00:00.000Z)
+Day 5: 1783900800000 (2026-07-13T00:00:00.000Z)
+```
 
-**Prompt**: Create a Permission object named "weather_permission_v1".
+> **Important**: Always re-run the script at test time — the timestamps depend on the current date. Copy the 5 printed values; they will be used in Step 0.4 (as repository data `id`) and Step 7.3 (as the submitted `activity_date`). The two must match exactly, otherwise the Guard query `repository.data has("Condition", convert_number_address(activity_date))` will return false.
+
+### 0.2 Create Weather Permission
+
+**Prompt**: Create a Permission object named "weather_permission".
 
 ```json
 {
   "operation_type": "permission",
   "data": {
     "object": {
-      "name": "weather_permission_v1",
+      "name": "weather_permission",
       "replaceExistName": true
     },
     "description": "Weather repository permission"
   },
   "env": {
-    "account": "weather_provider_v1",
+    "account": "weather_provider",
     "network": "testnet"
   }
 }
@@ -225,17 +146,15 @@ First, create a Permission object for the weather repository.
 
 ### 0.3 Create Weather Repository with Policies
 
-Create the weather repository with the "Condition" policy included during creation (this avoids the need to add policies later, which had issues in testing).
-
-**Prompt**: Create a Repository named "weather_repo_v2" with "Condition" policy.
+**Prompt**: Create a Repository named "weather_repo" with "Condition" policy.
 
 ```json
 {
   "operation_type": "repository",
   "data": {
     "object": {
-      "name": "weather_repo_v2",
-      "permission": "weather_permission_v1",
+      "name": "weather_repo",
+      "permission": "weather_permission",
       "replaceExistName": true
     },
     "description": "Weather data repository for Iceland travel activities",
@@ -253,7 +172,7 @@ Create the weather repository with the "Condition" policy included during creati
     }
   },
   "env": {
-    "account": "weather_provider_v1",
+    "account": "weather_provider",
     "network": "testnet"
   }
 }
@@ -261,90 +180,93 @@ Create the weather repository with the "Condition" policy included during creati
 
 ### 0.4 Add Weather Data
 
-Add 5 days of weather data. The last day is "rainy" to test the weather check Guard's rejection behavior.
+Add 5 days of weather data. The `weather_check_guard` (Step 3.1) only verifies that a record **exists** for the activity date (via `repository.data has`), so all 5 days will pass the Guard regardless of the condition value. The "rainy" value on Day 5 is informational only — to actually reject based on weather condition, you would need a Guard that queries `repository.data` and compares the value, which is more complex and not used in this example.
 
-**Prompt**: Add weather data to "weather_repo_v2" with policy "Condition". Use the timestamps calculated in step 0.1.
+**Prompt**: Add weather data to "weather_repo" with policy "Condition".
 
 ```json
 {
   "operation_type": "repository",
   "data": {
-    "object": "weather_repo_v2",
+    "object": "weather_repo",
     "data_add": {
       "name": "Condition",
       "items": [
         {
           "data": [
-            {"id": 1777334400000, "data": "sunny"},
-            {"id": 1777420800000, "data": "sunny"},
-            {"id": 1777507200000, "data": "sunny"},
-            {"id": 1777593600000, "data": "sunny"},
-            {"id": 1777680000000, "data": "rainy"}
+            {"id": <DAY1_TIMESTAMP>, "data": "sunny"},
+            {"id": <DAY2_TIMESTAMP>, "data": "sunny"},
+            {"id": <DAY3_TIMESTAMP>, "data": "sunny"},
+            {"id": <DAY4_TIMESTAMP>, "data": "sunny"},
+            {"id": <DAY5_TIMESTAMP>, "data": "rainy"}
           ]
         }
       ]
     }
   },
   "env": {
-    "account": "weather_provider_v1",
+    "account": "weather_provider",
     "network": "testnet"
   }
 }
 ```
 
-> **Note**: Replace the timestamps with actual values from step 0.1. The last day is "rainy" to demonstrate weather-dependent activity rejection.
+> **Note**: Replace `<DAY1_TIMESTAMP>` through `<DAY5_TIMESTAMP>` with the actual values from Step 0.1. The `id` field is the timestamp (as a number) that keys the weather record — it must **exactly match** the timestamp you submit later in Step 7.3.
 
 ---
 
 ## Step 1: Create Permission Object
 
-Create a Permission object to manage access control for the travel service.
+Create a Permission object to manage access control for the travel service. Add permission indices for the travel_provider account.
 
-**Prompt**: Create a Permission object named "travel_permission_v1" for the travel service.
+**Prompt**: Create a Permission object named "travel_permission" for the travel service.
 
 ```json
 {
   "operation_type": "permission",
   "data": {
     "object": {
-      "name": "travel_permission_v1",
+      "name": "travel_permission",
+      "tags": ["travel", "iceland", "tourism"],
       "replaceExistName": true
     },
     "description": "Permission for Iceland travel service",
     "table": {
       "op": "add perm by entity",
-      "entity": {"name_or_address": "travel_provider_v1"},
-      "index": [1000, 1001, 1002, 1003, 1004, 1005]
+      "entity": {"name_or_address": "travel_provider"},
+      "index": [1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009, 306]
     }
   },
   "env": {
-    "account": "travel_provider_v1",
+    "account": "travel_provider",
     "network": "testnet"
   }
 }
 ```
 
+> **Note**: Permission indices 1000-1009 are used for different workflow forwards. Index 306 is a reserved administrative permission. The travel_provider account is granted all these permissions.
+
 ---
 
 ## Step 2: Create Arbitration Object
 
 Create an Arbitration object for dispute resolution.
 
-**Prompt**: Create an Arbitration named "travel_arbitration_v1".
+**Prompt**: Create an Arbitration named "travel_arbitration".
 
 ```json
 {
   "operation_type": "arbitration",
   "data": {
     "object": {
-      "name": "travel_arbitration_v1",
-      "permission": "travel_permission_v1",
+      "name": "travel_arbitration",
+      "permission": "travel_permission",
       "replaceExistName": true
     },
     "description": "Arbitration for Iceland travel service disputes"
   },
   "env": {
-    "account": "travel_provider_v1",
+    "account": "travel_provider",
     "network": "testnet"
   }
 }
@@ -354,17 +276,15 @@ Create an Arbitration object for dispute resolution.
 
 ## Step 3: Create Guards
 
-### 3.1 Weather Check Guard
-
-> **Note**: This guard demonstrates how to query repository data using a timestamp converted to an address. You can test it using `gen_passport` with a timestamp from step 0.1.
+Create all Guards needed for the workflow and fund allocation. Guards are immutable once created, so create them before the Machine and Service.
 
-**Prompt**: Create a Guard named "weather_check_guard_v1" for weather condition verification.
+### 3.1 Weather Check Guard
 
-Creates a Guard that verifies weather conditions for a given date. Queries the weather Repository for the specified date and checks if the condition matches the expected value.
+Creates a Guard that verifies weather data exists for a given date. This Guard is bound to the "go_ice_scooting" forward (entering the weather-dependent Ice Scooting activity) to ensure the activity date has a weather record in the repository.
 
 **Guard Logic**:
 ```
-repository.data("Condition", convert_number_address(activity_date)) == expected_weather
+repository.data has("Condition", convert_number_address(activity_date))
 ```
 
 **Prompt**: Create a Guard named "weather_check_guard" for weather condition verification.
@@ -374,17 +294,17 @@ repository.data("Condition", convert_number_address(activity_date)) == expected_
   "operation_type": "guard",
   "data": {
     "namedNew": {
-      "name": "weather_check_guard_v1",
+      "name": "weather_check_guard",
       "tags": ["weather", "check", "travel"],
       "replaceExistName": true
     },
-    "description": "Weather check guard for ice scooting activity. Queries weather Repository for the activity date and verifies the condition is 'sunny'. The activity date is submitted at runtime.",
+    "description": "Weather check guard for ice scooting activity. Checks if weather data exists for the activity date.",
     "table": [
       {
         "identifier": 0,
         "b_submission": false,
         "value_type": "Address",
-        "value": "weather_repo_v2",
+        "value": "weather_repo",
         "name": "Weather Repository address"
       },
       {
@@ -400,65 +320,35 @@ repository.data("Condition", convert_number_address(activity_date)) == expected_
         "value_type": "U64",
         "value": 0,
         "name": "Activity date timestamp (submitted at runtime)"
-      },
-      {
-        "identifier": 3,
-        "b_submission": false,
-        "value_type": "String",
-        "value": "sunny",
-        "name": "Expected weather condition"
       }
     ],
     "root": {
-      "type": "node",
-      "node": {
-        "type": "logic_equal",
-        "nodes": [
-          {
-            "type": "query",
-            "query": "repository.data",
-            "object": {
-              "identifier": 0
-            },
-            "parameters": [
-              {
-                "type": "identifier",
-                "identifier": 1
-              },
-              {
-                "type": "convert_number_address",
-                "node": {
-                  "type": "identifier",
-                  "identifier": 2
-                }
-              }
-            ]
-          },
-          {
-            "type": "identifier",
-            "identifier": 3
-          }
-        ]
-      }
+      "type": "query",
+      "query": "repository.data has",
+      "object": {"identifier": 0},
+      "parameters": [
+        {"type": "identifier", "identifier": 1},
+        {
+          "type": "convert_number_address",
+          "node": {"type": "identifier", "identifier": 2}
+        }
+      ]
     }
   },
   "env": {
-    "account": "travel_provider_v1",
+    "account": "travel_provider",
     "network": "testnet"
   }
 }
 ```
 
-> **Note**: We use the repository name "weather_repo_v2" directly (the MCP server resolves names to addresses automatically). If you need the raw address, you can query it using `onchain_objects` with the name.
-
 **Guard Table**:
 
 | identifier | b_submission | value_type | value | Purpose |
 |------------|-------------|-----------|-------|---------|
-| 0 | false | Address | weather_repo address | Weather Repository to query |
+| 0 | false | Address | weather_repo | Weather Repository to query |
 | 1 | false | String | "Condition" | Repository policy name |
 | 2 | **true** | U64 | 0 (placeholder) | Activity date timestamp, submitted at runtime |
-| 3 | false | String | "sunny" | Expected weather condition |
 
 ### 3.2 Travel Complete Guard (Time-Lock)
 
@@ -477,11 +367,11 @@ clock > progress.current_time + 1000
   "operation_type": "guard",
   "data": {
     "namedNew": {
-      "name": "travel_complete_guard_v1",
+      "name": "travel_complete_guard",
       "tags": ["travel", "time-lock", "complete"],
       "replaceExistName": true
     },
-    "description": "Time-lock guard for travel order completion. Requires current clock > progress.current_time + 1000ms (1 second for TESTING; in production set to reasonable duration like 8 hours). Progress is accessed via Order with convert_witness=TypeOrderProgress(100).",
+    "description": "Time-lock guard for travel order completion. Requires current clock > progress.current_time + 1000ms.",
     "table": [
       {
         "identifier": 0,
@@ -494,42 +384,31 @@ clock > progress.current_time + 1000
         "identifier": 1,
         "b_submission": false,
         "value_type": "U64",
-        "value": 1000
+        "value": 1000,
+        "name": "Time-lock duration in ms"
       }
     ],
     "root": {
-      "type": "node",
-      "node": {
-        "type": "logic_as_u256_greater",
-        "nodes": [
-          {
-            "type": "context",
-            "context": "Clock"
-          },
-          {
-            "type": "calc_number_add",
-            "nodes": [
-              {
-                "type": "query",
-                "query": "progress.current_time",
-                "object": {
-                  "identifier": 0,
-                  "convert_witness": 100
-                },
-                "parameters": []
-              },
-              {
-                "type": "identifier",
-                "identifier": 1
-              }
-            ]
-          }
-        ]
-      }
+      "type": "logic_as_u256_greater",
+      "nodes": [
+        {"type": "context", "context": "Clock"},
+        {
+          "type": "calc_number_add",
+          "nodes": [
+            {
+              "type": "query",
+              "query": "progress.current_time",
+              "object": {"identifier": 0, "convert_witness": 100},
+              "parameters": []
+            },
+            {"type": "identifier", "identifier": 1}
+          ]
+        }
+      ]
     }
   },
   "env": {
-    "account": "travel_provider_v1",
+    "account": "travel_provider",
     "network": "testnet"
   }
 }
@@ -555,11 +434,11 @@ Creates a Guard that allows order cancellation. This Guard always passes (return
   "operation_type": "guard",
   "data": {
     "namedNew": {
-      "name": "travel_cancel_guard_v1",
+      "name": "travel_cancel_guard",
       "tags": ["travel", "cancel"],
       "replaceExistName": true
     },
-    "description": "Cancel guard for travel orders. Always passes - cancellation is controlled by permission-based access (only authorized operators can execute the cancel forward).",
+    "description": "Cancel guard for travel orders. Always passes - cancellation is controlled by permission-based access.",
     "table": [
       {
         "identifier": 0,
@@ -570,15 +449,192 @@ Creates a Guard that allows order cancellation. This Guard always passes (return
       }
     ],
     "root": {
-      "type": "node",
-      "node": {
-        "type": "identifier",
-        "identifier": 0
+      "type": "identifier",
+      "identifier": 0
+    }
+  },
+  "env": {
+    "account": "travel_provider",
+    "network": "testnet"
+  }
+}
+```
+
+### 3.4 Merchant Victory Guard (100% to Service)
+
+Checks if order progress current node is "Complete". If passed, merchant receives 100% of funds.
+
+**Prompt**: Create Guard "merchant_victory_guard".
+
+```json
+{
+  "operation_type": "guard",
+  "data": {
+    "namedNew": {
+      "name": "merchant_victory_guard",
+      "tags": ["merchant", "victory", "complete"],
+      "replaceExistName": true
+    },
+    "description": "Guard for merchant victory: checks if order progress current node is Complete. If passed, merchant receives 100% of funds.",
+    "table": [
+      {
+        "identifier": 0,
+        "b_submission": true,
+        "value_type": "Address",
+        "value": "0x0000000000000000000000000000000000000000000000000000000000000000",
+        "name": "Order ID (submitted at runtime)"
+      },
+      {
+        "identifier": 1,
+        "b_submission": false,
+        "value_type": "String",
+        "value": "Complete",
+        "name": "Complete node name"
+      }
+    ],
+    "root": {
+      "type": "logic_equal",
+      "nodes": [
+        {
+          "type": "query",
+          "query": "progress.current",
+          "object": {"identifier": 0, "convert_witness": 100},
+          "parameters": []
+        },
+        {"type": "identifier", "identifier": 1}
+      ]
+    }
+  },
+  "env": {
+    "account": "travel_provider",
+    "network": "testnet"
+  }
+}
+```
+
+### 3.5 No Ice Scooting Guard (80% Service, 20% Refund)
+
+Checks if progress current is "Cancel" or "Ice Scooting". If passed, merchant gets 80%, user gets 20% refund.
+
+**Prompt**: Create Guard "no_ice_scooting_guard".
+
+```json
+{
+  "operation_type": "guard",
+  "data": {
+    "namedNew": {
+      "name": "no_ice_scooting_guard",
+      "tags": ["user", "cancel", "ice_scooting"],
+      "replaceExistName": true
+    },
+    "description": "Guard for user not participating in ice scooting: checks if progress current is Cancel or Ice Scooting. If passed, merchant gets 80%, user gets 20% refund.",
+    "table": [
+      {
+        "identifier": 0,
+        "b_submission": true,
+        "value_type": "Address",
+        "value": "0x0000000000000000000000000000000000000000000000000000000000000000",
+        "name": "Order ID (submitted at runtime)"
+      },
+      {
+        "identifier": 1,
+        "b_submission": false,
+        "value_type": "String",
+        "value": "Cancel",
+        "name": "Cancel node name"
+      },
+      {
+        "identifier": 2,
+        "b_submission": false,
+        "value_type": "String",
+        "value": "Ice Scooting",
+        "name": "Ice Scooting node name"
+      }
+    ],
+    "root": {
+      "type": "logic_or",
+      "nodes": [
+        {
+          "type": "logic_equal",
+          "nodes": [
+            {
+              "type": "query",
+              "query": "progress.current",
+              "object": {"identifier": 0, "convert_witness": 100},
+              "parameters": []
+            },
+            {"type": "identifier", "identifier": 1}
+          ]
+        },
+        {
+          "type": "logic_equal",
+          "nodes": [
+            {
+              "type": "query",
+              "query": "progress.current",
+              "object": {"identifier": 0, "convert_witness": 100},
+              "parameters": []
+            },
+            {"type": "identifier", "identifier": 2}
+          ]
+        }
+      ]
+    }
+  },
+  "env": {
+    "account": "travel_provider",
+    "network": "testnet"
+  }
+}
+```
+
+### 3.6 No SPA Guard (5% Service, 95% Refund)
+
+Checks if progress current is "SPA". If passed, merchant gets 5%, user gets 95% refund.
+
+**Prompt**: Create Guard "no_spa_guard".
+
+```json
+{
+  "operation_type": "guard",
+  "data": {
+    "namedNew": {
+      "name": "no_spa_guard",
+      "tags": ["user", "cancel", "spa"],
+      "replaceExistName": true
+    },
+    "description": "Guard for user not participating in SPA: checks if progress current is SPA. If passed, merchant gets 5%, user gets 95% refund.",
+    "table": [
+      {
+        "identifier": 0,
+        "b_submission": true,
+        "value_type": "Address",
+        "value": "0x0000000000000000000000000000000000000000000000000000000000000000",
+        "name": "Order ID (submitted at runtime)"
+      },
+      {
+        "identifier": 1,
+        "b_submission": false,
+        "value_type": "String",
+        "value": "SPA",
+        "name": "SPA node name"
       }
+    ],
+    "root": {
+      "type": "logic_equal",
+      "nodes": [
+        {
+          "type": "query",
+          "query": "progress.current",
+          "object": {"identifier": 0, "convert_witness": 100},
+          "parameters": []
+        },
+        {"type": "identifier", "identifier": 1}
+      ]
     }
   },
   "env": {
-    "account": "travel_provider_v1",
+    "account": "travel_provider",
     "network": "testnet"
   }
 }
@@ -586,52 +642,39 @@ Creates a Guard that allows order cancellation. This Guard always passes (return
 
 ---
 
-## Step 4: Create Machine with Workflow
+## Step 4: Create and Publish Machine
+
+Create a Machine to define the travel service workflow with all nodes and forwards. The Machine must be published before it can be bound to a Service.
 
-Create a Machine to define the travel service workflow with all nodes and forwards.
+> **Important**: In the Machine node structure, each node's `pairs` define how to ENTER that node. The `prev_node` specifies the source node, and `forwards` are the operation names used to advance from `prev_node` to this node.
 
-**Prompt**: Create a Machine named "travel_machine" with the complete travel workflow.
+**Prompt**: Create and publish a Machine named "travel_machine" with the complete travel workflow.
 
 ```json
 {
   "operation_type": "machine",
   "data": {
     "object": {
-      "name": "travel_machine_v1",
-      "permission": "travel_permission_v1",
+      "name": "travel_machine",
+      "permission": "travel_permission",
       "replaceExistName": true
     },
-    "description": "Iceland travel service workflow: Start -> Buy Insurance -> SPA -> Ice Scooting -> Complete/Cancel",
+    "description": "Iceland travel service workflow: (init) -> Buy Insurance -> SPA -> Ice Scooting -> Complete/Cancel",
     "node": {
       "op": "add",
+      "bReplace": true,
       "nodes": [
-        {
-          "name": "Start",
-          "pairs": [
-            {
-              "prev_node": "",
-              "threshold": 0,
-              "forwards": [
-                {
-                  "name": "buy_insurance",
-                  "permissionIndex": 1000,
-                  "weight": 1
-                }
-              ]
-            }
-          ]
-        },
         {
           "name": "Buy Insurance",
           "pairs": [
             {
-              "prev_node": "Start",
+              "prev_node": "",
               "threshold": 1,
               "forwards": [
                 {
-                  "name": "go_ice_scooting",
-                  "permissionIndex": 1001,
-                  "weight": 1
+                  "name": "buy_insurance",
+                  "weight": 1,
+                  "permissionIndex": 1000
                 }
               ]
             }
@@ -645,9 +688,9 @@ Create a Machine to define the travel service workflow with all nodes and forwar
               "threshold": 1,
               "forwards": [
                 {
-                  "name": "go_ice_scooting",
-                  "permissionIndex": 1002,
-                  "weight": 1
+                  "name": "go_spa",
+                  "weight": 1,
+                  "permissionIndex": 1001
                 }
               ]
             }
@@ -661,19 +704,12 @@ Create a Machine to define the travel service workflow with all nodes and forwar
               "threshold": 1,
               "forwards": [
                 {
-                  "name": "complete_trip",
-                  "permissionIndex": 1003,
+                  "name": "go_ice_scooting",
                   "weight": 1,
-                  "guard": {
-                    "guard": "travel_complete_guard_v1"
-                  }
-                },
-                {
-                  "name": "cancel_trip",
                   "permissionIndex": 1004,
-                  "weight": 1,
                   "guard": {
-                    "guard": "travel_cancel_guard_v1"
+                    "guard": "weather_check_guard",
+                    "retained_submission": []
                   }
                 }
               ]
@@ -686,7 +722,17 @@ Create a Machine to define the travel service workflow with all nodes and forwar
             {
               "prev_node": "Ice Scooting",
               "threshold": 1,
-              "forwards": []
+              "forwards": [
+                {
+                  "name": "complete_trip",
+                  "weight": 1,
+                  "permissionIndex": 1002,
+                  "guard": {
+                    "guard": "travel_complete_guard",
+                    "retained_submission": []
+                  }
+                }
+              ]
             }
           ]
         },
@@ -696,7 +742,17 @@ Create a Machine to define the travel service workflow with all nodes and forwar
             {
               "prev_node": "Ice Scooting",
               "threshold": 1,
-              "forwards": []
+              "forwards": [
+                {
+                  "name": "cancel_trip",
+                  "weight": 1,
+                  "permissionIndex": 1003,
+                  "guard": {
+                    "guard": "travel_cancel_guard",
+                    "retained_submission": []
+                  }
+                }
+              ]
             }
           ]
         }
@@ -705,136 +761,172 @@ Create a Machine to define the travel service workflow with all nodes and forwar
     "publish": true
   },
   "env": {
-    "account": "travel_provider_v1",
+    "account": "travel_provider",
     "network": "testnet"
   }
 }
 ```
 
-**Workflow Nodes**:
+**Machine Workflow Diagram**:
+
+```
+("") --buy_insurance--> [Buy Insurance] --go_spa--> [SPA] --go_ice_scooting--[weather_check]--> [Ice Scooting]
+                                                                                                  |
+                                                                                                  +--complete_trip--[time-lock]--> [Complete]
+                                                                                                  +--cancel_trip-------------> [Cancel]
+```
+
+**Node Pair Structure**:
+
+| Node | prev_node | Forward | Permission Index | Guard |
+|------|-----------|---------|-----------------|-------|
+| Buy Insurance | "" (entry) | buy_insurance | 1000 | - |
+| SPA | Buy Insurance | go_spa | 1001 | - |
+| Ice Scooting | SPA | go_ice_scooting | 1004 | weather_check_guard |
+| Complete | Ice Scooting | complete_trip | 1002 | travel_complete_guard |
+| Cancel | Ice Scooting | cancel_trip | 1003 | travel_cancel_guard |
 
-| Node | Forward | Guard | PermissionIndex | Description |
-|------|---------|-------|-----------------|-------------|
-| Start | buy_insurance -> Buy Insurance | - | 1000 | Enter Start node from initial state |
-| Buy Insurance | go_ice_scooting -> SPA | - | 1001 | Proceed to SPA |
-| SPA | go_ice_scooting -> Ice Scooting | - | 1002 | Proceed to ice scooting |
-| Ice Scooting | complete_trip -> Complete | travel_complete_guard_v1 | 1003 | Complete trip (time-lock) |
-| Ice Scooting | cancel_trip -> Cancel | travel_cancel_guard_v1 | 1004 | Cancel trip |
-| Complete | (endpoint) | - | - | Final state |
-| Cancel | (endpoint) | - | - | Cancelled state |
+> **Note**: The `prev_node` field uses an empty string `""` to denote the entry point. Each node defines how to enter it from a previous node. The `threshold` field (required) specifies the minimum forward weight needed to trigger node advancement.
 
 ---
 
 ## Step 5: Create and Publish Service
 
-Create the travel service with Machine, Arbitration, sales, and order_allocators, then publish in a single transaction.
+Create the travel service with all configurations and publish it in one operation. The Service requires:
+- Machine binding (must be published first)
+- Sales items (product listing)
+- Arbitration binding
+- Order allocators (fund distribution rules)
+- `pause: false` and `publish: true` to make it active
 
-**Prompt**: Create and publish "travel_service" with all bindings and sales.
+**Prompt**: Create and publish a Service named "travel_service".
 
 ```json
 {
   "operation_type": "service",
   "data": {
     "object": {
-      "name": "travel_service_v1",
-      "type_parameter": "0x2::wow::WOW",
-      "permission": "travel_permission_v1",
+      "name": "travel_service",
+      "permission": "travel_permission",
       "replaceExistName": true
     },
-    "description": "Iceland travel service: Blue Lagoon SPA + Glacier Ice Scooting. Includes outdoor accident insurance.",
-    "machine": "travel_machine_v1",
-    "arbitrations": {
-      "op": "add",
-      "objects": ["travel_arbitration_v1"]
-    },
+    "description": "Iceland travel service: Blue Lagoon SPA + Glacier Ice Scooting.",
+    "machine": "travel_machine",
     "sales": {
       "op": "add",
       "sales": [
         {
           "name": "Iceland Travel Package",
-          "price": 500000000,
-          "stock": 100,
+          "price": "500000000",
+          "stock": "99",
           "suspension": false,
           "wip": "",
           "wip_hash": ""
         }
       ]
     },
+    "arbitrations": {
+      "op": "add",
+      "objects": ["travel_arbitration"]
+    },
     "order_allocators": {
-      "description": "Travel order revenue allocation",
+      "description": "Travel order revenue allocation based on progress state",
       "threshold": 0,
       "allocators": [
         {
-          "guard": "travel_complete_guard_v1",
+          "guard": "merchant_victory_guard",
+          "fix": "0",
           "sharing": [
             {
-              "who": {"Signer": "signer"},
+              "who": {"Entity": {"name_or_address": "travel_service"}},
               "sharing": 10000,
               "mode": "Rate"
             }
           ]
+        },
+        {
+          "guard": "no_ice_scooting_guard",
+          "fix": "0",
+          "sharing": [
+            {
+              "who": {"Entity": {"name_or_address": "travel_service"}},
+              "sharing": 8000,
+              "mode": "Rate"
+            },
+            {
+              "who": {"GuardIdentifier": 0},
+              "sharing": 2000,
+              "mode": "Rate"
+            }
+          ]
+        },
+        {
+          "guard": "no_spa_guard",
+          "fix": "0",
+          "sharing": [
+            {
+              "who": {"Entity": {"name_or_address": "travel_service"}},
+              "sharing": 500,
+              "mode": "Rate"
+            },
+            {
+              "who": {"GuardIdentifier": 0},
+              "sharing": 9500,
+              "mode": "Rate"
+            }
+          ]
         }
       ]
     },
+    "pause": false,
     "publish": true
   },
   "env": {
-    "account": "travel_provider_v1",
+    "account": "travel_provider",
     "network": "testnet"
   }
 }
 ```
 
-> **Note**: The `order_allocators` field is required for publishing a Service. It defines how order revenue is allocated. In this example, we use a simple allocator with the travel_complete_guard.
-
----
-
-## Step 6: Unpause Service
-
-Unpause the service to allow order creation.
+**order_allocators Field Reference**:
 
-**Prompt**: Unpause "travel_service".
-
-```json
-{
-  "operation_type": "service",
-  "data": {
-    "object": "travel_service",
-    "pause": false
-  },
-  "env": {
-    "account": "travel_provider_v1",
-    "network": "testnet"
-  }
-}
-```
+| Field | Type | Description |
+|-------|------|-------------|
+| `description` | string | Description of the allocation strategy |
+| `threshold` | number | Minimum threshold for allocation (0 = no minimum) |
+| `allocators` | array | Array of allocator configurations |
+| `allocators[].guard` | string | Guard name/ID that must pass for this allocation |
+| `allocators[].fix` | string | Fixed amount per recipient ("0" = none) |
+| `allocators[].sharing` | array | Array of sharing rules |
+| `allocators[].sharing[].who` | object | Recipient: `{"Entity": {...}}` for fixed address, `{"GuardIdentifier": N}` for Guard table index, `{"Signer": "signer"}` for caller |
+| `allocators[].sharing[].sharing` | number | Amount in basis points (10000 = 100%) |
+| `allocators[].sharing[].mode` | string | Allocation mode ("Rate" or "Amount") |
 
----
+**Recipient Types**:
 
-## Step 7: Verify Service Configuration
+| Type | Syntax | Resolves To | Use Case |
+|------|--------|-------------|----------|
+| `Entity` | `{"Entity": {"name_or_address": "travel_service"}}` | The named address | Merchant receipts (Service object) |
+| `GuardIdentifier` | `{"GuardIdentifier": 0}` | Address from Guard table index 0 (submitted at runtime) | Customer refunds (Order ID submitted to Guard) |
+| `Signer` | `{"Signer": "signer"}` | The caller of `alloc_by_guard` | When caller should receive all funds |
 
-Query the service to verify all configurations are correct.
+> **Important**: All allocation Guards (merchant_victory_guard, no_ice_scooting_guard, no_spa_guard) have `identifier: 0` as a submission field accepting the Order ID at runtime. `{"GuardIdentifier": 0}` resolves to this submitted Order ID, so funds are sent to the Order object — the customer (Order builder) can then withdraw.
 
-**Prompt**: Query "travel_service" to verify configuration.
+**Allocation Logic**:
 
-```json
-{
-  "query_type": "onchain_objects",
-  "objects": ["travel_service"],
-  "no_cache": true,
-  "network": "testnet"
-}
-```
+| Guard | Condition | Service Receives | Customer Receives |
+|-------|-----------|-----------------|-------------------|
+| merchant_victory_guard | Progress is "Complete" | 100% (Entity → travel_service) | 0% |
+| no_ice_scooting_guard | Progress is "Cancel" or "Ice Scooting" | 80% (Entity → travel_service) | 20% (GuardIdentifier: 0 → Order) |
+| no_spa_guard | Progress is "SPA" | 5% (Entity → travel_service) | 95% (GuardIdentifier: 0 → Order) |
 
 ---
 
-## Step 8: Test Order Creation and Progress
+## Step 6: Place Order (Customer Purchase)
 
-### 8.1 Create Travel Order (as Customer Alice)
+The customer (Alice) purchases the travel package. This creates an Order, a Progress (initialized at the entry node ""), and an Allocation object automatically.
 
-Create an order on the travel service as the test customer.
-
-**Prompt**: Create an order on "travel_service" using account "alice".
+**Prompt**: Alice purchases the Iceland Travel Package from the service.
 
 ```json
 {
@@ -846,312 +938,508 @@ Create an order on the travel service as the test customer.
         "items": [
           {
             "name": "Iceland Travel Package",
-            "stock": 1,
+            "stock": "1",
             "wip_hash": ""
           }
         ],
-        "total_pay": {
-          "balance": 500000000
-        }
+        "total_pay": {"balance": "500000000"}
       },
       "namedNewOrder": {
-        "name": "test_travel_order_v1",
+        "name": "alice_travel_order",
+        "replaceExistName": true
+      },
+      "namedNewProgress": {
+        "name": "alice_travel_progress",
+        "replaceExistName": true
+      },
+      "namedNewAllocation": {
+        "name": "alice_travel_allocation",
         "replaceExistName": true
       }
     }
   },
   "env": {
-    "account": "alice_v1",
+    "account": "alice",
     "network": "testnet"
   }
 }
 ```
 
-> **Note**: This creates an Order, Progress, and Allocation. Save the returned object IDs for the next steps.
+> **Note**: The `total_pay.balance` of `500000000` equals 0.5 WOW (1 WOW = 10^9 base units). The customer account must have sufficient balance. The operation creates three named objects: Order, Progress, and Allocation.
+
+---
+
+## Step 7: Progress Operations (Order Workflow)
 
-### 8.2 Advance Progress: Initial -> Start
+The service provider advances the Progress through the workflow nodes. Each operation moves the Progress from the current node to the next node via a specified forward.
 
-First, advance the progress from initial state to Start node.
+> **Important**: Add `"no_cache": true` to the `env` field for all Progress operations to avoid stale cache issues.
 
-**Prompt**: Advance progress to Start node.
+### 7.1 Progress to Buy Insurance
+
+Move from initial node ("") to "Buy Insurance" node.
+
+**Prompt**: Operate progress to move to Buy Insurance node.
 
 ```json
 {
   "operation_type": "progress",
   "data": {
-    "object": "<travel_progress_id>",
+    "object": "alice_travel_progress",
     "operate": {
       "operation": {
-        "next_node_name": "Start",
+        "next_node_name": "Buy Insurance",
         "forward": "buy_insurance"
       }
     }
   },
   "env": {
-    "account": "travel_provider_v1",
-    "network": "testnet"
+    "account": "travel_provider",
+    "network": "testnet",
+    "no_cache": true
   }
 }
 ```
 
-### 8.3 Advance Progress: Start -> Buy Insurance
+### 7.2 Progress to SPA
+
+Move from "Buy Insurance" to "SPA" node.
 
-**Prompt**: Advance progress from Start to Buy Insurance.
+**Prompt**: Operate progress to move to SPA node.
 
 ```json
 {
   "operation_type": "progress",
   "data": {
-    "object": "<travel_progress_id>",
+    "object": "alice_travel_progress",
     "operate": {
       "operation": {
-        "next_node_name": "Buy Insurance",
-        "forward": "buy_insurance"
+        "next_node_name": "SPA",
+        "forward": "go_spa"
       }
     }
   },
   "env": {
-    "account": "travel_provider_v1",
-    "network": "testnet"
+    "account": "travel_provider",
+    "network": "testnet",
+    "no_cache": true
   }
 }
 ```
 
-### 8.4 Advance Progress: Buy Insurance -> SPA
+### 7.3 Progress to Ice Scooting (with Weather Guard Submission)
 
-**Prompt**: Advance progress from Buy Insurance to SPA.
+Move from "SPA" to "Ice Scooting" node. This forward has a Guard (`weather_check_guard`) that verifies weather data exists in the repository for the activity date. You must submit the activity date timestamp (one of the sunny-day timestamps from Step 0.1) at runtime.
+
+**Prompt**: Operate progress to move to Ice Scooting node with weather Guard submission.
 
 ```json
 {
   "operation_type": "progress",
   "data": {
-    "object": "<travel_progress_id>",
+    "object": "alice_travel_progress",
     "operate": {
       "operation": {
-        "next_node_name": "SPA",
+        "next_node_name": "Ice Scooting",
         "forward": "go_ice_scooting"
       }
     }
   },
+  "submission": {
+    "type": "submission",
+    "guard": [
+      {
+        "object": "weather_check_guard",
+        "impack": true
+      }
+    ],
+    "submission": [
+      {
+        "guard": "weather_check_guard",
+        "submission": [
+          {
+            "identifier": 2,
+            "b_submission": true,
+            "value_type": "U64",
+            "value": <ACTIVITY_DATE_TIMESTAMP>,
+            "name": "Activity date timestamp"
+          }
+        ]
+      }
+    ]
+  },
   "env": {
-    "account": "travel_provider_v1",
-    "network": "testnet"
+    "account": "travel_provider",
+    "network": "testnet",
+    "no_cache": true
   }
 }
 ```
 
-### 8.5 Advance Progress: SPA -> Ice Scooting
+> **Note**: Replace `<ACTIVITY_DATE_TIMESTAMP>` with one of the sunny-day timestamps from Step 0.1 (e.g., `1783555200000` for Day 1). The timestamp **must exactly match** the `id` used when adding weather data to the repository in Step 0.4 — Repository data is keyed by timestamp, and the Guard queries `repository.data has("Condition", convert_number_address(activity_date))`.
+>
+> **Key**: Only `identifier: 2` (the activity date) is submitted at runtime. Identifiers 0 (weather_repo) and 1 ("Condition") are fixed in the Guard table and do not need to be submitted. The `submission` field is at the **top level** of the input (alongside `data` and `env`), NOT inside `data`.
+
+### 7.4 Complete Trip (with Guard Submission)
 
-**Prompt**: Advance progress from SPA to Ice Scooting.
+Move from "Ice Scooting" to "Complete" node. This forward has a Guard (`travel_complete_guard`) that requires the Order ID to be submitted for time-lock verification.
+
+**Prompt**: Operate progress to complete the trip with Guard submission.
 
 ```json
 {
   "operation_type": "progress",
   "data": {
-    "object": "<travel_progress_id>",
+    "object": "alice_travel_progress",
     "operate": {
       "operation": {
-        "next_node_name": "Ice Scooting",
-        "forward": "go_ice_scooting"
+        "next_node_name": "Complete",
+        "forward": "complete_trip"
       }
     }
   },
+  "submission": {
+    "type": "submission",
+    "guard": [
+      {
+        "object": "travel_complete_guard",
+        "impack": true
+      }
+    ],
+    "submission": [
+      {
+        "guard": "travel_complete_guard",
+        "submission": [
+          {
+            "identifier": 0,
+            "b_submission": true,
+            "value_type": "Address",
+            "value": "<ORDER_OBJECT_ID>",
+            "name": "Order ID"
+          }
+        ]
+      }
+    ]
+  },
   "env": {
-    "account": "travel_provider_v1",
-    "network": "testnet"
+    "account": "travel_provider",
+    "network": "testnet",
+    "no_cache": true
   }
 }
 ```
 
-### 8.6 Advance Progress: Ice Scooting -> Complete (Time-Lock)
+> **Note**: Replace `<ORDER_OBJECT_ID>` with the actual Order object ID (e.g., `0x7cc9f2228e130c2f6b585bb9c4666fd4d03252d38048355678f46e31b682eb38`). You can query the Progress object to find the `task` field which contains the Order ID.
+>
+> **Key**: The `submission` field is at the **top level** of the input (alongside `data` and `env`), NOT inside `data`. The `impack: true` means the Guard verification result affects the final outcome.
 
-Wait at least 1 second after the last progress update, then advance to Complete with the Order ID as submission.
+### 7.5 Cancel Trip (Alternative Path)
 
-**Prompt**: Advance progress to Complete, submitting the Order ID. Wait 1 second before executing.
+> **Note**: This is an **alternative** to Step 7.4. Once the trip is Completed, it cannot be Cancelled (and vice versa). Use this path only if cancelling from the "Ice Scooting" node.
+
+**Prompt**: Operate progress to cancel the trip with Guard submission.
 
 ```json
 {
   "operation_type": "progress",
   "data": {
-    "object": "<travel_progress_id>",
+    "object": "alice_travel_progress",
     "operate": {
       "operation": {
-        "next_node_name": "Complete",
-        "forward": "complete_trip"
+        "next_node_name": "Cancel",
+        "forward": "cancel_trip"
       }
     }
   },
+  "submission": {
+    "type": "submission",
+    "guard": [
+      {
+        "object": "travel_cancel_guard",
+        "impack": true
+      }
+    ],
+    "submission": [
+      {
+        "guard": "travel_cancel_guard",
+        "submission": []
+      }
+    ]
+  },
   "env": {
-    "account": "travel_provider_v1",
-    "network": "testnet"
+    "account": "travel_provider",
+    "network": "testnet",
+    "no_cache": true
+  }
+}
+```
+
+> **Note**: The `travel_cancel_guard` always passes (returns true), so no submission data is needed. The empty `submission: []` is sufficient.
+
+**Progress Operation Structure**:
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `data.object` | string | Progress object name/ID |
+| `data.operate.operation.next_node_name` | string | Target node name to move to |
+| `data.operate.operation.forward` | string | Forward name defined in Machine |
+| `submission` | object | Guard verification data (top-level, required when forward has Guard) |
+| `env.no_cache` | boolean | Set to `true` to avoid stale cache issues |
+
+---
+
+## Step 8: Execute Fund Allocation
+
+After the Progress reaches a terminal state (Complete or Cancel), execute the fund allocation. This operation verifies the allocation Guard and distributes funds according to the `order_allocators` configured in Step 5.
+
+**Anyone can call this operation** — the caller does not need to be the merchant or the customer. The Guard verification determines which allocator's sharing rules apply, and funds are distributed to the recipients defined in those rules.
+
+### 8.1 Query the Order ID
+
+The allocation Guard requires the Order ID as a submission (identifier: 0). Query the Progress object to find the `task` field, which contains the Order ID.
+
+**Prompt**: Query the Progress object to get the Order ID.
+
+```json
+{
+  "operation_type": "progress",
+  "data": {
+    "object": "alice_travel_progress"
+  },
+  "env": {
+    "network": "testnet",
+    "no_cache": true
+  }
+}
+```
+
+> **Note**: The response includes a `task` field containing the Order object ID. Copy this value for the allocation submission.
+
+### 8.2 Execute Allocation (Merchant Victory Path)
+
+When the Progress is "Complete", the `merchant_victory_guard` passes, and 100% of funds go to the Service object.
+
+**Prompt**: Execute fund allocation with the merchant_victory_guard, submitting the Order ID.
+
+```json
+{
+  "operation_type": "allocation",
+  "data": {
+    "object": "alice_travel_allocation",
+    "alloc_by_guard": "merchant_victory_guard"
   },
   "submission": {
     "type": "submission",
     "guard": [
       {
-        "object": "travel_complete_guard_v1",
+        "object": "merchant_victory_guard",
         "impack": true
       }
     ],
     "submission": [
       {
-        "guard": "travel_complete_guard_v1",
+        "guard": "merchant_victory_guard",
         "submission": [
           {
             "identifier": 0,
             "b_submission": true,
             "value_type": "Address",
-            "value": "<travel_order_id>"
+            "value": "<ORDER_OBJECT_ID>",
+            "name": "Order ID"
           }
         ]
       }
     ]
+  },
+  "env": {
+    "account": "travel_provider",
+    "network": "testnet",
+    "no_cache": true
   }
 }
 ```
 
-> **Note**: Replace `<travel_progress_id>` and `<travel_order_id>` with actual values from step 8.1.
+> **Note**: Replace `<ORDER_OBJECT_ID>` with the actual Order object ID from Step 8.1.
+>
+> **Two-phase submission**: If the first call returns a submission prompt (without executing), re-call with the `submission` field populated as shown above.
 
----
+### 8.3 Execute Allocation (Refund Paths)
 
-## Step 9: Test Weather Check Guard (Optional)
+For refund scenarios (Cancel or SPA), use the corresponding Guard. The same submission structure applies — the Order ID is submitted to identifier 0.
 
-Test the weather check Guard independently to verify weather data is correctly stored.
+**Cancel/Ice Scooting path** (80% Service, 20% Order):
 
-**Prompt**: Test "weather_check_guard" with a sunny day timestamp.
+```json
+{
+  "operation_type": "allocation",
+  "data": {
+    "object": "alice_travel_allocation",
+    "alloc_by_guard": "no_ice_scooting_guard"
+  },
+  "submission": {
+    "type": "submission",
+    "guard": [{"object": "no_ice_scooting_guard", "impack": true}],
+    "submission": [{
+      "guard": "no_ice_scooting_guard",
+      "submission": [{"identifier": 0, "b_submission": true, "value_type": "Address", "value": "<ORDER_OBJECT_ID>", "name": "Order ID"}]
+    }]
+  },
+  "env": {"account": "travel_provider", "network": "testnet", "no_cache": true}
+}
+```
+
+**SPA path** (5% Service, 95% Order):
 
 ```json
 {
-  "operation_type": "gen_passport",
+  "operation_type": "allocation",
   "data": {
-    "guard": "weather_check_guard",
-    "info": {
-      "type": "submission",
-      "guard": [
-        {
-          "object": "weather_check_guard",
-          "impack": true
-        }
-      ],
-      "submission": [
-        {
-          "guard": "weather_check_guard",
-          "submission": [
-            {
-              "identifier": 2,
-              "b_submission": true,
-              "value_type": "U64",
-              "value": 1745884800000
-            }
-          ]
-        }
-      ]
-    }
+    "object": "alice_travel_allocation",
+    "alloc_by_guard": "no_spa_guard"
   },
-  "env": {
-    "account": "travel_provider_v1",
-    "network": "testnet"
-  }
+  "submission": {
+    "type": "submission",
+    "guard": [{"object": "no_spa_guard", "impack": true}],
+    "submission": [{
+      "guard": "no_spa_guard",
+      "submission": [{"identifier": 0, "b_submission": true, "value_type": "Address", "value": "<ORDER_OBJECT_ID>", "name": "Order ID"}]
+    }]
+  },
+  "env": {"account": "travel_provider", "network": "testnet", "no_cache": true}
 }
 ```
 
-> **Note**: Replace the timestamp with one of the sunny day timestamps from step 0.1 (DAY1-DAY4). This should pass.
+### 8.4 Verify Allocation Result
 
-Test with a rainy day to verify rejection:
+After allocation, query the Allocation and Payment objects to verify the fund distribution.
 
-**Prompt**: Test "weather_check_guard" with a rainy day timestamp.
+**Prompt**: Query the Allocation object to verify the balance and payment records.
 
 ```json
 {
-  "operation_type": "gen_passport",
+  "operation_type": "allocation",
   "data": {
-    "guard": "weather_check_guard",
-    "info": {
-      "type": "submission",
-      "guard": [
-        {
-          "object": "weather_check_guard",
-          "impack": true
-        }
-      ],
-      "submission": [
-        {
-          "guard": "weather_check_guard",
-          "submission": [
-            {
-              "identifier": 2,
-              "b_submission": true,
-              "value_type": "U64",
-              "value": 1746230400000
-            }
-          ]
-        }
-      ]
-    }
+    "object": "alice_travel_allocation"
   },
   "env": {
-    "account": "travel_provider_v1",
-    "network": "testnet"
+    "network": "testnet",
+    "no_cache": true
   }
 }
 ```
 
-> **Note**: Replace the timestamp with the rainy day timestamp (DAY5). This should fail because the weather is "rainy", not "sunny".
+> **Expected result**: The Allocation `balance` should be 0 (all funds distributed), and the `payment` array should contain the Payment object ID(s) created by the allocation.
 
----
+**Allocation Operation Structure**:
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `data.object` | string | Allocation object name/ID |
+| `data.alloc_by_guard` | string | Guard name/ID to verify (determines which allocator's rules apply) |
+| `submission` | object | Guard submission data (Order ID at identifier 0) |
+| `env.no_cache` | boolean | Set to `true` to avoid stale cache issues |
 
-## Execution Checklist
-
-- [ ] Create `travel_provider`, `weather_provider`, `alice` accounts
-- [ ] Get test tokens for all accounts
-- [ ] Step 0.1: Calculate weather timestamps
-- [ ] Step 0.2: Create `weather_repo` Repository
-- [ ] Step 0.3: Add "Condition" policy to repository
-- [ ] Step 0.4: Add weather data (5 days)
-- [ ] Step 1: Create `travel_permission`
-- [ ] Step 2: Create `travel_arbitration`
-- [ ] Step 3.1: Create `weather_check_guard` (update weather_repo address)
-- [ ] Step 3.2: Create `travel_complete_guard`
-- [ ] Step 3.3: Create `travel_cancel_guard`
-- [ ] Step 4: Create `travel_machine` (with nodes including Complete/Cancel, published)
-- [ ] Step 5: Create and publish `travel_service` (with machine, arbitration, sales, order_allocators)
-- [ ] Step 6: Unpause Service
-- [ ] Step 7: Verify Service configuration
-- [ ] Step 8.1: Create test travel order (as alice)
-- [ ] Step 8.2: Advance Initial -> Start
-- [ ] Step 8.3: Advance Start -> Buy Insurance
-- [ ] Step 8.4: Advance Buy Insurance -> SPA
-- [ ] Step 8.5: Advance SPA -> Ice Scooting
-- [ ] Step 8.6: Wait 1s, advance Ice Scooting -> Complete
-- [ ] Step 9: Test weather check Guard (sunny passes, rainy fails)
+> **Important**: `alloc_by_guard` accepts Guard names (e.g., `"merchant_victory_guard"`) or Guard object IDs. The Guard must exist in the Allocation's `allocators` list. Only the first Guard that passes (first-Guard-wins) triggers fund distribution.
 
 ---
 
 ## Best Practices
 
-### 1. Machine Node Configuration
+### 1. Guard Root Format
 
-Ensure at least one node has a pair with `prev_node: ""` (empty string). This defines the entry point from the initial state where Progress starts with `current: ""`.
+Guards use a direct GuardNode as the `root` field — no wrapper needed:
+```json
+"root": {
+  "type": "logic_equal",
+  "nodes": [...]
+}
+```
 
-### 2. Service Publish Requires order_allocators
+### 2. Machine Node Structure
 
-Always include the `order_allocators` field when publishing a Service. This defines how order revenue is distributed.
+Each node's `pairs` define how to **enter** that node. The `prev_node` specifies the source, and `forwards` are the operations to advance:
+```json
+{
+  "name": "TargetNode",
+  "pairs": [{
+    "prev_node": "SourceNode",
+    "threshold": 1,
+    "forwards": [{"name": "forward_name", "weight": 1, "permissionIndex": 1000}]
+  }]
+}
+```
 
-### 3. Progress Operation Format
+- Use `prev_node` (not `prior_node`)
+- `threshold` is required for every pair
+- Consolidate forwards with the same `prev_node` into one pair
 
-Use the `operate` field with `operation` object containing `next_node_name` and `forward`, not the `task` field.
+### 3. Machine Publish Before Service
 
-### 4. Repository Data Policy
+The Machine must be published (`"publish": true`) before binding it to a Service. Unpublished Machines cannot be referenced by Services.
 
-When creating a Repository, include policies in the initial `policies` field instead of adding them later (this avoids "Invalid policy name" errors).
+### 4. Service Creation in One Step
 
-### 5. Submission Format
+Create the Service with all configurations — including `pause: false` and `publish: true` — in a single operation:
+```json
+{
+  "pause": false,
+  "publish": true,
+  "order_allocators": {...},
+  "sales": {...},
+  "machine": "...",
+  "arbitrations": {...}
+}
+```
 
-Ensure submission items include `b_submission: true` for values submitted at runtime during progress advancement.
+### 5. Guard Submission for Progress
 
----
+When a forward has a Guard, the Progress operation requires a `submission` field at the **top level** (not inside `data`):
+```json
+{
+  "operation_type": "progress",
+  "data": {...},
+  "submission": {
+    "type": "submission",
+    "guard": [{"object": "guard_name", "impack": true}],
+    "submission": [{
+      "guard": "guard_name",
+      "submission": [{"identifier": 0, "b_submission": true, "value_type": "Address", "value": "0x...", "name": "Order ID"}]
+    }]
+  },
+  "env": {"no_cache": true, ...}
+}
+```
+
+### 6. Cache Management
+
+Add `"no_cache": true` to the `env` field for all Progress operations and queries after mutations to avoid stale cache issues.
 
-## See Also
+### 7. Weather Data Timestamps
 
-- [Insurance Example](../Insurance/Insurance.md) - The insurance service used as sub-order
-- [WOWOK Documentation](../../skills/WOWOK.md) - Core WoWok protocol documentation
+Weather data in the Repository is keyed by timestamp (`id`). The `weather_check_guard` queries `repository.data has("Condition", convert_number_address(activity_date))` — the `activity_date` submitted at runtime in Step 7.3 **must exactly match** the `id` used when adding data in Step 0.4.
+
+- Always align timestamps to UTC 00:00:00 (`Math.floor(now / DAY_MS) * DAY_MS`) so they are reproducible.
+- Re-run `calc-weather-timestamps.js` at test time — the values depend on the current date.
+- The Guard only checks data **existence**, not the condition value. A "rainy" day will still pass. To reject by condition value, use a Guard querying `repository.data` with a value comparison.
+
+### 8. Order Placement
+
+Customers place orders using the `order_new` field in the Service operation. This automatically creates Order, Progress, and Allocation objects:
+```json
+{
+  "operation_type": "service",
+  "data": {
+    "object": "service_name",
+    "order_new": {
+      "buy": {
+        "items": [{"name": "Product", "stock": "1", "wip_hash": ""}],
+        "total_pay": {"balance": "price_amount"}
+      },
+      "namedNewOrder": {"name": "order_name", "replaceExistName": true},
+      "namedNewProgress": {"name": "progress_name", "replaceExistName": true},
+      "namedNewAllocation": {"name": "allocation_name", "replaceExistName": true}
+    }
+  },
+  "env": {"account": "customer", "network": "testnet"}
+}
+```