---
title: "Feast | Skills We Assign For | Azendo"
description: "Feast as a feature store — consistency between training and serving, plus the Azendo roles assigned for it."
url: "https://azendo.co/skills/feast/"
---

[Skills](https://azendo.co/skills/) MLOps and model delivery 

# Feast.

Feast is an open-source feature store providing a shared definition of features, an offline store for training data and an online store for low-latency serving, so both paths compute features identically.

## Where Feast fits on a long engagement.

Training-serving skew is the defect a feature store exists to prevent. When features are computed by a training script and reimplemented for the serving path, the two drift, and the model in production receives inputs subtly different from what it learned on. The result is a model that scored well and performs poorly, with nothing in the logs to explain it.

Point-in-time correctness is the other essential property. Training data must reflect feature values as they were at the moment of the event, not as they are now; joining current values into historical training rows leaks future information and produces an offline score that production will never reproduce.

## What an assigned team does with Feast.

A feature store is infrastructure with real operational weight — an online store to keep available, materialisation jobs to run, and consistency to maintain. It is justified when several models share features or when skew has already caused a problem, and premature otherwise.

Judging that threshold honestly rather than adopting it by default is part of the architectural work under [ai engineering services](https://azendo.co/services/ai-engineering/).

## What we use Feast for.

* One feature definition for both paths Training and serving computing the same thing, which removes skew by construction.
* Point-in-time correct training sets Historical values as they were, so offline scores are achievable in production.
* Features reused across models Shared definitions rather than each project reimplementing the same computation.

## How Feast capacity is assigned.

Feature infrastructure is assigned inside AI capacity, adopted when sharing or skew justifies it rather than as a default.

## Roles we assign Feast for

* [ML Platform Engineer MLOps engineering](https://azendo.co/services/mlops-engineering/ml-platform-engineer/)

## Service lines it sits in

* [MLOps engineering](https://azendo.co/services/mlops-engineering/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in mlops and model delivery

* [MLOps handoff — skill we assign for](https://azendo.co/skills/mlops-handoff/)
* [ONNX — skill we assign for](https://azendo.co/skills/onnx/)
* [TensorRT — skill we assign for](https://azendo.co/skills/tensorrt/)
* [Model registry — skill we assign for](https://azendo.co/skills/model-registry/)
* [Weights & Biases — skill we assign for](https://azendo.co/skills/weights-and-biases/)
* [Comet — skill we assign for](https://azendo.co/skills/comet/)
* [Neptune.ai — skill we assign for](https://azendo.co/skills/neptune-ai/)
* [DVC — skill we assign for](https://azendo.co/skills/dvc/)

## Tell us what your roadmap needs Feast for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)