7.1.2 ML_LANDING Model

Purpose

The ML_LANDING schema represents the inference-aligned feature event layer within the Snowflake serving model.

Its role is to materialise feature-engineered datasets that strictly follow a defined Feature Contract, ensuring alignment between:

• Model training

• Validation workflows

• Production inference logic

Unlike UNS_LANDING, which supports exploratory analysis and experimentation, ML_LANDING is a structured, governed dataset intended to match the feature format required by inference objectives.

Design Intent

1. Feature Contract–Driven

All records conform to a deterministic and versioned Feature Contract. Feature definitions, statistical calculations, ratios, and transformations are governed upstream and materialised in this layer without further reinterpretation. Any change to feature logic results in a new FEATURE_VERSION.

2. Inference Alignment

The feature structure stored in ML_LANDING mirrors the structure required by the production inference pipeline. Training datasets are assembled from ML_LANDING to guarantee structural consistency between:

• Offline model development

• Online scoring

3. Objective / Type Segmentation

Feature payloads may differ across:

• Machine types

• Asset classes

• Inference objectives

Rather than forcing a universal schema, ML_LANDING supports logical separation by:

• MACHINE_TYPE

• MODEL_OBJECTIVE

• FEATURE_VERSION

This prevents cross-contamination of feature definitions.

4. Separation from Experimental Data

ML_LANDING is not a general exploration layer. Data science experimentation, ad hoc feature discovery, and raw signal analysis occur using UNS_LANDING. ML_LANDING only contains feature sets that are approved, versioned, and aligned with inference requirements.

Data Grain & Structure

Grain

1 row per asset per inference evaluation event.

Each record represents a feature event aligned to a defined evaluation timestamp.

Core Identifiers

• EVENT_TS – timestamp representing the feature evaluation point

• ASSET_PATH – unique asset identifier

• ISA-95 routing context (SITE_ID, AREA_ID, LINE_ID, CELL_ID)

• MACHINE_TYPE

• MODEL_OBJECTIVE

• FEATURE_VERSION

Payload-Centric Storage Model

ML_LANDING follows the same payload-centric design as UNS_LANDING. Instead of wide exploded feature columns, all feature values are stored within a single structured payload.

Example conceptual structure:

CREATE OR REPLACE TABLE TMA_APPOMAX_DB.ML_LANDING.FEATURE_EVENTS (
    EVENT_TS        TIMESTAMP_NTZ(9),
    SITE_ID         VARCHAR,
    AREA_ID         VARCHAR,
    LINE_ID         VARCHAR,
    CELL_ID         VARCHAR,
    ASSET_PATH      VARCHAR,
    MACHINE_TYPE    VARCHAR,
    MODEL_OBJECTIVE VARCHAR,
    FEATURE_VERSION VARCHAR,
    PAYLOAD         VARIANT
);

The PAYLOAD column contains a structured JSON object, such as:

{
  "state_features": {
    "is_running": true,
    "error_count": 2
  },
  "statistical_features": {
    "avg_joint_speed": 12.4,
    "std_motor_current": 0.87
  },
  "ratio_features": {
    "motor_power_on_ratio": 0.92
  },
  "label": {
    "defect": 0,
    "horizon_min": 10
  }
}

This structure:

• Enables flexible feature evolution

• Avoids rigid schema changes

• Preserves inference contract integrity

• Supports future feature expansion without DDL modifications

NOTE: Only one ML_LANDING table for all types of machines.

Example Data: ML_LANDING

Feature Governance & Versioning

Usage Pattern

Relationship to Other Models

Upstream:

• Derived exclusively from UNS_LANDING using governed transformation logic

Downstream:

• Consumed by Pipeline J (On-Prem Inference)

• Feeds PRED_LANDING for inference result storage

ML_LANDING represents the controlled contract between contextualised OT data and production ML systems.

Summary

The ML_LANDING model provides:

• Versioned

• Objective-specific

• Inference-aligned

• Payload-centric feature event datasets

This ensures architectural consistency across training, validation, and production inference while preserving flexibility and governance.