2026-08-11 · Steve Cronan

What a media knowledge graph actually does

Everyone in the building already knows where the truth lives. It lives in ShotGrid for shots and versions, in FileMaker for the asset library, in Airtable for the schedule someone spun up last spring. The trouble is that no single one of them knows what the others know, and a person is the only integration between them. A media knowledge graph is what you build when you are tired of that person being the integration.

The phrase gets thrown around loosely, so it is worth being precise about what one is and what it is not. A media knowledge graph is not a bigger search box bolted onto your existing tools, and it is not another database you have to feed by hand. It is a governed model of your production that treats your systems of record as sources, joins them on shared entities, and answers questions that span all of them at once, with permissions and version history already accounted for in the answer.

Three systems of record, one model

Start with the honest picture. Your shots, tasks and reviews live in ShotGrid. Your characters, props and library assets live in FileMaker. Your delivery schedule and vendor list live in Airtable. Each is authoritative for its own slice and blind to the rest. When a coordinator needs to know which delivered shots feature a character whose likeness rights just changed, they open three tabs and reconcile by hand.

Fabric is the layer that removes the reconciliation. It joins ShotGrid, FileMaker and Airtable natively, and reaches another 300+ systems through its connector catalog, pulling them into one governed knowledge graph. Nothing gets migrated. Your teams keep working in the tools they already use. Fabric reads across them and holds the relationships between them, so a shot in ShotGrid, an asset in FileMaker and a delivery line in Airtable become connected nodes rather than three disconnected rows.

ShotGrid FileMaker Airtable Fabric graph MovieLabs OMC People Agents (MCP)
Sources of truth stay where they are. Fabric joins them into one governed graph, mapped to MovieLabs OMC, that both people and agents can query.

Why MovieLabs OMC is the difference

Joining systems is easy to promise and hard to do well, because every tool names things its own way. One calls it an asset, another a component, a third a line item. Without a shared vocabulary you get a join that is technically connected and semantically mush.

Fabric maps everything to the MovieLabs Ontology for Media Creation, the industry model for how production entities relate. In Fabric that mapping is concrete: 340 fields across 14 entity types. A character is a character whether it arrived from ShotGrid or FileMaker. A shot relates to the assets that appear in it, the tasks that produce it and the deliveries that ship it, in a way the graph understands rather than a way a person has to remember. That is what turns three data sources into one media metadata model you can actually reason over, and it is why the join holds up when the questions get specific.

Note: OMC is an open, published ontology, not a Fortify invention. Mapping to it means your graph speaks a vocabulary your other MovieLabs-aligned tools already understand, so you are not locked into one vendor's private schema.

More than a search index

Here is the part that separates a knowledge graph from a fast index. Search finds documents that match words. A graph answers questions about relationships, and it answers them with the rules already applied.

Two rules matter most in production. The first is permissions. In Fabric, access is resolved inside the query, not stapled on afterward. A coordinator on one show never sees an entity from a show they are not cleared for, because the query itself never returns it. The second is version time. Production is a moving target: assets get superseded, cuts get replaced, a version that was final on Monday is a relic by Thursday. Fabric is version time-aware, so it can distinguish what is current from what is superseded and answer accordingly. Ask which shots use the approved version of a hero asset and you get the approved version, not a pile of history you have to sort by hand.

That is the difference in one sentence: an index tells you what exists, a governed graph tells you what is true, for you, right now. The question a producer actually asks, which delivered shots feature this character and use a superseded asset version, is a single query against the graph instead of an afternoon of tab-switching.

1

Connect the sources

Fabric joins ShotGrid, FileMaker and Airtable natively, plus 300+ more systems through the connector catalog. No migration, no re-keying. Your teams keep working where they work.

2

Map to the ontology

Every source is mapped to MovieLabs OMC: 340 fields across 14 entity types. Suggested mappings wait for human approval before anything is written, so the model reflects your production, not a guess.

3

Enforce rules in the query

Permissions and version time-awareness live inside every query. Answers come back scoped to who is asking and filtered to what is current versus superseded.

4

Open it to people and agents

The same governed graph answers a coordinator in a browser and an agent over MCP, the open agent-connector standard, through 23 entity MCP tools. One model, two kinds of caller, the same rules.

Agents get the same governed answer

The reason to build the graph now, rather than the next time someone asks for a search upgrade, is what sits on top of it. Fabric exposes 23 entity MCP tools, which open the graph to agents over MCP, the open agent-connector standard. An agent platform can ask the graph about characters, shots, assets and their relationships and get back the same permission-scoped, version-aware answers a person would.

That matters because an agent is only as trustworthy as the data it can reach. Point an off-the-shelf assistant at three raw exports and it will confidently reconcile them wrong. Point it at a governed graph and it inherits your permissions and your version logic for free. The embeddings that power retrieval are computed inside your deployment environment, so the model is asking questions of your data without your data being shipped out to answer them, in production deployments.

Three raw exports

  • A person reconciles by hand across tabs
  • Every tool names entities differently
  • No shared idea of current versus superseded
  • Permissions checked after the fact, if at all
  • Agents guess, and guess confidently

One Fabric knowledge graph

  • ShotGrid, FileMaker and Airtable joined, plus 300+ connectors
  • Mapped to MovieLabs OMC, 340 fields across 14 entity types
  • Version time-awareness distinguishes current from superseded
  • Permissions resolved inside the query
  • 23 entity MCP tools give agents the same governed answer

What it is not

To keep the attribution honest: the knowledge graph is Fabric's job and only Fabric's. Estate-wide search across storage, including tape, plus duplicate and cost reporting, is Gateway, and it is read-only. In-browser preview of about 140 formats is Lens. Atomic ingest with checksum verification and delivery routing is Nexus. Turning a shooting script into a structured breakdown is Codex. Fabric is the layer that joins your systems of record into a queryable model. It does not replace them, it relates them.

If you have felt the tax of being the human integration between ShotGrid, FileMaker and Airtable, that is the tax a media knowledge graph is built to remove. The four-week pilot is scoped to one production or facility so you can see your own systems joined, mapped and queried against your own numbers before you commit to anything. If you want the wider picture of how the graph fits the rest of the platform, the production technology tour and the piece on making cold storage visible are good next stops.