Autonomous in the loop. Accountable at the gates. An agentic offering by Plainsight

Every transformation, traceable. No black box.

The builders generate your models from the documented logic, as readable code. Step from any mart table back through staging to the source query, with the transformation in plain sight and mapped to the legacy asset it replaced.

Plan my migration What you keep
No black box

Read how every table is built.

The builders turn the knowledge base into real models, written to your conventions. Paired with the lineage graph, you can move from a column in a mart, to the model that builds it, to the source query it started from, all in readable code.

  • Plain, maintainable SQL or your framework’s code
  • Generated from documented behavior, not guesswork
  • Each model linked to the legacy asset it replaced
  • Reviewable in version control, like any other code
models/marts/dim_customer.sqltransformation
-- compiled from DWH_Load_DimCustomer (SSIS)
with stg as (
    select customer_id, full_name, city, modified_at
    from stg_customer
)
select
    md5(customer_id)   as customer_key,
    customer_id,
    full_name,
    city,
    modified_at        as valid_from
from stg
What you can follow

Nothing hides between source and mart.

The transformations are documented and linked, so the path from raw to report is something you can walk, not just trust.

From mart back to source

Follow any table upstream through staging to the source query, hop by hop, without opening a single black box.

The logic, in plain SQL

Transformations are readable code, generated from documented behavior, not an opaque export you cannot maintain.

Mapped to the legacy asset

Each model references the package or procedure it replaced, so the new build and the old one stay connected.

Browsable in your repo

It lives in version control and the docs site, so a change is reviewable and the history is yours.

In dbt the compiled SQL and its docs come for free; in your own framework we generate equivalent, readable code into it, which is extra effort on our side, and you keep it either way. dbt or your framework →

Good questions

Navigable transformations, answered.

Can I see the actual transformation logic?

Yes. Every model is plain, readable SQL (or your framework’s code), generated from the documented behavior. You can open any mart and read exactly how it is built.

How does it map back to the old package?

Each generated model carries a reference to the legacy asset it came from, so you can step from a new table to the SSIS package or stored procedure it replaced.

Is the generated code readable or machine-ugly?

It is written to your layer conventions and naming, so it looks like code your team would have written, not an export. That is the point: you can maintain it. See everything you keep →

Let's talk

Want to read your own pipelines?

The estate assessment shows how the fleet would rebuild a representative slice of your estate, in code you can read and maintain, before you commit.

Plan my migration

A short form, no spam. We usually reply within one business day.

Plan my migration