`fs-tdstone2`¶

Register a trained tdstone2 model's per-partition predictions or computed features as governed tdfs4ds features — via the one-call bridge tdfs4ds.upload_tdstone2_scores(model).

Source file

Lives at tdfs4ds/skills/fs-tdstone2/SKILL.md.

name: "Feature Store: tdstone2 Model Outputs" description: "Generate Python code to register a trained tdstone2 model's per-partition predictions or computed features as GOVERNED tdfs4ds features — gaining lineage, freshness, time-travel and reuse. Invoke when the user has a trained tdstone2 HyperModel / DeepLearningModel / FeatureEngineering and wants its outputs to live in the feature store. Covers the one-call bridge tdfs4ds.upload_tdstone2_scores(model), how the entity is derived from the model's mapper, and when to prefer a denormalized recomputable process view instead. SKIP for registering an ordinary SQL/DataFrame source — use fs-upload." argument-hint: "[trained tdstone2 model object][data-domain]" allowed-tools: "Read, Edit, Write, Bash, Glob, Grep"

Generate Python code to persist a trained tdstone2 model's per-partition outputs as governed tdfs4ds features.

This is a tdfs4ds skill that consumes tdstone2 output — it belongs to the feature store, not to tdstone2. A tdstone2 model produces per-partition predictions (get_model_predictions()) or computed features (get_computed_features()) that otherwise live only in the tdstone2 scores repository. Registering them in tdfs4ds gives them lineage, freshness tracking, temporal time-travel, and discoverability through the consumer agent.

Before / After	Skill	Why
Before	`fs-setup`	Open the feature store; set `SCHEMA` + `DATA_DOMAIN`.
Before	(tdstone2 skills)	Train the model that produces the scores — `tdstone2-hypermodel` / `tdstone2-deeplearning` / `tdstone2-feature-engineering`.
Sibling	`fs-upload`	Register features from an ordinary SQL/DataFrame source (the non-tdstone2 path).
Architecture	`td-analytics-workflow`	Why `tdfs4ds` + `tdstone2` is the canonical pairing (no data movement).
Read side	`ca-algorithm`	Business-user Q&A about the ML model behind a registered feature (walks the chain backwards).

Prerequisites¶

Feature store initialised (tdfs4ds.setup(...) / connect(...)), with tdfs4ds.SCHEMA and tdfs4ds.DATA_DOMAIN set — see fs-setup.
A trained AND scored tdstone2 model in the same session, exposing get_model_predictions() (HyperModel / DeepLearningModel) or get_computed_features() (FeatureEngineering).
The Script table operator available on the system: tdstone2 runs on it. Error 9854 means it is not licensed there (seen on AI Studio); use the BYOM / ONNX scoring process described in fs-upload instead.

The one-call bridge¶

import tdfs4ds
from tdfs4ds import upload_tdstone2_scores

# The model was trained and scored in THIS session: keep its teradataml context
# (no reconnect_teradata here, it would open a new one) and attach the store to it.
tdfs4ds.connect(database='<DATABASE>')
tdfs4ds.select_data_domain('<DATA_DOMAIN>')   # isolates these features by project

# `model` is a trained + scored tdstone2 HyperModel / DeepLearningModel / FeatureEngineering
dataset = upload_tdstone2_scores(model)

What upload_tdstone2_scores(model) does in one pass (tdfs4ds/execution.py in the package):

Derives the entity from the model's mapper — tdstone2_entity_id(model) reads model.mapper_scoring (or model.mapper) id_row + id_partition and their SQL types. The feature-store entity keys are exactly the model's partition/row keys, so the features line up with how the model was segmented (one model per partition ⇒ features keyed by that partition).
Registers the entity + features in the feature catalog (register_entity, register_features).
Ingests the values — prepare_feature_ingestion_tdstone2(...) unpivots the melted FEATURE_NAME / FEATURE_VALUE scores into the feature-store storage tables (store_feature), then drops the volatile staging table.
Tags each FEATURE_NAME with the model's ID_PROCESS (the tdstone2 run id) as its feature version — preserving lineage back to the exact model run.
Builds and returns a dataset view over the registered features.

Auto-detection: if the model has a score method (HyperModel / DeepLearningModel) it reads get_model_predictions(); otherwise (FeatureEngineering) get_computed_features(). Both are the melted FEATURE_NAME / FEATURE_VALUE / ID_PROCESS shape, so the same path handles all three model types.

Snapshot vs recomputable — choose the right path¶

upload_tdstone2_scores ingests a snapshot of the current scores. When you want the feature to be run()-recomputable on a schedule, register a denormalized process view over the tdstone2 score output instead (via fs-upload's upload_features(df='SCHEMA.v_scores', ...)), because a run() re-reads the view each ingestion.

Goal	Path
One-off snapshot of the model's current scores	`upload_tdstone2_scores(model)`
Governed, scheduled, re-runnable feature over evolving scores	denormalized view over the score table + `upload_features` (`fs-upload`) — re-runs via `tdfs4ds.run(process_id)` / `roll_out(...)`

Both give lineage/freshness/time-travel; only the view path recomputes on run().

The ML-model lineage you get for free¶

Because each feature carries the model's ID_PROCESS as its version, the store can later walk the full chain — exactly what ca-algorithm reads backwards:

feature → process view → SHOW VIEW DDL → TDS_STO_SCORING_<uuid>
        → TDS_MAPPER_REPOSITORY → trained model → code + ARGUMENTS (hyper-params, column_names_X)

So "which algorithm / hyper-parameters / code produced this feature?" is answerable with no extra documentation step.

Rules¶

Set DATA_DOMAIN before registering — it namespaces the features by project. Two models registered under the same domain with colliding FEATURE_NAMEs conflate; scope by domain (or alias the model's output columns / target).
A feature's identity is (FEATURE_NAME, ENTITY_NAME). The entity comes from the model's partition/row keys — a same-named score under a different partitioning is a different feature. Keep partition keys stable across re-registration.
Train AND score before registering — get_model_predictions() reads the scores repository, empty until score() has run.
Safe to re-run — the call drops its volatile staging table and re-registers/re-ingests the current snapshot; feature-store storage is preserved.
Deep-learning forecasts emit melted <target>_prediction rows — those become the features. If the model emits many auxiliary columns, alias/filter to the ones you actually want to govern before registering.
Do not hand-roll the melt/unpivot — prepare_feature_ingestion_tdstone2 already expects the tdstone2 FEATURE_NAME / FEATURE_VALUE / ID_PROCESS melted shape.

Verification¶

Requires a live Vantage + feature store. After the call: the returned dataset has one row per entity-key with the model's features as columns; tdfs4ds.feature_catalog() lists the new FEATURE_NAMEs under your DATA_DOMAIN; and (read-side) get_process_info / the ca-algorithm skill resolves each feature back to the tdstone2 model run.

fs-tdstone2¶

Related skills¶