@wowok/agent-mcp 3.1.3 → 3.1.4

package/dist/schemas/query_toolkit.output.json

@@ -1024,12 +1024,14 @@
                                                 }
                                               },
                                               "check_all_founded": {
-                                                "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                                                "default": true,
+                                                "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                                                 "type": "boolean"
                                               }
                                             },
                                             "required": [
-                                              "entities"
+                                              "entities",
+                                              "check_all_founded"
                                             ],
                                             "additionalProperties": false,
                                             "description": "Used to batch find account or object IDs by name"
@@ -1445,11 +1447,11 @@
                                     "type": "string"
                                   }
                                 ],
-                                "description": "Current funds held in the Treasury pool (treasury.move balance: Balance<T>), denominated in the Treasury's token T."
+                                "description": "Current funds held in the Treasury pool (balance: Balance<T>), denominated in the Treasury's token T."
                               },
                               "history_count": {
                                 "type": "number",
-                                "description": "Number of transaction records in the Treasury's history (treasury.move history: ParentTable<address, Record> — one entry per payment). Displayed as the 'Transactions' count. Use 'query_table' or 'query_table_item' to list individual TreasuryRecord items."
+                                "description": "Number of transaction records in the Treasury's history (history: ParentTable<address, Record> — one entry per payment). Displayed as the 'Transactions' count. Use 'query_table' or 'query_table_item' to list individual TreasuryRecord items."
                               },
                               "external_deposit_guard": {
                                 "type": "array",
@@ -2582,7 +2584,7 @@
                                                         "description": "Current transaction signer (tx_context::sender) at the time of the alloc() call. For refunds, the Order owner must call alloc_by_guard themselves to receive the funds."
                                                       }
                                                     ],
-                                                    "description": "Recipient of this allocation. Three forms — each resolves the address at a DIFFERENT time:\n• { GuardIdentifier: u8 } — DYNAMIC address resolved from Passport at alloc() time (contract calls passport::submission_get). Use 0 for Order owner in Service-integrated mode (Customer who created the Order). The identifier must match a Guard table entry with b_submission=true. If Passport has no matching submission, contract aborts with E_VERIFY_FAILED. Use when the recipient address is not known at config time and must be supplied via Guard submission data.\n• { Entity: { name_or_address: '...' } } — FIXED address resolved via LocalMark at SDK build time (passed to contract as a literal address). Use for known recipients (e.g., 'turo_host', or a Treasury object address). Use when the recipient is a stable, known address (e.g., operator receives rent, platform fee to treasury).\n• 'Signer' — the transaction sender at the time of the alloc() call (tx_context::sender). RESOLVED AT EXECUTION TIME, not at config time. For refunds: the customer (Order owner) must call alloc_by_guard THEMSELVES so that tx_context::sender resolves to THEIR address — if the operator calls alloc_by_guard, the operator becomes the recipient (Signer = operator), NOT the customer. Use when the recipient is whoever submits the allocation transaction (e.g., customer receives refund)."
+                                                    "description": "Recipient of this allocation. Three forms — each resolves the address at a DIFFERENT time:\n• { GuardIdentifier: u8 } — DYNAMIC address resolved from Passport at alloc() time (from the passport's submission record). Use 0 for Order owner in Service-integrated mode (Customer who created the Order). The identifier must match a Guard table entry with b_submission=true. If Passport has no matching submission, contract aborts with E_VERIFY_FAILED. Use when the recipient address is not known at config time and must be supplied via Guard submission data.\n• { Entity: { name_or_address: '...' } } — FIXED address resolved via LocalMark at SDK build time (passed to contract as a literal address). Use for known recipients (e.g., 'turo_host', or a Treasury object address). Use when the recipient is a stable, known address (e.g., operator receives rent, platform fee to treasury).\n• 'Signer' — the transaction sender at the time of the alloc() call (tx_context::sender). RESOLVED AT EXECUTION TIME, not at config time. For refunds: the customer (Order owner) must call alloc_by_guard THEMSELVES so that tx_context::sender resolves to THEIR address — if the operator calls alloc_by_guard, the operator becomes the recipient (Signer = operator), NOT the customer. Use when the recipient is whoever submits the allocation transaction (e.g., customer receives refund)."
                                                   },
                                                   "sharing": {
                                                     "anyOf": [
@@ -2621,7 +2623,7 @@
                                               "description": "Fund allocation item list. Each item specifies a recipient (who), a value (sharing), and a mode. Items can mix modes (Amount + Rate + Surplus) within the same Allocator. RECIPIENT SEMANTICS: the Guard constrains what each submission slot may be; a recipient's safety follows from the sufficiency of those constraints (run the recipient constraint audit). Canonical order pattern: recipient = the single submitted Order — funds land at that object and are receivable only by its owner. ALLOCATION ORDER: Amount items first (cached as fix) → Rate items (proportional to balance - fix) → Surplus item (remaining). CONSTRAINTS: max ONE Surplus item per Allocator; Rate sum must == 10000 (no Surplus) or <= 10000 (with Surplus); Amount sum must >= threshold (no Rate and no Surplus) and <= max (if max set)."
                                             },
                                             "fix": {
-                                              "description": "OUTPUT-ONLY (query result). Cached sum of all Amount-mode `sharing` values in this Allocator. Computed by the contract during `allocator_add` — DO NOT set this field at creation. Used internally to compute `total_rates = balance - fix` for Rate allocation.",
+                                              "description": "OUTPUT-ONLY (query result). Cached sum of all Amount-mode `sharing` values in this Allocator. Computed by the contract when the allocator is added — DO NOT set this field at creation. Used internally to compute `total_rates = balance - fix` for Rate allocation.",
                                               "anyOf": [
                                                 {
                                                   "type": "number"
@@ -2632,7 +2634,7 @@
                                               ]
                                             },
                                             "max": {
-                                              "description": "Maximum allocation cap (OPTIONAL — omit the field or set to null to disable the cap; do NOT set to 0 as that means a cap of zero). Passed through to the contract as Option<u64> via allocator_add(): when null/omitted the contract treats it as `none` (no cap); when set, the contract enforces it. Has THREE effects when set:\n1. Construction: sum of Amount items must be <= max (EAMOUNT_EXCEEDS_MAX=13)\n2. Rate execution: total_rates = max - fix (instead of balance - fix)\n3. Surplus execution: surplus_amount = max - alloced_amount (instead of balance - alloced_amount)\nUse when you want to cap total allocation regardless of Order balance (e.g., cap payout to declared amount). SDK pre-validates Amount sum <= max at build time to give actionable error messages before on-chain abort.",
+                                              "description": "Maximum allocation cap (OPTIONAL — omit the field or set to null to disable the cap; do NOT set to 0 as that means a cap of zero). Passed through to the contract as Option<u64> when the allocator is added: when null/omitted the contract treats it as `none` (no cap); when set, the contract enforces it. Has THREE effects when set:\n1. Construction: sum of Amount items must be <= max (EAMOUNT_EXCEEDS_MAX=13)\n2. Rate execution: total_rates = max - fix (instead of balance - fix)\n3. Surplus execution: surplus_amount = max - alloced_amount (instead of balance - alloced_amount)\nUse when you want to cap total allocation regardless of Order balance (e.g., cap payout to declared amount). SDK pre-validates Amount sum <= max at build time to give actionable error messages before on-chain abort.",
                                               "anyOf": [
                                                 {
                                                   "anyOf": [
@@ -2643,7 +2645,7 @@
                                                       "type": "string"
                                                     }
                                                   ],
-                                                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                                                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: service sale prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."
                                                 },
                                                 {
                                                   "type": "null"
@@ -3784,12 +3786,14 @@
                                                                   }
                                                                 },
                                                                 "check_all_founded": {
-                                                                  "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                                                                  "default": true,
+                                                                  "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                                                                   "type": "boolean"
                                                                 }
                                                               },
                                                               "required": [
-                                                                "entities"
+                                                                "entities",
+                                                                "check_all_founded"
                                                               ],
                                                               "additionalProperties": false,
                                                               "description": "Used to batch find account or object IDs by name"
@@ -4854,7 +4858,7 @@
                                                 "description": "Current transaction signer (tx_context::sender) at the time of the alloc() call. For refunds, the Order owner must call alloc_by_guard themselves to receive the funds."
                                               }
                                             ],
-                                            "description": "Recipient of this allocation. Three forms — each resolves the address at a DIFFERENT time:\n• { GuardIdentifier: u8 } — DYNAMIC address resolved from Passport at alloc() time (contract calls passport::submission_get). Use 0 for Order owner in Service-integrated mode (Customer who created the Order). The identifier must match a Guard table entry with b_submission=true. If Passport has no matching submission, contract aborts with E_VERIFY_FAILED. Use when the recipient address is not known at config time and must be supplied via Guard submission data.\n• { Entity: { name_or_address: '...' } } — FIXED address resolved via LocalMark at SDK build time (passed to contract as a literal address). Use for known recipients (e.g., 'turo_host', or a Treasury object address). Use when the recipient is a stable, known address (e.g., operator receives rent, platform fee to treasury).\n• 'Signer' — the transaction sender at the time of the alloc() call (tx_context::sender). RESOLVED AT EXECUTION TIME, not at config time. For refunds: the customer (Order owner) must call alloc_by_guard THEMSELVES so that tx_context::sender resolves to THEIR address — if the operator calls alloc_by_guard, the operator becomes the recipient (Signer = operator), NOT the customer. Use when the recipient is whoever submits the allocation transaction (e.g., customer receives refund)."
+                                            "description": "Recipient of this allocation. Three forms — each resolves the address at a DIFFERENT time:\n• { GuardIdentifier: u8 } — DYNAMIC address resolved from Passport at alloc() time (from the passport's submission record). Use 0 for Order owner in Service-integrated mode (Customer who created the Order). The identifier must match a Guard table entry with b_submission=true. If Passport has no matching submission, contract aborts with E_VERIFY_FAILED. Use when the recipient address is not known at config time and must be supplied via Guard submission data.\n• { Entity: { name_or_address: '...' } } — FIXED address resolved via LocalMark at SDK build time (passed to contract as a literal address). Use for known recipients (e.g., 'turo_host', or a Treasury object address). Use when the recipient is a stable, known address (e.g., operator receives rent, platform fee to treasury).\n• 'Signer' — the transaction sender at the time of the alloc() call (tx_context::sender). RESOLVED AT EXECUTION TIME, not at config time. For refunds: the customer (Order owner) must call alloc_by_guard THEMSELVES so that tx_context::sender resolves to THEIR address — if the operator calls alloc_by_guard, the operator becomes the recipient (Signer = operator), NOT the customer. Use when the recipient is whoever submits the allocation transaction (e.g., customer receives refund)."
                                           },
                                           "sharing": {
                                             "anyOf": [
@@ -4893,7 +4897,7 @@
                                       "description": "Fund allocation item list. Each item specifies a recipient (who), a value (sharing), and a mode. Items can mix modes (Amount + Rate + Surplus) within the same Allocator. RECIPIENT SEMANTICS: the Guard constrains what each submission slot may be; a recipient's safety follows from the sufficiency of those constraints (run the recipient constraint audit). Canonical order pattern: recipient = the single submitted Order — funds land at that object and are receivable only by its owner. ALLOCATION ORDER: Amount items first (cached as fix) → Rate items (proportional to balance - fix) → Surplus item (remaining). CONSTRAINTS: max ONE Surplus item per Allocator; Rate sum must == 10000 (no Surplus) or <= 10000 (with Surplus); Amount sum must >= threshold (no Rate and no Surplus) and <= max (if max set)."
                                     },
                                     "fix": {
-                                      "description": "OUTPUT-ONLY (query result). Cached sum of all Amount-mode `sharing` values in this Allocator. Computed by the contract during `allocator_add` — DO NOT set this field at creation. Used internally to compute `total_rates = balance - fix` for Rate allocation.",
+                                      "description": "OUTPUT-ONLY (query result). Cached sum of all Amount-mode `sharing` values in this Allocator. Computed by the contract when the allocator is added — DO NOT set this field at creation. Used internally to compute `total_rates = balance - fix` for Rate allocation.",
                                       "anyOf": [
                                         {
                                           "type": "number"
@@ -4904,7 +4908,7 @@
                                       ]
                                     },
                                     "max": {
-                                      "description": "Maximum allocation cap (OPTIONAL — omit the field or set to null to disable the cap; do NOT set to 0 as that means a cap of zero). Passed through to the contract as Option<u64> via allocator_add(): when null/omitted the contract treats it as `none` (no cap); when set, the contract enforces it. Has THREE effects when set:\n1. Construction: sum of Amount items must be <= max (EAMOUNT_EXCEEDS_MAX=13)\n2. Rate execution: total_rates = max - fix (instead of balance - fix)\n3. Surplus execution: surplus_amount = max - alloced_amount (instead of balance - alloced_amount)\nUse when you want to cap total allocation regardless of Order balance (e.g., cap payout to declared amount). SDK pre-validates Amount sum <= max at build time to give actionable error messages before on-chain abort.",
+                                      "description": "Maximum allocation cap (OPTIONAL — omit the field or set to null to disable the cap; do NOT set to 0 as that means a cap of zero). Passed through to the contract as Option<u64> when the allocator is added: when null/omitted the contract treats it as `none` (no cap); when set, the contract enforces it. Has THREE effects when set:\n1. Construction: sum of Amount items must be <= max (EAMOUNT_EXCEEDS_MAX=13)\n2. Rate execution: total_rates = max - fix (instead of balance - fix)\n3. Surplus execution: surplus_amount = max - alloced_amount (instead of balance - alloced_amount)\nUse when you want to cap total allocation regardless of Order balance (e.g., cap payout to declared amount). SDK pre-validates Amount sum <= max at build time to give actionable error messages before on-chain abort.",
                                       "anyOf": [
                                         {
                                           "anyOf": [
@@ -4915,7 +4919,7 @@
                                               "type": "string"
                                             }
                                           ],
-                                          "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                                          "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: service sale prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."
                                         },
                                         {
                                           "type": "null"
@@ -5332,7 +5336,7 @@
                                                   "type": "string"
                                                 }
                                               ],
-                                              "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                                              "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: service sale prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."
                                             }
                                           },
                                           "required": [
@@ -5372,7 +5376,7 @@
                                   "additionalProperties": false,
                                   "description": "Reward Guard type"
                                 },
-                                "description": "Reward claim Guards (reward.move guards: vector<RewardGuard>). Count = number of claim paths: each Guard defines who may claim and how much, and a claim pays out when one of the Guards verifies successfully."
+                                "description": "Reward claim Guards (guards: vector<RewardGuard>). Count = number of claim paths: each Guard defines who may claim and how much, and a claim pays out when one of the Guards verifies successfully."
                               },
                               "balance": {
                                 "anyOf": [
@@ -5383,7 +5387,7 @@
                                     "type": "string"
                                   }
                                 ],
-                                "description": "Current claimable funds left in the Reward pool (reward.move balance: Balance<T>) — every payout is denominated in the Reward's token T. Also names the title amount badge on Reward cards ('N SYMBOL')."
+                                "description": "Current claimable funds left in the Reward pool (balance: Balance<T>) — every payout is denominated in the Reward's token T. Also names the title amount badge on Reward cards ('N SYMBOL')."
                               },
                               "guard_not_added_expiration_time": {
                                 "anyOf": [
@@ -5401,7 +5405,7 @@
                               },
                               "record_count": {
                                 "type": "number",
-                                "description": "Number of unique addresses that have claimed from this Reward (reward.move record: ParentTable<address, RecipientRecord> — one entry per claimer). Displayed as the 'Claimed by' count."
+                                "description": "Number of unique addresses that have claimed from this Reward (record: ParentTable<address, RecipientRecord> — one entry per claimer). Displayed as the 'Claimed by' count."
                               },
                               "um": {
                                 "anyOf": [
@@ -6676,12 +6680,14 @@
                                                   }
                                                 },
                                                 "check_all_founded": {
-                                                  "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                                                  "default": true,
+                                                  "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                                                   "type": "boolean"
                                                 }
                                               },
                                               "required": [
-                                                "entities"
+                                                "entities",
+                                                "check_all_founded"
                                               ],
                                               "additionalProperties": false,
                                               "description": "Used to batch find account or object IDs by name"
@@ -7117,7 +7123,7 @@
                                           "type": "string"
                                         }
                                       ],
-                                      "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                                      "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: service sale prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."
                                     }
                                   },
                                   "required": [
@@ -7847,12 +7853,14 @@
                                                           }
                                                         },
                                                         "check_all_founded": {
-                                                          "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                                                          "default": true,
+                                                          "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                                                           "type": "boolean"
                                                         }
                                                       },
                                                       "required": [
-                                                        "entities"
+                                                        "entities",
+                                                        "check_all_founded"
                                                       ],
                                                       "additionalProperties": false,
                                                       "description": "Used to batch find account or object IDs by name"
@@ -9259,7 +9267,7 @@
                                         "type": "string"
                                       }
                                     ],
-                                    "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                                    "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: service sale prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."
                                   },
                                   {
                                     "type": "null"
@@ -10200,12 +10208,14 @@
                                                       }
                                                     },
                                                     "check_all_founded": {
-                                                      "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                                                      "default": true,
+                                                      "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                                                       "type": "boolean"
                                                     }
                                                   },
                                                   "required": [
-                                                    "entities"
+                                                    "entities",
+                                                    "check_all_founded"
                                                   ],
                                                   "additionalProperties": false,
                                                   "description": "Used to batch find account or object IDs by name"
@@ -11620,12 +11630,14 @@
                                               }
                                             },
                                             "check_all_founded": {
-                                              "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                                              "default": true,
+                                              "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                                               "type": "boolean"
                                             }
                                           },
                                           "required": [
-                                            "entities"
+                                            "entities",
+                                            "check_all_founded"
                                           ],
                                           "additionalProperties": false,
                                           "description": "Used to batch find account or object IDs by name"
@@ -12607,12 +12619,14 @@
                                                 }
                                               },
                                               "check_all_founded": {
-                                                "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                                                "default": true,
+                                                "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                                                 "type": "boolean"
                                               }
                                             },
                                             "required": [
-                                              "entities"
+                                              "entities",
+                                              "check_all_founded"
                                             ],
                                             "additionalProperties": false,
                                             "description": "Used to batch find account or object IDs by name"
@@ -13252,7 +13266,7 @@
                             "type": "object",
                             "properties": {
                               "guard": {
-                                "description": "Guard that verified this claim (reward.move Record.guard)",
+                                "description": "Guard that verified this claim (Record.guard)",
                                 "anyOf": [
                                   {
                                     "type": "string"
@@ -14163,7 +14177,7 @@
                               },
                               "threshold": {
                                 "default": 0,
-                                "description": "Threshold to trigger node advancement. If total Forward weight is greater than or equal to threshold, node advancement is triggered. ⚠️ SINGLE-OPERATOR LOCK: each forward contributes its weight AT MOST ONCE (locked by its first operator — progress.move session_accomplish_imp; re-execution by others aborts E_NOT_THE_HOLDER). The maximum achievable weight of this Pair is the sum of its DISTINCT forward weights — if that sum < threshold the transition can NEVER migrate. Multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1), never one forward reused by several people.",
+                                "description": "Threshold to trigger node advancement. If total Forward weight is greater than or equal to threshold, node advancement is triggered. ⚠️ SINGLE-OPERATOR LOCK: each forward contributes its weight AT MOST ONCE (locked by its first operator; re-execution by others aborts E_NOT_THE_HOLDER). The maximum achievable weight of this Pair is the sum of its DISTINCT forward weights — if that sum < threshold the transition can NEVER migrate. Multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1), never one forward reused by several people.",
                                 "anyOf": [
                                   {
                                     "type": "number"
@@ -14194,7 +14208,7 @@
                                       ]
                                     },
                                     "permissionIndex": {
-                                      "description": "Forward operation permission 2: Permission index (one of the two must be specified); recommended if all Progress object operators are the same (e.g., same reward reviewers for all orders).",
+                                      "description": "Forward operation permission 2: Permission index (one of the two must be specified); recommended if all Progress object operators are the same (e.g., same reward reviewers for all orders). RANGE: use a USER_DEFINED index ≥1000 (0–999 are builtin/reserved) — a USER_DEFINED index works for the Permission's admin immediately without any grant; a builtin index (<1000) aborts with MoveAbort 7 unless it was explicitly granted to the operators first.",
                                       "anyOf": [
                                         {
                                           "type": "number"
@@ -14216,7 +14230,7 @@
                                           "type": "string"
                                         }
                                       ],
-                                      "description": "Forward weight — the contribution this forward makes toward its Pair's threshold. ⚠️ SINGLE-OPERATOR LOCK: a forward contributes its weight AT MOST ONCE. It is locked by the first operator that accomplishes it (progress.move session_accomplish_imp); a second operator re-executing the same accomplished forward aborts E_NOT_THE_HOLDER. Therefore multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1) — never reuse one forward."
+                                      "description": "Forward weight — the contribution this forward makes toward its Pair's threshold. ⚠️ SINGLE-OPERATOR LOCK: a forward contributes its weight AT MOST ONCE. It is locked by the first operator that accomplishes it; a second operator re-executing the same accomplished forward aborts E_NOT_THE_HOLDER. Therefore multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1) — never reuse one forward."
                                     },
                                     "guard": {
                                       "description": "Guard reference for this forward. Accepts TWO formats:\n• STRING (preferred): \"my_guard_name\" — the Guard's name or address as a plain string.\n• OBJECT (only when retained_submission is needed): {guard: \"my_guard_name\", retained_submission: [1,2,3]}.\nFOLLOW THE SCHEMA FIELD STRUCTURE: A Guard reference is fundamentally a STRING (the Guard object's name or address). Provide a string when you only need to reference a Guard — do NOT wrap a bare string in an object structure. The OBJECT form {guard: \"...\", retained_submission: [...]} exists ONLY to carry additional `retained_submission` data alongside the string reference; inside the object, the `guard` field is STILL a string. In short: string-in for a string reference, object-in only when you need to pass extra data.\nCOGNITIVE PRINCIPLE: Guard validation ALWAYS occurs BEFORE the forward operation. A Guard that queries state of the SAME Progress object this forward operates on (e.g. progress.current) will see the PRE-transition value (source node), NOT the target node. If the Guard checks progress.current == target_node, it will ALWAYS FAIL. Querying a DIFFERENT Progress object (cross-machine) is safe and reasonable — that progress is not modified by this forward. For target-node verification after transition, bind the Guard to the Allocator instead (allocation.alloc runs AFTER the state transition completes).\n⚠️ T1 LOSSY POINT (B-3): WoWok has NO on-chain cron. A business phrase like 'after N days, auto-X' is NOT an automatic trigger — it decomposes into (1) a time_guard that checks elapsed time, and (2) an OFF-CHAIN keeper that must submit the forward when the guard passes. Configuring a time_guard WITHOUT a keeper means nothing ever fires.\nRETAINED_SUBMISSION: a non-empty retained_submission does NOT relax Guard verification — the forward's Guard is always validated first. The list only selects which of the caller's already-verified submissions are persisted into the Progress history (see the guard field above).",
@@ -14231,7 +14245,7 @@
                                                   "description": "Guard object name or address (string). Example: 'my_attendance_guard' or '0x1234...'"
                                                 },
                                                 "retained_submission": {
-                                                  "description": "Guard table identifiers whose verified values are persisted into the Progress history when the forward is accomplished. The Guard is ALWAYS fully verified first (regardless of this list): the forward cannot complete unless the Passport carries a passing result for it. After verification, exactly the caller's submissions for the listed identifiers are copied into history (passport::submissions_get) as Guard-verified facts; empty array (default) records nothing. Use it for audit and downstream queries, never as a way to relax Guard conditions.",
+                                                  "description": "Guard table identifiers whose verified values are persisted into the Progress history when the forward is accomplished. The Guard is ALWAYS fully verified first (regardless of this list): the forward cannot complete unless the Passport carries a passing result for it. After verification, exactly the caller's submissions for the listed identifiers are copied into history (from the passport's submission records) as Guard-verified facts; empty array (default) records nothing. Use it for audit and downstream queries, never as a way to relax Guard conditions.",
                                                   "anyOf": [
                                                     {
                                                       "type": "array",
@@ -14962,12 +14976,14 @@
                                                             }
                                                           },
                                                           "check_all_founded": {
-                                                            "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                                                            "default": true,
+                                                            "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                                                             "type": "boolean"
                                                           }
                                                         },
                                                         "required": [
-                                                          "entities"
+                                                          "entities",
+                                                          "check_all_founded"
                                                         ],
                                                         "additionalProperties": false,
                                                         "description": "Used to batch find account or object IDs by name"
@@ -15400,7 +15416,7 @@
                               "type": "string"
                             }
                           ],
-                          "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                          "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: service sale prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."
                         },
                         "token_type": {
                           "type": "string",
@@ -15424,7 +15440,7 @@
                                     "type": "string"
                                   }
                                 ],
-                                "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                                "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: service sale prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."
                               },
                               "payment": {
                                 "type": "string",
@@ -16429,13 +16445,21 @@
                           "items": {
                             "type": "string"
                           }
+                        },
+                        "notices": {
+                          "type": "array",
+                          "items": {
+                            "type": "string"
+                          },
+                          "description": "Merchant-side availability reminders (paused / unpublished / no contact channel). These never affect riskLevel — a failed purchase costs gas at most, never escrowed funds."
                         }
                       },
                       "required": [
                         "riskLevel",
                         "keyRisks",
                         "protections",
-                        "missingProtections"
+                        "missingProtections",
+                        "notices"
                       ],
                       "additionalProperties": false
                     },
@@ -16644,7 +16668,7 @@
                                 },
                                 "reason": {
                                   "type": "string",
-                                  "description": "Chain-authoritative routing reason, including the wrong-route abort code (direct progress::next on a namedOperator='' forward aborts permission#5 'Permission denied') and the Guard passport requirement when the forward binds one."
+                                  "description": "Chain-authoritative routing reason, including the wrong-route abort code (direct Progress execution on a namedOperator='' forward aborts permission#5 'Permission denied') and the Guard passport requirement when the forward binds one."
                                 }
                               },
                               "required": [
@@ -16848,9 +16872,9 @@
                             "severity": {
                               "type": "string",
                               "enum": [
-                                "info",
-                                "warning",
-                                "critical"
+                                "critical",
+                                "high",
+                                "info"
                               ]
                             },
                             "title": {
@@ -17050,7 +17074,7 @@
                                 },
                                 "reason": {
                                   "type": "string",
-                                  "description": "Chain-authoritative routing reason, including the wrong-route abort code (direct progress::next on a namedOperator='' forward aborts permission#5 'Permission denied') and the Guard passport requirement when the forward binds one."
+                                  "description": "Chain-authoritative routing reason, including the wrong-route abort code (direct Progress execution on a namedOperator='' forward aborts permission#5 'Permission denied') and the Guard passport requirement when the forward binds one."
                                 }
                               },
                               "required": [
@@ -17254,9 +17278,9 @@
                             "severity": {
                               "type": "string",
                               "enum": [
-                                "info",
-                                "warning",
-                                "critical"
+                                "critical",
+                                "high",
+                                "info"
                               ]
                             },
                             "title": {
@@ -18429,10 +18453,6 @@
                         ],
                         "description": "Data-bound semantics: complete=full snapshot; bounded_exact=lossless bounded index; bounded_window=FIFO/ring <=5200 (counts are LOWER BOUNDS, see truncations); membership=current members only; derived=structurally produced; event_full=complete append-only event history (truncated flag when page budget hit); event_degraded=event source that can be inherently incomplete."
                       },
-                      "evidence": {
-                        "type": "string",
-                        "description": "Contract evidence anchor (move file + line range)."
-                      },
                       "key": {
                         "description": "Disambiguator for multi-edges of one schema between the same nodes (e.g. forward name).",
                         "type": "string"
@@ -18456,12 +18476,11 @@
                       "family",
                       "from",
                       "to",
-                      "retention",
-                      "evidence"
+                      "retention"
                     ],
                     "additionalProperties": false
                   },
-                  "description": "All deduped topology edges with retention + evidence."
+                  "description": "All deduped topology edges with retention semantics."
                 },
                 "workflows": {
                   "type": "array",
@@ -18556,7 +18575,7 @@
                                     },
                                     "reason": {
                                       "type": "string",
-                                      "description": "Chain-authoritative routing reason, including the wrong-route abort code (direct progress::next on a namedOperator='' forward aborts permission#5 'Permission denied') and the Guard passport requirement when the forward binds one."
+                                      "description": "Chain-authoritative routing reason, including the wrong-route abort code (direct Progress execution on a namedOperator='' forward aborts permission#5 'Permission denied') and the Guard passport requirement when the forward binds one."
                                     }
                                   },
                                   "required": [
@@ -18704,12 +18723,142 @@
                       },
                       "detail": {
                         "type": "string",
-                        "description": "Objective detail, facts only (English in code; localized by the output layer)."
+                        "description": "Objective detail, facts only (English in code; localized by the output layer). {key} placeholders reference the amounts entries and are already resolved to display text by the money annotation pass."
                       },
                       "suggestion": {
                         "type": "string",
                         "description": "Structural suggestion, never a score (English in code; localized by the output layer)."
                       },
+                      "amounts": {
+                        "description": "Structured money amounts this finding quantifies — raw smallest units plus the coin generic, so display conversion is never guessed.",
+                        "type": "array",
+                        "items": {
+                          "type": "object",
+                          "properties": {
+                            "key": {
+                              "type": "string",
+                              "description": "Placeholder key used in detail/suggestion ({key})."
+                            },
+                            "label": {
+                              "type": "string",
+                              "description": "Human label of the amount (e.g. 'Compensation fund')."
+                            },
+                            "raw": {
+                              "type": "string",
+                              "description": "Raw on-chain value in smallest units (always preserved)."
+                            },
+                            "coin_type": {
+                              "description": "Full token type tag (e.g. 0x2::wow::WOW); absent when the object's generic was not resolvable.",
+                              "type": "string"
+                            }
+                          },
+                          "required": [
+                            "key",
+                            "label",
+                            "raw"
+                          ],
+                          "additionalProperties": false
+                        }
+                      },
+                      "objects": {
+                        "description": "Full 0x addresses of every account/object this finding references (drill-through principle) — render each as an address chip so the user can open it and continue analysis; never abbreviated.",
+                        "type": "array",
+                        "items": {
+                          "type": "string"
+                        }
+                      },
+                      "exposure": {
+                        "description": "Loss/gain exposure attribution (loss-party/gain-path methodology): WHO bears the exposure, WHO could gain through which path, and whether that path survives on-chain semantics. When present, present the attribution next to the finding — never merge it into the prose detail.",
+                        "type": "object",
+                        "properties": {
+                          "lossParties": {
+                            "type": "array",
+                            "items": {
+                              "type": "object",
+                              "properties": {
+                                "role": {
+                                  "type": "string",
+                                  "description": "Commercial role bearing the loss (buyer/merchant/supplier/collaborator/arbitrator/system/neutral)."
+                                },
+                                "basis": {
+                                  "type": "string",
+                                  "description": "Why this party bears the loss — one sentence of fund-flow/object semantics (English in code; localized by the output layer)."
+                                }
+                              },
+                              "required": [
+                                "role",
+                                "basis"
+                              ],
+                              "additionalProperties": false
+                            },
+                            "description": "Parties that bear the exposure if the described path executes — empty only for evidence-bound notices."
+                          },
+                          "gainPaths": {
+                            "type": "array",
+                            "items": {
+                              "type": "object",
+                              "properties": {
+                                "role": {
+                                  "type": "string",
+                                  "description": "Commercial role that could gain."
+                                },
+                                "path": {
+                                  "type": "string",
+                                  "description": "The concrete path: which entry, who qualifies, where the funds land."
+                                },
+                                "viability": {
+                                  "type": "string",
+                                  "enum": [
+                                    "viable",
+                                    "conditional",
+                                    "blocked",
+                                    "unverifiable"
+                                  ],
+                                  "description": "On-chain viability of this path: viable = executable as described; conditional = executable under unconfirmed conditions; blocked = provably prevented by Move checks; unverifiable = deciding facts outside topology evidence."
+                                },
+                                "gate": {
+                                  "type": "string",
+                                  "description": "The fact that decides viability; for unverifiable paths, the disclosure duties the counterparty must satisfy."
+                                }
+                              },
+                              "required": [
+                                "role",
+                                "path",
+                                "viability",
+                                "gate"
+                              ],
+                              "additionalProperties": false
+                            },
+                            "description": "Candidate gain paths with their viability judgment — empty for shortfall/availability defects where nobody gains."
+                          },
+                          "verdict": {
+                            "type": "string",
+                            "enum": [
+                              "confirmed",
+                              "downgraded",
+                              "pending-disclosure"
+                            ],
+                            "description": "Gate verdict: confirmed = a viable/conditional path exists (severity stands); downgraded = every path provably blocked (severity auto-lowered to info, base severity in baseSeverity); pending-disclosure = undecided, severity stands plus disclosure duties."
+                          },
+                          "baseSeverity": {
+                            "description": "Pre-gate severity — present when verdict = downgraded.",
+                            "type": "string",
+                            "enum": [
+                              "info",
+                              "low",
+                              "medium",
+                              "high",
+                              "critical"
+                            ]
+                          }
+                        },
+                        "required": [
+                          "lossParties",
+                          "gainPaths",
+                          "verdict"
+                        ],
+                        "additionalProperties": false
+                      },
                       "interest": {
                         "description": "G2 role-interest view payload — present only on IR:<role> findings (stakes/actions/counterparties/risk reminders).",
                         "type": "object",
@@ -19083,7 +19232,7 @@
                               ],
                               "additionalProperties": false
                             },
-                            "description": "Counterparty game analysis — structural tension from the single ROLE_INTERESTS table."
+                            "description": "Counterparty game analysis — structural tension from the single role-interests table."
                           },
                           "risk_finding_ids": {
                             "type": "array",
@@ -19312,7 +19461,9 @@
                                 "type": "string",
                                 "enum": [
                                   "critical",
-                                  "warning",
+                                  "high",
+                                  "medium",
+                                  "low",
                                   "info"
                                 ]
                               },
@@ -19541,7 +19692,9 @@
                                 "type": "string",
                                 "enum": [
                                   "critical",
-                                  "warning",
+                                  "high",
+                                  "medium",
+                                  "low",
                                   "info"
                                 ]
                               },
@@ -20319,7 +20472,7 @@
                         ],
                         "additionalProperties": false
                       },
-                      "description": "Counterparty game analysis — structural tension from the single ROLE_INTERESTS table."
+                      "description": "Counterparty game analysis — structural tension from the single role-interests table."
                     },
                     "risk_finding_ids": {
                       "type": "array",
@@ -20398,6 +20551,131 @@
                   },
                   "description": "Fail-soft degradation notes — unreadable objects/tables and partial-data markers."
                 },
+                "exploration": {
+                  "description": "Exploration leads over this payload: undecided exposures (verification), window/budget boundaries (coverage) and fetch gaps — each as an open question with drill-through handles. Absent when no lead exists. Treat every lead as an open question for continued exploration, never as a settled conclusion.",
+                  "type": "object",
+                  "properties": {
+                    "open_questions": {
+                      "type": "array",
+                      "items": {
+                        "type": "object",
+                        "properties": {
+                          "id": {
+                            "type": "string",
+                            "description": "Stable lead id (X1..Xn) — synthesis per-role verdicts reference these ids for the questions they could not settle."
+                          },
+                          "kind": {
+                            "type": "string",
+                            "enum": [
+                              "verification",
+                              "data_gap",
+                              "coverage"
+                            ],
+                            "description": "verification = an exposure whose deciding facts sit outside this payload (disclosure duty attached); coverage = an evidence boundary the collection itself hit (window truncation / exhausted budget); data_gap = a fetch or degradation note."
+                          },
+                          "question": {
+                            "type": "string",
+                            "description": "The lead as a semantic proposition. It is an OPEN QUESTION, never a conclusion — keep it open until new evidence settles it, and never answer it from this payload alone."
+                          },
+                          "resolves_with": {
+                            "type": "array",
+                            "items": {
+                              "type": "string"
+                            },
+                            "description": "Drill-through handles: the object addresses whose evidence would settle the question (empty = resolving it is a posture change, e.g. raising a budget). Render each as an address chip."
+                          },
+                          "source": {
+                            "type": "string",
+                            "description": "Origin: the finding id carrying the undecided exposure, or 'truncation' / 'budget' / 'data_gap'."
+                          }
+                        },
+                        "required": [
+                          "id",
+                          "kind",
+                          "question",
+                          "resolves_with",
+                          "source"
+                        ],
+                        "additionalProperties": false
+                      },
+                      "description": "Exploration leads distilled from undecided exposures and evidence boundaries — the questions a curious user can pull next. Leads, not conclusions: they define what the current evidence does NOT settle."
+                    }
+                  },
+                  "required": [
+                    "open_questions"
+                  ],
+                  "additionalProperties": false
+                },
+                "synthesis": {
+                  "description": "Whole-exploration synthesis: one provisional verdict per commercial role exposed by the findings — max driver severity, interest-table posture, and the open questions that keep it from finalizing. Present per role with its open questions; never merge the verdicts into one terminal judgment.",
+                  "type": "object",
+                  "properties": {
+                    "per_role": {
+                      "type": "array",
+                      "items": {
+                        "type": "object",
+                        "properties": {
+                          "role": {
+                            "type": "string",
+                            "description": "Commercial role the verdict speaks for (buyer/merchant/supplier/collaborator/arbitrator/system/neutral); roles with no exposure driver are omitted."
+                          },
+                          "level": {
+                            "type": "string",
+                            "enum": [
+                              "info",
+                              "low",
+                              "medium",
+                              "high",
+                              "critical"
+                            ],
+                            "description": "Max severity over this role's driver findings — the only aggregation rule (no extra weighting)."
+                          },
+                          "drivers": {
+                            "type": "array",
+                            "items": {
+                              "type": "string"
+                            },
+                            "description": "Finding ids that drive the verdict: findings naming the role as a loss party, or aiming a viable/conditional gain path at it."
+                          },
+                          "open_questions": {
+                            "type": "array",
+                            "items": {
+                              "type": "string"
+                            },
+                            "description": "Exploration lead ids carried by the drivers — what the evidence could NOT verify. The verdict stays open until these settle."
+                          },
+                          "posture": {
+                            "type": "string",
+                            "enum": [
+                              "prefer",
+                              "avoid",
+                              "neutral"
+                            ],
+                            "description": "The judgment game.role_interests prefer/avoid keyword table hit over driver texts — the role's interest stance, not a recommendation."
+                          }
+                        },
+                        "required": [
+                          "role",
+                          "level",
+                          "drivers",
+                          "open_questions",
+                          "posture"
+                        ],
+                        "additionalProperties": false
+                      },
+                      "description": "Per-role provisional verdicts over the findings in hand."
+                    },
+                    "basis": {
+                      "type": "string",
+                      "description": "How the verdicts were composed (aggregation rule, posture source, open-question count) and the non-finality contract: a verdict never closes while its open questions stand."
+                    }
+                  },
+                  "required": [
+                    "per_role",
+                    "basis"
+                  ],
+                  "additionalProperties": false
+                },
                 "summary": {
                   "type": "string",
                   "description": "One-paragraph machine-readable topology summary."
@@ -22078,12 +22356,14 @@
                           }
                         },
                         "check_all_founded": {
-                          "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                          "default": true,
+                          "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                           "type": "boolean"
                         }
                       },
                       "required": [
-                        "entities"
+                        "entities",
+                        "check_all_founded"
                       ],
                       "additionalProperties": false,
                       "description": "Used to batch find account or object IDs by name"