Predictive skills: two-skill workflow (modeling + training)

[cafzal]

Why

Enable users to adopt the RAI predictive reasoner (GNN workloads) end-to-end through their coding agent — model → train → predict → integrate into ontology → chain into rules / prescriptive / graph reasoners — and recover when the runtime misbehaves.

Key changes

Two new customer-facing skills (early access):

• rai-predictive-modeling — concepts, Snowflake/CSV loading, task relationships, graph edges, PropertyTransformer features, graph-metric-as-feature. § Prerequisites (experiment-schema DDL + grants, package-version pin, two-engine model Logic-vs-Predictive). § Provisioning the Predictive reasoner recommends GPU_NV_S and shows the canonical CALL RELATIONALAI.API.CREATE_REASONER_ASYNC('predictive', '<name>', 'GPU_NV_S', OBJECT_CONSTRUCT()) shape. Examples: link_prediction / node_classification / regression. References: task relationships, PropertyTransformer types, auto-discovery SQL.
• rai-predictive-training — GNN constructor, fit(), predictions(), register/load; intent routing; downstream-chain patterns (same-model, cross-session, aggregation/bridge concepts, non-additive blending, multi-GNN). § Timing expectations distinguishes stream_logs=True/False semantics. § Known Limitations & Runtime Troubleshooting symptom→fix table, backed by references/known-limitations.md carrying the full 3-step "Training appears stuck" ladder + has_time_column workarounds + gnn.fit() idempotency + polling-without-timeout + opaque-transaction-wrapper guidance. Examples: train_link_prediction / train_node_classification / train_regression / register_and_load. References: hyperparameters, task-types-and-metrics, prediction-attributes, evaluation-debugging.

Both new skills' descriptions include negative-boundary clauses to catch routing failures at description-match time.

Discovery — predictive routing only:

• rai-discovery/references/predictive.md: rewritten around the three product-supported families (node_classification / node_regression / link_prediction); User-Type → GNN Task Type translation table mapping each user-facing type to the granular reasoner task_type (binary/multi/multilabel_classification, regression, link_prediction, repeated_link_prediction), default eval_metric, and has_time_column. Per-period forecasting routes to regression with a time column, not a separate task. Anomaly/clustering only emit as pre_computed. Adds the rai_predictive-mode precheck (GET_REASONER('predictive', ...) → READY before classifying).
• rai-discovery/SKILL.md: predictive rows refreshed in the Quick Reference, Reasoner Classification, Cumulative Discovery, Reference Files, Examples, routing-fields, and Post-Discovery Routing tables; predictive implementation_hint row exposes task_type / eval_metric / has_time_column / temporal_column / link_target_concept. Post-Discovery Routing per-reasoner table from rai-discovery: clarify role as translation/ideation/routing layer + complete per-reasoner skill routing #39 now has its predictive row.
• rai-discovery/examples/predictive_routing.md: three GNN walkthroughs (churn → node classification, per-unit output → node regression, recommendation → link prediction) alongside the pre-computed example.
• rai-graph-analysis/SKILL.md: cross-refs the GNN graph-construction pattern under § When NOT to use.

Reasoner-agnostic discovery improvements shipped in #39 / v2.1.4. Reasoner-agnostic engine-management surface ships in #41.

Existing reasoner-adjacent skills:

• rai-health: two new predictive sections, both framed as diagnostic-ladder → recovery (parallel to Logic / CDC ladders).
  • § Predictive reasoner stuck in data-index init: GET_REASONER (pod status) → relationalai.api.cdc_status (upstream stream health) → GET_OWN_TRANSACTION_PROBLEMS('<txn>') (transaction-specific problems). Cross-links § Step 4 and § Step 5.
  • § Predictive train jobs stuck QUEUED: GET_REASONER → client.jobs.list("Predictive", ...) → SHOW EXPERIMENTS. Recovery: SUSPEND_REASONER + RESUME_REASONER_ASYNC, escalating to DELETE_REASONER + CREATE_REASONER_ASYNC('predictive', ..., 'GPU_NV_S', OBJECT_CONSTRUCT()) for a fresh rebuild. Stays on the supported RELATIONALAI.API.* surface throughout.
• rai-setup: two-line Prerequisites pointer noting predictive needs additional schema setup, deferring to rai-predictive-modeling § Prerequisites for the DDL.

Examples: one canonical per task type, generic concept names (User/Item/Interaction; Source/Target/OptTarget) — no domain creep.

Folded-in PRs (closed, child branches deleted):

• docs(rai-predictive-modeling): add link prediction task table format validation #29 — link prediction validation (VARIANT task-table check + LATERAL FLATTEN recipe)
• predictive skills: gap-fixes from fraud template (Paysim dataset) run #30 — paysim gap-fixes + config-learnings
• Predictive skills adjustment #34 — predictive skills adjustment

Test plan (completed)

• All touched SKILL.md files structurally clean; pitfall tables aligned to 3-col (Mistake / Cause / Fix); no domain creep in examples
• Discovery routes the three GNN use cases to the correct task_type / eval_metric / has_time_column via the translation table; pre-computed and rai_predictive modes both covered; predictive engine precheck named in Data Sufficiency Signals
• Predictive provisioning + recovery stay on the supported RELATIONALAI.API.* surface; GPU recommended via CREATE_REASONER_ASYNC('predictive', ..., 'GPU_NV_S', OBJECT_CONSTRUCT()) (matches issues.md ISS-005 ground-truth verification)
• Cross-skill MECE: rai-health owns SUSPEND/RESUME + the diagnostic ladders; rai-predictive-training SKILL.md links to it; full diagnostic ladder lives once in references/known-limitations.md
• All claims source-grounded against PyRel gnn3 (relationalai 1.1.1 editable + relationalai_gnns 0.1.5): _stream_logs_formatted synchronous behavior at estimator.py:529, _wait_obtain_model_run_id at line 777, client.jobs.list("Predictive", ...) reachable via REASONER_TYPE_LABELS, GPU_NV_S accepted by AWSEngineSize Literal but excluded from REASONER_SIZES_AWS validation list
• /dev-skills-review checklist applied; line counts within budget
• End-to-end agent usability validated on HM_MINI (sales regression) — see comment thread
• Templates PR (RelationalAI/templates#49) end-to-end runs — subscriber_retention (Test-set RMSE 0.1386), demand_forecasting (Per-Sale RMSE 7.28)
• Layout migrated to plugins/rai/skills/<name>/; rebased onto post-rai-discovery: clarify role as translation/ideation/routing layer + complete per-reasoner skill routing #39 main

Related

• rai-discovery: clarify role as translation/ideation/routing layer + complete per-reasoner skill routing #39 — reasoner-agnostic discovery improvements (merged as v2.1.4)
• rai-setup: document the SQL-procedure reasoner surface, align engine sizes with platform docs #41 — reasoner-agnostic engine-management surface (parallel; not blocking)
• Predictive skills #12 — original three-skill version with review comments and test reports
• Sync rai-predictive-training with source skill (gap fixes) #28 — pkouki's gap-fix sync (already on this branch)

[cafzal]

Review: Consolidated Predictive Skill

Reviewed against: (1) issues from hands-on GNN testing in this session, (2) prior PR #12 findings, (3) dev-quality-skills-review checklist.

---

Must Fix

1. SKILL.md is 821 lines — exceeds 500-line checklist limit by 64%.

Recommend splitting into a two-skill workflow (mirroring the prescriptive pattern) plus extracting content to reference/example files:

Skill	Covers	Target
rai-predictive-modeling	Concepts, data loading, task relationships, graph construction, PropertyTransformer	~350 lines
rai-predictive-training	GNN constructor, fit, predictions, evaluation/debugging, register/load	~400 lines

Why two, not three or one:

• The original PR Predictive skills #12 had three skills, but management (195 lines) is thin and register/load shares the same GNN constructor knowledge as training — it's a natural appendix, not a standalone skill.
• One skill at 821 lines is too long to navigate. Two gives clean triggers: "building a data model for GNN" vs "training / predicting / managing a GNN model."
• Mirrors the prescriptive split: formulation (~440 lines) is the "build" phase, solver-management (~410 lines) is the "run + manage" phase.

Additionally, extract to reference files:

• Phase 1 auto-discovery SQL templates → references/auto-discovery.md
• Relationship arity rules (all task type code blocks) → references/task-relationships.md
• Evaluation/debugging details → references/evaluation-debugging.md

Keep inline summaries + load-trigger pointers in each SKILL.md.

2. Discovery routing points to old skill name. rai-discovery/SKILL.md routes predictive → rai-predictive-modeling but the skill is now called rai-predictive. Update to match whatever the final skill name(s) are.

3. Discovery predictive.md reference still treats GNN as "future." (Unchanged from PR #12 — Must Fix #1.) rai-discovery/references/predictive.md:42 says rai_predictive mode is "Future — when the RAI predictive reasoner is platform-integrated." Lines 131, 138 repeat this. The routing example only shows pre_computed mode. This contradicts the existence of the predictive skills.

4. Case mismatch persists in link prediction examples. (Unchanged from PR #12 — Must Fix #2.)

• link_prediction_snowflake.py:20 defines identify_by={"C_customer_id": Integer} (uppercase C)
• Lines 41/47/53 access Customer.c_customer_id (lowercase c)
• Line 61 accesses Customer.C_customer_id (uppercase C)
• train_link_prediction.py:37-38 uses Customer.c_customer_id (lowercase) and Customer.age (lowercase)
• Modeling example uses Customer.AGE (uppercase)

5. Missing ## Quick Reference section. Checklist requires Quick Reference near top with tables/code blocks. A Quick Reference showing the minimal import block + GNN constructor + prediction extraction would help agents navigate without reading the full phased workflow.

---

Should Fix

6. No guidance on experiment schema permissions for RAI native app. (From testing.) The GNN experiment tracking schema needs GRANT USAGE ON DATABASE ... TO APPLICATION RELATIONALAI and GRANT ALL ON SCHEMA ... TO APPLICATION RELATIONALAI. Without this, training fails at Step 3 with a permissions error. Add to training skill or Common Pitfalls.

7. No guidance on extending an existing ontology for GNN. (Unchanged from PR #12 — Must Fix #3.) Phase 1 auto-discovery builds from scratch. Users coming from rai-build-starter-ontology need to know: use the same Model? Redefine concepts with identify_by? What happens to existing Properties?

8. No guidance on creating train/val/test split tables. (Unchanged from PR #12 — Must Fix #4.) The skill assumes splits exist in Snowflake but never explains how to create them or what schema they need (columns, join keys, label format).

9. Domain-specific filtering in train_link_prediction.py. (Unchanged from PR #12.) Lines 44-45 add Customer.age < 50, Customer.age > 20 which obscures the pure link-prediction pattern. Strip it.

10. Unused GNN import in modeling examples. (Unchanged from PR #12.) node_classification_snowflake.py and link_prediction_snowflake.py import GNN but don't use it.

11. has_time_column=True known bug not documented. (From testing.) When the concept carrying time_col (e.g., Transaction) is an edge rather than a node, the time column doesn't propagate to the GNN data tables, causing a validation error. Note in Common Pitfalls until the gnn3 branch fixes it.

12. No cross-skill pattern for graph metrics → GNN features. (Unchanged from PR #12.) Common workflow: compute centrality/community → use as GNN features. Neither graph-analysis nor predictive skill shows this.

---

Nice to Have

13. Training examples aren't self-contained. All training examples assume gnn_graph, pt, Train, Val, Test from a prior modeling session. The docstrings document this well (with "Required variables"), but they can't be copy-paste-executed.

14. exp_database/exp_schema inconsistency across examples. train_node_classification.py uses "DB", train_link_prediction.py uses "MY_DB", register_and_load.py uses "MY_DB". Standardize.

---

Works Well

• property_transformer=pt correctly used everywhere (the critical pt=pt bug from PR Predictive skills #12 is fixed)
• database/schema correctly removed from GNN constructor (deprecated params)
• Register/load workflow includes source_concept=User and task_type (needed for load)
• Session 2 in register_and_load.py shows graph/PT rebuild inline (not commented out)
• has_time_column detection guidance is clear ("if template contains 'at' keyword")
• Link prediction choice guidance: "do not choose for the user" between link_prediction and repeated_link_prediction
• Phased workflow is well-structured with conversation templates for each phase
• Phase 1 auto-discovery includes practical SQL queries for PK/FK/edge detection
• Common Pitfalls table is comprehensive (20+ entries with consequences)
• Reference files are well-scoped and match SKILL.md API style
• gnn.visualize_dataset() documented for debugging
• gnn.fit() trains-at-most-once behavior documented
• select() fragment alternative for task definition documented

[cafzal]

Test Report: Skills-Driven GNN Pipeline on HM_MINI (Initial)

Tested the two-skill workflow (rai-predictive-modeling + rai-predictive-training) by following the skills to build a pipeline on HM_MINI (10K customers, 5K articles, 9.6K transactions). Two task types: sales regression + churn classification.

Results

Step	Status	Time	Notes
Data sync (9 tables)	PASS	~5 min	Dominated by RAI engine init, not data volume
GNN table materialization	PASS	10.88s
Dataset preparation	PASS	16.23s
Trainer configuration	PASS	1.93s
Training job submission	PASS	6.74s	Reused prior completed job
Prediction model prep	BLOCKED	60+ min	Step 2/4 "Preparing model" hangs — platform issue
Predictions output	NOT REACHED		Blocked by prediction prep

Bottom line: The skills produce code that successfully trains a GNN. Prediction extraction is blocked by a platform-side latency issue (prediction model preparation), not a skill or code issue.

Issues found (three-way classification)

Platform / Reasoner (P) — needs GNN team

#	Issue	Severity
P1	has_time_column=True validation fails for edge-only time_col concepts	Blocks temporal features
P2	Training log streaming + prediction model prep: 30-60+ min latency on small data	UX blocker
P3	SSL cert errors in venv during log streaming	Environment-specific
P4	Initial data sync overhead ~5 min regardless of data size	UX
P5	Experiment schema requires explicit GRANT ... TO APPLICATION RELATIONALAI	Blocking if not done

Skill files (S) — fixed in commit d8eea01

#	Issue	Fix applied
S1	Column casing guidance missing — identify_by keys must match exact Snowflake column names	Added note + pitfall to modeling skill
S2	has_time_column edge-only limitation not in pitfalls	Added to training pitfalls with workaround
S3	stream_logs=False not mentioned as option	Added to optional params description
S4	Experiment schema GRANT incomplete	Expanded pitfall with full SQL

Agent harness (A) — lessons learned

#	Issue	Lesson
A1	Used full HM_PYREL dataset instead of HM_MINI	Default to smallest available for testing
A2	Wrong column casing on first attempt	Always DESCRIBE TABLE before writing code
A3	Used pt=pt initially (PR #12 bug)	Fixed in this PR to property_transformer=pt

Skills assessment

The two-skill workflow (rai-predictive-modeling + rai-predictive-training) works well:

• An agent following the skills can produce code that passes all phases through training submission
• The phased structure maps cleanly to the actual API workflow
• Common Pitfalls caught most issues
• The split into modeling vs training feels natural (like prescriptive formulation vs solver-management)

Remaining skill gaps are minor and were patched in d8eea01. The main blockers are platform-side (P1: temporal features, P2: latency).

[ifountalis]

Nice split, matches the prescriptive pattern cleanly. Three things before we land:

1. Branch is behind main (~89 commits). The last merge from main was on 2026-04-07. Since then rai-discovery/SKILL.md and
   rai-graph-analysis/SKILL.md have seen substantive updates on main — the inspect.schema(model) grounding step (now Step 1 of
   discovery), WCC output-type guidance, DataFrame bridge rewording, removal of the separate-graph-model pattern, and more. A
   git diff main..HEAD currently looks like this PR is removing that content. Could you merge/rebase main in and resolve the
   conflicts so those changes aren't clobbered?

2. Malformed pitfall row in skills/rai-predictive-training/SKILL.md:379. The Common Pitfalls table header is 2-column
   (Mistake | Fix) but that row has three pipe-separated cells (Mistake | Cause | Fix). Either collapse Cause into the Fix cell,
   or promote the whole table to 3 columns to match the rai-predictive-modeling pitfalls table.

3. End-to-end agent test. The last checkbox in the test plan (Agent usability: can an agent follow the two-skill workflow
   end-to-end?) is still unchecked. The d8eea01 Fix skill gaps found during HM_MINI testing commit suggests hands-on testing
   happened — was a full end-to-end agent run on the split (modeling → training) workflow done, or is that still pending?

[cafzal]

Agent User Testing Report: Issues

E2E test — HM_MINI sales regression, then closing the loop into a downstream rule.

Followed both skills cold (no prior context) to build a sales-regression GNN on HM_MINI: predict transaction PRICE from Customer ↔ Transaction ↔ Article graph + temporal features. Then persisted predictions, loaded them as a Concept in a fresh model, and applied a rule — validating the predictive → rules chain end to end.

Verdict: both halves of the loop work. fit() + gnn.predictions(domain=Test) + select(...).to_df() produce correct results, and the same-model pattern (used by the retail_planning template) cleanly chains GNN output into rules or prescriptive reasoners. Gaps below are fixed on this PR or flagged for triage.

Environment

• PyRel gnn3 branch (ee7d70bf), venv ~/Documents/sandbox/.venv-gnn
• prod PM account jqb21724, HM_MINI DB, JWT auth, ACCOUNTADMIN role
• HM_MINI.EXPERIMENTS created with APPLICATION RELATIONALAI grants

Data model

• Created TRANSACTIONS_WITH_ID (row_number over dedup table) since source TRANSACTIONS_DEDUP has no PK
• Time-based split: 7,648 train / 1,147 val / 806 test
• task_type="regression", eval_metric="rmse", has_time_column=True
• Lean PropertyTransformer (9 category, 1 continuous, 1 text, 1 datetime/time_col)

Results — quickstart (n_epochs=5) vs longer (n_epochs=20)

Metric	ep5 (val)	ep5 (test)	ep20 (val)	ep20 (test)
RMSE	0.0142	0.0209	0.0015	0.0011
R²	0.07	−0.01	—	+0.997
Pearson r / Spearman ρ	—	0.33 / 0.45	—	0.998 / 0.996
Prediction-band / target-std	—	10%	—	100%
Skill lift vs predict-mean baseline	—	−0.7%	—	+94.5%

ep5: model collapsed to the target mean (predicted band 0.020–0.028 vs true 0.001–0.21). Pipeline-correct but under-trained. Spearman ρ of 0.45 meant signal was there — it was ranking correctly but couldn't express magnitudes.

ep20: model fits near-perfectly. Prediction band spans the full target range. Training wall-time dropped from 400s → 143s because the dataset-prep step (~350s) hits a cache on the second run in the same session; subsequent GNN constructors pay the full cost again.

Caveat on ep20: R² = 0.997 is suspiciously high for a first-pass GNN. Two benign explanations — (a) price is deeply determined by the Article, so the graph handily learns the Article→price mapping; (b) the temporal split doesn't separate "never-before-seen" articles. A leakage sanity-check is now in the skill.

Closing the loop: predictions → downstream reasoners

Validated two paths for consuming GNN predictions after .predictions(...):

Path	What it does	Result
Same-model (retail-planning pattern)	After Transaction.predictions = gnn.predictions(domain=Test), derive Transaction.predicted_value = Property(...) from Transaction.predictions.predicted_value, apply Transaction.is_high_value = Relationship(...) rule, query. All in one Model.	806 predictions bound, 19 flagged high-value, top-10 ranked returned.
Cross-session (explicit persistence)	write_pandas(...) writes the predictions DataFrame to HM_MINI.PUBLIC.SALES_PREDICTIONS, a fresh Model loads it as a Concept, derives properties, applies a rule, queries.	Same 19-flag result; validates that predictions can cross process boundaries.

Finding: the GNN does NOT auto-persist predictions as a durable Snowflake table when only exp_database/exp_schema are set (HM_MINI.EXPERIMENTS stayed empty after the run). The database=/schema= GNN constructor params are documented as "save predictions in" — likely the automatic path — but I haven't validated the resulting table schema/lifetime. For now the skill documents both patterns and notes the automatic-persistence caveat.

Compared to the retail_planning template (817 lines, 3 GNNs + 2 optimizers): our demo is ~90 lines doing 1 GNN + 1 rule. The template uses same-model throughout, adds per-GNN prediction sanity checks (NaN/range/sign), and aggregates predictions across entities (e.g., avg buyer churn per article). All three patterns are now in the skill.

Issues for triage

RelationalAI infra

1. fit() step 1 = 352s for 7,648 rows. Actual 5 training epochs ran in 15s; the other 385s is dataset export + reasoner handoff. Retraining with different hyperparameters (new GNN instance) re-pays the cost; prediction-step cache worked within a session but training-step cache didn't. Session-scoped dataset caching across GNN instances would make GNN tuning usable.
2. Spinner spam in non-TTY logs. Submitting job… spinner prints ~60 lines/s during gnn.predictions(...); 333s of export produced 12K+ ANSI-escape lines, ~99% of total log volume. Detect non-TTY and downgrade.
3. GNN prediction persistence path is unclear. exp_database/exp_schema alone doesn't produce a queryable Snowflake table; database/schema params may but untested. Clarifying the contract would let skills confidently document automatic persistence.
4. Client hangs indefinitely against a suspended GPU compute pool. gnn.fit() and gnn.predictions() poll forever (observed >90 min idle) instead of either auto-resuming the pool or failing fast with a clear message. Workaround documented in the skill: ALTER COMPUTE POOL <pool_name> RESUME before any run. Eng fix: have fit() check pool state and either trigger auto-resume or raise immediately.

Skills — fixed on this PR

4. ✅ identify_by case-sensitivity — rule said case-sensitive, examples used mixed case. Rule is actually case-insensitive. Clarified + pitfall row updated.
5. ✅ No regression example — added examples/regression_snowflake.py and examples/train_regression.py using generic User/Item/Interaction pattern.
6. ✅ Task-table column → Python attribute mapping — folded into the case-insensitivity paragraph.
7. ✅ Regression under-fitting heuristics — evaluation-debugging.md now has loss-trajectory table, multi-metric framework, prediction-band-vs-target-band and ranking-vs-magnitudes checks, suspicious-R²-means-check-for-leakage.
8. ✅ Training output / "What good means" — added business-utility framing (metrics are proxies for the real question).
9. ✅ lr is the first knob to sweep — added principle-level guidance to hyperparameters.md.
10. ✅ Message-passing depth vs graph diameter — added principle; param name to be confirmed with RelationalAI team.
11. ✅ Prediction sanity-check before downstream use — added to evaluation-debugging.md: verify no NaN / out-of-range / sign violations before feeding downstream.
12. ✅ Using Predictions Downstream section — new rai-predictive-training/SKILL.md section documenting same-model and cross-session patterns, with pointer to the retail_planning template as the canonical multi-GNN + multi-optimizer example.
13. ✅ Discovery routing — rai-predictive-modeling now appears in rai-discovery/SKILL.md Formulation skill list, and rai-discovery/references/predictive.md describes both pre_computed and rai_predictive (GNN) modes, cross-referencing the two new skills.
14. ✅ Aggregation-over-predictions + bridge-concept pattern — new "Aggregation and bridge concepts" subsection in rai-predictive-training/SKILL.md showing aggregates.<agg>(...).per(Target).where(join) rollup onto a bridge concept when the downstream reasoner's scope differs from the GNN source. Generic Source/OptTarget/Interaction naming.
15. ✅ has_time_column=True second failure mode — server-side ValidationError: Error processing datetime column '<name>' at scale, even with the time-bearing concept as a node and clean data. Added as a second numbered entry under § Known Limitations in rai-predictive-training/SKILL.md with matching Common Pitfalls row; same workaround (turn temporal off) as the existing edge-intermediary trigger. Also added a paragraph in rai-predictive-modeling/SKILL.md § Populate from Snowflake noting timestamp column type matters: TIMESTAMP_NTZ observed silently incompatible (loads but trainer doesn't pick up as temporal), VARCHAR ISO-8601 safer default but still subject to the at-scale issue. Both phrased as observed behavior, not guarantees.

Skills — partially fixed

16. ⚠️ GPU setup guidance (paired requirements). Predictive-skill side is in: rai-predictive-training/SKILL.md now notes under Common Hyperparameters that device="cuda" is a paired requirement — the predictive reasoner engine must also be GPU-sized, with a CPU-HIGHMEM vs GPU heuristic (RAM-for-speed tradeoff, "fits in GPU VM's CPU memory → GPU, else HIGHMEM CPU"), and forward-compatible cross-ref to "the RAI configuration/setup skill." The config-side content (engine-size raiconfig.yaml snippet + cloud-specific tier naming guidance) is deferred until PR Consolidate configuration, onboarding skills #23 merges — that PR deletes rai-configuration/SKILL.md in favor of rai-setup/, so the engine-size material lands in skills/rai-setup/references/reasoners.md as a follow-up.

17. ✅ GRANT pitfall was correct. Exactly matched what I needed — kept me from a 10-minute debug session. Keep it.

Full details

Artifacts in dev_temp/gnn_e2e/:

• sales_regression.py — training + predict script (n_epochs=20)
• save_predictions.py — persist DataFrame to Snowflake via write_pandas
• consume_predictions.py — cross-session downstream consumption test (new model, rule, query)
• end_to_end_demo.py — same-model end-to-end (train → predict → derive → rule → query)
• RETAIL_COMPARISON.md — side-by-side vs retail_planning template
• DOWNSTREAM_TEST.md — downstream-flow findings
• RUN_LOG.md / ISSUES.md — session-wide logs
• predictions_ep5.csv / predictions.csv (ep20) — side-by-side

Overall: the two-skill split is a clean mental model, the reorganized reference files kept the main SKILL.md files scannable, and the pipeline produces useful predictions when n_epochs is reasonable. The loop closes via the same-model pattern (as the retail_planning template demonstrates). Main ergonomic friction remains long dataset-export time on each retrain — infra item 1.

[ifountalis]

Second-pass review. Prior items are resolved — rebase is clean, training pitfall table is uniformly 2-column, E2E agent run happened. A few things still to address before landing.

Please fix

1. Internal contradiction about database / schema in rai-predictive-training/SKILL.md.

• The Include/Omit table (line ~384) lists database, schema under Omit ("now optional").
• But the "Load by Registry Key" example (line ~360) and the "Session 1: Train and Register" example (line ~402) both start with database="DB", schema="MY_SCHEMA",.
• A third paragraph at line ~326 hedges that these "are documented as 'save predictions in' … may be persisted".

Three surfaces, three stories. Pick one: either they're deprecated/omit (scrub both example blocks — the files under examples/ already do this), or they're the automatic-persistence path (then explain the contract and update the Include/Omit table). Agents will follow whichever surface they read first.

2. Pitfall-table shape now diverges between the two skills.

rai-predictive-modeling/SKILL.md uses 3-column Mistake | Cause | Fix; rai-predictive-training/SKILL.md uses 2-column Mistake | Fix. My earlier comment asked for alignment — that got fixed inside the training skill, but the two skills now disagree with each other. Align on one shape.

4. Training example files are not runnable and give no import hint.

train_node_classification.py, train_link_prediction.py, train_regression.py, register_and_load.py all use GNN (and select, plus Item in the link example) with no imports. Docstrings say "Assumes data model from rai-predictive-modeling", but an agent that runs the file cold gets NameError: GNN. One-line from relationalai.semantics.reasoners.predictive import GNN at the top plus a note that select/model come from the modeling session would fix this cheaply. (Flagged as Nice-to-Have #13 in the earlier review — still unfixed.)

Please check

3. Task-table column naming looks inconsistent across modeling examples — is this intentional?

• node_classification_snowflake.py: train_table_concept.user (no _id suffix)
• link_prediction_snowflake.py: train_table_concept.user_id, train_table_concept.item_id
• regression_snowflake.py: train_table_concept.interaction_id

The .user case is the odd one out and reads like it contradicts the modeling skill's "join key column matching a source concept PK." If the split-table schema legitimately varies by task type, a one-liner saying so would help; otherwise rename to user_id for consistency.

Nice to have

5. The database=/schema= paragraph at line ~326 is worth a second look. Your HM_MINI test report found these params don't produce a queryable table when only exp_database/exp_schema are set. The current hedged wording ("may be persisted", "confirm with the team") invites agents to invent behavior. Either commit to the finding ("does not auto-persist — use write_pandas") or drop the paragraph and ship the explicit persistence pattern only.

Otherwise the split is in good shape — downstream/aggregation section, GRANT pitfall, leakage check, has_time_column edge-only note, lr-as-first-knob, both SKILL.md under the 500-line cap, discovery routing correct. Close to landable.

[cafzal]

All 4 review items addressed on tip ebc21e7:

Item	Status	Evidence
1. database/schema contradiction in rai-predictive-training/SKILL.md	✅	Removed from all 3 example blocks (Load by Registry Key, Session 1 Train-and-Register, Session 2 Load-and-Predict). Hedge paragraph replaced with one-liner: "database= and schema= on GNN(...) are optional and omitted throughout this skill. For durable persistence, use the explicit write_pandas path above." Aligns with the (now optional) entry in the Include/Omit table — all three surfaces now tell the same story.
2. Pitfall-table shape divergence	✅	Training promoted from 2-col to 3-col (Mistake | Cause | Fix) to match modeling. 13 rows now each explain WHY (matches the checklist's "every major rule explains WHY" rule as a bonus).
3. Task-table column naming inconsistency	✅	Renamed train_table_concept.user / .user / .user → .user_id in node_classification_snowflake.py (3 join conditions) and the matching section in references/task-relationships.md. All three modeling examples + the reference file now use <concept>_id consistently: user_id (node classification), user_id/item_id (link prediction), interaction_id (regression). The convention matches the modeling skill's "join key column matching a source concept PK" guidance.
4. Training example files not runnable / no import hint	✅	Added from relationalai.semantics import select and from relationalai.semantics.reasoners.predictive import GNN to all 4 training examples (train_node_classification.py, train_link_prediction.py, train_regression.py, register_and_load.py). select only on the three that use it; register_and_load.py just imports GNN. Docstrings still note that model, gnn_graph, pt, Train/Val/Test, and source/target concepts come from the modeling session. Agents running the examples cold no longer hit NameError: GNN.

Also folded in from this round:

• device="cuda" pairing note extended to apply to all reasoner engine types — engine sizing is per-reasoner in raiconfig.yaml (logic / predictive / prescriptive), and the auto-suspend heuristic for dev/test iteration applies to any of them, not just GPU pools.
• Dropped a specific VM-tier name (GPU_NV_S) that had crept into the pairing paragraph; replaced with principle-level phrasing. No un-validated tier names or ratios remain.

PR tip ebc21e7, MERGEABLE / CLEAN.