Rai Predictive Task Generation

RAI Predictive Task Table Generator

Summary

What: Produces a prediction task table for a predictive-modeling framework (e.g. GNN) — a Snowflake SQL script that materializes a single labelled table conforming to the schema contract for one of six task types: binary, multiclass, and multilabel classification, regression, link prediction, and repeated link prediction.

When to use: whenever the user wants to create, scaffold, or modify a task table for any of the six task types — "build a task table", "set up a prediction task", "churn prediction task", "link prediction labels" — or has source tables and a prediction goal but doesn't yet know which task type fits.

When NOT to use:

• Building the model's graph/data model from the task table once it exists in Snowflake — that's rai-predictive-modeling.
• Training the model, generating predictions, or evaluating results — that's rai-predictive-training.
• Constructing features — the framework builds those downstream from the task table; this skill only produces the labelled rows and join key.

Overview: this skill has two sub-skills sharing everything below plus the reference files in references/:

This top-level SKILL.md asks which mode to use, then hands off to the matching sub-skill for the rest of the session.

Choose a workflow mode

Before anything else — whether the invocation is bare or already includes a data/task description — send this as its own standalone message. Nothing else goes in this message: no greeting, no data request, no SQL.

Predictive Task Table Builder

Before we start, how would you like to work through this?

1. Guided — you'll walk through each decision step by step, making the calls on table roles, task type, and configuration, adjusting anything you want before I generate any SQL.
2. One-shot — I'll infer as much as I can myself from your data and description, and show you one consolidated summary at the end instead of confirming each step. Requires a live Snowflake connection (via raiconfig.yaml).

If the opening message already states an explicit mode preference — words like "one-shot", "quickly", "just build it", "low-touch", "don't ask me a bunch of questions" (→ One-shot), or "guided", "step by step", "walk me through it", "ask me along the way" (→ Guided) — skip this message entirely, state the inferred mode back in one sentence, and proceed directly to routing below.

Otherwise, send the message above and wait for the reply before doing anything else — including handing off to either sub-skill.

Once the mode is settled, hand off to the matching sub-skill for the rest of the session, carrying forward whatever data/task description has already been given:

• Guided: hand off to references/GUIDED.md — follow its "On bare invocation" section (show its greeting if no data/task description has been given yet, otherwise skip straight to its Step 1 using the description already given).
• One-shot: hand off to references/ONE_SHOT.md — follow its Step 0 onward, showing its own bare-invocation greeting only if no data/task description has been given yet.
• Mind changed mid-flow: if the user asks to switch modes partway through, switch to the other sub-skill's workflow at the nearest equivalent step rather than restarting from scratch — carry over whatever table roles, schema, task type, or configuration have already been established.

Quick reference: the six task types at a glance

Use this only as a memory aid. The task_*.md reference files in references/ are the source of truth.

• Binary — one row per entity per cutoff, label is 0/1
• Multiclass — one row per entity per cutoff, label is the raw class value (no re-encoding)
• Multilabel — multiple rows per entity per cutoff (one per active label), or a single row with an array column
• Regression — one row per entity per cutoff, target is a real number
• Link prediction — one row per (src, cutoff), target is a LIST of dst PKs interacted with in the window (first-time or repeat); framework samples negatives internally
• Repeated link prediction — same list format as link prediction, but dst candidate pool restricted to pairs with prior history as of cutoff

Downstream column naming contract

The downstream rai-predictive-modeling step binds the task table to a source concept via a Relationship template. The column names in the task table must match what that template expects — no renaming is possible after the fact. Both sub-skills follow these conventions:

The entity join key column (e.g., customer_id) must exactly match the source concept's primary key column name — this is the .where(Source.pk == TaskTable.fk) join in the modeling step.

If the source data uses a different name for the label (e.g., churned, revenue), alias it to label / value in the INSERT SELECT — do not pass the raw name through.

What comes next: predictive modeling and training

The task table is the entry point to a two-step downstream pipeline. Once the table exists in Snowflake, use these two skills in order. Both also rely on a working Snowflake connection — see rai-setup if one isn't configured yet.

Step A — rai-predictive-modeling: build the data model

The task table is wrapped as a taskless concept (no primary key) and connected to the source entity concept via a Relationship. This step also defines graph edges between source concepts and configures the PropertyTransformer (feature column types).

# Wrap each split table as a separate taskless concept
TrainTable = Concept("TrainTable")
ValTable   = Concept("ValTable")
TestTable  = Concept("TestTable")

define(TrainTable.new(Table("DB.CHURN_TASK.TRAIN").to_schema()))
define(ValTable.new(  Table("DB.CHURN_TASK.VAL").to_schema()))
define(TestTable.new( Table("DB.CHURN_TASK.TEST").to_schema()))

# Bind each to the source concept on the shared join key
Train      = Relationship(f"{Customer} has {Any:label}")
Validation = Relationship(f"{Customer} has {Any:label}")

define(Train(Customer,      TrainTable.label)).where(Customer.customer_id == TrainTable.customer_id)
define(Validation(Customer, ValTable.label)).where(  Customer.customer_id == ValTable.customer_id)

Use the rai-predictive-modeling skill when you reach this step.

Step B — rai-predictive-training: train the GNN and generate predictions

The GNN is instantiated with the graph, property transformer, train/val relationships, task type, and eval metric, then fitted:

gnn = GNN(
    exp_database="MY_DB",
    exp_schema="MY_SCHEMA",
    graph=gnn_graph,
    property_transformer=pt,
    train=Train,
    validation=Validation,
    task_type="binary_classification",
    eval_metric="roc_auc",
)
gnn.fit()
Customer.predictions = gnn.predictions(domain=TestTable)

Use the rai-predictive-training skill when you reach this step.

Task type → downstream configuration at a glance

Multi-dataset experimentation

When the best label definition or window size is uncertain, generate multiple training datasets and compare model performance — without changing the val or test sets.

The rule: fix test and val, vary train only

Schema naming convention

Give each experiment its own schema, named to reflect what varies. The TEST (and optionally VAL) table can live in a shared schema referenced by all experiments.

DATABASE/
├── CHURN_SHARED/
│   ├── VAL           ← fixed val, shared across all experiments
│   └── TEST          ← fixed test, shared across all experiments
├── CHURN_45D/
│   ├── STAGING       ← full dataset for this variant (used for validation queries)
│   └── TRAIN         ← 45-day prediction window
├── CHURN_90D/
│   ├── STAGING
│   └── TRAIN         ← 90-day prediction window
└── CHURN_90D_STRICT/
    ├── STAGING
    └── TRAIN         ← 90-day window + tighter activity filter

How to generate this in SQL

Generate the shared val/test tables once, then generate a STAGING + TRAIN for each variant. In each variant's STAGING, include the val and test rows too (for the leakage check), but only materialise the TRAIN table — the shared val and test are already in CHURN_SHARED.

-- Shared schema: generated once
CREATE SCHEMA IF NOT EXISTS DB.CHURN_SHARED;
CREATE OR REPLACE TABLE DB.CHURN_SHARED.VAL  AS SELECT ... FROM DB.CHURN_45D.STAGING WHERE split = 'val';
CREATE OR REPLACE TABLE DB.CHURN_SHARED.TEST AS SELECT ... FROM DB.CHURN_45D.STAGING WHERE split = 'test';

-- Per-experiment: only TRAIN varies
CREATE SCHEMA IF NOT EXISTS DB.CHURN_90D;
-- ... STAGING INSERT with 90-day window ...
CREATE OR REPLACE TABLE DB.CHURN_90D.TRAIN AS SELECT ... FROM DB.CHURN_90D.STAGING WHERE split = 'train';
-- VAL and TEST: point to CHURN_SHARED, not regenerated

When to use this

Never proactively suggest or ask about multi-dataset experimentation, at any point in either sub-skill. Apply this pattern only when the user explicitly asks to compare multiple training dataset variants (e.g. different prediction windows or activity filters) — then follow the rule above (fix test/val, vary train only).

Common Pitfalls

Examples

No standalone examples/ directory — worked examples live inline, one per task type, in the guided sub-skill:

Each matching task_<type>.md file also carries one full worked SQL template (schema contract, downstream binding, leakage rules) for its task type — load it only after the task type is confirmed (Step 2 of GUIDED.md).

Reference files