Understand where every data point comes from⁠—and what breaks when it changes.

Data lineage is the record of how information moves and is transformed across systems: which source a piece of data comes from, which process reads it, what transformations it goes through and which table or dataset it ends up in. It lets you answer impact and data governance questions without depending on what one particular person happens to remember.

Done by hand, it means diagrams and spreadsheets that go stale the moment someone deploys a new job. AI Data Lineage Mapper takes it from the environment itself: it discovers the account's resources in read-only mode and analyses the code, the SQL and the configuration of the processes you select. The processes analysed to extract lineage are Glue Jobs, Lambda functions and Step Functions, and the resulting relationships connect Glue Data Catalog tables, Amazon S3 paths and Redshift objects.

It is lineage that goes down from the table level to the field level: which source column feeds each target column, and through which transformation (direct, rename, cast, calculation, join or aggregation). It is identified when the code and the SQL contain enough evidence; when they do not, the relationship is flagged as such instead of being taken as sound.

Once the lineage is published you query it in the graph or ask the Copilot in plain language. For any table, dataset or S3 path you can see its producing and consuming processes, and walk the lineage upstream and downstream as many levels as you need.

Impact analysis walks the lineage downstream from the asset you want to change and lists the processes, tables and datasets that depend on it. That way you know what might break before you touch a schema, instead of asking on chat and waiting for someone to remember the answer.

Every relationship is proposed with a confidence level and the specific evidence it rests on: file and line of code, SQL statement or job parameter. It then goes through human review before being published, and can be confirmed, rejected or left pending. The AI proposes and a person decides, so there is no black box.

Only if you choose to. The model provider is configured for each extraction: you can use Ollama running on your own infrastructure, in which case neither the code nor the SQL leaves your network, or the Anthropic or OpenAI APIs if you prefer their capability. The decision is explicit and is made before the analysis is launched.

No. Discovery runs in read-only mode and does not modify any resource in your account. The connection can be made in two ways: a read-only role assumed across accounts, protected with an ExternalId and without storing any credentials of yours, or by deploying the product as an appliance inside your own account. On top of that, only the processes you explicitly select are analysed, and you decide which accounts, regions and environments go into each scan.

No. Lineage is inferred from the code, the SQL and the schema metadata —database, table and column names— never from the rows. Data contents, samples and column values are classified as a category that cannot leave towards any model, external or local, and they do not enter the analysis either. AWS tags are excluded too, because they tend to contain email addresses, cost centres or ticket numbers that lineage does not need. The product analyses how data moves, not the data.

With the product's own users and three cumulative roles. Read grants access to the dashboard, the inventory, the catalogue, the lineage and the Copilot without being able to change anything. Operate adds launching scans, extracting lineage and reviewing relationships. Administer adds managing AWS connections, AI providers and users. Beyond the role, each user is assigned the AWS connections they are allowed to work on, so a team can see the development account and not production. Authorisation is checked on the server on every request: hiding a button is a convenience, not the protection. Access does not integrate with a corporate directory over SSO today.