In May 2026, InfoQ published Netflix Introduces ‘Model Lifecycle Graph’ to Scale Enterprise Machine Learning, announcing that Netflix operates a mechanism in production that visualizes and manages machine learning models as "graph structures."
In conventional MLOps based on "model ID + version number," teams could not track dependencies such that "updating model A breaks model B," leaving issues like cascading production outages unaddressed. Netflix's Model Lifecycle Graph is an example that tackled this problem using a "DAG (Directed Acyclic Graph)." This article outlines the steps for building an equivalent governance platform in custom development projects.
Why "model ID management" has reached its limits
| Challenge | Impact on operations |
|---|---|
| Invisibility of inter-model dependencies | Failing to notice that updating A breaks B |
| Loss of dataset lineage | Inability to trace "what was this model trained on?" |
| Breakdown of reproducibility | Inability to reproduce the same predictions |
| Regulatory compliance difficulties | Inability to present model lineage during audits |
| Stagnation of cost optimization | Inability to decommission unnecessary models |
In particular, "loss of dataset lineage" is an issue heavily scrutinized under the EU AI Act, US Executive Orders, and Japan's AI Guidelines for Business, and the cost of retrofitting governance in client projects is becoming immense. This conversation extends the evaluation framework discussions to the model management tier, following what was covered in AI Evals Compute Bottleneck Client Projects.
Four structural characteristics of the Model Lifecycle Graph
Feature 1: Treating models, datasets, and features as "nodes"
[データセット A]
│
├─→ [特徴量 X]
│ │
│ └─→ [モデル M1]──→ [サービス S1]
│
└─→ [特徴量 Y]
│
└─→ [モデル M2]──→ [モデル M3]──→ [サービス S2]
With this graph structure, you can identify in seconds "which final services will be affected by a quality degradation in dataset A."
Feature 2: Recording version transitions as "edges"
New model versions are recorded as "edges from earlier versions," expressing rollbacks, A/B testing, and shadow deployments within the same graph.
Feature 3: Enabling impact analysis in advance
The architecture is designed so that the moment you decide to "suspend this dataset for a week," a "list of affected models and services" is automatically generated. This extends to the ML domain the exact same philosophy of "visualizing change impact in advance" discussed in DORA / SPACE / Core 4 ROI Custom Development.
Feature 4: Tying governance logs directly to the graph
Because audit logs are preserved per graph node and edge rather than per model version, you can trace "when, who approved which model" across chronological timelines and dependency structures.
Four implementation phases built in custom development
Phase 1: Metadata integration layer
Aggregate metadata for models, datasets, and features from existing instances of MLflow, SageMaker, Vertex AI, and Weights & Biases. Establishing a unified schema upfront is key.
Phase 2: Graph store adoption
Introduce a graph database such as Neo4j, Amazon Neptune, or TigerGraph to persist metadata as a DAG. A simple design where "nodes = assets" and "edges = dependencies" is sufficient.
Phase 3: Impact analysis API
Provide an impact analysis API that returns "a list of nodes affected if node X changes." Call it from CI/CD pipelines to ensure an operation that "stops failures before they break."
Phase 4: Audit dashboard
Provide a dashboard for auditors that visualizes the graph via a web UI and allows taking "snapshots at specific points in time." Combining this with the observability covered in Langfuse AI Development Observability makes it possible to trace all three layers—prompts, models, and data—on a single screen.
Technology stack for custom development
| Layer | Recommended technology | Alternative |
|---|---|---|
| Metadata collection | OpenLineage / DataHub | In-house ETL |
| Graph store | Neo4j | Amazon Neptune / TigerGraph |
| Model management | MLflow / Vertex AI | SageMaker |
| Feature store | Feast | Tecton |
| Observability | LangFuse + OpenTelemetry | Datadog |
In particular, the combination of DataHub + Neo4j can be constructed primarily with open source software, and minimizing vendor lock-in is critical in custom development projects.
Enterprise MLOps maturity model
| Level | Status | Client support scope |
|---|---|---|
| L0 | Model ID management only | Inventory audit + roadmap |
| L1 | Version management in place | Metadata integration |
| L2 | Lineage traceability enabled | Graph store adoption |
| L3 | Automated impact analysis | API + CI/CD integration |
| L4 | Governance log integration | Audit dashboard |
For the vast majority of Japanese enterprises currently at L0 or L1, rapidly elevating them to L2 through L4 represents the primary value delivered through custom development.
"MLOps governance clauses" to include in custom development contracts
| Clause | Details | What the client should verify |
|---|---|---|
| Data lineage retention period | Statutory and audit requirements | Storage costs |
| Impact analysis SLA | Guaranteed API response time | Operational business impact during incidents |
| Model approval workflow | Approvers and deadlines for production promotion | Alignment with existing approval workflows |
| Regulatory reporting compliance | EU AI Act / Japan guidelines | Reporting frequency |
| Separation of duties | Data science / operations / audit | Alignment with existing organization |
Four common pitfalls
Pitfall 1: Misunderstanding that "introducing a graph DB is the end of the job"
A graph store presupposes metadata collection, making it necessary to first establish lineage collection via OpenLineage or similar tools. If you get the sequence wrong, you will end up with an empty graph.
Pitfall 2: Overly demanding "real-time" impact analysis
In most cases, a response time of a few seconds is completely sufficient; demanding millisecond-level latency will increase costs tenfold. Designing SLAs tailored to use cases is critical.
Pitfall 3: Retrofitting an audit dashboard at the end
Auditors place high importance on "being able to inspect it themselves." If you do not incorporate an auditor-focused UI from the start of the design, you will end up rebuilding it at the very end.
Pitfall 4: Model approval workflows diverging from the existing organization
If ML engineers determine approval workflows alone, it causes friction with existing quality assurance and compliance departments. It is essential to involve relevant departments during Phase 0.
Summary: Moving from "model IDs" to "graphs"
Netflix Model Lifecycle Graph signals the end of the era of "managing ML models in isolation." In custom development projects, handling datasets, features, models, and services within a single DAG enables the simultaneous realization of regulatory compliance, outage reduction, and cost optimization.
For challenges like "we can no longer track ML model dependencies" or "we need to organize audit logs for EU AI Act / Japanese guideline compliance," the appropriate measures vary widely based on model counts, existing infrastructure, and audit requirements. From initial maturity assessments to graph store deployment, we offer customized consultations and estimates based on your specifications, so please feel free to reach out via our contact form.









