Rai Discovery

Question Discovery

Summary

What: Multi-reasoner question discovery from ontology models. Acts as the translation, ideation, and routing layer between the ontology and the reasoners — surfaces what the data can answer, classifies by reasoner family, and translates user-facing problem framings into the technical implementation hints the downstream coding skills consume.

When to use:

• Suggesting questions a given ontology can answer
• Analyzing a user's question to determine reasoner type and feasibility
• Classifying whether a question needs prescriptive, graph, predictive, or rules reasoning
• Identifying multi-reasoner chains (e.g., predict demand then optimize allocation)
• Assessing data feasibility before committing to a workflow

When NOT to use:

• Formulating optimization variables, constraints, objectives — see rai-prescriptive-problem-formulation
• PyRel syntax and coding patterns — see rai-pyrel-coding
• Ontology modeling or enrichment — see rai-ontology-design
• Solver execution and diagnostics — see rai-prescriptive-solver-management
• Post-solve interpretation — see rai-prescriptive-results-interpretation

Overview:

1. Ground in the real model via inspect.schema(model) — concepts, properties with real types, relationships, data sources
2. Analyze the ontology to identify what the data can support
3. Classify each opportunity by reasoner type (prescriptive, graph, predictive, rules)
4. Identify multi-reasoner chains where applicable
5. Assess feasibility (READY / MODELGAP / DATAGAP)
6. Present ranked suggestions to the user
7. Route the selected question to the appropriate reasoner workflow

---

Quick Reference

| Signal in Ontology | Reasoner | Question Pattern | |--------------------|----------|-----------------| | Constrained resources, costs, capacities | Prescriptive | "What should we do?" — allocate, schedule, route. Within prescriptive, formulation splits along a style axis: MIP-style (Problem(model, Float) + HiGHS/Gurobi — continuous-friendly) vs CSP-style (Problem(model, Integer) + MiniZinc — all-integer with globals, multi-solution enumeration, audit/witness). See prescriptive.md § Formulation Style Detection. | | Network topology, graph structure | Graph | "What patterns exist?" — centrality, clusters, paths | | Labels/values per entity, historical pair data, graph topology | Predictive | "What will happen?" / "Which Y for each X?" — node classification, node regression, link prediction | | Threshold/status fields, business rules | Rules | "Is this valid?" — compliance, classification |

| Feasibility | Meaning | Next Step | |-------------|---------|-----------| | READY | All data in model | Proceed to reasoner workflow | | MODELGAP | Data in schema, not mapped | Enrich ontology first | | DATAGAP | Data doesn't exist | Blocks the question |

---

Discovery Workflow

Question discovery is the analyst's springboard into data-driven reasoning. The ontology reveals what questions the data can answer -- the analyst learns what's possible before choosing what to pursue.

Steps

1. Ground in the real model first. Before enumerating opportunities from memory or source files, run inspect.schema(model) to see what's actually registered — concepts, properties (including inherited), types (enriched from the backing TableSchema where available), relationships, and both model.tables and inline model.data_items sources. Discovery suggestions are only useful if they're grounded in what the data can actually support; guessing from partial reads produces confident-but-wrong recommendations. See rai-querying/references/inspect-module.md.

```python from relationalai.semantics import inspect

schema = inspect.schema(model) # Now enumerate signals from real state: concepts with network topology, # temporal properties, constrained-resource concepts, boolean flags, etc. ```

When to skip: if the user is asking "what can I do with this new dataset" and the model is still greenfield (no concepts yet), start at Step 2 and return to inspect later.

1. Analyze the ontology — what concepts, relationships, and data exist? Look for network topology (graph), temporal patterns (predictive), constrained decisions (prescriptive), threshold/status fields (rules).
2. Classify by reasoner — for each opportunity, determine which reasoner(s) apply (→ Reasoner Classification). Tag with reasoners field.
3. Identify chains — where one reasoner's output enables another (→ Multi-Reasoner Chaining, Cumulative Discovery).
4. Assess feasibility — READY / MODELGAP / DATAGAP for each suggestion (→ Feasibility Framework).
5. Generate ranked suggestions — with implementation hints per reasoner type (→ reference files: prescriptive.md, graph.md, predictive.md, rules.md).
6. User selects — route to the appropriate reasoner workflow (→ Post-Discovery Routing). If MODEL_GAP, enrich first (→ Enrichment Handoff).

Your role

• Analyze the ontology to surface opportunities grounded in actual data
• Write the statement field as a business question the analyst can evaluate -- not a technical formulation
• GOOD: "Allocate capacity across sites to meet demand while staying within budget"
• GOOD: "Schedule technicians to maintenance tasks to minimize downtime and balance workload"
• BAD: "Minimize sum(ACTIVITY.COSTPERUNIT * ACTIVITY.X_FLOW) subject to SITE.CAPACITY"
• BAD: "Optimize Allocation.quantity across Activity edges"
• Maintain full technical specificity in implementation_hint fields -- these drive downstream workflow and must reference actual concept/property names
• For each suggestion, distinguish what's ready to pursue, what needs model enrichment (auto-fixable), and what needs new data (blocks the question)
• Suggest questions across reasoner types when the data supports it -- don't default to only one type

Presenting the discovery landscape

Present suggestions as a landscape of what the data can answer -- across reasoner types -- not as a menu of one kind of question.

Frame suggestions by the type of question they answer:

• "Here's what we can tell you about structure and connectivity" (graph)
• "Here's what we can predict" (predictive)
• "Here's what we can optimize" (prescriptive)
• "Here's what we can validate/enforce" (rules)

Connect each suggestion to the decision or insight it enables, not just the analysis it performs:

• NOT: "Run centrality analysis on the network"
• YES: "Identify which hubs are critical connectors -- so you know where disruptions would cascade and where to invest in redundancy"

---

Reasoner Classification

Each suggestion must be tagged with one or more reasoner types. Use these signals to classify:

| Signal | Primary Reasoner | Question Pattern | |--------|-----------------|------------------| | Optimizing decisions over constrained resources | Prescriptive | "What should we do?" — allocate, schedule, route, price. Cross-cutting style choice within prescriptive: MIP-style (continuous-friendly) vs CSP-style (all-integer + globals). See prescriptive.md § Formulation Style Detection. | | Understanding structure, connectivity, influence | Graph | "What patterns exist?" — who is central, what clusters exist, shortest path | | Predicting node labels/values or future links from features and graph topology | Predictive | "What will happen?" / "Which Y for each X?" — node classification, node regression, link prediction | | Enforcing business rules and logical constraints | Rules | "Is this valid?" — compliance, classification, derivation |

Disambiguation rules:

• "What should we do?" → prescriptive (optimization)
• "What patterns/structure exist?" → graph
• "What will happen / what category?" → predictive
• "Is this correct / does this comply?" → rules
• If a question spans two categories, consider a multi-reasoner chain
• Competing objectives? If the problem has two measurable goals in tension (improving one worsens the other) — flag competing_objectives in the prescriptive hint. See prescriptive.md § Multi-Objective Detection for the checklist.
• Parameter variations? If a key constraint parameter could plausibly vary and the user would benefit from comparing solutions across levels — flag scenario_parameter in the prescriptive hint. See prescriptive.md § Scenario Detection for the checklist.
• Pure feasibility, find-K, counterexample, audit, or "enumerate all valid X"? Signal phrases include "find K of these," "is this property always true," "enumerate all configurations satisfying," "audit / counterexample," "configurator," "all-integer decisions and data," "constraint satisfaction," "satisfaction mode," "pure satisfaction." Flag csp_style_witness_enumeration in the prescriptive hint — a style choice within an existing problem type, not a new problem type. See prescriptive.md § Formulation Style Detection for the checklist.

For detailed question types, classification signals, and structural checklists per reasoner, see the reasoner-specific reference files: prescriptive.md, graph.md, predictive.md, rules.md.

---

Multi-Reasoner Chaining

Some questions require multiple reasoners in sequence. Each stage's output enriches the ontology, enabling the next stage.

Chaining principles

1. Each stage enriches the same ontology. Outputs (predictions, scores, flags, allocations) become queryable properties. The ontology grows through use — it accumulates knowledge from each reasoner.
2. Each stage must be independently valuable. If a downstream stage fails or isn't needed, the upstream results still stand on their own.
3. The user's question drives stage selection. Chains aren't fixed pipelines — the agent identifies which stages are needed based on what the user asks and what the ontology can support.
4. Stages follow a natural progression: understand structure (graph) and validate data (rules) → predict what will happen (predictive) → decide what to do (prescriptive). Not every chain uses all stages.
5. Later stages reference earlier outputs as data. Predicted values become constraint parameters. Centrality scores become allocation weights. Rule flags become filters. The handoff is always through the ontology.

Common chain patterns

| Chain | Pattern | What flows between stages | |-------|---------|---------------------------| | Predictive → Prescriptive | Predict parameters, then optimize | Forecasted values become constraint/objective data | | Graph → Prescriptive | Discover structure, then optimize over it | Centrality scores, cluster labels become weights/filters | | Rules → Prescriptive | Validate/classify, then optimize given compliance | Flags and classifications constrain the feasible set | | Rules → Graph | Flag entities, then analyze their structural role | Flagged nodes become the focus of graph analysis | | Graph → Predictive | Extract structural features, then predict | Centrality, component membership become prediction features | | Paths → Prescriptive (PREVIEW) | Enumerate candidate routes, then select | Each enumerated path becomes a candidate decision variable; constraints enforce demand across selected paths | | Paths → Rules (PREVIEW) | Enumerate routes, then classify | Per-path rules flag "any path through a watch-list node," "any path over a length/weight budget" | | Rules → Paths (PREVIEW) | Pre-filter the candidate set | Rules mark concepts Critical / Non-Critical; path enumeration uses the derived subconcepts as endpoint filters | | Predictive → Rules | Predict outcomes, then enforce thresholds | Predicted scores are evaluated against business rules |

Suggesting chained questions

• State the full chain in the statement field: "Forecast appointment volume per clinic (predictive), then assign staff to shifts to meet expected demand (prescriptive)"
• Tag with reasoners: ["predictive", "prescriptive"] (ordered by execution sequence)
• Implementation hint includes per-stage detail: what each stage needs and what it produces for the next stage

Inter-stage handoff

• Stage N output becomes Stage N+1 input context — always through ontology properties
• If Stage N produces derived data (predictions, graph metrics, rule flags), Stage N+1 may need model enrichment to incorporate it
• Each stage should be independently valuable — if Stage 2 fails, Stage 1 results are still useful

Implementation pattern

Each stage enriches the shared ontology with new properties. Downstream stages consume those properties as if they were base data.

• Enrichment write-back: A stage's output becomes a new Property or Relationship on an existing concept via model.define(). Downstream stages reference it like any other property.
• DataFrame bridge: When a stage produces results as a pandas DataFrame (e.g., from an external API), load into the model via model.data() and bind with model.define().
• Fallback operator (|): Allows downstream stages to degrade gracefully when an upstream enrichment is missing for some entities — e.g., Entity.predicted_value | Entity.current_value.

---

Cumulative Discovery

Each reasoner adds new concepts and properties to the ontology. Discovery should surface not just what's answerable now, but what becomes answerable after earlier stages run.

Reasoner output enables new questions

| Stage 1 Output | What It Adds to Ontology | Stage 2 Questions Unlocked | |----------------|--------------------------|---------------------------| | Graph centrality | node.centrality_score | Predictive: centrality as feature. Prescriptive: weight allocation by node importance. | | Graph reachability | impact_count, affected flags | Prescriptive: minimize disruption to high-impact nodes. Rules: alert on critical dependencies. | | Graph paths (enumeration, PREVIEW) | PathTraversal with length, nodes(index), relationship_fields(index, field_index); a route can be bound onto a concept | Prescriptive: route selection over enumerated candidate paths. Rules: flag a route whose length or summed weight exceeds a budget (a per-path predicate). | | Graph WCC / community | WCC: (node, component_id_node) membership (access .id to get its identifying value; cast to int only for integer-identified nodes); community: node.community_label (int) | Prescriptive: optimize within-cluster vs cross-cluster. Rules: flag isolated components. | | Predictive node classification | Entity.predictions with .probs, .predicted_labels | Rules: flag above threshold. Prescriptive: incorporate risk/class as constraint. | | Predictive node regression | Entity.predictions.predicted_value (incl. per-period forecasts) | Prescriptive: optimize against predicted values, often via aggregation/bridge concept. | | Predictive link prediction | User.predictions with .rank, .scores, .predicted_ | Prescriptive: top-K predicted pairs as candidate edges in assignment/matching. Rules: flag pairs above score threshold. |

How to suggest cumulative questions

When generating suggestions:

1. First, identify questions answerable with the current ontology (standard discovery)
2. Then, for graph/predictive suggestions, ask: "What additional questions does this output enable?"
3. Present second-order questions with a clear dependency: "After running [Stage 1], this becomes answerable"

Second-order questions are expansion opportunities, not alternatives. The analyst sees: "Here's what you can do now. Here's what opens up if you also run graph analysis."

The cumulative narrative

The ontology grows through use:

• Start: what exists (base model from data)
• After graph: + what's connected, what's central, what's clustered
• After predictive: + what will happen, what's at risk
• After prescriptive: + what should we do, what's optimal
• After rules: + what's

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: RelationalAI
• Source: RelationalAI/rai-agent-skills
• License: Apache-2.0
• Homepage: https://relational.ai

Install and usage instructions live in the source repository linked above.