What Credible Reads
Your Omni model —.view files (dimensions and measures over tables) and .topic files (views joined into queryable units, with AI context and default filters), authored in YAML. The agent works from those files directly, inventorying workbook-level extensions too — logic often lives there, not just in the shared model. Connecting Omni’s MCP server or Model API is optional and adds live validation (and can round-trip the model files).
What Comes Across
The everyday modeling carries over. Here’s how the bigger pieces land — and where they get better:The Migration Flow
Credible reads the shared model, topics, and workbook layers, translates views to sources and topics to joined sources, enriches with#(doc)/#(index) tags (seeded from ai_context), and — where you connect it — validates against Omni’s query engine.
What Credible Handles
- Logic split across layers — the “real” definition of a field may live in an un-promoted workbook model, not the shared model. Credible reconciles the shared, branch, and workbook layers into one canonical Malloy definition, resolving promotion lineage as it goes.
- Field-level inline SQL — Omni encourages
sql:with${…}references and implicit typing. Credible resolves the references and makes Malloy types explicit. - Removable default filters belong in the query, not the model, so query-time defaults become part of a named view rather than a source-level filter.
Before & After
An Omni.view and .topic:
ai_context becomes #(doc) intent on the source and its views; the same physical view joined multiple ways in a topic becomes multiple named joins in Malloy.
More than a reformat. Definitions once split across shared, branch, and workbook layers collapse into one canonical, AI-discoverable model that composes into new questions. See what you gain →
Next Steps
Migration Overview
The method behind every migration
Publishing
Package and publish your migrated model