From 6b1d4990a03e641dcd60f66c9e0e53cf04d361b4 Mon Sep 17 00:00:00 2001 From: cafzal Date: Tue, 7 Jul 2026 10:05:49 -0700 Subject: [PATCH 1/2] Remap all v1 template docs to the consolidated v3.0.0 skill names Skills release v3.0.0 consolidates 15 skills to 11. Every skill invocation and prose mention under v1/ moves to the new names: - rai-querying, rai-rules-authoring, rai-pyrel-coding -> rai-pyrel - rai-build-starter-ontology, rai-ontology-design -> rai-ontology - rai-prescriptive-problem-formulation -> rai-prescriptive-problem - rai-prescriptive-results-interpretation -> rai-prescriptive-results - rai-prescriptive-solver-management splits by context: solver selection / pre-solve (with formulation) -> rai-prescriptive-problem; solve execution / scenarios / diagnostics -> rai-prescriptive-results Combined invocations collapse accordingly: 'problem-formulation + solver-management' steps become a single /rai-prescriptive-problem step; 'solver-management + results-interpretation' scenario steps become a single /rai-prescriptive-results step. In commercial_underwriting and shipment_compliance the merge left a rules step immediately followed by a query step that only read the derived flags back, so each pair collapses into one /rai-pyrel step. ASCII stage diagrams re-aligned where the shorter names shifted columns. --- v1/ad_spend_allocation/runbook.md | 12 ++++---- v1/bom-reachability/runbook.md | 4 +-- v1/book_slate_recommendation/runbook.md | 8 +++--- v1/campaign_roi/runbook.md | 12 ++++---- v1/cell_tower_coverage/runbook.md | 12 ++++---- v1/cicd_runner_allocation/runbook.md | 14 +++++----- v1/commercial_underwriting/runbook.md | 26 ++++++----------- v1/cybersecurity-attack-paths/runbook.md | 4 +-- v1/datacenter_compute_allocation/README.md | 4 +-- .../datacenter_compute_allocation.py | 2 +- v1/datacenter_compute_allocation/runbook.md | 14 +++++----- v1/defect_root_cause/runbook.md | 24 ++++++++-------- v1/demand_forecasting/README.md | 2 +- v1/demand_forecasting/runbook.md | 4 +-- v1/demand_planning_temporal/runbook.md | 12 ++++---- v1/diet/runbook.md | 12 ++++---- v1/disease-outbreak-prevention/runbook.md | 4 +-- v1/energy_grid_planning/runbook.md | 12 ++++---- v1/entity_resolution/runbook.md | 28 +++++++++---------- v1/factory_production/runbook.md | 12 ++++---- v1/financial_index_replication/runbook.md | 12 ++++---- v1/fraud-detection/runbook.md | 12 ++++---- v1/hospital_staffing/runbook.md | 12 ++++---- v1/humanitarian-aid-supply-chain/runbook.md | 4 +-- v1/it-dependency-mapping/runbook.md | 4 +-- v1/memory_supply_allocation/runbook.md | 14 +++++----- .../runbook.md | 14 +++++----- v1/network_flow_planning/runbook.md | 12 ++++---- v1/patient_cohort_recruitment/runbook.md | 10 +++---- v1/planogram_optimization/runbook.md | 8 +++--- v1/pod_placement/runbook.md | 12 ++++---- v1/portfolio_balancing/portfolio_balancing.py | 2 +- v1/portfolio_balancing/runbook.md | 14 +++++----- v1/product_configurator/runbook.md | 12 ++++---- v1/production_planning/runbook.md | 12 ++++---- v1/retail_markdown/runbook.md | 12 ++++---- v1/retail_planning/runbook.md | 10 +++---- v1/shift_assignment/runbook.md | 12 ++++---- v1/shipment_compliance/runbook.md | 24 ++++++---------- v1/smoker_status_prediction/runbook.md | 4 +-- v1/sprint_scheduling/runbook.md | 12 ++++---- v1/subscriber_retention/README.md | 2 +- v1/subscriber_retention/runbook.md | 6 ++-- v1/supplier_reliability/runbook.md | 14 +++++----- v1/supply_chain_resilience/runbook.md | 12 ++++---- .../supply_chain_resilience.py | 2 +- v1/supply_chain_transport/runbook.md | 12 ++++---- v1/telco_network_recovery/runbook.md | 20 ++++++------- v1/transaction_screening_local/runbook.md | 6 ++-- v1/traveling_salesman/runbook.md | 12 ++++---- v1/underwriting_audit/runbook.md | 12 ++++---- v1/warehouse_allocation/runbook.md | 8 +++--- v1/water_allocation/runbook.md | 12 ++++---- v1/wildlife-conservation-network/runbook.md | 4 +-- 54 files changed, 278 insertions(+), 294 deletions(-) diff --git a/v1/ad_spend_allocation/runbook.md b/v1/ad_spend_allocation/runbook.md index 6c2506c6..0a718c40 100644 --- a/v1/ad_spend_allocation/runbook.md +++ b/v1/ad_spend_allocation/runbook.md @@ -6,7 +6,7 @@ A marketing team wants to split an advertising budget across channels and campai 5 channels (min/max spend) · 3 campaigns (budget) · 15 channel-campaign conversion rates │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decisions: spend per (channel-campaign, budget level) + binary "fund this pair?" • constraints: spend within channel min/max when funded; per-campaign budget; ≥ 1 funded channel per campaign; total spend ≤ the scenario's budget level @@ -14,7 +14,7 @@ A marketing team wants to split an advertising budget across channels and campai • budget levels $35k / $45k / $55k in one solve · HiGHS -> OPTIMAL, 9,740 conversions │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • the two higher budget levels give the identical plan — extra budget buys no more conversions • the real limits are per-channel max-spend and per-campaign budgets, not the total cap ``` @@ -25,25 +25,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/channels.csv` (each channel has a min and max spend), `data/campaigns.csv` (each campaign has a budget), and `data/effectiveness.csv` (the conversion rate — conversions per dollar — for each channel-campaign pair). Model effectiveness as a relationship linking a channel and a campaign to its conversion rate. +**Prompt:** /rai-ontology Build an ontology from `data/channels.csv` (each channel has a min and max spend), `data/campaigns.csv` (each campaign has a budget), and `data/effectiveness.csv` (the conversion rate — conversions per dollar — for each channel-campaign pair). Model effectiveness as a relationship linking a channel and a campaign to its conversion rate. **Response:** Loads `Channel` (5: Search, Social, Display, Video, Email — each with `min_spend`, `max_spend`), `Campaign` (3: Brand_Awareness $15k, Product_Launch $20k, Seasonal_Sale $10k), and `Effectiveness` (15, every channel-campaign pair, with `conversion_rate` 0.03–0.12). ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many of each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many of each? **Response:** Three concepts — 5 `Channel` (min/max spend), 3 `Campaign` (budget), and 15 `Effectiveness` (one conversion rate per channel-campaign pair). ## 3. Allocate spend across budget levels -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management How should we spend across each channel-campaign pair to maximize total expected conversions, at three total-budget levels — $35k, $45k, and $55k — solved together? Use a continuous spend per pair and a binary "fund this pair" decision: when a pair is funded its spend must sit within that channel's min and max, each campaign's spend across channels can't exceed its budget, every campaign needs at least one funded channel, and total spend can't exceed the budget level. Model the budget level as a first-class scenario concept with the spend indexed by (pair, level). Maximize conversions and persist the spend to the ontology. +**Prompt:** /rai-prescriptive-problem How should we spend across each channel-campaign pair to maximize total expected conversions, at three total-budget levels — $35k, $45k, and $55k — solved together? Use a continuous spend per pair and a binary "fund this pair" decision: when a pair is funded its spend must sit within that channel's min and max, each campaign's spend across channels can't exceed its budget, every campaign needs at least one funded channel, and total spend can't exceed the budget level. Model the budget level as a first-class scenario concept with the spend indexed by (pair, level). Maximize conversions and persist the spend to the ontology. **Response:** OPTIMAL (HiGHS), combined **9,740 conversions** across the three budget levels (relative gap 0.0). 90 variables (45 continuous spend + 45 binary funding) and 111 constraints; spend and funding are written back as `Allocation.x_spend(Scenario)` and `Allocation.x_active(Scenario)`. ## 4. Read the allocation across budget levels -**Prompt:** /rai-prescriptive-results-interpretation How does the plan change as the total budget grows, and what does that say about diminishing returns? +**Prompt:** /rai-prescriptive-results How does the plan change as the total budget grows, and what does that say about diminishing returns? **Response:** OPTIMAL, **9,740 combined conversions**. The tell is sharply diminishing returns: the **two higher budget levels ($45k and $55k) produce the identical allocation and conversions** — beyond a point, additional budget can't be profitably deployed because every remaining channel-campaign pair is already capped by its channel's max-spend or its campaign's budget. So the extra budget goes unused, and the **total-budget cap is not the binding limit** — the per-channel and per-campaign caps are. Raising the overall budget past that point buys zero marginal conversions. diff --git a/v1/bom-reachability/runbook.md b/v1/bom-reachability/runbook.md index 9ba52ed3..45c48aca 100644 --- a/v1/bom-reachability/runbook.md +++ b/v1/bom-reachability/runbook.md @@ -19,13 +19,13 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build a RelationalAI ontology from `data/skus.csv` and `data/bill_of_materials.csv`. Each SKU has an id, name, type (`RAW_MATERIAL`, `COMPONENT`, or `FINISHED_GOOD`), and category. Each bill-of-materials entry links an output SKU (what is produced) to an input SKU (what it requires), and may be site-specific. Model `BillOfMaterials` as an edge between SKUs so we can trace what depends on what. +**Prompt:** /rai-ontology Build a RelationalAI ontology from `data/skus.csv` and `data/bill_of_materials.csv`. Each SKU has an id, name, type (`RAW_MATERIAL`, `COMPONENT`, or `FINISHED_GOOD`), and category. Each bill-of-materials entry links an output SKU (what is produced) to an input SKU (what it requires), and may be site-specific. Model `BillOfMaterials` as an edge between SKUs so we can trace what depends on what. **Response:** Loads 9 `SKU` nodes (properties `name`, `type`, `category`) and a `BillOfMaterials` edge concept with `output_sku` / `input_sku` relationships from the 14 BOM rows. Several rows are site-specific duplicates (e.g. SKU001 is assembled at both S001 and S012), so the 14 entries collapse to 10 distinct output→input dependency edges; the duplicate-edge warning is informational. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how is the product structure tiered? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how is the product structure tiered? **Response:** One concept, `SKU`, with properties `name`, `type`, and `category`, plus the `BillOfMaterials` edge carrying `output_sku` / `input_sku`. The 9 SKUs span three tiers — 4 raw materials (wafer, display glass, lithium cells, NAND die), 3 components (Mobile Processor A15, OLED Display Panel 6.1, Lithium Battery Pack 4500mAh), and 2 finished goods (ProPhone X1, ProTab T1) — joined by 10 "produces → requires" edges that always point a higher tier down to a lower one. diff --git a/v1/book_slate_recommendation/runbook.md b/v1/book_slate_recommendation/runbook.md index c7f17923..4cd35c9e 100644 --- a/v1/book_slate_recommendation/runbook.md +++ b/v1/book_slate_recommendation/runbook.md @@ -32,7 +32,7 @@ support — OPTIMAL, every user gets an ordered, subject-diverse, fully-explaine **Prompt** ``` -/rai-build-starter-ontology Build an ontology from the data/ CSVs: books, authors, subjects, users, the read history (which user read which book, with a rating), and the knowledge-graph edges — book_author (a book's authors), book_subject (a book's subjects), and book_similar (books similar to a book). Model these as relationships so a book connects to its authors, subjects, similar books, and readers. +/rai-ontology Build an ontology from the data/ CSVs: books, authors, subjects, users, the read history (which user read which book, with a rating), and the knowledge-graph edges — book_author (a book's authors), book_subject (a book's subjects), and book_similar (books similar to a book). Model these as relationships so a book connects to its authors, subjects, similar books, and readers. ``` **Response** @@ -44,7 +44,7 @@ Loads `Book` (59), `Author` (52), `Subject` (12), `User` (25), a 150-row read hi **Prompt** ``` -/rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +/rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? ``` **Response** @@ -80,7 +80,7 @@ For every (user, unread book) candidate, the connecting paths are counted across **Prompt** ``` -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management For each user, pick an ordered 3-book slate (slots 1–3) to maximize weighted explanation support — sum of (4 − slot) times the candidate's path count, so stronger picks go in higher slots — while keeping the slate subject-diverse and meeting a minimum total explanation floor. Persist each user's chosen books and slots. +/rai-prescriptive-problem For each user, pick an ordered 3-book slate (slots 1–3) to maximize weighted explanation support — sum of (4 − slot) times the candidate's path count, so stronger picks go in higher slots — while keeping the slate subject-diverse and meeting a minimum total explanation floor. Persist each user's chosen books and slots. ``` **Response** @@ -92,7 +92,7 @@ OPTIMAL — all 25 users get an ordered 3-book slate (`Candidate.slot`) that max **Prompt** ``` -/rai-prescriptive-results-interpretation What does each user's slate look like, and how is each pick explained? +/rai-prescriptive-results What does each user's slate look like, and how is each pick explained? ``` diff --git a/v1/campaign_roi/runbook.md b/v1/campaign_roi/runbook.md index ae951af4..d41f52ad 100644 --- a/v1/campaign_roi/runbook.md +++ b/v1/campaign_roi/runbook.md @@ -6,7 +6,7 @@ A marketing team wants to rebalance a fixed quarterly budget across an existing 12 campaigns across 5 regions · current budget ($K) + conversion rate each · $1,130K total │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decision: a new budget per campaign, ≥ 0 • constraints: each campaign within 10%–300% of its current budget; total spend ≤ $1,130K (pure reallocation); paused WEST region ≤ 50% of total @@ -14,7 +14,7 @@ A marketing team wants to rebalance a fixed quarterly budget across an existing • HiGHS linear program -> OPTIMAL, 3,151 conversions (+17.1%) │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • total budget binds at $1,130K; WEST binds at its $565K cap • high-rate campaigns pushed to their 3x ceiling; low-rate ones cut toward their floor ``` @@ -25,25 +25,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/campaigns.csv` — each campaign has a name, a region, a current budget (in $K), and a conversion rate (conversions per $K). +**Prompt:** /rai-ontology Build an ontology from `data/campaigns.csv` — each campaign has a name, a region, a current budget (in $K), and a conversion rate (conversions per $K). **Response:** Loads `Campaign` (12, with `region`, `current_budget`, `conversion_rate`) across 5 regions (CENTRAL 3, SOUTH 3, EAST 2, NORTH 2, WEST 2), totalling $1,130K of current budget; WEST holds the two highest-rate campaigns. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? **Response:** One concept, `Campaign` (12 rows, with `region`, `current_budget`, `conversion_rate`), spanning 5 regions and $1,130K of total current budget. ## 3. Rebalance the portfolio -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management How should we reallocate the budget across campaigns to maximize total expected conversions, keeping total spend at today's $1,130K? Each campaign's new budget must stay between 10% and 300% of its current budget, and the paused WEST region can get at most 50% of the total. Maximize conversions (budget times conversion rate) and persist the new budgets to the ontology. +**Prompt:** /rai-prescriptive-problem How should we reallocate the budget across campaigns to maximize total expected conversions, keeping total spend at today's $1,130K? Each campaign's new budget must stay between 10% and 300% of its current budget, and the paused WEST region can get at most 50% of the total. Maximize conversions (budget times conversion rate) and persist the new budgets to the ontology. **Response:** OPTIMAL (HiGHS), **3,151 expected conversions** — up from the current baseline of 2,691, a **+17.1% lift** — at unchanged total spend. One continuous budget variable per campaign; new budgets are written back as `Campaign.x_budget`. Both the total-budget constraint ($1,130K) and the WEST cap ($565K) bind exactly. ## 4. Read the reallocation -**Prompt:** /rai-prescriptive-results-interpretation Where does the money move, and which constraints decide the shape of the new plan? +**Prompt:** /rai-prescriptive-results Where does the money move, and which constraints decide the shape of the new plan? **Response:** The optimizer concentrates spend on the highest-converting campaigns — three are pushed all the way to their **3x ceiling** — while the lowest-rate campaigns are cut toward their **10% floor**; every campaign keeps a nonzero budget (the floor guarantees it). The plan is shaped by two binding limits: total spend holds at **$1,130K**, and the paused **WEST region sits at its $565K (50%) cap** even though it holds the two best conversion rates — so WEST's headroom, not campaign quality, is what stops more money flowing there. diff --git a/v1/cell_tower_coverage/runbook.md b/v1/cell_tower_coverage/runbook.md index ab741291..d141f97e 100644 --- a/v1/cell_tower_coverage/runbook.md +++ b/v1/cell_tower_coverage/runbook.md @@ -6,7 +6,7 @@ A network planner wants to know which new cell tower sites to build, and which d 6 candidate sites (build cost, capacity) · 10 demand zones (population) · 19 feasible coverage links │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decisions: build site? · zone covered? · tower serves zone? (all binary) • constraints: ≤ 3 towers; total build cost ≤ $650k; each covered zone served by exactly one built tower; each tower's served population ≤ its capacity @@ -14,7 +14,7 @@ A network planner wants to know which new cell tower sites to build, and which d • HiGHS mixed-integer program -> OPTIMAL, 90,000 covered │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • build T02, T04, T06 ($610k of $650k) → 8 of 10 zones, 87.5% of population • the 3-tower cap binds (budget has $40k slack); Riverfront + Lakeside stay uncovered ``` @@ -25,25 +25,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/tower_sites.csv` (each candidate site has a build cost and a serving capacity), `data/demand_zones.csv` (each zone has a population), and `data/coverage_pairs.csv` (the feasible site-to-zone links a tower could serve). Model the coverage pair as a relationship linking a tower site to a demand zone. +**Prompt:** /rai-ontology Build an ontology from `data/tower_sites.csv` (each candidate site has a build cost and a serving capacity), `data/demand_zones.csv` (each zone has a population), and `data/coverage_pairs.csv` (the feasible site-to-zone links a tower could serve). Model the coverage pair as a relationship linking a tower site to a demand zone. **Response:** Loads `TowerSite` (6, with `build_cost` and `capacity`), `DemandZone` (10, with `population` — 102,900 total), and `CoveragePair` (19 feasible site-zone links, each with `distance_km` and `signal_score`), linked back to their site and zone. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many of each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many of each? **Response:** Three concepts — 6 `TowerSite` (build cost, capacity), 10 `DemandZone` (population, 102,900 total), and 19 `CoveragePair` (the only allowed site-to-zone service links) — so not every zone can be served by every tower. ## 3. Maximize covered population -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Which sites should we build and which tower should serve each zone to cover the most people, building at most 3 towers within a $650,000 budget? Use a binary build decision per site, a binary covered decision per zone, and a binary serve decision per feasible site-zone pair. A zone counts as covered only if it's assigned to exactly one built tower, a tower can only serve zones if it's built, and the population a tower serves can't exceed its capacity. Maximize total covered population and persist the decisions to the ontology. +**Prompt:** /rai-prescriptive-problem Which sites should we build and which tower should serve each zone to cover the most people, building at most 3 towers within a $650,000 budget? Use a binary build decision per site, a binary covered decision per zone, and a binary serve decision per feasible site-zone pair. A zone counts as covered only if it's assigned to exactly one built tower, a tower can only serve zones if it's built, and the population a tower serves can't exceed its capacity. Maximize total covered population and persist the decisions to the ontology. **Response:** OPTIMAL (HiGHS), covered population **90,000 of 102,900** (relative gap 0.0). The model has 3 binary decision families and 5 constraint families; build, cover, and serve decisions are written back as `TowerSite.x_selected`, `DemandZone.y_covered`, and `CoveragePair.z_assigned`. ## 4. Read the build plan -**Prompt:** /rai-prescriptive-results-interpretation Which towers get built, which zones do they serve, and what's the coverage rate — and is the budget or the tower count the binding limit? +**Prompt:** /rai-prescriptive-results Which towers get built, which zones do they serve, and what's the coverage rate — and is the budget or the tower count the binding limit? **Response:** Build **T02 (North Water Tank), T04 (Campus Microcell), and T06 (Airport Perimeter)** for **$610,000 of the $650,000 budget**, covering **8 of 10 zones — 90,000 people, an 87.5% coverage rate**. All three towers run above 90% of capacity. The **3-tower cap is the binding limit** in this solve — 0 towers to spare, versus $40k of budget headroom; Riverfront (7,200) and Lakeside (5,700) are left uncovered. Reaching them would take both another tower and more budget: the only sites that can serve those two zones push the cheapest fully-covering plan to a 4th tower at about $850k, past both the count cap and the budget. diff --git a/v1/cicd_runner_allocation/runbook.md b/v1/cicd_runner_allocation/runbook.md index 3f82165a..c34d953f 100644 --- a/v1/cicd_runner_allocation/runbook.md +++ b/v1/cicd_runner_allocation/runbook.md @@ -6,14 +6,14 @@ A platform team wants to assign every CI/CD workflow job to a compatible runner 8 runners (cost/min, concurrency cap) · 20 workflow jobs (OS/cpu/mem, minutes) · 70 compatible pairs │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decision: binary assign per compatible (job, runner) pair • constraints: each job on exactly one compatible runner; per-runner jobs ≤ cap x multiplier • objective: minimize total cost = sum(assign x cost/min x job minutes) • concurrency multiplier 0.5 / 1.0 / 1.5 -> OPTIMAL $10.18 / $9.62 / $9.53 │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • cheaper self-hosted-linux absorbs more jobs as the cap loosens, so cost falls • outage (2 runners offline) → INFEASIBLE; the IIS pins ubuntu-xlarge's cap (5) against 6 of the 7 high-CPU Linux jobs — restore a runner or raise that one cap @@ -25,31 +25,31 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/runners.csv` (each runner has a cost per minute and a max concurrency), `data/workflows.csv` (each job has a required OS, a minimum CPU and memory, and an estimated runtime in minutes), and `data/compatibility.csv` (the precomputed compatible job-runner pairs). Model compatibility as a relationship linking a workflow job to the runners it can run on. +**Prompt:** /rai-ontology Build an ontology from `data/runners.csv` (each runner has a cost per minute and a max concurrency), `data/workflows.csv` (each job has a required OS, a minimum CPU and memory, and an estimated runtime in minutes), and `data/compatibility.csv` (the precomputed compatible job-runner pairs). Model compatibility as a relationship linking a workflow job to the runners it can run on. **Response:** Loads `Runner` (8, with `cost_per_minute` and `max_concurrent`), `Workflow` (20, with OS and resource requirements and `estimated_minutes`), and `Compatibility` (70 compatible job-runner pairs) — the cheapest runner is self-hosted-linux at $0.005/min. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many of each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many of each? **Response:** Three concepts — 8 `Runner` (cost, concurrency cap), 20 `Workflow` (OS / CPU / memory / minutes), and 70 `Compatibility` pairs (the only allowed assignments) — so each job can run on a restricted subset of runners. ## 3. Assign jobs at minimum cost across capacity scenarios -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Which runner should each job run on to minimize total pipeline cost — runner cost-per-minute times the job's estimated minutes — given that each job must go to exactly one compatible runner and each runner can run at most its concurrency cap of jobs? Solve it for three capacity scenarios that scale every runner's concurrency cap to 0.5x, 1.0x, and 1.5x. Persist the assignment to the ontology. +**Prompt:** /rai-prescriptive-problem Which runner should each job run on to minimize total pipeline cost — runner cost-per-minute times the job's estimated minutes — given that each job must go to exactly one compatible runner and each runner can run at most its concurrency cap of jobs? Solve it for three capacity scenarios that scale every runner's concurrency cap to 0.5x, 1.0x, and 1.5x. Persist the assignment to the ontology. **Response:** OPTIMAL in all three scenarios (HiGHS), all 20 jobs assigned each time. Minimum total cost is **$10.18 at 0.5x, $9.62 at 1.0x, and $9.53 at 1.5x**. The binary assignment is written back as `Assignment.x_assigned`; the assign-one and per-runner concurrency constraints are keyed by workflow and runner so their conflict membership can be read back later. ## 4. Read the cost-vs-capacity curve -**Prompt:** /rai-prescriptive-results-interpretation How does minimum pipeline cost change as concurrency capacity scales, and what drives the difference? +**Prompt:** /rai-prescriptive-results How does minimum pipeline cost change as concurrency capacity scales, and what drives the difference? **Response:** Cost falls as caps loosen — $10.18 → $9.62 → $9.53 — but with diminishing returns (most of the saving is from 0.5x to 1.0x). The driver is the cheapest runner, **self-hosted-linux**: as its concurrency cap rises it absorbs more jobs (about 4 at 0.5x, 8 at 1.0x, 12 at 1.5x), displacing work from pricier runners. OS-specific jobs (macOS, Windows) are pinned to their only compatible runner and don't move. ## 5. Diagnose a maintenance outage -**Prompt:** /rai-prescriptive-solver-management + /rai-prescriptive-results-interpretation If two runners — ubuntu-large and self-hosted-linux — go offline for maintenance at normal (1.0x) capacity, can every job still be scheduled? If not, return the minimal conflict (the IIS): which runner's concurrency cap, and which jobs, make it infeasible? +**Prompt:** /rai-prescriptive-results If two runners — ubuntu-large and self-hosted-linux — go offline for maintenance at normal (1.0x) capacity, can every job still be scheduled? If not, return the minimal conflict (the IIS): which runner's concurrency cap, and which jobs, make it infeasible? **Response:** INFEASIBLE — the solver returns a conflict. The irreducible infeasible subsystem pins **ubuntu-xlarge's concurrency cap (max 5)** against the high-CPU Linux jobs that, with the two runners offline, have nowhere else to go: **6 of the 7 high-CPU Linux jobs are stranded** (the minimal conflict names cap-plus-one = 6; exactly which 6 is solver-dependent). The fix is named directly: restore one of the offline runners or raise ubuntu-xlarge's cap — far more actionable than a bare "infeasible." diff --git a/v1/commercial_underwriting/runbook.md b/v1/commercial_underwriting/runbook.md index f0afe177..6982c468 100644 --- a/v1/commercial_underwriting/runbook.md +++ b/v1/commercial_underwriting/runbook.md @@ -6,43 +6,35 @@ A commercial property & casualty carrier needs to triage a portfolio of submissi 8 insured entities → 8 policies → 11 locations → 33 coverages │ ▼ -/rai-rules-authoring (layered derived flags, then a risk tier) +/rai-pyrel (layered derived flags, then a risk tier, then the triage readout) • location/coverage flags: poor fire protection, old construction, high-risk occupancy, underinsured • roll up to the entity: has_decline_factor, has_marginal_factor • classify each insured into one tier: Decline / Non-Standard / Standard / Preferred - │ - ▼ -/rai-querying — the tier of each insured + premium by tier - Decline 3 · Non-Standard 3 · Standard 1 · Preferred 1 + • read the tier of each insured + premium by tier + -> Decline 3 · Non-Standard 3 · Standard 1 · Preferred 1 ``` -Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` skill (named at the start of each prompt). They run in order in a single session — the rules step writes flags and tiers back onto the concepts the build step created, and the query step reads them. +Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` skill (named at the start of each prompt). They run in order in a single session — the rules step writes flags and tiers back onto the concepts the build step created, then reads the triage out of them. --- ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/insured_entities.csv` (each business has an industry code, years in business, and annual revenue), `data/policies.csv` (each policy is bound to an insured entity and has a total premium), `data/locations.csv` (each location is scheduled on a policy and has an occupancy class, a year built, a fire protection class, and a replacement value), and `data/coverages.csv` (each coverage is scheduled on a location with a coverage type and limit). Model the hierarchy: entity to policy to location to coverage. +**Prompt:** /rai-ontology Build an ontology from `data/insured_entities.csv` (each business has an industry code, years in business, and annual revenue), `data/policies.csv` (each policy is bound to an insured entity and has a total premium), `data/locations.csv` (each location is scheduled on a policy and has an occupancy class, a year built, a fire protection class, and a replacement value), and `data/coverages.csv` (each coverage is scheduled on a location with a coverage type and limit). Model the hierarchy: entity to policy to location to coverage. **Response:** Loads `InsuredEntity` (8, with industry / years-in-business / revenue), `Policy` (8, one per entity, with premium), `Location` (11, with occupancy class, year built, fire protection class, replacement value), and `Coverage` (33, three lines per location) — a four-level entity-to-coverage hierarchy. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? **Response:** Four concepts in a hierarchy — 8 `InsuredEntity`, 8 `Policy` (bound to entities), 11 `Location` (scheduled on policies), and 33 `Coverage` (scheduled on locations, three coverage lines each). -## 3. Author the underwriting rules and risk tiers - -**Prompt:** /rai-rules-authoring Encode the underwriting guardrails as layered flags. At the location level: poor fire protection (fire protection class above 6), old construction (built before 1950), high-risk occupancy (gas station, cannabis retail, fast-food, or habitational). At the coverage level: underinsured (a building coverage limit below 80% of the location's replacement value). Roll these up to each insured: a **decline factor** is a restricted industry, fewer than 3 years in business, or any unprotected/old-construction location; a **marginal factor** is a marginal industry, a high-risk-occupancy location, or an underinsured coverage. Then classify each insured into exactly one risk tier: **Decline** if it has any decline factor; otherwise **Non-Standard** if it has any marginal factor; otherwise **Preferred** if it's well-established (15+ years) with every location well-protected; otherwise **Standard**. - -**Response:** Authors the location flags (`has_poor_fire_protection`, `has_old_construction`, `has_high_risk_occupancy`), the coverage flag (`is_underinsured`), the entity rollups (`has_decline_factor`, `has_marginal_factor`), and four mutually-exclusive risk-tier subtype concepts. The rules are declarative, so the reasoner resolves their dependency order automatically and every insured lands in exactly one tier. - -## 4. Read the triage +## 3. Author the underwriting rules and read the triage -**Prompt:** /rai-querying How many insured entities fall in each risk tier, and what premium does each tier represent? +**Prompt:** /rai-pyrel Encode the underwriting guardrails as layered flags. At the location level: poor fire protection (fire protection class above 6), old construction (built before 1950), high-risk occupancy (gas station, cannabis retail, fast-food, or habitational). At the coverage level: underinsured (a building coverage limit below 80% of the location's replacement value). Roll these up to each insured: a **decline factor** is a restricted industry, fewer than 3 years in business, or any unprotected/old-construction location; a **marginal factor** is a marginal industry, a high-risk-occupancy location, or an underinsured coverage. Then classify each insured into exactly one risk tier: **Decline** if it has any decline factor; otherwise **Non-Standard** if it has any marginal factor; otherwise **Preferred** if it's well-established (15+ years) with every location well-protected; otherwise **Standard**. How many insured entities fall in each tier, and what premium does each tier represent? -**Response:** The 8 insureds partition cleanly: **3 Decline** (a cannabis business, one under 3 years old, one with pre-1950 construction), **3 Non-Standard** (marginal industries or a high-risk-occupancy/underinsured location), **1 Standard**, and **1 Preferred** (15+ years, every location well-protected). Premium concentrates in Non-Standard (~$236k across 3) versus Decline (~$150k) — so the book's exposure is mostly in the marginal tier, exactly the segment underwriting should price and monitor most closely. +**Response:** Authors the location flags (`has_poor_fire_protection`, `has_old_construction`, `has_high_risk_occupancy`), the coverage flag (`is_underinsured`), the entity rollups (`has_decline_factor`, `has_marginal_factor`), and four mutually-exclusive risk-tier subtype concepts. The rules are declarative, so the reasoner resolves their dependency order automatically and every insured lands in exactly one tier. The 8 insureds partition cleanly: **3 Decline** (a cannabis business, one under 3 years old, one with pre-1950 construction), **3 Non-Standard** (marginal industries or a high-risk-occupancy/underinsured location), **1 Standard**, and **1 Preferred** (15+ years, every location well-protected). Premium concentrates in Non-Standard (~$236k across 3) versus Decline (~$150k) — so the book's exposure is mostly in the marginal tier, exactly the segment underwriting should price and monitor most closely. ## Data diff --git a/v1/cybersecurity-attack-paths/runbook.md b/v1/cybersecurity-attack-paths/runbook.md index 4ce3caaa..10a75b5d 100644 --- a/v1/cybersecurity-attack-paths/runbook.md +++ b/v1/cybersecurity-attack-paths/runbook.md @@ -21,13 +21,13 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build a RelationalAI ontology from `data/assets.csv` and `data/attack_steps.csv`. Each asset has an id, name, zone, whether it is internet-facing, whether it is a crown jewel, and an exposure score. Each attack step is a directed move from one asset to another tagged with a technique (`exploit`, `cred`, or `pivot`). Model one relationship per technique between assets, plus a technique-agnostic `can_reach` relationship populated from every step. +**Prompt:** /rai-ontology Build a RelationalAI ontology from `data/assets.csv` and `data/attack_steps.csv`. Each asset has an id, name, zone, whether it is internet-facing, whether it is a crown jewel, and an exposure score. Each attack step is a directed move from one asset to another tagged with a technique (`exploit`, `cred`, or `pivot`). Model one relationship per technique between assets, plus a technique-agnostic `can_reach` relationship populated from every step. **Response:** Loads 12 `Asset` nodes and four asset-to-asset relationships — `exploit_to`, `cred_to`, `pivot_to` (one per technique), and the union `can_reach`. The 16 steps split into the three typed edges and all 16 populate `can_reach`. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many of each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many of each? **Response:** One concept, `Asset`, with properties `name`, `zone`, `internet_facing`, `crown_jewel`, and `exposure_score`; and four self-relationships (`exploit_to`, `cred_to`, `pivot_to`, `can_reach`). diff --git a/v1/datacenter_compute_allocation/README.md b/v1/datacenter_compute_allocation/README.md index 144684bb..73d896ae 100644 --- a/v1/datacenter_compute_allocation/README.md +++ b/v1/datacenter_compute_allocation/README.md @@ -148,7 +148,7 @@ Set `EXP_DATABASE` at the top of `datacenter_compute_allocation.py` to that data 110 workloads assigned, $25.28M revenue, 83% margin, 95% anchor share ``` - Full stage-by-stage log (GNN distribution, PageRank scores, both Pareto frontiers, the demand-scenario overlay, and expected per-cell behavior) is in `runbook.md`. GNN probabilities depend on seed and predictive engine; the `--no-gnn` fallback values are deterministic. Stage 4 reaches `OPTIMAL` in seconds with Gurobi; the open-source HiGHS default returns a feasible solution at the `time_limit_sec=240` wall and may surface `TIME_LIMIT` (signal, not failure, per `rai-prescriptive-results-interpretation`). Set `SOLVER` in `datacenter_compute_allocation.py` to switch. + Full stage-by-stage log (GNN distribution, PageRank scores, both Pareto frontiers, the demand-scenario overlay, and expected per-cell behavior) is in `runbook.md`. GNN probabilities depend on seed and predictive engine; the `--no-gnn` fallback values are deterministic. Stage 4 reaches `OPTIMAL` in seconds with Gurobi; the open-source HiGHS default returns a feasible solution at the `time_limit_sec=240` wall and may surface `TIME_LIMIT` (signal, not failure, per `rai-prescriptive-results`). Set `SOLVER` in `datacenter_compute_allocation.py` to switch. ## Template structure @@ -294,7 +294,7 @@ Some cell's constraints are mutually unsatisfiable AND the C1 P0 commitment is a
Solver returns TIME_LIMIT with sensible per-cell results -Expected at the default `time_limit_sec=240`. Per-cell numbers remain valid with `TIME_LIMIT` (`rai-prescriptive-results-interpretation`: `TIME_LIMIT` is signal, not error). Raise `time_limit_sec` or switch to a faster solver in the `# Stage 4: Prescriptive` section if you need a tighter MIP gap. +Expected at the default `time_limit_sec=240`. Per-cell numbers remain valid with `TIME_LIMIT` (`rai-prescriptive-results`: `TIME_LIMIT` is signal, not error). Raise `time_limit_sec` or switch to a faster solver in the `# Stage 4: Prescriptive` section if you need a tighter MIP gap.
diff --git a/v1/datacenter_compute_allocation/datacenter_compute_allocation.py b/v1/datacenter_compute_allocation/datacenter_compute_allocation.py index ce520368..32563606 100644 --- a/v1/datacenter_compute_allocation/datacenter_compute_allocation.py +++ b/v1/datacenter_compute_allocation/datacenter_compute_allocation.py @@ -916,7 +916,7 @@ def _pos_prob(v): print(f" Solving 24-cell scenario sweep with {SOLVER}...") problem.solve(SOLVER, time_limit_sec=SOLVER_TIME_LIMIT_SEC) si = problem.solve_info() -# Per rai-prescriptive-results-interpretation: status is signal, not always error. +# Per rai-prescriptive-results: status is signal, not always error. # INFEASIBLE/TIME_LIMIT cells in a multi-scenario sweep are diagnostic information # about which constraint combinations bind. print(f" Termination status: {si.termination_status}") diff --git a/v1/datacenter_compute_allocation/runbook.md b/v1/datacenter_compute_allocation/runbook.md index 260c8598..c9e8cbd6 100644 --- a/v1/datacenter_compute_allocation/runbook.md +++ b/v1/datacenter_compute_allocation/runbook.md @@ -55,7 +55,7 @@ Prompts below are designed to run in order in a single session so each step inhe **Prompt** ``` -/rai-build-starter-ontology Build a datacenter compute allocation ontology from the CSVs in data/. workload_dependencies is an edge concept (source/target workload). lab_metrics is keyed by (lab, date). The three scenario CSVs (power_envelope_levels, margin_floors, diversity_caps) each map to a Scenario Concept identified by name. +/rai-ontology Build a datacenter compute allocation ontology from the CSVs in data/. workload_dependencies is an edge concept (source/target workload). lab_metrics is keyed by (lab, date). The three scenario CSVs (power_envelope_levels, margin_floors, diversity_caps) each map to a Scenario Concept identified by name. ``` **Response** @@ -67,7 +67,7 @@ Concepts: `DataCenterRequest`, `GpuPool`, `AILab`, `Workload`, `WorkloadDependen **Prompt** ``` -/rai-querying What concepts and relationships does the ontology have, how many rows in each, and what date range does the lab metrics history cover? +/rai-pyrel What concepts and relationships does the ontology have, how many rows in each, and what date range does the lab metrics history cover? ``` **Response** @@ -91,7 +91,7 @@ Plan routes sub-questions to predictive (per-workload utilization-probability cl **Prompt** ``` -/rai-querying How is workload demand distributed across labs, workload types, and contract tiers, and which labs dominate GPU-hour pressure (sum of gpu_count_required × duration_hours)? +/rai-pyrel How is workload demand distributed across labs, workload types, and contract tiers, and which labs dominate GPU-hour pressure (sum of gpu_count_required × duration_hours)? ``` **Response** @@ -115,7 +115,7 @@ Frontier labs (Anthropic, OpenAI, xAI Internal) carry the 15 P0 pretrains (256 **Prompt** ``` -/rai-rules-authoring Which (workload, GPU pool) pairs are technically eligible? A pair qualifies when (1) the pool's per-GPU memory meets the workload's mem_required_gb and (2) the pool's gpu_type is in the workload's allowlist. Also classify each workload's priority tier from its lab's contract_tier — frontier-anchor → P0 (weight 100), committed → P1 (10), on-demand → P2 (1) — and write the tier, numeric weight, and an under-provisioning penalty (P0 = 1.0, P1 = 0.3, P2 = 0.0) the optimizer can amplify against to model asymmetric failure modes (unfilled anchor seats cost more than the foregone revenue). +/rai-pyrel Which (workload, GPU pool) pairs are technically eligible? A pair qualifies when (1) the pool's per-GPU memory meets the workload's mem_required_gb and (2) the pool's gpu_type is in the workload's allowlist. Also classify each workload's priority tier from its lab's contract_tier — frontier-anchor → P0 (weight 100), committed → P1 (10), on-demand → P2 (1) — and write the tier, numeric weight, and an under-provisioning penalty (P0 = 1.0, P1 = 0.3, P2 = 0.0) the optimizer can amplify against to model asymmetric failure modes (unfilled anchor seats cost more than the foregone revenue). ``` **Response** @@ -139,7 +139,7 @@ Frontier labs (Anthropic, OpenAI, xAI Internal) carry the 15 P0 pretrains (256 **Prompt** ``` -/rai-prescriptive-problem-formulation Which workloads should be assigned to which (DC, GPU pool) under three scenario axes — power envelope (85% / 100% of approved_mw), gross-margin floor (unconstrained / 80% / 85%), and anchor-concentration cap (none / 70% / 50% / 40% with workload-type floor) — solved as one MIP indexed by all three? Stay within per-pool GPU capacity and per-DC power, hit the margin and diversity caps per cell, and amplify anchor reward by the under-provisioning penalty so unfilled anchor seats cost more than unfilled research seats. Per-cell INFEASIBLE is diagnostic — the global solve should not fail when one cell binds too tight. +/rai-prescriptive-problem Which workloads should be assigned to which (DC, GPU pool) under three scenario axes — power envelope (85% / 100% of approved_mw), gross-margin floor (unconstrained / 80% / 85%), and anchor-concentration cap (none / 70% / 50% / 40% with workload-type floor) — solved as one MIP indexed by all three? Stay within per-pool GPU capacity and per-DC power, hit the margin and diversity caps per cell, and amplify anchor reward by the under-provisioning penalty so unfilled anchor seats cost more than unfilled research seats. Per-cell INFEASIBLE is diagnostic — the global solve should not fail when one cell binds too tight. ``` **Response** @@ -151,7 +151,7 @@ Single MIP across 24 cells: `Assignment.x_assign(PowerEnvelopeLevel, MarginFloor **Prompt** ``` -/rai-prescriptive-results-interpretation What's the headline plan for the unconstrained baseline cell — revenue, total cost, realized margin, anchor share, n_assigned, and which axis would bind first if we tightened it? Where do the two Pareto frontiers (margin × revenue, diversity × revenue) cliff, and what does each cliff cost? Then replay the chosen plan under three demand-risk scenarios (diffusion slowdown, scaling-law plateau, frontier-lab displacement) to surface stranded-capacity exposure — anchor revenue is contractual, but opportunistic seats only realize a fraction of forecast under risk. +/rai-prescriptive-results What's the headline plan for the unconstrained baseline cell — revenue, total cost, realized margin, anchor share, n_assigned, and which axis would bind first if we tightened it? Where do the two Pareto frontiers (margin × revenue, diversity × revenue) cliff, and what does each cliff cost? Then replay the chosen plan under three demand-risk scenarios (diffusion slowdown, scaling-law plateau, frontier-lab displacement) to surface stranded-capacity exposure — anchor revenue is contractual, but opportunistic seats only realize a fraction of forecast under risk. ``` **Response** @@ -163,7 +163,7 @@ Baseline: 110 workloads, $25.28M revenue, $4.18M cost, 83% margin, 95% anchor, b **Prompt** ``` -/rai-ontology-design Add an AllocationPlan singleton holding the baseline-cell summary (chosen envelope/margin/diversity, revenue_usd, total_cost_usd, realized_margin, anchor_share, n_assigned, status, binding_axis), an Assignment.is_chosen unary Relationship narrowing Assignment to the decision rows in the chosen cell, and a DemandScenario / DemandScenarioOutlook pair carrying the four risk scenarios and their realized/stranded revenue so the overlay survives the chain run. +/rai-ontology Add an AllocationPlan singleton holding the baseline-cell summary (chosen envelope/margin/diversity, revenue_usd, total_cost_usd, realized_margin, anchor_share, n_assigned, status, binding_axis), an Assignment.is_chosen unary Relationship narrowing Assignment to the decision rows in the chosen cell, and a DemandScenario / DemandScenarioOutlook pair carrying the four risk scenarios and their realized/stranded revenue so the overlay survives the chain run. ``` **Response** diff --git a/v1/defect_root_cause/runbook.md b/v1/defect_root_cause/runbook.md index 0f9f7243..daa40a05 100644 --- a/v1/defect_root_cause/runbook.md +++ b/v1/defect_root_cause/runbook.md @@ -13,7 +13,7 @@ minimal root-cause diagnosis. ───────────────────────────────────────────────────────────────── EXAMINE Descriptive ──► final-test failure rate by build week - /rai-querying 1.9% (wk1) -> 6.6% (wk2) -> 8.3% (wk3); + /rai-pyrel 1.9% (wk1) -> 6.6% (wk2) -> 8.3% (wk3); spike onset = week 2. ───────────────────────────────────────────────────────────────── STAGE 1 Graph ──► Unit.touches_lot (57,133 incidence facts) @@ -21,12 +21,12 @@ minimal root-cause diagnosis. 105-lot / 162-edge parent->child genealogy. ───────────────────────────────────────────────────────────────── STAGE 2 Rules ──► Factor.lift, Factor.is_suspect (10 suspects) - /rai-rules-authoring Defect lift vs. the 5.68% baseline; screens + /rai-pyrel Defect lift vs. the 5.68% baseline; screens out high-coverage / low-lift trunk factors. ───────────────────────────────────────────────────────────────── STAGE 3 Prescriptive ──► Factor.is_root_cause (2), DiagnosisResult - /rai-prescriptive- OPTIMAL · obj 46.32 · {SP-0423, REF-02} - problem-formulation explain 120/142 defects (85% coverage). + /rai-prescriptive-problem OPTIMAL · obj 46.32 · {SP-0423, REF-02} + explain 120/142 defects (85% coverage). ───────────────────────────────────────────────────────────────── ``` @@ -39,7 +39,7 @@ minimal root-cause diagnosis. **Prompt** ``` -/rai-build-starter-ontology Build a manufacturing genealogy ontology from the CSVs in data/. Model finished Units with their final-test result and build week, the multi-tier SKU bill of materials, material Lots with a parent->child genealogy (a built lot consumes its input lots) and receipt dates, each unit's directly-consumed lots and its process history (machine and shift per operation), and a Factor concept enumerating the candidate root causes — every lot, machine, and shift. +/rai-ontology Build a manufacturing genealogy ontology from the CSVs in data/. Model finished Units with their final-test result and build week, the multi-tier SKU bill of materials, material Lots with a parent->child genealogy (a built lot consumes its input lots) and receipt dates, each unit's directly-consumed lots and its process history (machine and shift per operation), and a Factor concept enumerating the candidate root causes — every lot, machine, and shift. ``` **Response** @@ -51,7 +51,7 @@ Concepts bound to the bundled CSVs: `SKU` (20, four tiers), `BillOfMaterials` (2 **Prompt** ``` -/rai-querying How many units are there, how many are defective, what failure rate is that, and what is the defect-type mix? +/rai-pyrel How many units are there, how many are defective, what failure rate is that, and what is the defect-type mix? ``` **Response** @@ -63,7 +63,7 @@ Concepts bound to the bundled CSVs: `SKU` (20, four tiers), `BillOfMaterials` (2 **Prompt** ``` -/rai-querying Before touching genealogy: when did the failures start climbing? Roll the final-test failure rate up by build week, and identify the onset — the first week whose rate runs well above the opening week's baseline. +/rai-pyrel Before touching genealogy: when did the failures start climbing? Roll the final-test failure rate up by build week, and identify the onset — the first week whose rate runs well above the opening week's baseline. ``` **Response** @@ -80,7 +80,7 @@ Failure rate by build week: 1.9% (week 1, 795 units) → 6.6% (week 2, 852) → **Response** -Plans the backward chain on the shared ontology: graph (`/rai-graph-analysis`) to close the lot genealogy transitively and attribute every upstream lot to the units that carry it; rules (`/rai-rules-authoring`) to contrast-score each candidate factor by defect lift versus baseline and screen out high-coverage / low-lift factors; prescriptive (`/rai-prescriptive-problem-formulation` + `/rai-prescriptive-results-interpretation`) to solve a minimal set-cover diagnosis and explain why it prefers the deep root over its proximate carriers. +Plans the backward chain on the shared ontology: graph (`/rai-graph-analysis`) to close the lot genealogy transitively and attribute every upstream lot to the units that carry it; rules (`/rai-pyrel`) to contrast-score each candidate factor by defect lift versus baseline and screen out high-coverage / low-lift factors; prescriptive (`/rai-prescriptive-problem` + `/rai-prescriptive-results`) to solve a minimal set-cover diagnosis and explain why it prefers the deep root over its proximate carriers. ### 5. Trace genealogy backward @@ -99,7 +99,7 @@ A directed parent -> child genealogy graph on `Lot` (105 nodes, 162 edges); `rea **Prompt** ``` -/rai-rules-authoring Score each candidate factor by how concentrated defects are among the units it touches. Define lift as the factor's defect rate — defective units touched divided by units touched — divided by the plant-wide baseline failure rate (5.68%). Flag a factor as a suspect when its lift is at least 1.5, it touches at least 30 units, and at least 5 of those are defective, so a near-universal lot or the busiest machine — high coverage but baseline lift — is screened out. +/rai-pyrel Score each candidate factor by how concentrated defects are among the units it touches. Define lift as the factor's defect rate — defective units touched divided by units touched — divided by the plant-wide baseline failure rate (5.68%). Flag a factor as a suspect when its lift is at least 1.5, it touches at least 30 units, and at least 5 of those are defective, so a near-universal lot or the busiest machine — high coverage but baseline lift — is screened out. ``` **Response** @@ -111,7 +111,7 @@ Derived `Factor.touched_count`, `Factor.defect_count`, `Factor.defect_rate`, and **Prompt** ``` -/rai-prescriptive-problem-formulation From the suspect factors, find the smallest, most specific set that together explains the defective units. Name as few factors as possible — each named factor carries a fixed cost — and penalize naming a factor that also touches many good (non-defective) units. Allow a defective unit to be left unexplained at a cost rather than forcing in a spurious cause. Every defective unit must be explained by a named factor it touches, or marked unexplained. +/rai-prescriptive-problem From the suspect factors, find the smallest, most specific set that together explains the defective units. Name as few factors as possible — each named factor carries a fixed cost — and penalize naming a factor that also touches many good (non-defective) units. Allow a defective unit to be left unexplained at a cost rather than forcing in a spurious cause. Every defective unit must be explained by a named factor it touches, or marked unexplained. ``` **Response** @@ -123,7 +123,7 @@ Status OPTIMAL, objective 46.32 (24.32 in factor-selection cost plus 22 unexplai **Prompt** ``` -/rai-prescriptive-results-interpretation What is the final diagnosis — which factors, how many defects do they explain, and what evidence supports each? Why did the optimizer name the solder-paste lot rather than the three populated-board lots that scored higher on lift? +/rai-prescriptive-results What is the final diagnosis — which factors, how many defects do they explain, and what evidence supports each? Why did the optimizer name the solder-paste lot rather than the three populated-board lots that scored higher on lift? ``` **Response** @@ -135,7 +135,7 @@ Two root causes explain 85% of the failures, each with corroborating evidence: ` **Prompt** ``` -/rai-ontology-design Materialize the diagnosis as queryable ontology: a DiagnosisResult singleton holding the defective-unit count, units explained, coverage, and number of root causes, and mark the named factors on Factor.is_root_cause. +/rai-ontology Materialize the diagnosis as queryable ontology: a DiagnosisResult singleton holding the defective-unit count, units explained, coverage, and number of root causes, and mark the named factors on Factor.is_root_cause. ``` **Response** diff --git a/v1/demand_forecasting/README.md b/v1/demand_forecasting/README.md index adddac93..9e6b08f3 100644 --- a/v1/demand_forecasting/README.md +++ b/v1/demand_forecasting/README.md @@ -240,7 +240,7 @@ The bundled `favorita_mini` is intentionally tiny so the template runs in minute 1. Download the dataset from [Kaggle: Corporación Favorita Grocery Sales Forecasting](https://www.kaggle.com/c/favorita-grocery-sales-forecasting). License is "Subject to Competition Rules" — review before redistributing. 2. Load the CSVs into Snowflake (`stores.csv`, `items.csv`, `train.csv` is the sales table). Rename `train.csv → sales.csv` to match the template. -3. Replace the `pd.read_csv(...)` calls at the top of the script with Snowpark queries against your loaded tables (or use `model.Table("..")` per `rai-pyrel-coding` skill's data-loading guidance): +3. Replace the `pd.read_csv(...)` calls at the top of the script with Snowpark queries against your loaded tables (or use `model.Table("..
")` per `rai-pyrel` skill's data-loading guidance): ```python from relationalai.config import SnowflakeConnection, create_config from snowflake import snowpark diff --git a/v1/demand_forecasting/runbook.md b/v1/demand_forecasting/runbook.md index 21184589..edfe281e 100644 --- a/v1/demand_forecasting/runbook.md +++ b/v1/demand_forecasting/runbook.md @@ -21,13 +21,13 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/favorita_mini/stores.csv` (each store has a city, state, type, and cluster), `data/favorita_mini/items.csv` (each item has a family, class, and perishable flag), and `data/favorita_mini/sales.csv` (one row per store-item-date with unit sales and an on-promotion flag). Derive an item-family concept from the item families. +**Prompt:** /rai-ontology Build an ontology from `data/favorita_mini/stores.csv` (each store has a city, state, type, and cluster), `data/favorita_mini/items.csv` (each item has a family, class, and perishable flag), and `data/favorita_mini/sales.csv` (one row per store-item-date with unit sales and an on-promotion flag). Derive an item-family concept from the item families. **Response:** Loads `Store` (3, with city/state/type/cluster), `Item` (25, with family/class/perishable), a derived `ItemFamily` (from the distinct item families), and `Sale` (~27,375 rows, each with `unit_sales`, `date`, and `onpromotion`, linked to its store and item). ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? **Response:** Four concepts — 3 `Store`, 25 `Item`, the derived `ItemFamily`, and ~27,375 `Sale` (one per store-item-date) — the history the forecaster learns from. diff --git a/v1/demand_planning_temporal/runbook.md b/v1/demand_planning_temporal/runbook.md index dd153ba8..871707f7 100644 --- a/v1/demand_planning_temporal/runbook.md +++ b/v1/demand_planning_temporal/runbook.md @@ -6,7 +6,7 @@ A supply planner wants a least-cost, multi-week production-and-inventory plan: h 3 sites · 3 SKUs · 25 dated demand orders · per-site-SKU capacity + opening inventory │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decision: weekly production, end-of-week inventory, and unmet demand (all continuous ≥ 0) • constraints: inventory flow (inv[t] = inv[t-1] + production − demand); capacity; 95% service level; safety stock ≥ 1 week of average demand @@ -14,7 +14,7 @@ A supply planner wants a least-cost, multi-week production-and-inventory plan: h • horizons ending Jan / Feb / Mar in a scenario sweep -> OPTIMAL all three; cost is pure holding, rising with horizon │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • all demand met (0 unmet) in every horizon; cost rises with the horizon length • the abundant opening inventory covers demand — zero production, cost is pure holding ``` @@ -25,25 +25,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/sites.csv` (each site has a weekly capacity), `data/skus.csv` (each SKU has a unit cost and a weekly holding cost), `data/demand_orders.csv` (each order is a quantity of one SKU due at one site on a due date), `data/production_capacity.csv` (max production per week and production cost for each site-SKU pair), and `data/initial_inventory.csv` (opening inventory per site-SKU). Link orders and capacities to their site and SKU. +**Prompt:** /rai-ontology Build an ontology from `data/sites.csv` (each site has a weekly capacity), `data/skus.csv` (each SKU has a unit cost and a weekly holding cost), `data/demand_orders.csv` (each order is a quantity of one SKU due at one site on a due date), `data/production_capacity.csv` (max production per week and production cost for each site-SKU pair), and `data/initial_inventory.csv` (opening inventory per site-SKU). Link orders and capacities to their site and SKU. **Response:** Loads `Site` (3: Chicago_DC, Atlanta_DC, Dallas_DC, each with `capacity_per_week`), `SKU` (3: Widget_A, Widget_B, Gadget_C, with `unit_cost` and `holding_cost_per_week`), `DemandOrder` (25, with `quantity` and `due_date`, linked to site and SKU), and `ProdCapacity` (9 site-SKU pairs, with `max_production_per_week`, `production_cost`, and opening inventory). ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? **Response:** Four concepts — 3 `Site`, 3 `SKU`, 25 `DemandOrder` (linked to site and SKU), and 9 `ProdCapacity` (one per site-SKU pair, carrying capacity, production cost, and opening inventory). The orders span October 2025 through March 2026. ## 3. Build the least-cost multi-week plan across horizons -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Map each order's due date to a week and build a weekly time grid, then decide weekly production, end-of-week inventory, and any unmet demand per site-SKU (all non-negative). Inventory must carry over week to week — end-of-week inventory equals last week's inventory plus this week's production minus this week's demand, starting from opening inventory — weekly production can't exceed capacity, at least 95% of total demand must be met, and end-of-week inventory must stay above one week of average demand (safety stock). Minimize total cost — production plus holding plus a penalty on unmet demand. Solve three planning horizons in a scenario sweep — ending 2026-01-31, 2026-02-28, and 2026-03-31 — and persist the decisions to the ontology. +**Prompt:** /rai-prescriptive-problem Map each order's due date to a week and build a weekly time grid, then decide weekly production, end-of-week inventory, and any unmet demand per site-SKU (all non-negative). Inventory must carry over week to week — end-of-week inventory equals last week's inventory plus this week's production minus this week's demand, starting from opening inventory — weekly production can't exceed capacity, at least 95% of total demand must be met, and end-of-week inventory must stay above one week of average demand (safety stock). Minimize total cost — production plus holding plus a penalty on unmet demand. Solve three planning horizons in a scenario sweep — ending 2026-01-31, 2026-02-28, and 2026-03-31 — and persist the decisions to the ontology. **Response:** OPTIMAL in all three horizons (HiGHS). Total cost **rises with the horizon** — a longer plan carries the same inventory for more weeks and pulls in more orders, so more holding cost accrues. (The absolute dollar totals depend on the planning-start date and how the weekly grid is anchored, so the reproducible result is the upward trend across horizons, not a specific figure.) Production, inventory, and unmet decisions are written back as `ProdCapacity.x_production`, `ProdCapacity.x_inventory`, and `DemandOrder.x_unmet`. ## 4. Read the plan across horizons -**Prompt:** /rai-prescriptive-results-interpretation Is all demand met in each horizon, what drives the cost, and why does cost rise as the horizon extends? +**Prompt:** /rai-prescriptive-results Is all demand met in each horizon, what drives the cost, and why does cost rise as the horizon extends? **Response:** All demand is met in every horizon — **unmet demand is zero** throughout, so the service-level and safety-stock constraints hold with slack. With opening inventory abundant relative to in-scope demand, the optimal plan **produces nothing and draws demand down from inventory**, so total cost is essentially holding cost on carried stock. Extending the horizon from January to March pulls in more weeks and more orders, accumulating more holding cost — which is why cost climbs steadily across the three horizons. diff --git a/v1/diet/runbook.md b/v1/diet/runbook.md index 394f4535..7fa7118a 100644 --- a/v1/diet/runbook.md +++ b/v1/diet/runbook.md @@ -6,14 +6,14 @@ A nutritionist wants the cheapest daily food basket that still meets every nutri 9 foods x 4 nutrients (calories, protein, fat, sodium), each nutrient has a [min, max] bound │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decision: a continuous amount per (food, scenario), at least 0 • constraint: each nutrient's total intake within [min, max] scaled by the scenario • objective: minimize total cost summed across all three scenarios • single solve over scenarios 0.8 / 1.0 / 1.2 -> OPTIMAL, $35.49 total (HiGHS) │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • basket = hamburger + icecream + milk in every scenario • per-scenario cost: $9.46 (0.8) / $11.83 (1.0) / $14.19 (1.2) — scales linearly ``` @@ -24,25 +24,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/nutrients.csv` (each nutrient has min/max bounds) and `data/foods.csv` (each food has a cost plus one column per nutrient). Model food-to-nutrient content as a ternary relationship — a food contains a nutrient in some quantity. +**Prompt:** /rai-ontology Build an ontology from `data/nutrients.csv` (each nutrient has min/max bounds) and `data/foods.csv` (each food has a cost plus one column per nutrient). Model food-to-nutrient content as a ternary relationship — a food contains a nutrient in some quantity. **Response:** Loads `Nutrient` (properties `min`, `max`) and `Food` (property `cost`), plus a ternary `Food.contains(Nutrient) -> qty` relationship populated from the per-nutrient columns. 4 nutrients (calories, protein, fat, sodium) and 9 foods. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? **Response:** Two concepts — 4 `Nutrient` (calories 1800–2200, protein 91–200, fat 0–65, sodium 0–1779) and 9 `Food` (hamburger, chicken, hotdog, fries, macaroni, pizza, salad, milk, icecream) — linked by the `contains` ternary with 36 food-nutrient quantity rows (9 foods x 4 nutrients). ## 3. Minimize cost across requirement scenarios -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management What's the minimum-cost amount of each food (continuous, non-negative) that keeps every nutrient's total intake within its [min, max] bounds? Solve three requirement scenarios in one solve — bounds scaled to 80%, 100%, and 120% — with the scenario as a first-class concept and the amount decision indexed by (food, scenario). Minimize total cost across all three, and persist the amounts to the ontology. +**Prompt:** /rai-prescriptive-problem What's the minimum-cost amount of each food (continuous, non-negative) that keeps every nutrient's total intake within its [min, max] bounds? Solve three requirement scenarios in one solve — bounds scaled to 80%, 100%, and 120% — with the scenario as a first-class concept and the amount decision indexed by (food, scenario). Minimize total cost across all three, and persist the amounts to the ontology. **Response:** OPTIMAL (HiGHS), total objective $35.49 across the three scenarios. The amount decision is written back as `Food.x_amount(Scenario) -> amount` so the next step can read it; the solve is sub-second (18 simplex iterations). ## 4. Read the per-scenario diet plan -**Prompt:** /rai-prescriptive-results-interpretation For each scenario, which foods are selected and in what amount, and what is each scenario's total cost? How does cost respond as the requirements scale up and down? +**Prompt:** /rai-prescriptive-results For each scenario, which foods are selected and in what amount, and what is each scenario's total cost? How does cost respond as the requirements scale up and down? **Response:** The optimal basket is the same three foods in every scenario — hamburger, icecream, and milk — scaled proportionally. Per-scenario cost is $9.46 at 0.8x, $11.83 at baseline, and $14.19 at 1.2x. Because every bound scales by the same factor and the model is a pure linear program, both the amounts and the cost scale linearly with the requirement multiplier (the 0.8x and 1.2x baskets are exactly 0.8 and 1.2 times the baseline). diff --git a/v1/disease-outbreak-prevention/runbook.md b/v1/disease-outbreak-prevention/runbook.md index 509eeda5..4fcd930d 100644 --- a/v1/disease-outbreak-prevention/runbook.md +++ b/v1/disease-outbreak-prevention/runbook.md @@ -18,13 +18,13 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/facilities.csv` (each facility has a type and a region) and `data/connections.csv` (each directed connection links two facilities and has a patient transfer volume and a contact intensity). Derive a risk weight as transfer volume times contact intensity, and model the connection as a directed relationship from one facility to another carrying that risk weight. +**Prompt:** /rai-ontology Build an ontology from `data/facilities.csv` (each facility has a type and a region) and `data/connections.csv` (each directed connection links two facilities and has a patient transfer volume and a contact intensity). Derive a risk weight as transfer volume times contact intensity, and model the connection as a directed relationship from one facility to another carrying that risk weight. **Response:** Loads `Facility` (10: hospitals, clinics, testing centers, government and emergency services across 5 regions) and `FacilityConnection` (15 directed links, each with `transfer_volume`, `contact_intensity`, and a derived `risk_weight`) — a directed, risk-weighted transmission graph. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many of each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many of each? **Response:** One node concept, `Facility` (10), connected by `FacilityConnection` (15 directed, risk-weighted edges) — about 3 connections per facility. diff --git a/v1/energy_grid_planning/runbook.md b/v1/energy_grid_planning/runbook.md index 3ba9c4fd..b9382c4c 100644 --- a/v1/energy_grid_planning/runbook.md +++ b/v1/energy_grid_planning/runbook.md @@ -51,7 +51,7 @@ $300M unlocks 5 DCs (1,500 MW, $264M net value) including xAI Colossus. **Prompt** ``` -/rai-build-starter-ontology Build an ontology for grid infrastructure planning from the CSVs in data/. +/rai-ontology Build an ontology for grid infrastructure planning from the CSVs in data/. ``` **Response** @@ -63,7 +63,7 @@ Concepts: `Substation`, `Generator`, `TransmissionLine`, `LoadZone`, `DemandPeri **Prompt** ``` -/rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +/rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? ``` **Response** @@ -123,7 +123,7 @@ Plan routing sub-questions to predictive, graph, rules, and prescriptive reasone **Prompt** ``` -/rai-rules-authoring Screen each data center request against three criteria: (1) substation must have enough capacity after predicted load, (2) substation's low-carbon (renewable + nuclear) generation share must meet the DC's low-carbon requirement, (3) substation shouldn't be one of the top-3 structurally critical. Which requests pass all three? +/rai-pyrel Screen each data center request against three criteria: (1) substation must have enough capacity after predicted load, (2) substation's low-carbon (renewable + nuclear) generation share must meet the DC's low-carbon requirement, (3) substation shouldn't be one of the top-3 structurally critical. Which requests pass all three? ``` **Response** @@ -135,7 +135,7 @@ Plan routing sub-questions to predictive, graph, rules, and prescriptive reasone **Prompt** ``` -/rai-prescriptive-problem-formulation Which data center requests should we approve and which substation upgrades should we fund at each of the five investment levels ($200M, $300M, $400M, $500M, $600M), maximizing annual revenue across all five in a single solve? A request can only be approved if its substation has enough capacity after upgrades, and total upgrade spend at each level must stay within budget. Consider all 10 requests — the compliance flags from the rules screen are informational, not hard filters. +/rai-prescriptive-problem Which data center requests should we approve and which substation upgrades should we fund at each of the five investment levels ($200M, $300M, $400M, $500M, $600M), maximizing annual revenue across all five in a single solve? A request can only be approved if its substation has enough capacity after upgrades, and total upgrade spend at each level must stay within budget. Consider all 10 requests — the compliance flags from the rules screen are informational, not hard filters. ``` **Response** @@ -147,7 +147,7 @@ OPTIMAL MIP across 5 `InvestmentLevel` values in one solve; `x_approve` and `x_u **Prompt** ``` -/rai-prescriptive-results-interpretation Which data centers get approved and which upgrades are selected at each budget level, and where's the knee — the budget where the marginal net value per added dollar starts to drop sharply? +/rai-prescriptive-results Which data centers get approved and which upgrades are selected at each budget level, and where's the knee — the budget where the marginal net value per added dollar starts to drop sharply? ``` **Response** @@ -159,7 +159,7 @@ Pareto frontier with knee at $300M (5 DCs, 1,500 MW, $264M net); marginal $995K/ **Prompt** ``` -/rai-ontology-design Add an InvestmentPortfolio concept indexed by InvestmentLevel that materializes the per-budget aggregates (approved-DC count, total MW, annual revenue, upgrade cost, net value, marginal value per added $M) and flags the knee point. +/rai-ontology Add an InvestmentPortfolio concept indexed by InvestmentLevel that materializes the per-budget aggregates (approved-DC count, total MW, annual revenue, upgrade cost, net value, marginal value per added $M) and flags the knee point. ``` **Response** diff --git a/v1/entity_resolution/runbook.md b/v1/entity_resolution/runbook.md index 452f613e..9f39a41e 100644 --- a/v1/entity_resolution/runbook.md +++ b/v1/entity_resolution/runbook.md @@ -12,9 +12,9 @@ record level, and cedes $927k of excess exposure to reinsurance for $111k. ───────────────────────────────────────────────────────────────── SETUP Ontology + candidates ──► Record (51), CandidateMatch (25), - /rai-build-starter-ontology, ReviewPair (1). Blocking -> 28 candidate - /rai-pyrel-coding pairs; two bands: >= 0.70 auto-merge, - [0.55, 0.70) held for review. + /rai-ontology, ReviewPair (1). Blocking -> 28 candidate + /rai-pyrel pairs; two bands: >= 0.70 auto-merge, + [0.55, 0.70) held for review. ───────────────────────────────────────────────────────────────── STAGE 1 Graph ──► Record.entity_key (31 auto-resolved parties) /rai-graph-analysis Weakly-connected-components over the auto-merge @@ -22,15 +22,15 @@ record level, and cedes $927k of excess exposure to reinsurance for $111k. records). ───────────────────────────────────────────────────────────────── STAGE 2 Rules ──► CandidateMatch.confidence_tier; Record.is_duplicate; - /rai-rules-authoring ResolvedParty.total_exposure + is_over_limit. + /rai-pyrel ResolvedParty.total_exposure + is_over_limit. 0 record-level breaches -> 4 resolved households. ───────────────────────────────────────────────────────────────── STAGE 3 Prescriptive ──► ResolvedParty.cede (reinsurance knapsack) - /rai-prescriptive- OPTIMAL: cede Fitzgerald + Chen -> $927,000 of - problem-formulation excess exposure for $111,240 of the $120,000 budget. + /rai-prescriptive-problem OPTIMAL: cede Fitzgerald + Chen -> $927,000 of + excess exposure for $111,240 of the $120,000 budget. ───────────────────────────────────────────────────────────────── STAGE 4 Interpret ──► record-vs-resolved breach contrast; review queue - /rai-querying (+1 hidden breach); precision 1.000 / recall 0.963. + /rai-pyrel (+1 hidden breach); precision 1.000 / recall 0.963. ───────────────────────────────────────────────────────────────── ``` @@ -43,7 +43,7 @@ record level, and cedes $927k of excess exposure to reinsurance for $111k. **Prompt** ``` -/rai-build-starter-ontology Build an entity-resolution ontology from data/records.csv. Create a Record concept identified by record_id. Load the always-present columns (source_system, full_name, street, city, state, postal_code, created_at, coverage_amount) by schema; read coverage_amount as a float. Load the optional columns (email, phone, date_of_birth, gov_id_last4) only for the rows where they are non-empty, so a missing value stays null instead of dropping the whole record. +/rai-ontology Build an entity-resolution ontology from data/records.csv. Create a Record concept identified by record_id. Load the always-present columns (source_system, full_name, street, city, state, postal_code, created_at, coverage_amount) by schema; read coverage_amount as a float. Load the optional columns (email, phone, date_of_birth, gov_id_last4) only for the rows where they are non-empty, so a missing value stays null instead of dropping the whole record. ``` **Response** @@ -55,7 +55,7 @@ record level, and cedes $927k of excess exposure to reinsurance for $111k. **Prompt** ``` -/rai-querying How many records are there per source system, how complete are the matchable identifiers (email, phone, date of birth, government-ID fragment), and does any single policy's coverage already exceed a $1,000,000 accumulation limit? +/rai-pyrel How many records are there per source system, how complete are the matchable identifiers (email, phone, date of birth, government-ID fragment), and does any single policy's coverage already exceed a $1,000,000 accumulation limit? ``` **Response** @@ -67,7 +67,7 @@ record level, and cedes $927k of excess exposure to reinsurance for $111k. **Prompt** ``` -/rai-pyrel-coding Generate candidate duplicate pairs and split them into two bands. Block first: only compare records that share a normalized email handle, the same last-10-digit phone, the same first-four-of-last-name plus 3-digit postal prefix, or the same date of birth. Score each candidate in [0,1]: +0.45 full email match (or +0.32 handle-only), +0.42 phone, +0.30 date of birth, +0.20 government-ID fragment, +0.30 * Jaro-Winkler on names (fold nicknames like Bob->Robert first), +0.15 * Jaro-Winkler on the full address. The fuzzy scoring runs in pandas (no string-similarity primitive in PyRel). Load pairs scoring >= 0.70 as a CandidateMatch concept (auto-merge) and pairs in [0.55, 0.70) as a ReviewPair concept (held for a steward), each with rec_a, rec_b, and score. +/rai-pyrel Generate candidate duplicate pairs and split them into two bands. Block first: only compare records that share a normalized email handle, the same last-10-digit phone, the same first-four-of-last-name plus 3-digit postal prefix, or the same date of birth. Score each candidate in [0,1]: +0.45 full email match (or +0.32 handle-only), +0.42 phone, +0.30 date of birth, +0.20 government-ID fragment, +0.30 * Jaro-Winkler on names (fold nicknames like Bob->Robert first), +0.15 * Jaro-Winkler on the full address. The fuzzy scoring runs in pandas (no string-similarity primitive in PyRel). Load pairs scoring >= 0.70 as a CandidateMatch concept (auto-merge) and pairs in [0.55, 0.70) as a ReviewPair concept (held for a steward), each with rec_a, rec_b, and score. ``` **Response** @@ -91,7 +91,7 @@ Weakly-connected-components over 51 nodes and 25 auto-merge edges resolves the r **Prompt** ``` -/rai-rules-authoring Classify each auto-merge CandidateMatch by confidence: HIGH at or above 0.90, otherwise MEDIUM. Separately, flag every record whose resolved party contains more than one record as a duplicate. +/rai-pyrel Classify each auto-merge CandidateMatch by confidence: HIGH at or above 0.90, otherwise MEDIUM. Separately, flag every record whose resolved party contains more than one record as a duplicate. ``` **Response** @@ -103,7 +103,7 @@ Weakly-connected-components over 51 nodes and 25 auto-merge edges resolves the r **Prompt** ``` -/rai-rules-authoring For each resolved party, total the coverage across its policies, and flag the parties whose total exposure exceeds the $1,000,000 accumulation limit. How many policies breach the limit at the record level versus how many households breach it after resolution? +/rai-pyrel For each resolved party, total the coverage across its policies, and flag the parties whose total exposure exceeds the $1,000,000 accumulation limit. How many policies breach the limit at the record level versus how many households breach it after resolution? ``` **Response** @@ -115,7 +115,7 @@ A `ResolvedParty` per party key carries `total_exposure` (summed `coverage_amoun **Prompt** ``` -/rai-prescriptive-problem-formulation We can spend a $120,000 reinsurance premium this period, at a 12% rate on line, to cede the excess exposure of breached households (premium = 12% of the amount over the limit). Which households should we cede to transfer the most excess exposure off the book? Each breached household is cede-or-not (binary), total premium must stay within budget, and we maximize the excess exposure ceded. +/rai-prescriptive-problem We can spend a $120,000 reinsurance premium this period, at a 12% rate on line, to cede the excess exposure of breached households (premium = 12% of the amount over the limit). Which households should we cede to transfer the most excess exposure off the book? Each breached household is cede-or-not (binary), total premium must stay within budget, and we maximize the excess exposure ceded. ``` **Response** @@ -127,7 +127,7 @@ A binary `ResolvedParty.cede` over the 4 breached households; budget constraint **Prompt** ``` -/rai-querying How many matches are held in the review queue, and would confirming them change the accumulation picture? Also score the auto-resolution against the ground_truth.csv labels: pairwise precision, recall, and F1. +/rai-pyrel How many matches are held in the review queue, and would confirming them change the accumulation picture? Also score the auto-resolution against the ground_truth.csv labels: pairwise precision, recall, and F1. ``` **Response** diff --git a/v1/factory_production/runbook.md b/v1/factory_production/runbook.md index be0ecd0e..ca0e9a06 100644 --- a/v1/factory_production/runbook.md +++ b/v1/factory_production/runbook.md @@ -6,14 +6,14 @@ A manufacturing planner wants the most profitable production plan across two fac 2 factories (resource-hours) x 4 products (rate units/hr, profit, demand cap) │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decision: continuous quantity per product, 0 ≤ qty ≤ demand cap • constraint: per factory, sum(qty / rate) ≤ available resource-hours • objective: maximize sum(profit x qty); solve with sensitivity marginals on • HiGHS linear program -> OPTIMAL, $200,000 total profit │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • plan: bands 6000, coils 1400, stouts 1000, ales 2000 • steel_factory capacity is binding (shadow price $4,200/hr, 0 idle hours) • amazing_brewery is demand-bound (5 idle hours); coils is the swing product @@ -25,25 +25,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/factories.csv` (each factory has available resource-hours) and `data/products.csv` (each product belongs to a factory and has a production rate in units per hour, a per-unit profit, and a demand cap). Link each product to its factory. +**Prompt:** /rai-ontology Build an ontology from `data/factories.csv` (each factory has available resource-hours) and `data/products.csv` (each product belongs to a factory and has a production rate in units per hour, a per-unit profit, and a demand cap). Link each product to its factory. **Response:** Loads `Factory` (2: steel_factory 40 hrs, amazing_brewery 30 hrs) and `Product` (4, each with `rate`, `profit`, `demand`, linked to its factory) — steel_factory makes bands and coils, amazing_brewery makes stouts and ales. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many of each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many of each? **Response:** Two concepts — 2 `Factory` (with `avail` resource-hours) and 4 `Product` (with `rate`, `profit`, `demand`, each linked to its factory). Each factory makes two products. ## 3. Find the most profitable production plan -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management How many units of each product should we make to maximize total profit, given each factory's limited resource-hours and each product's demand cap? Model the demand cap as the upper bound on each product's quantity (so its marginal reads back as a reduced cost), require each factory's total resource usage — the sum of quantity divided by rate — to stay within its available hours, and solve with sensitivity analysis on so capacity shadow prices and product reduced costs come back too. +**Prompt:** /rai-prescriptive-problem How many units of each product should we make to maximize total profit, given each factory's limited resource-hours and each product's demand cap? Model the demand cap as the upper bound on each product's quantity (so its marginal reads back as a reduced cost), require each factory's total resource usage — the sum of quantity divided by rate — to stay within its available hours, and solve with sensitivity analysis on so capacity shadow prices and product reduced costs come back too. **Response:** OPTIMAL (HiGHS), total profit **$200,000** (relative gap 0.0). 4 continuous quantity variables, 2 capacity constraints. The plan, capacity shadow prices (keyed by factory), and per-product reduced costs and basis status are all available from the solve handles. ## 4. Read the plan and the marginals -**Prompt:** /rai-prescriptive-results-interpretation What's the optimal quantity per product, which factory's capacity should we expand first, and which products are limited by demand rather than capacity? +**Prompt:** /rai-prescriptive-results What's the optimal quantity per product, which factory's capacity should we expand first, and which products are limited by demand rather than capacity? **Response:** Plan: bands 6000, coils 1400 (steel_factory); stouts 1000, ales 2000 (amazing_brewery). **steel_factory** is the binding capacity — 0 idle hours and a shadow price of **$4,200 per added hour** (the profit-per-hour of coils, its swing product), so it's the one to expand first. **amazing_brewery** has 5 idle hours and is demand-bound, not capacity-bound. Bands, stouts, and ales sit at their demand caps (nonbasic-at-upper, positive reduced cost); **coils** is the single swing product (basic, reduced cost 0) absorbing steel_factory's remaining capacity. diff --git a/v1/financial_index_replication/runbook.md b/v1/financial_index_replication/runbook.md index 05a5a8cc..9f45c7b9 100644 --- a/v1/financial_index_replication/runbook.md +++ b/v1/financial_index_replication/runbook.md @@ -6,7 +6,7 @@ A portfolio manager wants to track a broad benchmark without holding all of its 50-stock universe (benchmark weight, sector, ADV) · 42 months of returns · benchmark index returns │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decisions: pick 20 names (binary) + weights (continuous) + monthly tracking residuals • constraints: exactly 20 names; weights sum to 1; ≤ 10% per name; sectors within ±4% of benchmark; trading-capacity (ADV) limit; residual = benchmark − basket return each month @@ -14,7 +14,7 @@ A portfolio manager wants to track a broad benchmark without holding all of its • HiGHS mixed-integer program (240s cap) -> feasible basket, ~0.4% annualized tracking error │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • the 20-name basket tracks the benchmark to well under 1% annualized error • several times tighter than an equal-weight top-20 baseline (~2.6%); solve is time-limited ``` @@ -25,25 +25,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/stocks.csv` (each stock has a benchmark weight, a sector, an average dollar volume, and a previous weight), `data/index_returns.csv` (the benchmark's monthly return per date), and `data/stock_returns.csv` (each stock's monthly return per date). Derive sectors from the stocks, and model the stock return as a relationship from a stock to a date carrying that month's return. +**Prompt:** /rai-ontology Build an ontology from `data/stocks.csv` (each stock has a benchmark weight, a sector, an average dollar volume, and a previous weight), `data/index_returns.csv` (the benchmark's monthly return per date), and `data/stock_returns.csv` (each stock's monthly return per date). Derive sectors from the stocks, and model the stock return as a relationship from a stock to a date carrying that month's return. **Response:** Loads `Stock` (50, with `benchmark_weight`, `sector`, `avg_dollar_volume`, `previous_weight`), `ReturnDate` (42 monthly dates with the benchmark `index_return`), a derived `Sector` (7, carrying each sector's aggregated benchmark weight), and a `Stock.return_on(ReturnDate)` relationship (2,100 stock-month returns). ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? **Response:** Concepts — 50 `Stock`, 42 `ReturnDate` (with `index_return`), and a derived `Sector` (7: Technology, Healthcare, Consumer Discretionary, Financials, Industrials, Consumer Staples, Energy) — linked by `return_on` with 2,100 stock-month return rows (50 stocks x 42 months). ## 3. Build the replication basket -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Which 20 stocks, and at what weights, best replicate the benchmark's monthly returns? Select exactly 20 names (binary) and assign continuous weights that sum to 1, with at most 10% in any one name and a weight only if the name is selected; keep each sector within ±4% of its benchmark weight; respect a trading-capacity limit (the change from the previous weight, scaled by a $10 million portfolio value, can't exceed 5% of a stock's average dollar volume); and define each month's tracking residual as benchmark return minus basket return. Minimize the total absolute monthly tracking error, and persist the selection and weights to the ontology. +**Prompt:** /rai-prescriptive-problem Which 20 stocks, and at what weights, best replicate the benchmark's monthly returns? Select exactly 20 names (binary) and assign continuous weights that sum to 1, with at most 10% in any one name and a weight only if the name is selected; keep each sector within ±4% of its benchmark weight; respect a trading-capacity limit (the change from the previous weight, scaled by a $10 million portfolio value, can't exceed 5% of a stock's average dollar volume); and define each month's tracking residual as benchmark return minus basket return. Minimize the total absolute monthly tracking error, and persist the selection and weights to the ontology. **Response:** Returns a 20-name basket. The decision is `Stock.x_selected` (exactly 20 names) plus `Stock.x_weight` (summing to 1) and per-month residual variables. This is a cardinality-constrained tracking MILP: depending on the solver it either solves to OPTIMAL or returns a strong feasible incumbent at the time limit — either way the exact names and weights can vary, so treat the tracking quality below, not a specific basket, as the result. ## 4. Assess tracking quality -**Prompt:** /rai-prescriptive-results-interpretation How closely does the basket track the benchmark (annualized tracking error), and how does it compare to a naive equal-weight basket of the 20 stocks most correlated with the benchmark? +**Prompt:** /rai-prescriptive-results How closely does the basket track the benchmark (annualized tracking error), and how does it compare to a naive equal-weight basket of the 20 stocks most correlated with the benchmark? **Response:** The optimized 20-name basket tracks the benchmark to a **low annualized tracking error — on the order of ~0.4%** (the exact figure varies with the solver and solve settings) — **materially tighter than the naive equal-weight top-20-by-correlation baseline (~2.6%)**. It holds sector neutrality within the ±4% band (Energy and Consumer Staples sit closest to the edge). The reproducible headline is that the optimized basket tracks well under the naive one, not any single name list. diff --git a/v1/fraud-detection/runbook.md b/v1/fraud-detection/runbook.md index f162d26e..d5ea1434 100644 --- a/v1/fraud-detection/runbook.md +++ b/v1/fraud-detection/runbook.md @@ -42,7 +42,7 @@ about +40% over a naive sort-by-score. **Prompt** ``` -/rai-build-starter-ontology Build an ontology from the PaySim mobile-money Snowflake schema: accounts (each with an id and an account-type prefix), transactions (each with a type, an amount, sender and receiver balance changes, the sender and receiver accounts, an existing fraud flag, and an audit cost), and the train / validation / test split tables that label transactions as fraud or not. Model a transaction's sender and receiver as relationships to accounts. +/rai-ontology Build an ontology from the PaySim mobile-money Snowflake schema: accounts (each with an id and an account-type prefix), transactions (each with a type, an amount, sender and receiver balance changes, the sender and receiver accounts, an existing fraud flag, and an audit cost), and the train / validation / test split tables that label transactions as fraud or not. Model a transaction's sender and receiver as relationships to accounts. ``` **Response** @@ -54,7 +54,7 @@ Loads `Account` (~32,661: customer and merchant prefixes), `Transaction` (~16,42 **Prompt** ``` -/rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +/rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? ``` **Response** @@ -90,7 +90,7 @@ PageRank runs over the account funds-flow graph; `Account.pagerank` is written b **Prompt** ``` -/rai-rules-authoring For each account, count how many transactions it sends, and persist it as Account.activity_count for use as a model feature. +/rai-pyrel For each account, count how many transactions it sends, and persist it as Account.activity_count for use as a model feature. ``` **Response** @@ -114,7 +114,7 @@ A GNN binary classifier trains on the transaction-account graph (features includ **Prompt** ``` -/rai-rules-authoring Combine the existing fraud flag and the model's probability into a single alert score — 30% the flag, 70% the predicted probability — and persist it as Transaction.alert_score. +/rai-pyrel Combine the existing fraud flag and the model's probability into a single alert score — 30% the flag, 70% the predicted probability — and persist it as Transaction.alert_score. ``` **Response** @@ -126,7 +126,7 @@ A GNN binary classifier trains on the transaction-account graph (features includ **Prompt** ``` -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Choose which test transactions to audit to maximize captured expected loss — alert score times amount — within a 2,000 investigator-hour budget (each audit costs its transaction's audit_cost in hours), with at most one audit per receiving account. Persist the audit decision as Transaction.x_audit. +/rai-prescriptive-problem Choose which test transactions to audit to maximize captured expected loss — alert score times amount — within a 2,000 investigator-hour budget (each audit costs its transaction's audit_cost in hours), with at most one audit per receiving account. Persist the audit decision as Transaction.x_audit. ``` **Response** @@ -138,7 +138,7 @@ OPTIMAL (HiGHS knapsack MILP), capturing about **$1.70B** of expected loss withi **Prompt** ``` -/rai-prescriptive-results-interpretation How much more expected loss does the optimized audit queue capture than a naive queue that just sorts by alert score until the budget runs out? +/rai-prescriptive-results How much more expected loss does the optimized audit queue capture than a naive queue that just sorts by alert score until the budget runs out? ``` **Response** diff --git a/v1/hospital_staffing/runbook.md b/v1/hospital_staffing/runbook.md index b683fefd..0e3a6c62 100644 --- a/v1/hospital_staffing/runbook.md +++ b/v1/hospital_staffing/runbook.md @@ -6,7 +6,7 @@ A nurse manager faces a real tradeoff: minimize overtime cost, or minimize unmet 6 nurses (cost, skill) · 3 shifts (demand 45/60/25, min staff & skill) · 18 availability pairs │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decision: binary nurse-shift assignment + overtime hours + unmet demand per shift • constraints: availability; each nurse 1–2 shifts; min staff & skill per shift; patients served capped by demand and nursing capacity; unmet = demand − served @@ -14,7 +14,7 @@ A nurse manager faces a real tradeoff: minimize overtime cost, or minimize unmet • HiGHS — two anchors + 5 epsilon points -> Pareto frontier, all OPTIMAL │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • frontier from a cheapest-overtime anchor (most unmet) to a full-service anchor (most overtime) • a knee: service improves cheaply, then overtime climbs steeply to reach zero unmet ``` @@ -25,25 +25,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/nurses.csv` (each nurse has a skill level, an hourly cost, regular hours, and an overtime multiplier), `data/shifts.csv` (each shift has a patient demand, a minimum nurse count, a minimum skill, and a patients-per-nurse-hour rate), and `data/availability.csv` (which nurses are available for which shifts). Model availability as a relationship from nurse to shift. +**Prompt:** /rai-ontology Build an ontology from `data/nurses.csv` (each nurse has a skill level, an hourly cost, regular hours, and an overtime multiplier), `data/shifts.csv` (each shift has a patient demand, a minimum nurse count, a minimum skill, and a patients-per-nurse-hour rate), and `data/availability.csv` (which nurses are available for which shifts). Model availability as a relationship from nurse to shift. **Response:** Loads `Nurse` (6, with `skill_level`, `hourly_cost`, `regular_hours`, `overtime_multiplier`), `Shift` (3: Morning demand 45, Afternoon 60, Night 25, each with `min_nurses` and `min_skill`), and a `Nurse.available_for(Shift)` relationship from the 18 availability rows. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? **Response:** Two concepts — 6 `Nurse` (cost, skill) and 3 `Shift` (patient demand 45/60/25, staffing minimums) — linked by `available_for` with 18 nurse-shift availability pairs. ## 3. Trace the cost-vs-service frontier -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Trace the tradeoff between overtime cost and unmet patient demand. Assign nurses to shifts (binary, only where available; each nurse works 1 or 2 shifts; each shift meets its minimum staff and skill), track overtime hours beyond regular hours, and let patients served be capped by both demand and nursing capacity, with unmet demand the shortfall. First find the two anchors — the minimum-overtime schedule and the minimum-unmet schedule — then sweep five intermediate caps on total unmet demand, each minimizing overtime cost (the epsilon-constraint method). Report each point on the frontier. +**Prompt:** /rai-prescriptive-problem Trace the tradeoff between overtime cost and unmet patient demand. Assign nurses to shifts (binary, only where available; each nurse works 1 or 2 shifts; each shift meets its minimum staff and skill), track overtime hours beyond regular hours, and let patients served be capped by both demand and nursing capacity, with unmet demand the shortfall. First find the two anchors — the minimum-overtime schedule and the minimum-unmet schedule — then sweep five intermediate caps on total unmet demand, each minimizing overtime cost (the epsilon-constraint method). Report each point on the frontier. **Response:** All solves OPTIMAL (HiGHS). The anchors bound the frontier: the minimum-overtime schedule keeps overtime cost lowest while leaving the most patient demand unmet, and the best-service schedule drives unmet demand to zero by taking on the most overtime. The epsilon caps step between them, each the cheapest schedule that meets its service level. (The exact unmet counts and overtime dollars depend on how nurse capacity, patient demand, and overtime are modeled, so the frontier's shape — not specific figures — is the reproducible result.) ## 4. Find the knee -**Prompt:** /rai-prescriptive-results-interpretation Where's the knee of the cost-vs-service frontier — the best-value operating point — and how fast does overtime cost rise as we push toward full service? +**Prompt:** /rai-prescriptive-results Where's the knee of the cost-vs-service frontier — the best-value operating point — and how fast does overtime cost rise as we push toward full service? **Response:** The frontier has a clear knee: overtime stays flat (the cheapest schedules) across a range of service levels, then rises steeply as you push toward serving every patient — the last increments of service are the most expensive, so the cost-per-patient accelerates as the frontier turns convex. The recommended operating point is the knee, capturing most of the achievable service before overtime cost takes off; closing the final gap to zero unmet is disproportionately expensive. diff --git a/v1/humanitarian-aid-supply-chain/runbook.md b/v1/humanitarian-aid-supply-chain/runbook.md index 4440609d..1719f57c 100644 --- a/v1/humanitarian-aid-supply-chain/runbook.md +++ b/v1/humanitarian-aid-supply-chain/runbook.md @@ -18,13 +18,13 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/distribution_points.csv` (each point has a type, a region, a capacity, and a population served) and `data/supply_routes.csv` (each directed route links two points and has a route capacity, a reliability score, and a distance). Derive a route flow weight as route capacity times reliability divided by distance, and model the route as a directed relationship from one point to another carrying that flow weight. +**Prompt:** /rai-ontology Build an ontology from `data/distribution_points.csv` (each point has a type, a region, a capacity, and a population served) and `data/supply_routes.csv` (each directed route links two points and has a route capacity, a reliability score, and a distance). Derive a route flow weight as route capacity times reliability divided by distance, and model the route as a directed relationship from one point to another carrying that flow weight. **Response:** Loads `DistributionPoint` (18, with `type`, `region`, `capacity`, `population_served`) and `SupplyRoute` (28 directed routes, each with `route_capacity`, `reliability_score`, `distance_km`, and a derived `flow_weight`) — a directed, flow-weighted supply network serving 152,000 people. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many of each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many of each? **Response:** One node concept, `DistributionPoint` (18), connected by `SupplyRoute` (28 directed, flow-weighted edges) — about 3.1 routes per point, total network capacity ~64,600 units. diff --git a/v1/it-dependency-mapping/runbook.md b/v1/it-dependency-mapping/runbook.md index cc7d47a1..ef5ce63a 100644 --- a/v1/it-dependency-mapping/runbook.md +++ b/v1/it-dependency-mapping/runbook.md @@ -19,13 +19,13 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build a RelationalAI ontology from `data/features.csv` and `data/dependencies.csv`. Each feature is a node in a software / data-pipeline estate — a raw source, pipeline, feature job, service, or dashboard — with an owner and a deploy tier. Each dependency edge says an upstream feature contributes to (feeds) a downstream one. Model `contributes_to` as a self-relationship between features. +**Prompt:** /rai-ontology Build a RelationalAI ontology from `data/features.csv` and `data/dependencies.csv`. Each feature is a node in a software / data-pipeline estate — a raw source, pipeline, feature job, service, or dashboard — with an owner and a deploy tier. Each dependency edge says an upstream feature contributes to (feeds) a downstream one. Model `contributes_to` as a self-relationship between features. **Response:** Loads 14 `Feature` nodes (properties `name`, `owner`, `deploy_tier`) and a `contributes_to` self-relationship populated from the 15 dependency edges, forming an acyclic dependency DAG from raw sources down to dashboards. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and what does the dependency estate look like end to end? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and what does the dependency estate look like end to end? **Response:** One concept, `Feature`, with a single `contributes_to` self-relationship. The 14 features flow from two critical raw sources (Clickstream Ingest, Transaction CDC Stream) and a CRM sync, through enrichment and feature-engineering pipelines, into services (Churn Scoring API, Billing API, Recommendation Service), and finally two leaf dashboards (Retention Dashboard, Executive Revenue Dashboard). 15 edges, no cycles. diff --git a/v1/memory_supply_allocation/runbook.md b/v1/memory_supply_allocation/runbook.md index d0ac837a..6ecfb19a 100644 --- a/v1/memory_supply_allocation/runbook.md +++ b/v1/memory_supply_allocation/runbook.md @@ -55,7 +55,7 @@ maker customers stay pinned at their elevated floors. **Prompt** ``` -/rai-build-starter-ontology Build a memory-chip allocation ontology from the CSVs in data/. Include a Dependency junction concept so downstream-to-upstream customer yield declarations can be modeled, plus Supplier, SupplierProductCapacity, Input, and InputUsage concepts so capacity can be composed from supplier capability and raw-material exposure. Also include a SupplierCapabilityForecast concept holding the predicted capability_pct per (supplier, month). +/rai-ontology Build a memory-chip allocation ontology from the CSVs in data/. Include a Dependency junction concept so downstream-to-upstream customer yield declarations can be modeled, plus Supplier, SupplierProductCapacity, Input, and InputUsage concepts so capacity can be composed from supplier capability and raw-material exposure. Also include a SupplierCapabilityForecast concept holding the predicted capability_pct per (supplier, month). ``` **Response** @@ -67,7 +67,7 @@ Concepts created and bound to the bundled CSVs: Customer (11 rows), Product (5 S **Prompt** ``` -/rai-querying What concepts and relationships does the ontology have, how many rows are in each, and what is the customer-customer dependency landscape: how many customers declare yield to an upstream supplier, how many are protected by an elevated floor, and is there any multi-hop chaining? +/rai-pyrel What concepts and relationships does the ontology have, how many rows are in each, and what is the customer-customer dependency landscape: how many customers declare yield to an upstream supplier, how many are protected by an elevated floor, and is there any multi-hop chaining? ``` **Response** @@ -84,14 +84,14 @@ Concepts created and bound to the bundled CSVs: Customer (11 rows), Product (5 S **Response** -Four-reasoner chain on the shared ontology. **Rules** (`/rai-rules-authoring`) to derive per-customer max_declared_yield_pct + elevated_floor_pct + a single-point-of-failure flag from the Dependency junction. **Predictive** (`/rai-predictive-modeling` or pre-computed table) to provide a SupplierCapabilityForecast per (supplier, month). **Prescriptive** (`/rai-prescriptive-problem-formulation`) to solve revenue-max LP as a rolling horizon — baseline plus one re-solve per disruption reveal, with effective capacity recomputed against the current forecast and input-availability state each time. **Graph** (`/rai-graph-analysis` with the paths library) to enumerate variable-length customer dependency chains, flag the dependency SPOF, and run two cascade what-if branches (supplier-offline, input-shortage). +Four-reasoner chain on the shared ontology. **Rules** (`/rai-pyrel`) to derive per-customer max_declared_yield_pct + elevated_floor_pct + a single-point-of-failure flag from the Dependency junction. **Predictive** (`/rai-predictive-modeling` or pre-computed table) to provide a SupplierCapabilityForecast per (supplier, month). **Prescriptive** (`/rai-prescriptive-problem`) to solve revenue-max LP as a rolling horizon — baseline plus one re-solve per disruption reveal, with effective capacity recomputed against the current forecast and input-availability state each time. **Graph** (`/rai-graph-analysis` with the paths library) to enumerate variable-length customer dependency chains, flag the dependency SPOF, and run two cascade what-if branches (supplier-offline, input-shortage). ### 4. Derive customer yield, elevated floor, and SPOF flag **Prompt** ``` -/rai-rules-authoring Which customers should be flagged as yielding-downstream (willing to give up part of their allocation to keep an upstream supplier covered), which carry an elevated service floor above their base, and which are dependency single points of failure? A customer is a dependency single point of failure when (a) exactly one incoming dependency lifts its floor above its base, and (b) that floor would drop back to base if the single protecting edge were removed. +/rai-pyrel Which customers should be flagged as yielding-downstream (willing to give up part of their allocation to keep an upstream supplier covered), which carry an elevated service floor above their base, and which are dependency single points of failure? A customer is a dependency single point of failure when (a) exactly one incoming dependency lifts its floor above its base, and (b) that floor would drop back to base if the single protecting edge were removed. ``` **Response** @@ -115,7 +115,7 @@ Predictions bind into `SupplierCapabilityForecast` (216 rows) with per-supplier **Prompt** ``` -/rai-prescriptive-problem-formulation What is the revenue-maximizing 36-month monthly allocation of supply across customers, subject to: (1) capacity per (product, month) computed as the sum over suppliers of nominal_capacity_usd × capability_pct, scaled by the product across raw-material inputs of (1 − intensity × (1 − input_availability)); (2) per-cell upper bound of (1 − max_declared_yield_pct) × demand_usd; (3) per-cell lower bound of max(base_service_floor_pct, elevated_floor_pct) × demand_usd. Solve under baseline forecast with no disruption applied. Report total margin and per-customer service level (alloc / demand aggregated per customer over the horizon). +/rai-prescriptive-problem What is the revenue-maximizing 36-month monthly allocation of supply across customers, subject to: (1) capacity per (product, month) computed as the sum over suppliers of nominal_capacity_usd × capability_pct, scaled by the product across raw-material inputs of (1 − intensity × (1 − input_availability)); (2) per-cell upper bound of (1 − max_declared_yield_pct) × demand_usd; (3) per-cell lower bound of max(base_service_floor_pct, elevated_floor_pct) × demand_usd. Solve under baseline forecast with no disruption applied. Report total margin and per-customer service level (alloc / demand aggregated per customer over the horizon). ``` **Response** @@ -127,7 +127,7 @@ OPTIMAL · margin $45,488,032,436 over months 1–36 · binding constraint is HB **Prompt** ``` -/rai-prescriptive-problem-formulation Replan as each disruption surfaces. At month 5, Orion Foundry's capability_pct drops to 0.78 for months 5–10 (unscheduled EUV tool downtime) and recovers afterward. At month 13, helium availability drops to 0.80 and holds at that level through end of horizon (planner's conservative assumption — the geopolitical event has uncertain resolution timing). For each reveal, update effective capacity and re-solve the remaining months against the same three constraint types from the baseline solve. Report the cumulative plan diff at the customer level vs the prior iteration's allocation over the overlapping months. +/rai-prescriptive-problem Replan as each disruption surfaces. At month 5, Orion Foundry's capability_pct drops to 0.78 for months 5–10 (unscheduled EUV tool downtime) and recovers afterward. At month 13, helium availability drops to 0.80 and holds at that level through end of horizon (planner's conservative assumption — the geopolitical event has uncertain resolution timing). For each reveal, update effective capacity and re-solve the remaining months against the same three constraint types from the baseline solve. Report the cumulative plan diff at the customer level vs the prior iteration's allocation over the overlapping months. ``` **Response** @@ -178,7 +178,7 @@ Widest supplier impact: Orion Foundry — 72 cells affected, max 60.0% capacity **Prompt** ``` -/rai-prescriptive-results-interpretation Summarize the rolling-horizon outcome: who absorbs the disruption, what protects the equipment-maker customers, and how does the margin evolve across the three iterations? Highlight the structural risk visible in the supplier-offline and input-shortage cascade rankings. +/rai-prescriptive-results Summarize the rolling-horizon outcome: who absorbs the disruption, what protects the equipment-maker customers, and how does the margin evolve across the three iterations? Highlight the structural risk visible in the supplier-offline and input-shortage cascade rankings. ``` **Response** diff --git a/v1/money_laundering_motif_detection/runbook.md b/v1/money_laundering_motif_detection/runbook.md index 4c85a9ae..663785a7 100644 --- a/v1/money_laundering_motif_detection/runbook.md +++ b/v1/money_laundering_motif_detection/runbook.md @@ -6,7 +6,7 @@ An AML investigator wants to catch "layering" — the obfuscation stage where a shared ledger: 90 accounts (beneficial owner, KYC tier, jurisdiction) · 138 transactions (amount, time) │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management (three CSP motif detectors) +/rai-prescriptive-problem (three CSP motif detectors) • butterfly (scatter-gather): 1 source → 3 same-owner hubs → 1 dest, per-hub $ conservation, all sub-$10k -> 2 rings found (enumeration exhausted) • smurf army (fan-in): 5 distinct-owner accounts → 1 merchant, summing ~$27k within a 60-min window @@ -15,7 +15,7 @@ shared ledger: 90 accounts (beneficial owner, KYC tier, jurisdiction) · 138 tra -> cohorts surfaced (count depends on target scope + solution limit) │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • each motif is a joint constraint a rules/path query alone can't express; the planted decoys are correctly excluded ``` @@ -25,31 +25,31 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/accounts.csv` (each account has a beneficial-owner id, a KYC tier, and a jurisdiction) and `data/transactions.csv` (each transaction is a directed transfer from a source account to a destination account with a dollar amount and a timestamp in minutes). Model the transaction as a relationship from a source account to a destination account. +**Prompt:** /rai-ontology Build an ontology from `data/accounts.csv` (each account has a beneficial-owner id, a KYC tier, and a jurisdiction) and `data/transactions.csv` (each transaction is a directed transfer from a source account to a destination account with a dollar amount and a timestamp in minutes). Model the transaction as a relationship from a source account to a destination account. **Response:** Loads `Account` (90, with `bo_id` beneficial-owner cluster, `kyc_tier`, `jurisdiction`) and `Transaction` (138 directed transfers, each with `amount_dollars` and `ts_minutes`) — a transaction ledger with two planted scatter-gather rings, a smurf cohort, a KYC-burst cohort, decoys, and noise. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? **Response:** Two concepts — 90 `Account` (beneficial owner, KYC tier, jurisdiction) and 138 `Transaction` (directed transfers with amount and timestamp) — forming a directed money-flow graph. The CTR reporting threshold is $10,000; all motif transfers sit below it. ## 3. Detect butterfly (scatter-gather) rings -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Find butterfly scatter-gather rings: one source account that fans funds out to exactly 3 hub accounts sharing the same beneficial owner, which then gather into one destination account — with no direct source-to-destination or hub-to-hub edges, every transfer under $10,000, and each hub's dollars in roughly equal to its dollars out (flow conservation within a small tolerance). Enumerate all such rings. +**Prompt:** /rai-prescriptive-problem Find butterfly scatter-gather rings: one source account that fans funds out to exactly 3 hub accounts sharing the same beneficial owner, which then gather into one destination account — with no direct source-to-destination or hub-to-hub edges, every transfer under $10,000, and each hub's dollars in roughly equal to its dollars out (flow conservation within a small tolerance). Enumerate all such rings. **Response:** OPTIMAL — enumeration exhausted (MiniZinc), **2 rings found**, both planted scatter-gathers: SourceShellCorp → 3 same-owner hubs → WireRecipientCorp, and SecondShellCorp → 3 same-owner hubs → OffshoreLLC (12 motif edges total). The per-hub dollar-conservation constraint is what rejects structurally-similar but non-laundering fan-outs. ## 4. Detect a smurf army (fan-in) -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Find smurf cohorts: exactly 5 accounts, each with a distinct beneficial owner, each sending a sub-$10,000 transfer into the same target merchant, where the transfers sum to about $27,000 and all fall within a 60-minute window. Enumerate the cohorts. +**Prompt:** /rai-prescriptive-problem Find smurf cohorts: exactly 5 accounts, each with a distinct beneficial owner, each sending a sub-$10,000 transfer into the same target merchant, where the transfers sum to about $27,000 and all fall within a 60-minute window. Enumerate the cohorts. **Response:** SOLUTION_LIMIT — the solver hit its cap of 5 enumerated cohorts (more exist; raise the limit to see them). All five fan into the same merchant, sum to ~$27,000 within the window, and have pairwise-distinct beneficial owners. The distinct-owner constraint correctly prevents the two decoy accounts that share a beneficial owner from both appearing in one cohort. ## 5. Detect a KYC-mix burst (fan-in) -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Find KYC-mix bursts: exactly 5 accounts that each send a sub-$10,000 transfer into the same target within a 60-minute window, where at least 4 of the 5 are retail-tier accounts. Enumerate the cohorts. +**Prompt:** /rai-prescriptive-problem Find KYC-mix bursts: exactly 5 accounts that each send a sub-$10,000 transfer into the same target within a 60-minute window, where at least 4 of the 5 are retail-tier accounts. Enumerate the cohorts. **Response:** The detector returns KYC-burst cohorts — 5 sub-$10k transfers into one flagged target within the window, at least 4 from retail-tier accounts. The **at-least-4-retail cardinality over the chosen subset** is the joint condition a per-account rule can't capture. How many cohorts surface depends on how tightly the target and window are scoped (and the solution-limit cap): pinned to the planted target the shipped script surfaces a small set, while a looser target scope admits many more — so treat this motif as "find the bursts at this target," not a fixed count. diff --git a/v1/network_flow_planning/runbook.md b/v1/network_flow_planning/runbook.md index 4e9a2457..8b6f8a09 100644 --- a/v1/network_flow_planning/runbook.md +++ b/v1/network_flow_planning/runbook.md @@ -6,7 +6,7 @@ A logistics planner has to make two coupled decisions at once: which fulfillment 12 sites (4 tiers, FCs carry fixed costs) · 17 directed lanes (cost, capacity) · 3 customer demands (450 total) │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decisions: continuous flow per lane + binary "open this fulfillment center?" • constraints: warehouse supply; flow conservation at hubs and FCs; FC inflow ≤ capacity only if opened; customer demand met @@ -14,7 +14,7 @@ A logistics planner has to make two coupled decisions at once: which fulfillment • HiGHS mixed-integer program -> OPTIMAL, $5,280 │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • open FC_Northeast + FC_Southwest; FC_West stays closed • skipping FC_West saves its $1,000 fixed cost — worth more than the route it would unlock ``` @@ -25,25 +25,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/sites.csv` (each site has a type — warehouse, hub, fulfillment center, or customer — plus inventory, capacity, and a fixed cost), `data/lanes.csv` (each directed lane links a source site to a destination site with a per-unit cost and a capacity), and `data/demand.csv` (each customer site has a demand quantity). Model the lane as a relationship between a source and a destination site. +**Prompt:** /rai-ontology Build an ontology from `data/sites.csv` (each site has a type — warehouse, hub, fulfillment center, or customer — plus inventory, capacity, and a fixed cost), `data/lanes.csv` (each directed lane links a source site to a destination site with a per-unit cost and a capacity), and `data/demand.csv` (each customer site has a demand quantity). Model the lane as a relationship between a source and a destination site. **Response:** Loads `Site` (12: 3 warehouses, 3 hubs, 3 fulfillment centers with fixed costs, 3 customers), `Lane` (17 directed links, each with `cost_per_unit` and `capacity`), and `Demand` (3: NYC 180, LA 120, Houston 150 — 450 total). ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many of each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many of each? **Response:** Three concepts — 12 `Site` (typed across four tiers, fulfillment centers carrying `capacity` and `fixed_cost`), 17 `Lane` (directed, with `cost_per_unit` and `capacity`), and 3 `Demand` (one per customer, 450 units total) — forming a warehouse-to-hub-to-FC-to-customer flow network. ## 3. Open centers and route flow at minimum cost -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Which fulfillment centers should we open, and how much should we ship on each lane, to meet every customer's demand at minimum total cost? Use a continuous flow per lane (bounded by its capacity) and a binary open decision per fulfillment center. Warehouse outflow can't exceed inventory, flow must balance at each hub and center, a center can only receive flow if it's open (inflow up to its capacity), and each customer's inflow must meet its demand. Minimize total transport cost plus fixed opening cost, and persist both decisions to the ontology. +**Prompt:** /rai-prescriptive-problem Which fulfillment centers should we open, and how much should we ship on each lane, to meet every customer's demand at minimum total cost? Use a continuous flow per lane (bounded by its capacity) and a binary open decision per fulfillment center. Warehouse outflow can't exceed inventory, flow must balance at each hub and center, a center can only receive flow if it's open (inflow up to its capacity), and each customer's inflow must meet its demand. Minimize total transport cost plus fixed opening cost, and persist both decisions to the ontology. **Response:** OPTIMAL (HiGHS), total cost **$5,280** (relative gap 0.0). 20 variables (17 continuous lane flows + 3 binary open decisions) and 15 constraints; flows and open decisions are written back as `Lane.x_flow` and `Site.x_open`. ## 4. Read the network plan -**Prompt:** /rai-prescriptive-results-interpretation Which centers open, how does product flow to each customer, and why is one center left closed? +**Prompt:** /rai-prescriptive-results Which centers open, how does product flow to each customer, and why is one center left closed? **Response:** The plan opens **FC_Northeast and FC_Southwest** and leaves **FC_West closed** — its $1,000 fixed cost outweighs the cheaper LA route it would unlock, so LA's 120 units are split across the two open centers instead (70 from Northeast, 50 from Southwest). Nine lanes carry flow: warehouses feed the Memphis and Kansas City hubs, which feed the two open centers, which serve NYC (180), Houston (150), and the split LA demand. Total cost $5,280 — the open/closed trade-off, not lane capacity, is what shapes the plan. diff --git a/v1/patient_cohort_recruitment/runbook.md b/v1/patient_cohort_recruitment/runbook.md index 754845fb..0cf7ab90 100644 --- a/v1/patient_cohort_recruitment/runbook.md +++ b/v1/patient_cohort_recruitment/runbook.md @@ -37,7 +37,7 @@ eligible set, then picks a diverse 4-patient cohort — OPTIMAL, covering **Prompt** ``` -/rai-build-starter-ontology Build an ontology from the data/ CSVs: genes and gene_is_a (a gene ontology where each is_a edge says a child gene is a kind of a parent gene), therapies, ae_terms (adverse-event terms), patients, and the three patient event tables — mutation_events (patient has a mutation in a gene at a time), therapy_events (patient received a therapy at a time), and adverse_events (patient had an adverse-event term at a time). Model is_a as a relationship between genes and each event as a relationship from a patient. +/rai-ontology Build an ontology from the data/ CSVs: genes and gene_is_a (a gene ontology where each is_a edge says a child gene is a kind of a parent gene), therapies, ae_terms (adverse-event terms), patients, and the three patient event tables — mutation_events (patient has a mutation in a gene at a time), therapy_events (patient received a therapy at a time), and adverse_events (patient had an adverse-event term at a time). Model is_a as a relationship between genes and each event as a relationship from a patient. ``` **Response** @@ -49,7 +49,7 @@ Loads `Gene` (10) with an `is_a` self-relationship (8 edges), `Therapy` (5), `Ad **Prompt** ``` -/rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +/rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? ``` **Response** @@ -85,7 +85,7 @@ Reachability over the `is_a` hierarchy from the kinase root returns **7 of the 1 **Prompt** ``` -/rai-rules-authoring A patient is eligible if they (a) carry a mutation in a KinaseGene, and (b) had an adverse event within 0 to 90 days after receiving some therapy. Flag the eligible patients, and for each record which kinase genes, therapies, and adverse-event terms they cover. +/rai-pyrel A patient is eligible if they (a) carry a mutation in a KinaseGene, and (b) had an adverse event within 0 to 90 days after receiving some therapy. Flag the eligible patients, and for each record which kinase genes, therapies, and adverse-event terms they cover. ``` **Response** @@ -97,7 +97,7 @@ Reachability over the `is_a` hierarchy from the kinase root returns **7 of the 1 **Prompt** ``` -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Pick exactly 4 eligible patients to form the study cohort such that, collectively, they cover at least 3 distinct kinase genes, at least 2 distinct therapies, and at least 2 distinct adverse-event terms. Persist the chosen patients as Patient.is_in_cohort and the covered genes/therapies/adverse events. +/rai-prescriptive-problem Pick exactly 4 eligible patients to form the study cohort such that, collectively, they cover at least 3 distinct kinase genes, at least 2 distinct therapies, and at least 2 distinct adverse-event terms. Persist the chosen patients as Patient.is_in_cohort and the covered genes/therapies/adverse events. ``` **Response** @@ -109,7 +109,7 @@ OPTIMAL (constraint solver) — a valid 4-patient cohort that **exceeds every di **Prompt** ``` -/rai-prescriptive-results-interpretation Which patients are in the cohort, what diversity does it achieve, and what's the binding constraint? +/rai-prescriptive-results Which patients are in the cohort, what diversity does it achieve, and what's the binding constraint? ``` **Response** diff --git a/v1/planogram_optimization/runbook.md b/v1/planogram_optimization/runbook.md index 1644e9f1..419893b1 100644 --- a/v1/planogram_optimization/runbook.md +++ b/v1/planogram_optimization/runbook.md @@ -32,7 +32,7 @@ predicted weekly demand — a strong plan (~1,600+ units), 16 of 18 SKUs given s **Prompt** ``` -/rai-build-starter-ontology Build an ontology from data/skus.csv (each SKU has a category, a width, a max facings, and an assigned shelf), data/shelves.csv (each shelf has a length), data/categories.csv (each category has a min and max number of active SKUs), and data/predicted_demand_table.csv (predicted weekly demand for each SKU at each possible facing count). Model predicted demand as a relationship keyed by SKU and facing count. +/rai-ontology Build an ontology from data/skus.csv (each SKU has a category, a width, a max facings, and an assigned shelf), data/shelves.csv (each shelf has a length), data/categories.csv (each category has a min and max number of active SKUs), and data/predicted_demand_table.csv (predicted weekly demand for each SKU at each possible facing count). Model predicted demand as a relationship keyed by SKU and facing count. ``` **Response** @@ -44,7 +44,7 @@ Loads `Sku` (18, across 4 categories: snacks, beverages, candy, household_paper, **Prompt** ``` -/rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +/rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? ``` **Response** @@ -80,7 +80,7 @@ Each SKU has a concave demand curve over facing counts — demand rises with fac **Prompt** ``` -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Choose an integer number of facings for each SKU (within its max facings) to maximize total predicted weekly demand, where each SKU's realized demand is the predicted demand at its chosen facing count. Respect each shelf's length (sum of facings times width can't exceed shelf length) and each category's min and max number of active SKUs. Persist the chosen facings, realized demand, and active flag. +/rai-prescriptive-problem Choose an integer number of facings for each SKU (within its max facings) to maximize total predicted weekly demand, where each SKU's realized demand is the predicted demand at its chosen facing count. Respect each shelf's length (sum of facings times width can't exceed shelf length) and each category's min and max number of active SKUs. Persist the chosen facings, realized demand, and active flag. ``` **Response** @@ -92,7 +92,7 @@ Total predicted weekly demand around **1,600+ units** — the decision picks fac **Prompt** ``` -/rai-prescriptive-results-interpretation How many SKUs get shelf space, which shelf is the tightest, and what forces any SKU off the shelf? +/rai-prescriptive-results How many SKUs get shelf space, which shelf is the tightest, and what forces any SKU off the shelf? ``` **Response** diff --git a/v1/pod_placement/runbook.md b/v1/pod_placement/runbook.md index c263e1a3..c9b5ba1c 100644 --- a/v1/pod_placement/runbook.md +++ b/v1/pod_placement/runbook.md @@ -6,7 +6,7 @@ A platform team running a multi-tenant cluster needs to place every workload pod 8 nodes (2 GPU) · 50 pods · 12 deployments · 4 tenants · affinity / anti-affinity / training-clique rules │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decisions: binary pod-to-node assignment · pod placed? · deployment placed? • constraints: per-node CPU/mem/GPU capacity; tenant anti-affinity; deployment affinity; zone spread; gang (all replicas or none); distributed-training pods share a rack @@ -14,7 +14,7 @@ A platform team running a multi-tenant cluster needs to place every workload pod • MiniZinc constraint solver -> OPTIMAL, all 12 deployments placed │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • all 50 pods + 12 deployments placed, every rule satisfied • the 4-pod training clique pins one GPU node to exactly 100% on CPU, memory, and GPU ``` @@ -25,25 +25,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/nodes.csv` (each node has CPU, memory, and GPU capacity plus a zone and rack), `data/pods.csv` (each pod belongs to a deployment and requests CPU, memory, and GPU), `data/deployments.csv` (each deployment belongs to a tenant and has a replica count), `data/tenants.csv`, and the rule files `data/tenant_anti_affinity.csv` (tenant pairs that must not share a node), `data/deployment_affinity.csv` (deployment pairs that must co-locate), and `data/distributed_training.csv` (pod pairs that must share a rack). Derive zones and racks from the node data. +**Prompt:** /rai-ontology Build an ontology from `data/nodes.csv` (each node has CPU, memory, and GPU capacity plus a zone and rack), `data/pods.csv` (each pod belongs to a deployment and requests CPU, memory, and GPU), `data/deployments.csv` (each deployment belongs to a tenant and has a replica count), `data/tenants.csv`, and the rule files `data/tenant_anti_affinity.csv` (tenant pairs that must not share a node), `data/deployment_affinity.csv` (deployment pairs that must co-locate), and `data/distributed_training.csv` (pod pairs that must share a rack). Derive zones and racks from the node data. **Response:** Loads `Node` (8: 6 general-purpose, 2 with 4 GPUs each), `Pod` (50, each with CPU/memory/GPU requests, linked to a deployment), `Deployment` (12, linked to a tenant with a replica count), `Tenant` (4), and `Zone`/`Rack` derived from the nodes — plus the three rule relationships (2 anti-affinity pairs, 1 affinity pair, the 6-pair distributed-training clique). ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many of each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many of each? **Response:** Concepts: 8 `Node` (CPU/memory/GPU, zone, rack), 50 `Pod` (resource requests), 12 `Deployment` (replicas, tenant), 4 `Tenant`, plus derived `Zone` (2) and `Rack` (4). Rule relationships: tenant anti-affinity (2 pairs), deployment affinity (1 pair), and distributed-training (the C(4,2) clique over the 4 training pods). ## 3. Place the pods under all rules -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Assign pods to nodes to place as many deployments as possible, treating every rule as hard: a pod goes on at most one node; a deployment is placed only if all its replicas are; per node, total CPU, memory, and GPU requests can't exceed capacity; pods of anti-affine tenants can't share a node; affinity-paired deployments must share a node; each deployment's pods are spread so no zone holds more than its share; and the distributed-training pods must all land on the same rack. Maximize the number of placed deployments and persist the assignment to the ontology. +**Prompt:** /rai-prescriptive-problem Assign pods to nodes to place as many deployments as possible, treating every rule as hard: a pod goes on at most one node; a deployment is placed only if all its replicas are; per node, total CPU, memory, and GPU requests can't exceed capacity; pods of anti-affine tenants can't share a node; affinity-paired deployments must share a node; each deployment's pods are spread so no zone holds more than its share; and the distributed-training pods must all land on the same rack. Maximize the number of placed deployments and persist the assignment to the ontology. **Response:** OPTIMAL (MiniZinc constraint solver), objective **12 — all 12 deployments placed**. The model is a binary pod-to-node assignment matrix plus placed indicators (hundreds of variables and constraints across the six rule families); the assignment, `Pod.placed`, and `Deployment.placed` are written back to the ontology and re-verified against every rule. ## 4. Read the placement -**Prompt:** /rai-prescriptive-results-interpretation Are all deployments placed, which node is the tightest, and what makes it the binding one? +**Prompt:** /rai-prescriptive-results Are all deployments placed, which node is the tightest, and what makes it the binding one? **Response:** Every deployment is placed — all 50 pods land on a node with no rule violated. The binding node is **one of the two GPU nodes** (which one is an alternate-optimum detail), pinned to **exactly 100% on all three resources** (8000/8000 millicores, 32768 MiB, 4/4 GPU): the 4-pod distributed-training clique must share one rack and each pod needs a GPU, so it consumes a GPU node entirely. The other nodes carry general-purpose pods with headroom, and the affinity-paired caches co-locate as required — so the GPU/rack-locality rule, not raw cluster capacity, is what's tight. diff --git a/v1/portfolio_balancing/portfolio_balancing.py b/v1/portfolio_balancing/portfolio_balancing.py index d2fbae4f..ae17fbd8 100644 --- a/v1/portfolio_balancing/portfolio_balancing.py +++ b/v1/portfolio_balancing/portfolio_balancing.py @@ -1221,7 +1221,7 @@ def frontier_dichotomic(n): # Knee = the last point before the frontier slope accelerates most: the largest RATIO # jump between consecutive exact duals (lambda_j / lambda_{j-1}), marking point j-1 so # "cost jumps beyond this point". This applies the ratio-knee principle from - # rai-prescriptive-results-interpretation ("Knee from the exact dual sequence") to the exact + # rai-prescriptive-results ("Knee from the exact dual sequence") to the exact # duals rather than finite-difference secants -- the knee is NOT where the absolute slope is # highest (that is always the last point). The min-risk anchor (k=0) declares no return # floor so its dual is structurally 0; the scan starts at j=2 to skip that 0->lambda_1 diff --git a/v1/portfolio_balancing/runbook.md b/v1/portfolio_balancing/runbook.md index 33d46d0c..76e2ae92 100644 --- a/v1/portfolio_balancing/runbook.md +++ b/v1/portfolio_balancing/runbook.md @@ -49,7 +49,7 @@ without the cluster collapse, the gap would grow. **Prompt** ``` -/rai-build-starter-ontology Build a portfolio ontology from the CSVs in data/. The covariance file is in long form (stock_i, stock_j, value) — model it as a binary property on Stock rather than a separate Concept. Promote sector to its own Concept so downstream rules can aggregate exposure per sector. +/rai-ontology Build a portfolio ontology from the CSVs in data/. The covariance file is in long form (stock_i, stock_j, value) — model it as a binary property on Stock rather than a separate Concept. Promote sector to its own Concept so downstream rules can aggregate exposure per sector. ``` **Response** @@ -61,7 +61,7 @@ Concepts: `Stock` (with binary `Stock.covar(Stock, Stock)` property carrying cov **Prompt** ``` -/rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +/rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? ``` **Response** @@ -85,7 +85,7 @@ Plan: rules for compliance flags, graph for correlation clustering + representat **Prompt** ``` -/rai-rules-authoring Which holdings are overconcentrated (worth more than 15% of their account), which (account, sector) pairs are overweight (more than 30% of the account), and which traders are high-risk (risk score above 0.8 with more than five flagged transactions)? +/rai-pyrel Which holdings are overconcentrated (worth more than 15% of their account), which (account, sector) pairs are overweight (more than 30% of the account), and which traders are high-risk (risk score above 0.8 with more than five flagged transactions)? ``` **Response** @@ -109,7 +109,7 @@ Plan: rules for compliance flags, graph for correlation clustering + representat **Prompt** ``` -/rai-prescriptive-problem-formulation What's the Markowitz mean-variance frontier across our 6 scenarios (3 budgets — 500, 1000, 2000 — times 2 regimes — base, crisis)? Each scenario must be fully invested; cap any single position at 30% of budget and any sector at 30%; only invest in cluster representatives. Solve with sensitivity enabled so each return-floor constraint returns its shadow price. Trace 6 frontier points per scenario by dual-guided sampling: start from the min-risk and max-return anchors, then add each next return target where the two bracketing points' shadow prices (their tangents) predict the largest gap to the chord — not on a uniform grid, which over-samples the flat low-risk end and crowds the max-return wall. +/rai-prescriptive-problem What's the Markowitz mean-variance frontier across our 6 scenarios (3 budgets — 500, 1000, 2000 — times 2 regimes — base, crisis)? Each scenario must be fully invested; cap any single position at 30% of budget and any sector at 30%; only invest in cluster representatives. Solve with sensitivity enabled so each return-floor constraint returns its shadow price. Trace 6 frontier points per scenario by dual-guided sampling: start from the min-risk and max-return anchors, then add each next return target where the two bracketing points' shadow prices (their tangents) predict the largest gap to the chord — not on a uniform grid, which over-samples the flat low-risk end and crowds the max-return wall. ``` **Response** @@ -121,7 +121,7 @@ Plan: rules for compliance flags, graph for correlation clustering + representat **Prompt** ``` -/rai-prescriptive-results-interpretation For the reference scenario (base_1000), list the Pareto frontier with each point's exact shadow price (the return-floor dual), and find the knee — the last point before the marginal risk per unit return jumps the most. Treat the knee as the largest ratio jump between consecutive duals. +/rai-prescriptive-results For the reference scenario (base_1000), list the Pareto frontier with each point's exact shadow price (the return-floor dual), and find the knee — the last point before the marginal risk per unit return jumps the most. Treat the knee as the largest ratio jump between consecutive duals. ``` **Response** @@ -133,7 +133,7 @@ Reference base_1000 frontier: return 64.87 -> 84.00, variance 4641.57 -> 8528.00 **Prompt** ``` -/rai-pyrel-coding + /rai-prescriptive-results-interpretation How much does volatility expand at each frontier point under crisis covariance — where correlations shrink 30% of the way toward all-ones (preserving positive semi-definiteness) — versus the base regime? +/rai-pyrel + /rai-prescriptive-results How much does volatility expand at each frontier point under crisis covariance — where correlations shrink 30% of the way toward all-ones (preserving positive semi-definiteness) — versus the base regime? ``` **Response** @@ -145,7 +145,7 @@ Crisis vol runs 22-30% above base at every frontier point (budget 1000: min_risk **Prompt** ``` -/rai-ontology-design Add a FrontierPoint concept indexed by (Scenario, eps_label) that materializes each Pareto point's metadata: return, risk, marginal risk-per-return, knee flag, base-regime volatility, crisis-regime volatility, and the percentage gap between them. +/rai-ontology Add a FrontierPoint concept indexed by (Scenario, eps_label) that materializes each Pareto point's metadata: return, risk, marginal risk-per-return, knee flag, base-regime volatility, crisis-regime volatility, and the percentage gap between them. ``` **Response** diff --git a/v1/product_configurator/runbook.md b/v1/product_configurator/runbook.md index 14944c50..f56e8f37 100644 --- a/v1/product_configurator/runbook.md +++ b/v1/product_configurator/runbook.md @@ -6,7 +6,7 @@ A sales or product team configuring a complex product (here, a car) needs more t 6 slots · 16 options (priced) · 4 implies + 3 excludes rules · regional availability (EU/US) │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decision: binary "pick this option?" over the region-allowed options • constraints: exactly one option per slot; implies (A ⇒ B); excludes (not both); total price ≤ $20,000 @@ -14,7 +14,7 @@ A sales or product team configuring a complex product (here, a car) needs more t • MiniZinc constraint solver -> 63 legal EU builds │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • 63 distinct buildable configurations, $1,500 (cheapest) to $18,200 (loaded) • dropping V6 (not EU-allowed) also removes the V6/Manual exclusion from play ``` @@ -25,25 +25,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/slots.csv` (option slots), `data/options.csv` (each option belongs to a slot and has a price in cents), `data/implies.csv` (head option requires tail option), `data/excludes.csv` (two options that can't both be chosen), and `data/regional_rules.csv` (which options are allowed in which region). Model implies and excludes as relationships between options, and region availability as a relationship from an option to the regions it's allowed in. +**Prompt:** /rai-ontology Build an ontology from `data/slots.csv` (option slots), `data/options.csv` (each option belongs to a slot and has a price in cents), `data/implies.csv` (head option requires tail option), `data/excludes.csv` (two options that can't both be chosen), and `data/regional_rules.csv` (which options are allowed in which region). Model implies and excludes as relationships between options, and region availability as a relationship from an option to the regions it's allowed in. **Response:** Loads `Slot` (6: Engine, Transmission, Trim, Sound, Wheels, Roof), `Option` (16, each priced and linked to a slot), an `Implies` relationship (4 rules, e.g. Premium Audio → Premium Trim), an `Excludes` relationship (3 symmetric pairs, e.g. V6 / Manual), and option-to-region availability (US allows all 16; EU allows 15 — the V6 is not EU-allowed). ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many of each? Does every slot have at least one EU-allowed option, and do the implies rules point to EU-allowed options? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many of each? Does every slot have at least one EU-allowed option, and do the implies rules point to EU-allowed options? **Response:** Concepts: 6 `Slot`, 16 `Option` (priced, slotted). Rule relationships: 4 `Implies`, 3 `Excludes`, plus regional availability. Every slot has at least one EU-allowed option and every implies rule's target is EU-allowed, so the EU catalog is well-formed — the region filter won't silently make a slot unfillable. ## 3. Enumerate the legal EU builds -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Enumerate every legal configuration for the EU region that costs at most $20,000. Use a binary "pick this option" decision over the EU-allowed options, require exactly one option per slot, enforce the implies rules (if the head is picked, the tail must be) and the excludes rules (the two can't both be picked), and keep total price within the ceiling. There's no objective — return the full set of feasible builds in multi-solution mode. +**Prompt:** /rai-prescriptive-problem Enumerate every legal configuration for the EU region that costs at most $20,000. Use a binary "pick this option" decision over the EU-allowed options, require exactly one option per slot, enforce the implies rules (if the head is picked, the tail must be) and the excludes rules (the two can't both be picked), and keep total price within the ceiling. There's no objective — return the full set of feasible builds in multi-solution mode. **Response:** OPTIMAL — search exhausted (MiniZinc constraint solver in multi-solution mode). **63 distinct feasible builds** found. Because the EU filter drops the V6, the model has 15 binary option variables and 13 constraints (the V6/Manual exclusion drops out with the V6). The selection is `Option.selected`, with the first solution persisted to the ontology for verification. ## 4. Read the configuration population -**Prompt:** /rai-prescriptive-results-interpretation How many buildable configurations are there, and what's the price range from the cheapest to the most loaded build? +**Prompt:** /rai-prescriptive-results How many buildable configurations are there, and what's the price range from the cheapest to the most loaded build? **Response:** There are **63 buildable EU configurations** under the ceiling, spanning **$1,500 to $18,200**. The cheapest pairs the 1.6L Inline-4, manual transmission, base trim, steel roof, standard sound, and 16-inch alloys; the most loaded build is the 2.0L Turbo with DCT, premium trim, premium audio, panoramic glass, and 18-inch sport wheels. The full population — one row per build — is what feeds a quote tool or trade-off slider, rather than a single "optimal" car. diff --git a/v1/production_planning/runbook.md b/v1/production_planning/runbook.md index 9060d371..d8877389 100644 --- a/v1/production_planning/runbook.md +++ b/v1/production_planning/runbook.md @@ -6,7 +6,7 @@ A manufacturer wants the production plan that maximizes profit across three prod 3 products (demand floor, profit) · 3 machines (hours) · 9 machine-product rates │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decision: integer quantity per (machine, product, scenario), ≥ 0 • constraints: per machine, sum(qty x hours/unit) ≤ machine hours; per product, total qty ≥ demand x scenario multiplier @@ -14,7 +14,7 @@ A manufacturer wants the production plan that maximizes profit across three prod • demand scenarios 0.8 / 1.0 / 1.1 in one solve · HiGHS -> OPTIMAL, $44,735 total │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • per-scenario profit: $15,020 (0.8) > $14,945 (1.0) > $14,770 (1.1) • looser demand floors leave more capacity for the most profitable mix • Machine_2 runs Widget_B at full capacity (70 units, 35 hrs) in every scenario @@ -26,25 +26,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/products.csv` (each product has a demand and a per-unit profit), `data/machines.csv` (each machine has available hours), and `data/production_rates.csv` (the hours per unit for each machine-product pair). Model the production rate as a relationship linking a machine and a product to its hours-per-unit. +**Prompt:** /rai-ontology Build an ontology from `data/products.csv` (each product has a demand and a per-unit profit), `data/machines.csv` (each machine has available hours), and `data/production_rates.csv` (the hours per unit for each machine-product pair). Model the production rate as a relationship linking a machine and a product to its hours-per-unit. **Response:** Loads `Product` (3: Widget_A demand 100 / profit 50, Widget_B 80 / 70, Widget_C 60 / 45), `Machine` (3: Machine_1 40 hrs, Machine_2 35 hrs, Machine_3 45 hrs), and `ProductionRate` (9, every machine-product pair, with `hours_per_unit` 0.4–0.8). ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many of each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many of each? **Response:** Three concepts — 3 `Product` (demand, profit), 3 `Machine` (hours_available), and 9 `ProductionRate` (one per machine-product pair, with `hours_per_unit`). ## 3. Maximize profit across demand scenarios -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management How many units of each product should each machine make to maximize total profit, given each machine's limited hours and a floor on each product's total output? Use a non-negative integer quantity per machine-product pair. Each machine's total time — quantity times hours-per-unit, summed over its products — must stay within its hours; each product's total output across machines must meet its demand floor. Solve three demand scenarios in one solve — demand floors scaled to 80%, 100%, and 110% — with the scenario as a first-class concept and the quantity indexed by (machine, product, scenario). Persist the quantities to the ontology. +**Prompt:** /rai-prescriptive-problem How many units of each product should each machine make to maximize total profit, given each machine's limited hours and a floor on each product's total output? Use a non-negative integer quantity per machine-product pair. Each machine's total time — quantity times hours-per-unit, summed over its products — must stay within its hours; each product's total output across machines must meet its demand floor. Solve three demand scenarios in one solve — demand floors scaled to 80%, 100%, and 110% — with the scenario as a first-class concept and the quantity indexed by (machine, product, scenario). Persist the quantities to the ontology. **Response:** OPTIMAL (HiGHS), combined profit **$44,735** across the three scenarios (relative gap 0.0). 27 integer variables (9 machine-product pairs x 3 scenarios), 18 constraints. Quantities are written back as `Production.x_quantity(Scenario)`. ## 4. Read the plan across scenarios -**Prompt:** /rai-prescriptive-results-interpretation What's the per-scenario profit and production plan, and why does profit move the way it does as the demand floor rises? +**Prompt:** /rai-prescriptive-results What's the per-scenario profit and production plan, and why does profit move the way it does as the demand floor rises? **Response:** Per-scenario profit is **$15,020 at 0.8x, $14,945 at baseline, and $14,770 at 1.1x** — profit *falls* as the demand floor rises. With capacity fixed, a looser demand floor leaves more machine time free to chase the highest-margin mix, while a higher floor forces lower-margin units to be made just to satisfy it. Across all scenarios **Machine_2 runs Widget_B at full capacity** (70 units, its entire 35 hours), and Widget_A is made mostly on Machine_3 (its fastest 0.4 hours/unit line). diff --git a/v1/retail_markdown/runbook.md b/v1/retail_markdown/runbook.md index ec964ab9..dc475d8f 100644 --- a/v1/retail_markdown/runbook.md +++ b/v1/retail_markdown/runbook.md @@ -6,7 +6,7 @@ A merchandiser needs to clear seasonal inventory before it loses value, setting 4 products (price, inventory, base demand, salvage) · 5 discount levels (lift) · 4 weeks (seasonal decay) │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decisions: one discount level per product-week (binary) + units sold + cumulative sold • constraints: exactly one discount per product-week; discounts only deepen over time; sales ≤ demand at the chosen discount; cumulative sales ≤ inventory @@ -14,7 +14,7 @@ A merchandiser needs to clear seasonal inventory before it loses value, setting • HiGHS mixed-integer program -> OPTIMAL, $23,374.65 │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • discounts start shallow (20%) and deepen to 30% late; no product needs the 50% tier • Pants, Shirt, Sweater nearly clear inventory by the final week ``` @@ -25,25 +25,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/products.csv` (each product has an initial price, a cost, an initial inventory, a base demand, and a salvage rate), `data/discounts.csv` (each discount level has a percentage and a demand lift), and `data/weeks.csv` (each week has a seasonal demand multiplier). +**Prompt:** /rai-ontology Build an ontology from `data/products.csv` (each product has an initial price, a cost, an initial inventory, a base demand, and a salvage rate), `data/discounts.csv` (each discount level has a percentage and a demand lift), and `data/weeks.csv` (each week has a seasonal demand multiplier). **Response:** Loads `Product` (4: Sweater, Jacket, Pants, Shirt, each with price, cost, inventory, base demand, salvage rate), `Discount` (5 levels: 0/10/20/30/50%, each with a demand lift from 1.0 to 2.0), and `Week` (4, with seasonal multipliers 1.0/0.9/0.8/0.7). ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? **Response:** Three concepts — 4 `Product` (price, cost, inventory, base demand, salvage rate), 5 `Discount` (percentage and demand lift), and 4 `Week` (seasonal demand multiplier, declining 1.0 → 0.7 across the season). ## 3. Set the markdown schedule -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management What discount should each product carry each week to maximize total revenue plus the salvage value of leftover stock? Pick exactly one discount level per product-week (binary), and only let discounts deepen over the season, never reverse. Units sold can't exceed demand at the chosen discount (base demand times the discount's lift times the week's seasonal multiplier), and a product's cumulative sales can't exceed its inventory. Maximize discounted sales revenue plus salvage value of any unsold stock, and persist the schedule to the ontology. +**Prompt:** /rai-prescriptive-problem What discount should each product carry each week to maximize total revenue plus the salvage value of leftover stock? Pick exactly one discount level per product-week (binary), and only let discounts deepen over the season, never reverse. Units sold can't exceed demand at the chosen discount (base demand times the discount's lift times the week's seasonal multiplier), and a product's cumulative sales can't exceed its inventory. Maximize discounted sales revenue plus salvage value of any unsold stock, and persist the schedule to the ontology. **Response:** OPTIMAL (HiGHS), total revenue plus salvage **$23,374.65** (relative gap 0.0). 176 variables (binary discount selections plus continuous sales and cumulative-sales) and 248 constraints; the discount selection, sales, and cumulative sales are written back as `Product.x_select`, `Product.x_sales`, and `Product.x_cuml_sales`. ## 4. Read the markdown plan -**Prompt:** /rai-prescriptive-results-interpretation How does the discount schedule evolve over the season, and how much inventory clears? +**Prompt:** /rai-prescriptive-results How does the discount schedule evolve over the season, and how much inventory clears? **Response:** Discounts start shallow — **20% across the board early** — and **deepen to 30% in the later weeks** for the slower movers (Shirt and Sweater move to 30% by week 3, Pants by week 4; Jacket holds at 20% throughout). **No product ever needs the deepest 50% tier.** By the final week Pants, Shirt, and Sweater have nearly cleared their inventory (roughly 99%, 99%, and 99% sold), while the higher-margin Jacket sells through about two-thirds — the plan protects Jacket's margin rather than discounting hard to clear it. diff --git a/v1/retail_planning/runbook.md b/v1/retail_planning/runbook.md index a0abe612..c7a93595 100644 --- a/v1/retail_planning/runbook.md +++ b/v1/retail_planning/runbook.md @@ -33,7 +33,7 @@ per-article demand with a GNN, then runs two optimizers on it. **Prompt** ``` -/rai-build-starter-ontology Build an ontology from the bundled H&M subset in data/hm_mini/: articles (products), customers, and transactions (a customer bought an article), with train / validation / test sales splits for the demand model. Also load the planning inputs: the planning articles' inventory, the weeks, and the discount tiers. Model a transaction as a relationship linking a customer and an article. +/rai-ontology Build an ontology from the bundled H&M subset in data/hm_mini/: articles (products), customers, and transactions (a customer bought an article), with train / validation / test sales splits for the demand model. Also load the planning inputs: the planning articles' inventory, the weeks, and the discount tiers. Model a transaction as a relationship linking a customer and an article. ``` **Response** @@ -45,7 +45,7 @@ Loads `Article` (5,000), `Customer` (10,000), and `Transaction` (~9,601, linking **Prompt** ``` -/rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +/rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? ``` **Response** @@ -81,7 +81,7 @@ A sales-regression GNN trains over the transaction graph (beating the predict-th **Prompt** ``` -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Using the learned demand, choose a discount tier for each planning article in each week to maximize total revenue plus salvage value of leftover stock, respecting inventory. Persist the chosen discounts. +/rai-prescriptive-problem Using the learned demand, choose a discount tier for each planning article in each week to maximize total revenue plus salvage value of leftover stock, respecting inventory. Persist the chosen discounts. ``` **Response** @@ -93,7 +93,7 @@ OPTIMAL (HiGHS), total revenue plus salvage **$62,038.94**. The markdown decisio **Prompt** ``` -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Using the learned demand, plan weekly production and inventory for the planning articles to minimize total cost — production plus holding plus an unmet-demand penalty — within production capacity. Persist the plan. +/rai-prescriptive-problem Using the learned demand, plan weekly production and inventory for the planning articles to minimize total cost — production plus holding plus an unmet-demand penalty — within production capacity. Persist the plan. ``` **Response** @@ -105,7 +105,7 @@ OPTIMAL (HiGHS), total cost **$8,761.30** (production + holding + unmet penalty) **Prompt** ``` -/rai-prescriptive-results-interpretation What do the two plans recommend, and how does the learned demand drive them? +/rai-prescriptive-results What do the two plans recommend, and how does the learned demand drive them? ``` diff --git a/v1/shift_assignment/runbook.md b/v1/shift_assignment/runbook.md index 6d434f0f..66e31ea6 100644 --- a/v1/shift_assignment/runbook.md +++ b/v1/shift_assignment/runbook.md @@ -6,14 +6,14 @@ A scheduling manager wants to staff every shift from a small hourly workforce wi 10 workers, 3 shifts (capacity), 22 availability pairs │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decision: binary assign per (worker, shift, scenario), only over available pairs • constraints: each shift staffed ≥ min_coverage and ≤ capacity; each worker ≤ 1 shift • feasibility (no objective); coverage scenarios swept 1 / 2 / 3 in one solve • solved as a CSP -> OPTIMAL (satisfiable) at all 3 levels │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • feasible at all three targets; minimum staffing 3 / 6 / 9 across the shifts • triple coverage needs 9 of the 10 workers — the roster's sustainable ceiling ``` @@ -24,25 +24,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/workers.csv`, `data/shifts.csv` (each shift has a capacity), and `data/availability.csv` (worker-shift pairs the worker is available for). Model availability as a relationship from worker to the shifts they can work. +**Prompt:** /rai-ontology Build an ontology from `data/workers.csv`, `data/shifts.csv` (each shift has a capacity), and `data/availability.csv` (worker-shift pairs the worker is available for). Model availability as a relationship from worker to the shifts they can work. **Response:** Loads `Worker` (10), `Shift` (3: Morning capacity 3, Afternoon 4, Night 3), and a `Worker.available_for(Shift)` relationship populated from the 22 availability pairs. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? **Response:** Two concepts — 10 `Worker` and 3 `Shift` (with `capacity`) — linked by `available_for` with 22 worker-shift availability pairs. ## 3. Staff the shifts across coverage targets -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Is there a feasible assignment of workers to shifts where each shift has at least its minimum coverage and no more than its capacity, each worker works at most one shift, and no one is assigned to a shift they're unavailable for? Solve it for three minimum-coverage targets — 1, 2, and 3 workers per shift — in a single solve, with the coverage target as a first-class scenario concept and the assignment decision indexed by (worker, shift, scenario). Persist the assignments to the ontology. +**Prompt:** /rai-prescriptive-problem Is there a feasible assignment of workers to shifts where each shift has at least its minimum coverage and no more than its capacity, each worker works at most one shift, and no one is assigned to a shift they're unavailable for? Solve it for three minimum-coverage targets — 1, 2, and 3 workers per shift — in a single solve, with the coverage target as a first-class scenario concept and the assignment decision indexed by (worker, shift, scenario). Persist the assignments to the ontology. **Response:** OPTIMAL (satisfiable) at all three coverage levels — 66 binary variables (22 availability pairs x 3 scenarios), 48 constraints. The assignment is written back as `Worker.x_assign(Shift, Scenario)`. This is a feasibility problem with no objective, so the solver returns one valid assignment per level — an alternative valid assignment may differ run to run. ## 4. Read the staffing levels -**Prompt:** /rai-prescriptive-results-interpretation For each coverage target, what's the minimum staffing the team needs, and how much coverage can the current roster sustain? +**Prompt:** /rai-prescriptive-results For each coverage target, what's the minimum staffing the team needs, and how much coverage can the current roster sustain? **Response:** All three targets are satisfiable. Meeting 1, 2, and 3 workers per shift requires at minimum **3, 6, and 9 staffed slots** across the three shifts. With 10 workers each capped at one shift, even triple coverage (9 slots) fits — with one worker to spare — so **3-per-shift is the sustainable ceiling** for this roster; any higher target, or losing availability, would risk infeasibility. (Because there's no objective, the solver may return any assignment meeting these minimums, so the exact roster varies.) diff --git a/v1/shipment_compliance/runbook.md b/v1/shipment_compliance/runbook.md index 513cb9ad..c58b543c 100644 --- a/v1/shipment_compliance/runbook.md +++ b/v1/shipment_compliance/runbook.md @@ -6,43 +6,35 @@ Supply-chain operations generate more shipment, sourcing, and demand data than a 6 concepts: 5 suppliers · 6 SKUs · 12 shipments · 7 operations · 6 BOM lines · 8 demand orders │ ▼ -/rai-rules-authoring (four derived flags) +/rai-pyrel (four derived flags, then the exception worklist) • Shipment.is_late (delay_days > 0) -> 2 • Shipment.is_at_risk (undelivered AND supplier reliability < 0.8) -> 6 • BillOfMaterials.is_single_sourced (only one operation makes the input) -> 2 • Demand.is_escalated (priority HIGH or URGENT) -> 4 - │ - ▼ -/rai-querying — list the flagged shipments, BOM inputs, and demand orders + • list the flagged shipments, BOM inputs, and demand orders ``` -Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` skill (named at the start of each prompt). They run in order in a single session — the rules step writes the flags back onto the concepts the build step created, and the query step reads them. +Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` skill (named at the start of each prompt). They run in order in a single session — the rules step writes the flags back onto the concepts the build step created, then reads the exception worklist out of them. --- ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/suppliers.csv` (each supplier has a reliability score), `data/skus.csv` (each SKU has a product type), `data/shipments.csv` (each shipment has a status and a delay in days, and links to a SKU and a supplier), `data/operations.csv` (each operation consumes an input SKU and produces an output SKU), `data/bill_of_materials.csv` (each BOM line requires an input SKU), and `data/demands.csv` (each demand order has a quantity and a priority, and links to a SKU). +**Prompt:** /rai-ontology Build an ontology from `data/suppliers.csv` (each supplier has a reliability score), `data/skus.csv` (each SKU has a product type), `data/shipments.csv` (each shipment has a status and a delay in days, and links to a SKU and a supplier), `data/operations.csv` (each operation consumes an input SKU and produces an output SKU), `data/bill_of_materials.csv` (each BOM line requires an input SKU), and `data/demands.csv` (each demand order has a quantity and a priority, and links to a SKU). **Response:** Loads `Supplier` (5, with `reliability_score`), `SKU` (6, with `product_type`), `Shipment` (12, with `status` and `delay_days`, linked to SKU and supplier), `Operation` (7, with input/output SKU), `BillOfMaterials` (6, requiring an input SKU), and `Demand` (8, with `quantity` and `priority`). Status and priority are closed enumerations. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? **Response:** Six concepts — 5 `Supplier`, 6 `SKU`, 12 `Shipment`, 7 `Operation`, 6 `BillOfMaterials`, 8 `Demand` — linked by SKU/supplier references, forming a small sourcing-and-fulfillment model. -## 3. Author the compliance rules - -**Prompt:** /rai-rules-authoring Define four derived flags. (1) A shipment is **late** if its delay in days is greater than zero. (2) A shipment is **at risk** if it isn't delivered yet and its supplier's reliability score is below 0.8. (3) A bill-of-materials input is **single-sourced** if exactly one operation produces that input SKU. (4) A demand order is **escalated** if its priority is HIGH or URGENT. Write each as a boolean property on its concept. - -**Response:** Authors `Shipment.is_late` (threshold rule), `Shipment.is_at_risk` (cross-entity join to the supplier), `BillOfMaterials.is_single_sourced` (aggregation over producing operations), and `Demand.is_escalated` (OR over two priority tiers) — four boolean derived properties, one per rule pattern. - -## 4. List the flagged records +## 3. Author the compliance rules and list the flagged records -**Prompt:** /rai-querying How many records does each flag catch, and which ones? +**Prompt:** /rai-pyrel Define four derived flags. (1) A shipment is **late** if its delay in days is greater than zero. (2) A shipment is **at risk** if it isn't delivered yet and its supplier's reliability score is below 0.8. (3) A bill-of-materials input is **single-sourced** if exactly one operation produces that input SKU. (4) A demand order is **escalated** if its priority is HIGH or URGENT. Write each as a boolean property on its concept. Then: how many records does each flag catch, and which ones? -**Response:** **2 late shipments** (Widget-B from GlobalChip, 3 days; Frame-Z from Acme Parts, 1 day). **6 at-risk shipments** — all from the two low-reliability suppliers, GlobalChip (0.65) and BudgetSupply (0.72). **2 single-sourced BOM inputs**, both Chip-Y, which only one operation produces — a concentration risk. **4 escalated demand orders** (the HIGH and URGENT ones, all Widget-A or Widget-B). The flags turn raw rows into an exception worklist without anyone scanning the tables. +**Response:** Authors `Shipment.is_late` (threshold rule), `Shipment.is_at_risk` (cross-entity join to the supplier), `BillOfMaterials.is_single_sourced` (aggregation over producing operations), and `Demand.is_escalated` (OR over two priority tiers) — four boolean derived properties, one per rule pattern. Reading them back: **2 late shipments** (Widget-B from GlobalChip, 3 days; Frame-Z from Acme Parts, 1 day). **6 at-risk shipments** — all from the two low-reliability suppliers, GlobalChip (0.65) and BudgetSupply (0.72). **2 single-sourced BOM inputs**, both Chip-Y, which only one operation produces — a concentration risk. **4 escalated demand orders** (the HIGH and URGENT ones, all Widget-A or Widget-B). The flags turn raw rows into an exception worklist without anyone scanning the tables. ## Data diff --git a/v1/smoker_status_prediction/runbook.md b/v1/smoker_status_prediction/runbook.md index 790968a3..a615e789 100644 --- a/v1/smoker_status_prediction/runbook.md +++ b/v1/smoker_status_prediction/runbook.md @@ -18,13 +18,13 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/people.csv` (each person has an id and health-screening attributes — age, height, weight, blood pressure, fasting blood sugar, cholesterol, triglyceride, HDL, LDL, hemoglobin, and more), `data/related.csv` (an edge list pairing two people who are related), and the `data/train.csv`, `data/validation.csv`, and `data/test.csv` tables that carry the smoking label for each split. Model "related" as a relationship between people. +**Prompt:** /rai-ontology Build an ontology from `data/people.csv` (each person has an id and health-screening attributes — age, height, weight, blood pressure, fasting blood sugar, cholesterol, triglyceride, HDL, LDL, hemoglobin, and more), `data/related.csv` (an edge list pairing two people who are related), and the `data/train.csv`, `data/validation.csv`, and `data/test.csv` tables that carry the smoking label for each split. Model "related" as a relationship between people. **Response:** Loads `People` (38,984, with the health-screening attributes), a `Related` person-to-person edge list (58,355 edges), and the train / validation / test label tables (31,187 / 3,898 / 3,899 people, each with a `smoking` flag). ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? **Response:** `People` (38,984, with health attributes), a `Related` self-relationship (58,355 person-to-person edges), and the labeled splits — 31,187 train, 3,898 validation, 3,899 test. The test split is scored by the model. diff --git a/v1/sprint_scheduling/runbook.md b/v1/sprint_scheduling/runbook.md index 3d85e3da..e28d33b3 100644 --- a/v1/sprint_scheduling/runbook.md +++ b/v1/sprint_scheduling/runbook.md @@ -6,7 +6,7 @@ An engineering manager needs to decide which developer works which backlog issue 8 developers (team, capacity) · 30 issues (25 in horizon: story points, priority, team) · 4 sprints · skill map │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decision: binary assign per valid (developer, issue, sprint) — 259 candidates • constraints: each in-scope issue assigned once; per-developer-per-sprint story points ≤ capacity x multiplier; only skill-matched developers, only sprints at or after the issue's target sprint @@ -14,7 +14,7 @@ An engineering manager needs to decide which developer works which backlog issue • capacity scenarios 0.35 / 0.5 / 1.0 -> INFEASIBLE / OPTIMAL 112 / OPTIMAL 112 │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • 0.35x capacity can't fit the backlog (INFEASIBLE); 0.5x already suffices (objective 112, same as full) • the plan front-loads Sprint 1 (10 of 25 issues); per-sprint developer capacity is the binding limit ``` @@ -25,25 +25,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/developers.csv` (each developer has a team and a capacity in story points per sprint), `data/sprints.csv` (each sprint has a number and start/end dates), `data/issues.csv` (each issue has story points, a priority, a team, and a creation date), and `data/skills.csv` (which teams each developer can work). Keep only issues created within the planning horizon, and derive each issue's target sprint (the earliest sprint it could be worked) from its creation date. +**Prompt:** /rai-ontology Build an ontology from `data/developers.csv` (each developer has a team and a capacity in story points per sprint), `data/sprints.csv` (each sprint has a number and start/end dates), `data/issues.csv` (each issue has story points, a priority, a team, and a creation date), and `data/skills.csv` (which teams each developer can work). Keep only issues created within the planning horizon, and derive each issue's target sprint (the earliest sprint it could be worked) from its creation date. **Response:** Loads `Developer` (8, with team and `capacity_points_per_sprint`), `Sprint` (4 two-week periods), `Issue` (30, of which **25 fall inside the horizon**; the 5 created before the horizon are filtered out), and `Skill` (the developer-team map). Each in-scope issue gets a derived `target_sprint_number`. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? **Response:** Four concepts — 8 `Developer`, 4 `Sprint`, 30 `Issue` (25 in the planning horizon), and a 10-row `Skill` map (two developers carry cross-team skills) — the inputs to a developer-issue-sprint assignment. ## 3. Build the sprint plan across capacity scenarios -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Assign each in-scope issue to exactly one developer in one sprint to minimize weighted completion time — where an urgent (low-priority-number) issue costs more the later its sprint. A developer can only take an issue if their team matches the issue's team and the sprint is at or after the issue's target sprint, and each developer's assigned story points per sprint can't exceed their capacity. Solve three capacity scenarios — scaling every developer's capacity to 35%, 50%, and 100% — and persist the assignment. +**Prompt:** /rai-prescriptive-problem Assign each in-scope issue to exactly one developer in one sprint to minimize weighted completion time — where an urgent (low-priority-number) issue costs more the later its sprint. A developer can only take an issue if their team matches the issue's team and the sprint is at or after the issue's target sprint, and each developer's assigned story points per sprint can't exceed their capacity. Solve three capacity scenarios — scaling every developer's capacity to 35%, 50%, and 100% — and persist the assignment. **Response:** The decision is a binary assignment over the 259 valid (developer, issue, sprint) combinations, with 57 constraints per scenario (HiGHS). At **0.35x capacity the problem is INFEASIBLE** — the backlog can't fit — while **0.5x and 1.0x are both OPTIMAL with objective 112.0**. The assignment is read back per scenario from the solved decision. ## 4. Read the plan -**Prompt:** /rai-prescriptive-results-interpretation At what capacity does the backlog stop fitting, how does the plan distribute work across sprints, and what's the binding limit? +**Prompt:** /rai-prescriptive-results At what capacity does the backlog stop fitting, how does the plan distribute work across sprints, and what's the binding limit? **Response:** The backlog is infeasible at 35% capacity but fits from **50% upward — and 50% already achieves the same optimal objective (112) as full capacity**, so the team has slack at 100%. The plan **front-loads Sprint 1 with 10 of the 25 issues** (then 8 and 7 into Sprints 2 and 3), because urgent issues are cheaper to finish early. The binding limit is **per-sprint developer capacity** — it's what makes 0.35x infeasible and what shapes the front-loading. (Specific developer assignments vary between the 0.5x and 1.0x optima; the objective and sprint distribution are stable.) diff --git a/v1/subscriber_retention/README.md b/v1/subscriber_retention/README.md index 87f26857..015504bd 100644 --- a/v1/subscriber_retention/README.md +++ b/v1/subscriber_retention/README.md @@ -260,7 +260,7 @@ For the implementation, see `subscriber_retention.py`; to reproduce it step by s The bundled CSVs are loaded via `model.data(df)` for a no-setup local demo. To run against full data living in Snowflake instead: -1. Replace the three `pd.read_csv(...)` calls at the top of the script with Snowpark queries (or use `model.Table("..
")` directly per the `rai-pyrel-coding` skill's data-loading guidance): +1. Replace the three `pd.read_csv(...)` calls at the top of the script with Snowpark queries (or use `model.Table("..
")` directly per the `rai-pyrel` skill's data-loading guidance): ```python from relationalai.config import SnowflakeConnection, create_config from snowflake import snowpark diff --git a/v1/subscriber_retention/runbook.md b/v1/subscriber_retention/runbook.md index 2dae7fb3..79cb69f8 100644 --- a/v1/subscriber_retention/runbook.md +++ b/v1/subscriber_retention/runbook.md @@ -30,7 +30,7 @@ reaching a test RMSE of ~0.14 — a network-aware retention queue. **Prompt** ``` -/rai-build-starter-ontology Build an ontology from data/telco_mini/: subscribers.csv (each subscriber has a segment, type, status, lifetime value, NPS, signup date, and a churn risk score), plans_contracts.csv (each subscriber's plan — type, monthly rate, data limit, term, auto-renew, early-termination fee — joined onto the subscriber), and call_detail_records.csv (each call is from one subscriber to another). Model the call as a relationship between subscribers. +/rai-ontology Build an ontology from data/telco_mini/: subscribers.csv (each subscriber has a segment, type, status, lifetime value, NPS, signup date, and a churn risk score), plans_contracts.csv (each subscriber's plan — type, monthly rate, data limit, term, auto-renew, early-termination fee — joined onto the subscriber), and call_detail_records.csv (each call is from one subscriber to another). Model the call as a relationship between subscribers. ``` **Response** @@ -42,7 +42,7 @@ Loads `Subscriber` (1,200, with plan attributes joined on, segment mix PREMIUM/S **Prompt** ``` -/rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +/rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? ``` **Response** @@ -90,7 +90,7 @@ A GNN regression head trains on the subscriber call graph (features: segment, pl **Prompt** ``` -/rai-querying For each segment, which test-set subscribers have the highest predicted churn risk — the retention queue to action first? +/rai-pyrel For each segment, which test-set subscribers have the highest predicted churn risk — the retention queue to action first? ``` **Response** diff --git a/v1/supplier_reliability/runbook.md b/v1/supplier_reliability/runbook.md index a8f07348..baa5b170 100644 --- a/v1/supplier_reliability/runbook.md +++ b/v1/supplier_reliability/runbook.md @@ -6,14 +6,14 @@ A procurement team wants the cheapest way to source every product across supplie 4 suppliers (price, capacity) · 3 products (demand, 750 total) · 10 supplier-product lanes │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decision: continuous order quantity per supply lane, ≥ 0 • constraints: per-supplier total ≤ capacity; per-product total ≥ demand • objective: minimize sum(quantity x lane cost); solve with sensitivity marginals • HiGHS linear program -> OPTIMAL, $4,850 │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • SupplierC capacity is the bottleneck (cheapest on every product; shadow price −2) • disruption: remove SupplierC → $6,750 (+39%); remove SupplierB → $5,150 (+6%) ``` @@ -24,31 +24,31 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/suppliers.csv` (each supplier has a capacity and a reliability score), `data/products.csv` (each product has a demand), and `data/supply_options.csv` (each supplier-product lane has a per-unit cost). Model the supply option as a relationship linking a supplier and a product to its cost. +**Prompt:** /rai-ontology Build an ontology from `data/suppliers.csv` (each supplier has a capacity and a reliability score), `data/products.csv` (each product has a demand), and `data/supply_options.csv` (each supplier-product lane has a per-unit cost). Model the supply option as a relationship linking a supplier and a product to its cost. **Response:** Loads `Supplier` (4: SupplierA–D, capacities 500/400/600/350, with a `reliability` score), `Product` (3: Widget 300, Gadget 250, Component 200 — 750 total), and `SupplyOption` (10 supplier-product lanes, each with `cost_per_unit`; SupplierC is cheapest on every product). Note that 10 of the 12 possible pairs exist. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many of each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many of each? **Response:** Three concepts — 4 `Supplier` (capacity, reliability), 3 `Product` (demand, 750 total), and 10 `SupplyOption` (the available supplier-product lanes with per-unit cost). The reliability score is carried as context; the sourcing optimization is cost-driven. ## 3. Source at minimum cost -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management What order quantity on each supply lane meets every product's demand at minimum total cost, with no supplier shipping beyond its capacity? Use a continuous, non-negative quantity per lane, require each supplier's total to stay within capacity and each product's total to cover its demand, and solve with sensitivity analysis on so the capacity shadow prices, demand shadow prices, and lane reduced costs come back too. +**Prompt:** /rai-prescriptive-problem What order quantity on each supply lane meets every product's demand at minimum total cost, with no supplier shipping beyond its capacity? Use a continuous, non-negative quantity per lane, require each supplier's total to stay within capacity and each product's total to cover its demand, and solve with sensitivity analysis on so the capacity shadow prices, demand shadow prices, and lane reduced costs come back too. **Response:** OPTIMAL (HiGHS), total sourcing cost **$4,850** (relative gap 0.0). 10 continuous quantity variables, 7 constraints (4 capacity, 3 demand); the capacity and demand constraints are keyed by supplier and product so their shadow prices read back per entity, and each lane's reduced cost and basis status are available from the solve. (Several cost-equal optima exist, so the exact lane quantities can vary; the cost and marginals are stable.) ## 4. Read the marginals -**Prompt:** /rai-prescriptive-results-interpretation Which supplier's capacity is the bottleneck to expand first, what does an extra unit of each product's demand cost, and which lanes are priced out? +**Prompt:** /rai-prescriptive-results Which supplier's capacity is the bottleneck to expand first, what does an extra unit of each product's demand cost, and which lanes are priced out? **Response:** **SupplierC is the bottleneck** — the only supplier whose capacity binds (shadow price −2, i.e. one more unit of its capacity saves $2), because it's cheapest on every product. Each product's demand shadow price is the marginal cost of one more unit: **Component $7, Widget $8, Gadget $9**. The priced-out lanes (positive reduced cost, unused) are the SupplierA and SupplierD lanes — they'd only enter the plan if their cost dropped or SupplierC capacity ran out. ## 5. Stress-test supplier disruption -**Prompt:** /rai-prescriptive-results-interpretation How much does total cost rise if we lose a supplier entirely — first SupplierC, then SupplierB — re-solving sourcing without them? +**Prompt:** /rai-prescriptive-results How much does total cost rise if we lose a supplier entirely — first SupplierC, then SupplierB — re-solving sourcing without them? **Response:** Removing **SupplierC** (the cheapest, capacity-binding supplier) pushes cost to **$6,750 — a 39% increase** — confirming it as the critical dependency. Removing **SupplierB** raises cost only to **$5,150 (+6%)**, since its volume re-sources cheaply. Both remain OPTIMAL (demand is still satisfiable), so the risk is cost, not feasibility — the reliability exposure concentrates on SupplierC. diff --git a/v1/supply_chain_resilience/runbook.md b/v1/supply_chain_resilience/runbook.md index 2f15daaf..0a0acf43 100644 --- a/v1/supply_chain_resilience/runbook.md +++ b/v1/supply_chain_resilience/runbook.md @@ -44,7 +44,7 @@ watch->avoid downgrade = +0.0% (optimizer already routed around it). **Prompt** ``` -/rai-build-starter-ontology Build a supply chain ontology from the CSVs in data/. It should have a Site (a physical location with a region), a Business (a supplier, manufacturer, warehouse, or buyer, each at a site, with a reliability score), a SKU, an Operation (a shipping lane between two sites carrying a SKU at a per-unit cost — model it as the network edge the optimizer will route flow over), a Demand order (a quantity of a SKU requested by a business, with a priority), a Shipment (a historical movement with an on-time/late flag), and a quarterly DelayPrediction per supplier. Wire Operations between their origin and destination Sites so the shipment graph can be traced, and link Demand and Shipment back to their Business and SKU. +/rai-ontology Build a supply chain ontology from the CSVs in data/. It should have a Site (a physical location with a region), a Business (a supplier, manufacturer, warehouse, or buyer, each at a site, with a reliability score), a SKU, an Operation (a shipping lane between two sites carrying a SKU at a per-unit cost — model it as the network edge the optimizer will route flow over), a Demand order (a quantity of a SKU requested by a business, with a priority), a Shipment (a historical movement with an on-time/late flag), and a quarterly DelayPrediction per supplier. Wire Operations between their origin and destination Sites so the shipment graph can be traced, and link Demand and Shipment back to their Business and SKU. ``` **Response** @@ -56,7 +56,7 @@ Concepts: `Site`, `Business`, `SKU`, `Operation`, `Demand`, `Shipment`, `DelayPr **Prompt** ``` -/rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +/rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? ``` **Response** @@ -104,7 +104,7 @@ Reasoner-routing plan: (1) Graph reachability for upstream supplier exposure, (2 **Prompt** ``` -/rai-rules-authoring Which suppliers are unreliable (reliability score below 0.80) or high-delay-risk (Q1 delay prediction above 0.15), and how should we tier them — 'avoid' (both flags fire), 'watch' (either flag fires), or 'reliable' (neither)? Also flag any HIGH-priority demand orders as escalated so downstream solves can prioritize them. +/rai-pyrel Which suppliers are unreliable (reliability score below 0.80) or high-delay-risk (Q1 delay prediction above 0.15), and how should we tier them — 'avoid' (both flags fire), 'watch' (either flag fires), or 'reliable' (neither)? Also flag any HIGH-priority demand orders as escalated so downstream solves can prioritize them. ``` **Response** @@ -116,7 +116,7 @@ Reasoner-routing plan: (1) Graph reachability for upstream supplier exposure, (2 **Prompt** ``` -/rai-prescriptive-problem-formulation What's the minimum-cost shipping plan that fulfills all open demand, hard-blocks 'avoid' suppliers (x_flow == 0), adds a $5/unit surcharge on 'watch' suppliers, weights each unit of flow into a destination site by 2.0 × that site's centrality (so flow into high-centrality hubs costs more), and penalizes unmet demand at $100/unit? +/rai-prescriptive-problem What's the minimum-cost shipping plan that fulfills all open demand, hard-blocks 'avoid' suppliers (x_flow == 0), adds a $5/unit surcharge on 'watch' suppliers, weights each unit of flow into a destination site by 2.0 × that site's centrality (so flow into high-centrality hubs costs more), and penalizes unmet demand at $100/unit? ``` **Response** @@ -128,7 +128,7 @@ OPTIMAL · $1,865 · 8 active flows · 0 unmet. MILP on `Operation.x_flow` + `De **Prompt** ``` -/rai-prescriptive-solver-management + /rai-prescriptive-results-interpretation Re-solve with the highest-centrality site offline, and again with watch-level suppliers downgraded to avoid. What's the cost delta in each, and why are they asymmetric? +/rai-prescriptive-results Re-solve with the highest-centrality site offline, and again with watch-level suppliers downgraded to avoid. What's the cost delta in each, and why are they asymmetric? ``` **Response** @@ -140,7 +140,7 @@ Baseline OPTIMAL $1,865 / 8 flows / 0 unmet; S004 offline +88.5%; watch->avoid + **Prompt** ``` -/rai-ontology-design Add a RoutingScenario concept that materializes each scenario solve (Baseline, S004-offline, Watch->Avoid) with its status, total cost, cost delta versus baseline, active flow count, unmet total, and any blocked businesses. +/rai-ontology Add a RoutingScenario concept that materializes each scenario solve (Baseline, S004-offline, Watch->Avoid) with its status, total cost, cost delta versus baseline, active flow count, unmet total, and any blocked businesses. ``` **Response** diff --git a/v1/supply_chain_resilience/supply_chain_resilience.py b/v1/supply_chain_resilience/supply_chain_resilience.py index 8f77e5f2..864c827a 100644 --- a/v1/supply_chain_resilience/supply_chain_resilience.py +++ b/v1/supply_chain_resilience/supply_chain_resilience.py @@ -737,7 +737,7 @@ def solve_flow(label, exclude_site_id=None, block_business_ids=None, use_avoid_r # -------------------------------------------------- # Persist scenario solves into the ontology (RoutingScenario Concept) # -------------------------------------------------- -# Per /rai-prescriptive-problem-formulation/scenario-analysis.md "Scenario +# Per /rai-prescriptive-problem/scenario-analysis.md "Scenario # Concept" pattern: load scenario rows via model.data(list_of_tuples, # columns=[...]) and bind via Concept.new(...).to_schema(). diff --git a/v1/supply_chain_transport/runbook.md b/v1/supply_chain_transport/runbook.md index 284d6516..24b29a0f 100644 --- a/v1/supply_chain_transport/runbook.md +++ b/v1/supply_chain_transport/runbook.md @@ -6,7 +6,7 @@ A freight planner has to decide, for each shipment, *when* to ship, *how much*, 2 freight groups (day-windows, weight) · 2 modes (TL fixed-per-truck, LTL piecewise) · LTL rate tiers │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decisions: when/how much to ship, by which mode; daily inventory; arrival day • constraints: inventory flow & deadline windows; ship-all (all-or-nothing); TL truck capacity; LTL piecewise rate tiers; arrival = departure + transit time @@ -14,7 +14,7 @@ A freight planner has to decide, for each shipment, *when* to ship, *how much*, • HiGHS mixed-integer program -> OPTIMAL (script total $1,444) │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • both groups ship by LTL within their windows; zero TL trucks • each light load's LTL cost is far below the $2,000-per-truck fixed charge ``` @@ -25,25 +25,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/freight_groups.csv` — each freight group has an inventory window, a transport window, an arrival window (each a start and end day), and a starting weight. Also model two transport types — truckload (transit 2 days, $2,000 per truck, 24,000 lb capacity) and less-than-truckload (transit 3 days) — and the LTL cost segments as a piecewise per-pound rate: up to 6,000 lb at $0.18/lb, then up to 7,000 lb at $0.12/lb. Inventory holding costs 0.1% of weight per day held. +**Prompt:** /rai-ontology Build an ontology from `data/freight_groups.csv` — each freight group has an inventory window, a transport window, an arrival window (each a start and end day), and a starting weight. Also model two transport types — truckload (transit 2 days, $2,000 per truck, 24,000 lb capacity) and less-than-truckload (transit 3 days) — and the LTL cost segments as a piecewise per-pound rate: up to 6,000 lb at $0.18/lb, then up to 7,000 lb at $0.12/lb. Inventory holding costs 0.1% of weight per day held. **Response:** Loads `FreightGroup` (2: fg1 4,000 lb, fg2 5,000 lb, each with inventory/transport/arrival day-windows), `TransportType` (2: TL transit 2 days, LTL transit 3 days), and `LTLSegment` (2 piecewise tiers: up to 6,000 lb at $0.18/lb, then to 7,000 lb at $0.12/lb). ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many of each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many of each? **Response:** Three concepts — 2 `FreightGroup` (day-windows and starting weight), 2 `TransportType` (TL, LTL with transit times), and 2 `LTLSegment` (the LTL piecewise rate tiers). TL costs $2,000 per truck (24,000 lb capacity); inventory holding is 0.1% of weight per day held. ## 3. Schedule and route the freight -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management For each freight group, decide when to ship, how much, and by which mode to minimize total cost. Track daily warehouse inventory (it must start at the group's weight and reach zero by the end), ship each group all at once within its transport window, set arrival day as departure plus the mode's transit time within the arrival window, cap truckload weight at truck capacity per truck used, and price LTL across its piecewise weight tiers. Minimize inventory holding cost plus truckload fixed cost plus LTL cost, and persist the decisions to the ontology. +**Prompt:** /rai-prescriptive-problem For each freight group, decide when to ship, how much, and by which mode to minimize total cost. Track daily warehouse inventory (it must start at the group's weight and reach zero by the end), ship each group all at once within its transport window, set arrival day as departure plus the mode's transit time within the arrival window, cap truckload weight at truck capacity per truck used, and price LTL across its piecewise weight tiers. Minimize inventory holding cost plus truckload fixed cost plus LTL cost, and persist the decisions to the ontology. **Response:** OPTIMAL (HiGHS), total cost **$1,444** (relative gap 0.0). 62 variables (continuous quantities and inventory, integer arrival days, binary mode/segment choices) and 52 constraints; the inventory, shipment, and arrival decisions are written back across the `FreightGroup`, `TransportType`, and `LTLSegment` concepts. ## 4. Read the shipping plan -**Prompt:** /rai-prescriptive-results-interpretation How does the optimal plan ship each group, and why does it pick that mode? +**Prompt:** /rai-prescriptive-results How does the optimal plan ship each group, and why does it pick that mode? **Response:** The plan ships **both groups by LTL on day 2** (9,000 lb combined), each arriving on day 5, and uses **zero truckload trucks**. LTL consolidation wins here: the combined LTL cost of $1,444 undercuts the $2,000 fixed cost of even a single TL truck, so paying per-pound on LTL beats committing to truckload at these volumes. diff --git a/v1/telco_network_recovery/runbook.md b/v1/telco_network_recovery/runbook.md index 1a091e38..ff91b8c7 100644 --- a/v1/telco_network_recovery/runbook.md +++ b/v1/telco_network_recovery/runbook.md @@ -21,7 +21,7 @@ figures shift run to run; the structural outcome holds.) probabilities; range 0.02-10.47. ───────────────────────────────────────────────────────────────── STAGE 2 Rules ──► CellTower.is_critical_restore (142) - /rai-rules-authoring Three-branch flag: 2 WEST operational + /rai-pyrel Three-branch flag: 2 WEST operational branches + 1 predictive branch. ───────────────────────────────────────────────────────────────── STAGE 3 Graph ──► Subscriber.influence_score (PageRank, @@ -37,8 +37,8 @@ figures shift run to run; the structural outcome holds.) recovered. Top route persisted. ───────────────────────────────────────────────────────────────── STAGE 5 Prescriptive ──► TowerUpgradeOption.selected (27) - /rai-prescriptive- OPTIMAL · 12 BRONZE · 7 SILVER · 8 GOLD - problem-formulation $4,992,276 of $5M (binding) · 180 Gbps + /rai-prescriptive-problem OPTIMAL · 12 BRONZE · 7 SILVER · 8 GOLD + $4,992,276 of $5M (binding) · 180 Gbps 161 of 200 install-weeks (slack) Region: SOUTH 7, EAST 6, WEST 6, CENTRAL 4, NORTH 4. @@ -54,7 +54,7 @@ figures shift run to run; the structural outcome holds.) **Prompt** ``` -/rai-build-starter-ontology Build a telco network ontology from the CSVs in data/. Include a ModelAdvisory concept so manufacturer recall/defect/EOL/firmware notices can be linked to every equipment item of the affected model. +/rai-ontology Build a telco network ontology from the CSVs in data/. Include a ModelAdvisory concept so manufacturer recall/defect/EOL/firmware notices can be linked to every equipment item of the affected model. ``` **Response** @@ -66,7 +66,7 @@ Concepts: `CellTower`, `NetworkEquipment` (with `tower_id_fk` FK property), `Equ **Prompt** ``` -/rai-querying What concepts and relationships does the ontology have, how many rows are in each, and what's the advisory coverage — how many MODELs are advised, what are the severities, and what fraction of equipment sits on an advised MODEL? +/rai-pyrel What concepts and relationships does the ontology have, how many rows are in each, and what's the advisory coverage — how many MODELs are advised, what are the severities, and what fraction of equipment sits on an advised MODEL? ``` **Response** @@ -83,7 +83,7 @@ Concepts: `CellTower`, `NetworkEquipment` (with `tower_id_fk` FK property), `Equ **Response** -Plans the 5-reasoner chain on the shared ontology — descriptive (`/rai-querying`) to scope the ontology and advisory landscape; predictive (`/rai-predictive-modeling` + `/rai-predictive-training`) to train an equipment-failure binary classification GNN with a `ModelAdvisory → NetworkEquipment` edge and bind the per-tower `failure_intensity` back to `CellTower`; rules (`/rai-rules-authoring`) to flag critical-restore towers via a three-branch rule combining operational degradation with the predictive intensity; graph (`/rai-graph-analysis`) to compute subscriber PageRank and aggregate per-tower customer impact (revenue × churn across ACTIVE callers); prescriptive (`/rai-prescriptive-problem-formulation` + `/rai-prescriptive-results-interpretation`) to compose all three signals into the tier-selection MIP and explain the binding constraint. +Plans the 5-reasoner chain on the shared ontology — descriptive (`/rai-pyrel`) to scope the ontology and advisory landscape; predictive (`/rai-predictive-modeling` + `/rai-predictive-training`) to train an equipment-failure binary classification GNN with a `ModelAdvisory → NetworkEquipment` edge and bind the per-tower `failure_intensity` back to `CellTower`; rules (`/rai-pyrel`) to flag critical-restore towers via a three-branch rule combining operational degradation with the predictive intensity; graph (`/rai-graph-analysis`) to compute subscriber PageRank and aggregate per-tower customer impact (revenue × churn across ACTIVE callers); prescriptive (`/rai-prescriptive-problem` + `/rai-prescriptive-results`) to compose all three signals into the tier-selection MIP and explain the binding constraint. ### 4. Train the equipment-failure GNN @@ -102,7 +102,7 @@ GNN binary classification with `eval_metric=roc_auc`, 80 epochs, three FK / shar **Prompt** ``` -/rai-rules-authoring Which towers should we flag as critical-restore? Any tower fitting one of three cases: (1) in WEST and DEGRADED with poor equipment health (avg health below 0.85); (2) in WEST and showing high packet loss (above 5%) with poor health — catches ACTIVE-but-failing towers operations would otherwise miss; (3) predicted equipment-failure intensity above 1.5 (any region) — catches towers where multiple equipment items are at risk before they fail. Compute the per-tower health average by joining EquipmentHealth through NetworkEquipment to CellTower. +/rai-pyrel Which towers should we flag as critical-restore? Any tower fitting one of three cases: (1) in WEST and DEGRADED with poor equipment health (avg health below 0.85); (2) in WEST and showing high packet loss (above 5%) with poor health — catches ACTIVE-but-failing towers operations would otherwise miss; (3) predicted equipment-failure intensity above 1.5 (any region) — catches towers where multiple equipment items are at risk before they fail. Compute the per-tower health average by joining EquipmentHealth through NetworkEquipment to CellTower. ``` **Response** @@ -138,7 +138,7 @@ Where PageRank scores a *subscriber*, paths scores the *route*. From the top-Pag **Prompt** ``` -/rai-prescriptive-problem-formulation Which tower upgrade plan maximizes weighted capacity restored within our $5M capex and 200 install-week envelope? For each critical-restore tower, pick at most one upgrade tier — BRONZE, SILVER, or GOLD. Each option's contribution to the objective is its `capacity_increase_gbps` multiplied by the tower's `weighted_impact` and its `failure_intensity` — a three-factor product so a high-failure-intensity tower serving high-revenue, churn-fragile accounts outscores a low-risk one. +/rai-prescriptive-problem Which tower upgrade plan maximizes weighted capacity restored within our $5M capex and 200 install-week envelope? For each critical-restore tower, pick at most one upgrade tier — BRONZE, SILVER, or GOLD. Each option's contribution to the objective is its `capacity_increase_gbps` multiplied by the tower's `weighted_impact` and its `failure_intensity` — a three-factor product so a high-failure-intensity tower serving high-revenue, churn-fragile accounts outscores a low-risk one. ``` **Response** @@ -150,7 +150,7 @@ Status OPTIMAL; 27 towers covered (selected from the 142 flagged) across all fiv **Prompt** ``` -/rai-prescriptive-results-interpretation What is the final plan we ended up with — total cost, capacity restored, tier mix, towers covered? Which constraints are binding, and what would relaxing them unlock? +/rai-prescriptive-results What is the final plan we ended up with — total cost, capacity restored, tier mix, towers covered? Which constraints are binding, and what would relaxing them unlock? ``` **Response** @@ -162,7 +162,7 @@ Budget is the binding constraint ($4,992,276 of $5M); install-weeks have ~20% sl **Prompt** ``` -/rai-ontology-design Materialize the optimal plan and the selected upgrades as queryable ontology. Add a RestorePlan concept holding the plan summary (total cost, install-weeks, capacity restored, tier-mix counts, towers covered, binding constraint) and mark the chosen tower-tier rows on TowerUpgradeOption. +/rai-ontology Materialize the optimal plan and the selected upgrades as queryable ontology. Add a RestorePlan concept holding the plan summary (total cost, install-weeks, capacity restored, tier-mix counts, towers covered, binding constraint) and mark the chosen tower-tier rows on TowerUpgradeOption. ``` **Response** diff --git a/v1/transaction_screening_local/runbook.md b/v1/transaction_screening_local/runbook.md index 56d5ef70..72a89310 100644 --- a/v1/transaction_screening_local/runbook.md +++ b/v1/transaction_screening_local/runbook.md @@ -7,14 +7,14 @@ A paste-testable walkthrough for an analyst. Each prompt below is something you ``` transactions.csv — 75 transfers, 54 accounts (in-memory DuckDB, no Snowflake) │ - ▼ /rai-setup and /rai-pyrel-coding — ontology + ▼ /rai-setup and /rai-pyrel — ontology Account · transfers_to (self-referential) │ - ▼ /rai-rules-authoring — classification + ▼ /rai-pyrel — classification is_structuring · is_large_sender · is_suspect · near_suspect · under_review → 6 suspects │ - ▼ /rai-querying — surface and expand + ▼ /rai-pyrel — surface and expand suspect → counterparty (self-join) · investigation set → 8 accounts under review ``` diff --git a/v1/traveling_salesman/runbook.md b/v1/traveling_salesman/runbook.md index 211c2409..b10eb956 100644 --- a/v1/traveling_salesman/runbook.md +++ b/v1/traveling_salesman/runbook.md @@ -6,14 +6,14 @@ A route planner wants the shortest round-trip that visits every stop exactly onc 4 locations, 12 directed distance edges (complete graph), symmetric distances │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decision: a binary "use this edge?" per edge + an integer position per node (MTZ) • constraints: each node has exactly one edge in and one out; MTZ subtour elimination; anchor node 1 • objective: minimize total distance of the selected edges • HiGHS mixed-integer program -> OPTIMAL, tour distance 8.5 │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • optimal tour: 1 → 2 → 4 → 3 → 1 (4 edges, total distance 8.5) ``` @@ -23,25 +23,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/edges.csv` — each row is a directed edge with a source node `i`, a destination node `j`, and a distance `dist`. Derive the set of nodes from the edge endpoints. +**Prompt:** /rai-ontology Build an ontology from `data/edges.csv` — each row is a directed edge with a source node `i`, a destination node `j`, and a distance `dist`. Derive the set of nodes from the edge endpoints. **Response:** Loads `Edge` (12 directed edges, properties `i`, `j`, `dist`) and derives a `Node` concept (4 nodes) from the edge endpoints. The data is a complete directed graph on 4 nodes with symmetric distances (e.g. 1↔2 = 2.0, 2↔4 = 1.5, 3↔4 = 2.5, 1↔4 = 4.0). ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many of each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many of each? **Response:** Two concepts — 12 `Edge` (each with `i`, `j`, `dist`) and 4 `Node` (derived from the endpoints) — forming a complete directed graph where every ordered pair of distinct nodes has an edge. ## 3. Find the shortest tour -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management What's the shortest round-trip that visits every node exactly once and returns to the start, as one connected tour with no disconnected subtours? Use a binary decision per edge for whether it's in the tour, require every node to have exactly one selected edge in and one out, and eliminate subtours with MTZ ordering variables — one integer position per node, anchored at node 1. Minimize total distance, and persist the edge selection to the ontology. +**Prompt:** /rai-prescriptive-problem What's the shortest round-trip that visits every node exactly once and returns to the start, as one connected tour with no disconnected subtours? Use a binary decision per edge for whether it's in the tour, require every node to have exactly one selected edge in and one out, and eliminate subtours with MTZ ordering variables — one integer position per node, anchored at node 1. Minimize total distance, and persist the edge selection to the ontology. **Response:** OPTIMAL (HiGHS mixed-integer program), shortest tour distance **8.5** (relative gap 0.0). The model has 16 variables (12 binary edge selections + 4 integer MTZ positions) and 15 constraints; the edge decision is written back as `Edge.x` and the position as `Node.u`. ## 4. Read the optimal route -**Prompt:** /rai-prescriptive-results-interpretation Which edges form the optimal tour, in what order, and what's the total distance? +**Prompt:** /rai-prescriptive-results Which edges form the optimal tour, in what order, and what's the total distance? **Response:** Four edges are selected — 1 → 2 (2.0), 2 → 4 (1.5), 4 → 3 (2.5), 3 → 1 (2.5) — forming the single tour **1 → 2 → 4 → 3 → 1** with total distance **8.5**. Exactly one edge enters and leaves each node, and the MTZ positions confirm no disconnected subtours. diff --git a/v1/underwriting_audit/runbook.md b/v1/underwriting_audit/runbook.md index 905476c5..ad16b511 100644 --- a/v1/underwriting_audit/runbook.md +++ b/v1/underwriting_audit/runbook.md @@ -6,14 +6,14 @@ A model-risk or RegTech reviewer needs to verify that an underwriting ruleset ac underwriting rule pack (senior / frail / manual-review rules) · applicant attributes (age, coverage, chronic flag) │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • encode the rules as constraints over an applicant's attributes • per audited property: search for a counterexample — an applicant that obeys the rules but violates the property — enumerating up to 16 distinct witnesses (multi-solution mode) • MiniZinc constraint solver -> 3 properties audited │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • 1 PASS, 2 FAIL: "frail ⇒ review" fails (12 witnesses), "chronic under-50 ⇒ review" fails (8) • root cause: manual-review keys only off senior, missing the chronic arm of frailty ``` @@ -24,25 +24,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/age_buckets.csv` (each bucket is an id and an age in years) and `data/coverage_bands.csv` (each band is an id and a coverage amount). These are the reference dimensions for an applicant, who is described by an age bucket, a coverage band, and a chronic-condition flag. +**Prompt:** /rai-ontology Build an ontology from `data/age_buckets.csv` (each bucket is an id and an age in years) and `data/coverage_bands.csv` (each band is an id and a coverage amount). These are the reference dimensions for an applicant, who is described by an age bucket, a coverage band, and a chronic-condition flag. **Response:** Loads `AgeBucket` (4: ages 28, 45, 55, 72) and `CoverageBand` (4: $100k, $250k, $500k, $1M). These define the space of possible applicants; the applicant's attributes and the underwriting rules are added in the audit step. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? **Response:** Two reference concepts — 4 `AgeBucket` (28/45/55/72 years) and 4 `CoverageBand` ($100k/$250k/$500k/$1M). Together they bound the applicant space the audit searches over. ## 3. Audit the ruleset for counterexamples -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Encode the underwriting rules as constraints over an applicant's attributes: an applicant is senior if their age is at least 70; frail if senior or chronically ill; and the ruleset flags an applicant for manual review if they are senior. Then audit three properties — (a) every senior is flagged for review, (b) every frail applicant is flagged for review, (c) every chronically-ill applicant under 50 is flagged for review — by searching for a counterexample for each: an applicant who satisfies the rules but violates the property. Enumerate up to 16 distinct counterexample applicants per property (multi-solution mode). A property passes only if no counterexample exists. +**Prompt:** /rai-prescriptive-problem Encode the underwriting rules as constraints over an applicant's attributes: an applicant is senior if their age is at least 70; frail if senior or chronically ill; and the ruleset flags an applicant for manual review if they are senior. Then audit three properties — (a) every senior is flagged for review, (b) every frail applicant is flagged for review, (c) every chronically-ill applicant under 50 is flagged for review — by searching for a counterexample for each: an applicant who satisfies the rules but violates the property. Enumerate up to 16 distinct counterexample applicants per property (multi-solution mode). A property passes only if no counterexample exists. **Response:** Each property is audited as a fresh constraint problem (MiniZinc) over 6 applicant decision variables. A property with no feasible counterexample is INFEASIBLE — meaning it holds (PASS); a property with feasible counterexamples FAILS, and each witness is a concrete applicant exhibiting the gap. ## 4. Read the audit report -**Prompt:** /rai-prescriptive-results-interpretation Which properties pass, which fail, how many counterexamples does each failure have, and what do they reveal about the rule pack? +**Prompt:** /rai-prescriptive-results Which properties pass, which fail, how many counterexamples does each failure have, and what do they reveal about the rule pack? **Response:** **1 PASS, 2 FAIL.** "Every senior is reviewed" **passes** (no counterexample exists). "Every frail applicant is reviewed" **fails with 12 counterexamples**, and "every chronically-ill applicant under 50 is reviewed" **fails with 8** (a strict subset — the under-50 chronic cases). The witnesses share a shape: chronically-ill, non-senior applicants who are frail but never flagged. The root cause is a one-line gap — manual review is keyed only off *senior*, so it misses the chronic arm of frailty. The audit names the exact failure population rather than just reporting "a test failed." diff --git a/v1/warehouse_allocation/runbook.md b/v1/warehouse_allocation/runbook.md index e639afd3..9c529b44 100644 --- a/v1/warehouse_allocation/runbook.md +++ b/v1/warehouse_allocation/runbook.md @@ -33,7 +33,7 @@ warehouses carry centrality-proportional buffer stock — OPTIMAL at $13,713.29 **Prompt** ``` -/rai-build-starter-ontology Build an ontology from data/sites.csv (each site has a region, a type — warehouse or store — and a per-unit holding cost), data/routes.csv (each route links a source site to a destination site with a capacity and a transport cost), and data/demands.csv (each demand is a quantity at a site). Model the route as a relationship between sites. +/rai-ontology Build an ontology from data/sites.csv (each site has a region, a type — warehouse or store — and a per-unit holding cost), data/routes.csv (each route links a source site to a destination site with a capacity and a transport cost), and data/demands.csv (each demand is a quantity at a site). Model the route as a relationship between sites. ``` **Response** @@ -45,7 +45,7 @@ Loads `Site` (10: 5 warehouses, 5 stores, each with `region`, `type`, `holding_c **Prompt** ``` -/rai-querying What concepts and relationships does the ontology have, and how many rows are in each? +/rai-pyrel What concepts and relationships does the ontology have, and how many rows are in each? ``` **Response** @@ -81,7 +81,7 @@ Eigenvector centrality (the "important neighbors make you important" measure) ra **Prompt** ``` -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management Allocate a non-negative number of units to each site to minimize total holding cost (units times each site's holding cost), keeping total units within the 2,000-unit budget, meeting every site's demand, and requiring each warehouse to hold at least its centrality score times 200 as buffer stock. Persist the allocation as Site.x_inventory. +/rai-prescriptive-problem Allocate a non-negative number of units to each site to minimize total holding cost (units times each site's holding cost), keeping total units within the 2,000-unit budget, meeting every site's demand, and requiring each warehouse to hold at least its centrality score times 200 as buffer stock. Persist the allocation as Site.x_inventory. ``` **Response** @@ -93,7 +93,7 @@ OPTIMAL (HiGHS), total holding cost **$13,713.29**. 10 continuous allocation var **Prompt** ``` -/rai-prescriptive-results-interpretation How much inventory does each site hold, which constraints bind, and is the budget the limiting factor? +/rai-prescriptive-results How much inventory does each site hold, which constraints bind, and is the budget the limiting factor? ``` **Response** diff --git a/v1/water_allocation/runbook.md b/v1/water_allocation/runbook.md index ffc68f86..a1b3213a 100644 --- a/v1/water_allocation/runbook.md +++ b/v1/water_allocation/runbook.md @@ -6,7 +6,7 @@ A water utility wants to meet every user group's demand at minimum sourcing cost 3 sources (capacity, cost) · 3 users (demand) · 9 connections (max flow, loss rate) │ ▼ -/rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management +/rai-prescriptive-problem • decision: continuous flow per connection, 0 ≤ flow ≤ max flow • constraints: outflow per source ≤ capacity; effective inflow per user ≥ demand where delivered = flow x (1 − loss_rate x flow / max_flow) (nonlinear) @@ -14,7 +14,7 @@ A water utility wants to meet every user group's demand at minimum sourcing cost • Ipopt nonlinear program -> LOCALLY_SOLVED, $853.39 │ ▼ -/rai-prescriptive-results-interpretation +/rai-prescriptive-results • 6 of 9 connections carry flow; the expensive Groundwater source is unused • Reservoir_A is pushed to its Municipal connection cap (400, binding) ``` @@ -25,25 +25,25 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/sources.csv` (each source has a capacity and a per-unit extraction cost), `data/users.csv` (each user has a demand), and `data/connections.csv` (each connection links a source to a user with a max flow rate and a loss rate). Model the connection as a relationship between a source and a user carrying its max-flow and loss-rate properties. +**Prompt:** /rai-ontology Build an ontology from `data/sources.csv` (each source has a capacity and a per-unit extraction cost), `data/users.csv` (each user has a demand), and `data/connections.csv` (each connection links a source to a user with a max flow rate and a loss rate). Model the connection as a relationship between a source and a user carrying its max-flow and loss-rate properties. **Response:** Loads `Source` (3: Reservoir_A capacity 1000 / cost 0.5, Reservoir_B 800 / 0.6, Groundwater 500 / 0.8), `User` (3: Municipal demand 600, Industrial 400, Agricultural 500 — total 1500), and `Connection` (9, fully connected, each with `max_flow` and `loss_rate`). ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many of each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many of each? **Response:** Three concepts — 3 `Source` (capacity, cost), 3 `User` (demand), and 9 `Connection` (every source-to-user pair, with `max_flow` and `loss_rate`) — total demand 1500 against 2300 of total source capacity. ## 3. Minimize sourcing cost with transmission loss -**Prompt:** /rai-prescriptive-problem-formulation + /rai-prescriptive-solver-management What non-negative flow on each connection meets every user's demand at minimum total sourcing cost, given that each source's total outflow can't exceed its capacity and that transmission loss grows with utilization — the water delivered on a connection is flow times (1 minus loss_rate times flow over max_flow)? That delivered-water term is quadratic, so this needs a nonlinear solver. Persist the chosen flows to the ontology. +**Prompt:** /rai-prescriptive-problem What non-negative flow on each connection meets every user's demand at minimum total sourcing cost, given that each source's total outflow can't exceed its capacity and that transmission loss grows with utilization — the water delivered on a connection is flow times (1 minus loss_rate times flow over max_flow)? That delivered-water term is quadratic, so this needs a nonlinear solver. Persist the chosen flows to the ontology. **Response:** LOCALLY_SOLVED (Ipopt nonlinear solver), total cost **$853.39**. 9 continuous flow variables (each bounded by its connection's max flow), 6 constraints (3 source-capacity, 3 nonlinear demand-satisfaction). Flows are written back as `Connection.x_flow`. ## 4. Read the allocation -**Prompt:** /rai-prescriptive-results-interpretation Which connections carry water and how much, and what does the plan reveal about the cheapest sourcing strategy? +**Prompt:** /rai-prescriptive-results Which connections carry water and how much, and what does the plan reveal about the cheapest sourcing strategy? **Response:** 6 of the 9 connections carry flow; all three **Groundwater** connections are zero — the solver avoids the most expensive source entirely and serves the network from the two cheaper reservoirs. Reservoir_A is pushed to its Municipal connection's max-flow cap (400.0, binding) and also supplies Agricultural and Industrial; Reservoir_B covers the remainder (Municipal 229, Agricultural 182, Industrial 178). Demand is met everywhere at $853.39. diff --git a/v1/wildlife-conservation-network/runbook.md b/v1/wildlife-conservation-network/runbook.md index bc17ad14..cbd699f4 100644 --- a/v1/wildlife-conservation-network/runbook.md +++ b/v1/wildlife-conservation-network/runbook.md @@ -18,13 +18,13 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 1. Build the ontology -**Prompt:** /rai-build-starter-ontology Build an ontology from `data/organizations.csv` (each organization has a type, a region, and a focus species) and `data/partnerships.csv` (each row is a collaboration partnership between two organizations). Model the partnership as an undirected relationship between organizations. +**Prompt:** /rai-ontology Build an ontology from `data/organizations.csv` (each organization has a type, a region, and a focus species) and `data/partnerships.csv` (each row is a collaboration partnership between two organizations). Model the partnership as an undirected relationship between organizations. **Response:** Loads `Organization` (12, with `type`, `region`, `focus_species`) and a `Partnership` relationship (19 undirected collaboration edges between organizations) — forming a collaboration network across East and Southern Africa. ## 2. Examine the ontology -**Prompt:** /rai-querying What concepts and relationships does the ontology have, and how many of each? +**Prompt:** /rai-pyrel What concepts and relationships does the ontology have, and how many of each? **Response:** One concept, `Organization` (12, with type / region / focus species), connected by `Partnership` (19 undirected edges) — an average of about 3.2 partnerships per organization. From 6eadacc2a150c79942782ecabfe966fd9960a34a Mon Sep 17 00:00:00 2001 From: cafzal Date: Thu, 9 Jul 2026 08:54:35 -0700 Subject: [PATCH 2/2] Fix runbook-prompt ambiguities found by the v3.0.0 paste-test sweep Named restricted/marginal industry codes (commercial_underwriting), made the persist step explicit (bom-reachability), quantified the flow-balance tolerance (money_laundering_motif_detection), de-overloaded "relationships" (fraud-detection), named exact cost weights (defect_root_cause), named the SPOF criterion and allowed ties (memory_supply_allocation), and stated the discount-monotonicity rule (retail_planning). Each was reproducible: a different agent given the same ambiguous prompt could plausibly reach a different, equally-defensible answer. --- v1/bom-reachability/runbook.md | 2 +- v1/commercial_underwriting/runbook.md | 2 +- v1/defect_root_cause/runbook.md | 2 +- v1/fraud-detection/runbook.md | 2 +- v1/memory_supply_allocation/runbook.md | 4 ++-- v1/money_laundering_motif_detection/runbook.md | 2 +- v1/retail_planning/runbook.md | 2 +- 7 files changed, 8 insertions(+), 8 deletions(-) diff --git a/v1/bom-reachability/runbook.md b/v1/bom-reachability/runbook.md index 45c48aca..e1ef9d48 100644 --- a/v1/bom-reachability/runbook.md +++ b/v1/bom-reachability/runbook.md @@ -49,6 +49,6 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 6. Maximal chains and assembly depth -**Prompt:** /rai-graph-analysis The full path set repeats every sub-chain. Reduce it to just the maximal end-to-end chains — the longest routes not contained inside a longer one — and record each finished good's assembly depth, the length of the deepest chain that builds it. +**Prompt:** /rai-graph-analysis The full path set repeats every sub-chain. Reduce it to just the maximal end-to-end chains — the longest routes not contained inside a longer one — and persist each finished good's assembly depth as `SKU.assembly_depth` on the ontology (the length of the deepest chain that builds it). **Response:** 8 of the 18 paths are maximal; the other 10 are shorter sub-chains contained inside them. All 8 maximal chains are 2-hop raw-material → component → finished-good routes (e.g. Silicon Wafer 300mm → Mobile Processor A15 → ProTab T1). Both finished goods have an assembly depth of 2, persisted back onto the ontology as `SKU.assembly_depth` so a later query can rank products by build complexity without re-enumerating paths. diff --git a/v1/commercial_underwriting/runbook.md b/v1/commercial_underwriting/runbook.md index 6982c468..e8d19d01 100644 --- a/v1/commercial_underwriting/runbook.md +++ b/v1/commercial_underwriting/runbook.md @@ -32,7 +32,7 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 3. Author the underwriting rules and read the triage -**Prompt:** /rai-pyrel Encode the underwriting guardrails as layered flags. At the location level: poor fire protection (fire protection class above 6), old construction (built before 1950), high-risk occupancy (gas station, cannabis retail, fast-food, or habitational). At the coverage level: underinsured (a building coverage limit below 80% of the location's replacement value). Roll these up to each insured: a **decline factor** is a restricted industry, fewer than 3 years in business, or any unprotected/old-construction location; a **marginal factor** is a marginal industry, a high-risk-occupancy location, or an underinsured coverage. Then classify each insured into exactly one risk tier: **Decline** if it has any decline factor; otherwise **Non-Standard** if it has any marginal factor; otherwise **Preferred** if it's well-established (15+ years) with every location well-protected; otherwise **Standard**. How many insured entities fall in each tier, and what premium does each tier represent? +**Prompt:** /rai-pyrel Encode the underwriting guardrails as layered flags. At the location level: poor fire protection (fire protection class above 6), old construction (built before 1950), high-risk occupancy (gas station, cannabis retail, fast-food, or habitational). At the coverage level: underinsured (a building coverage limit below 80% of the location's replacement value). Roll these up to each insured: a **decline factor** is a restricted industry (cannabis, nuclear, explosives, or asbestos remediation), fewer than 3 years in business, or any unprotected/old-construction location; a **marginal factor** is a marginal industry (heavy manufacturing or auto repair), a high-risk-occupancy location, or an underinsured coverage. Then classify each insured into exactly one risk tier: **Decline** if it has any decline factor; otherwise **Non-Standard** if it has any marginal factor; otherwise **Preferred** if it's well-established (15+ years) with every location well-protected; otherwise **Standard**. How many insured entities fall in each tier, and what premium does each tier represent? **Response:** Authors the location flags (`has_poor_fire_protection`, `has_old_construction`, `has_high_risk_occupancy`), the coverage flag (`is_underinsured`), the entity rollups (`has_decline_factor`, `has_marginal_factor`), and four mutually-exclusive risk-tier subtype concepts. The rules are declarative, so the reasoner resolves their dependency order automatically and every insured lands in exactly one tier. The 8 insureds partition cleanly: **3 Decline** (a cannabis business, one under 3 years old, one with pre-1950 construction), **3 Non-Standard** (marginal industries or a high-risk-occupancy/underinsured location), **1 Standard**, and **1 Preferred** (15+ years, every location well-protected). Premium concentrates in Non-Standard (~$236k across 3) versus Decline (~$150k) — so the book's exposure is mostly in the marginal tier, exactly the segment underwriting should price and monitor most closely. diff --git a/v1/defect_root_cause/runbook.md b/v1/defect_root_cause/runbook.md index daa40a05..fe316a58 100644 --- a/v1/defect_root_cause/runbook.md +++ b/v1/defect_root_cause/runbook.md @@ -111,7 +111,7 @@ Derived `Factor.touched_count`, `Factor.defect_count`, `Factor.defect_rate`, and **Prompt** ``` -/rai-prescriptive-problem From the suspect factors, find the smallest, most specific set that together explains the defective units. Name as few factors as possible — each named factor carries a fixed cost — and penalize naming a factor that also touches many good (non-defective) units. Allow a defective unit to be left unexplained at a cost rather than forcing in a spurious cause. Every defective unit must be explained by a named factor it touches, or marked unexplained. +/rai-prescriptive-problem From the suspect factors, find the smallest, most specific set that together explains the defective units. Name as few factors as possible — each named factor carries a fixed cost of $5, plus $0.02 per good (non-defective) unit it also touches. Allow a defective unit to be left unexplained at a cost of $1 rather than forcing in a spurious cause. Every defective unit must be explained by a named factor it touches, or marked unexplained. ``` **Response** diff --git a/v1/fraud-detection/runbook.md b/v1/fraud-detection/runbook.md index d5ea1434..76eda537 100644 --- a/v1/fraud-detection/runbook.md +++ b/v1/fraud-detection/runbook.md @@ -42,7 +42,7 @@ about +40% over a naive sort-by-score. **Prompt** ``` -/rai-ontology Build an ontology from the PaySim mobile-money Snowflake schema: accounts (each with an id and an account-type prefix), transactions (each with a type, an amount, sender and receiver balance changes, the sender and receiver accounts, an existing fraud flag, and an audit cost), and the train / validation / test split tables that label transactions as fraud or not. Model a transaction's sender and receiver as relationships to accounts. +/rai-ontology Build an ontology from the PaySim mobile-money Snowflake schema: accounts (each with an id and an account-type prefix), transactions (each with a type, an amount, sender and receiver balance changes, the sender and receiver accounts, an existing fraud flag, and an audit cost), and the train / validation / test split tables that label transactions as fraud or not. Link each transaction to its sender and receiver accounts. ``` **Response** diff --git a/v1/memory_supply_allocation/runbook.md b/v1/memory_supply_allocation/runbook.md index 6ecfb19a..f2459b4d 100644 --- a/v1/memory_supply_allocation/runbook.md +++ b/v1/memory_supply_allocation/runbook.md @@ -154,7 +154,7 @@ Cast `PathTraversal.length` to int before pandas comparisons (the paths library **Prompt** ``` -/rai-graph-analysis Using the paths library, enumerate every 1- to 3-hop chain through the Customer.depends_on graph. Which customer endpoints have the most paths terminating at them (the most redundant protection), and which customer is structurally a single point of failure — the only customer whose elevated floor depends on exactly one direct incoming dependency edge AND has no alternative-path protection? +/rai-graph-analysis Using the paths library, enumerate every 1- to 3-hop chain through the Customer.depends_on graph. Which customer endpoints have the most paths terminating at them (the most redundant protection), and which customer is structurally a single point of failure — the only customer whose elevated floor depends on exactly one direct incoming dependency edge AND is not itself on any other customer's dependency chain (no one else's protection routes through it)? ``` **Response** @@ -166,7 +166,7 @@ Cast `PathTraversal.length` to int before pandas comparisons (the paths library **Prompt** ``` -/rai-graph-analysis For each supplier, recompute effective capacity with that supplier's capability_pct forced to 0 across all 36 months and count the (product, period) cells whose capacity drops more than 10% vs the baseline forecast. Do the same for each raw-material input by forcing its availability to 0.30 and counting cells whose drop exceeds 5%. Which single supplier and which single input cast the widest cascade footprint? Persist the per-supplier and per-input cell counts back to the ontology so a downstream analyst can query the risk ranking without re-running the cascade. +/rai-graph-analysis For each supplier, recompute effective capacity with that supplier's capability_pct forced to 0 across all 36 months and count the (product, period) cells whose capacity drops more than 10% vs the baseline forecast. Do the same for each raw-material input by forcing its availability to 0.30 and counting cells whose drop exceeds 5%. Which supplier(s) and which input(s) cast the widest cascade footprint (ties allowed)? Persist the per-supplier and per-input cell counts back to the ontology so a downstream analyst can query the risk ranking without re-running the cascade. ``` **Response** diff --git a/v1/money_laundering_motif_detection/runbook.md b/v1/money_laundering_motif_detection/runbook.md index 663785a7..a42fc378 100644 --- a/v1/money_laundering_motif_detection/runbook.md +++ b/v1/money_laundering_motif_detection/runbook.md @@ -37,7 +37,7 @@ Each prompt is pasted into a fresh agent session loaded with the named `/rai-*` ## 3. Detect butterfly (scatter-gather) rings -**Prompt:** /rai-prescriptive-problem Find butterfly scatter-gather rings: one source account that fans funds out to exactly 3 hub accounts sharing the same beneficial owner, which then gather into one destination account — with no direct source-to-destination or hub-to-hub edges, every transfer under $10,000, and each hub's dollars in roughly equal to its dollars out (flow conservation within a small tolerance). Enumerate all such rings. +**Prompt:** /rai-prescriptive-problem Find butterfly scatter-gather rings: one source account that fans funds out to exactly 3 hub accounts sharing the same beneficial owner, which then gather into one destination account — with no direct source-to-destination or hub-to-hub edges, every transfer under $10,000, and each hub's dollars in roughly equal to its dollars out (flow conservation within 5%). Enumerate all such rings. **Response:** OPTIMAL — enumeration exhausted (MiniZinc), **2 rings found**, both planted scatter-gathers: SourceShellCorp → 3 same-owner hubs → WireRecipientCorp, and SecondShellCorp → 3 same-owner hubs → OffshoreLLC (12 motif edges total). The per-hub dollar-conservation constraint is what rejects structurally-similar but non-laundering fan-outs. diff --git a/v1/retail_planning/runbook.md b/v1/retail_planning/runbook.md index c7a93595..85f8775c 100644 --- a/v1/retail_planning/runbook.md +++ b/v1/retail_planning/runbook.md @@ -81,7 +81,7 @@ A sales-regression GNN trains over the transaction graph (beating the predict-th **Prompt** ``` -/rai-prescriptive-problem Using the learned demand, choose a discount tier for each planning article in each week to maximize total revenue plus salvage value of leftover stock, respecting inventory. Persist the chosen discounts. +/rai-prescriptive-problem Using the learned demand, choose a discount tier for each planning article in each week to maximize total revenue plus salvage value of leftover stock, respecting inventory. Only let discounts deepen over the season, never reverse. Persist the chosen discounts. ``` **Response**