What Credible Reads
The agent inventories your LookML project —manifest, model, view, and explore files — resolving manifest constants as it goes. Give it the .lkml files and it has what it needs; it can also work from dashboards and other unstructured context when that’s all you have. How far validation goes depends on what else it can reach:
- LookML + live data — with a warehouse connection (and, optionally, the Looker API), LookML supplies the business context and the data validates each proposal against live results.
- LookML only — with no connection, LookML is the sole source of context and each proposal is flagged unvalidated until data confirms it.
What Comes Across
The everyday modeling carries over. Here’s how the bigger pieces land — and where they get better:The Migration Flow
1
Read
Inventory every
.lkml file, categorize it, and extract source and join candidates with prior-art notes. The explore/view split collapses into a single Malloy source: joins move from the explore into the source, and relationship: many_to_one becomes join_one.2
Translate
Extract field-level proposals from each view — dimensions and measures with a
lookml provenance — and convert derived tables and struct/UNNEST joins. Apply the keep / skip / flag triage: keep aggregation formulas, join cardinality, and CASE logic; skip drill_fields, html:/Liquid, and PDT optimization keys; flag 50-line SQL dimensions and synthetic primary keys.3
Enrich
Rewrite each LookML
description: into a #(doc) tag that tells an agent what the field means and how to use it, #(index) the categorical dimensions, and map LookML visibility (hidden, fields exclusions, required_access_grants) to Malloy access modifiers and access control.4
Validate
Confirm numeric parity and produce a coverage report — what was modeled, renamed, rearchitected, deferred, or skipped, and why.
What Credible Handles
- Liquid and HTML —
{% … %}templating andhtml:conditional formatting are stripped; their intent is noted, and re-created as a renderer annotation only if it belongs in the model. - Persistent derived tables — classified as transformation, aggregation, or performance-only. Perf-only PDTs are skipped in favor of querying the base table directly; real transformations become query-based sources.
- Refinements (
+view) — consolidated into one definition rather than layered, so there’s a single source of truth per field. - Synthetic keys — a
primary_keybuilt fromconcat()orgenerate_uuid()is flagged so you can confirm the real grain instead of baking in a workaround.
Proving Parity
Two channels, used together:- Looker API — run the original explore through the API and compare. This requires the service account to satisfy the explore’s
required_access_grants, or restricted explores return 404 — so the agent preflights access first. - SQL against the same warehouse — run equivalent SQL directly against the warehouse the LookML reads and diff it against the Malloy result. This is the channel that validates the numbers in practice, with or without API access.
Before & After
A LookML view and explore:type: time dimension group becomes a single date dimension you truncate with .month/.year in a view — no enumerated timeframe list. drill_fields, the Liquid html: block, and value_format_name have no field-level model equivalent: drilling is implicit in Malloy, and formatting moves to # currency/# percent render tags.
More than a reformat. Off LookML, the model is AI-discoverable through the Context Engine, composes into questions your explores couldn’t answer, and is open code you own rather than logic locked in Looker. See what you gain →
Next Steps
Migration Overview
The method behind every migration
Metadata & Discovery
Tune your migrated model for AI retrieval