Your company has 14 ML teams shipping 60+ models. Every team writes its own feature pipelines. The same feature: "restaurant average rating over the last 30 days": is implemented four times, with three different definitions, and two of those implementations leak future information into training.
Three separate incidents last quarter were traced to training-serving skew: a feature computed one way in a Spark training job and another way in a Java serving path. Nobody can answer "which models depend on this column?" when an upstream table changes.
Design a feature store that these 14 teams will actually adopt. It must serve features online at low latency, produce point-in-time-correct training datasets, and make feature definitions shareable and discoverable.
Build the architecture on a canvas: place the components, configure them, connect them into a data flow, and write a short reason for each one. The AI reviewer grades your design against a rubric written specifically for this problem.
Show me concretely how a naive join produces label leakage, and how the as-of join fixes it.
A team needs a feature computed from the request payload itself. Where does that live, and how do you stop skew reappearing there?
Two teams define 'active user' differently and both are correct for their use case. What does your registry do about that?
Minimum 8 components · needs a wide desktop screen