Choose which lineage evidence each connector shows, without deleting anything.
A lineage policy controls which of a connector's collected lineage evidence is actually shown as lineage. Use it to hide noise — a scratch schema, ad-hoc human queries, a redundant evidence source — without touching the underlying data. Nothing is deleted: when you change the policy, Embrasure re-evaluates existing edges and hides or restores them to match.
Each connector has its own policy, edited from the source's actions menu. Every change is saved as a new revision, so you can see what changed and roll back.
A policy applies everywhere lineage is used: traversal, impact analysis, CI checks, alerts, MCP, investigations, and the dashboard. Hidden edges are marked stale rather than removed, and each edge's explanation records which rule hid it, such as policy:schema_scope or policy:provider_rule.
Because a policy changes what the graph serves to everyone, it is different from read-time filters, which narrow one response without changing the graph.
What Embrasure catalogs and what it shows lineage for are controlled separately. Connector setup decides what gets cataloged; the policy can then include or exclude specific relation names, so a schema can stay visible in the catalog while its lineage is hidden.
Write patterns as case-insensitive dotted globs. A two-segment pattern matches the trailing parts of a three-segment table name, so analytics.* matches project.analytics.orders. An empty include list admits every relation, and exclusions always win. An edge is hidden when either of its endpoints falls outside the allowed scope.
For lineage mined from query history, you can include or exclude the users and service accounts that ran statements, and choose which kinds of write statement create lineage. By default these are CREATE TABLE AS, CREATE VIEW, INSERT, INSERT OVERWRITE, and MERGE.
Principal rules apply only to query-history evidence, because only that evidence records who ran a statement. Google Cloud Data Lineage and imports carry no principal — scope those with relation patterns and provider rules instead. When evidence carries both a pipeline and a human principal, excluding only the human does not hide the edge.
Statement-kind rules are enforced when query history is mined and again when evidence is fused into the graph. Evidence collected before statement kinds were recorded keeps serving until the next mining pass, which runs every six hours, re-evaluates it.
A connector can receive lineage from several evidence providers. You can disable a provider entirely, or use the provider and engine matrix to limit one to a particular engine or set of relations. For example, a BigQuery connector can hide query_log evidence while keeping only google_data_lineage evidence from the bigquery engine. Provider rules are checked against both ends of an edge.
Policy revisions are immutable and carry an activation time and a hash, so you can audit exactly which rules were in force when. Saving a revision immediately queues a bounded sweep that re-evaluates affected edges. Most connectors converge in minutes; very large ones, with roughly more than 50,000 claims, can take hours. Graph closures update on the next dirty-drain cycle.
A policy never deletes evidence. Restore an earlier scope or rule and the same evidence is served again. To see why an edge is shown or hidden, open its explanation and check the contributing evidence and its policy disposition.
Manage policies over the API with GET and PUT /v1/connectors/{connector_id}/lineage-policy.