Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
How data lineage tracking works in practice: the four lineage types, the five components, how lineage is captured, and worked examples you can verify.
Updated on
Data lineage is the end to end record of where a piece of data came from, every transformation it went through, and every downstream asset that depends on it. It maps the journey of data across an organisation, from source systems through transformation layers to dashboards, reports and the inputs of AI models.
The most useful data lineage definition is the technical one, because it says what a lineage system is actually holding: a set of edges. Each edge says that this field, in this table, was produced from that field, in that table, by this operation, at this time. A lineage graph is nothing more than a very large collection of those statements, drawn so a person can follow them. Every argument about lineage, including the arguments about tools, is really an argument about how those edges are collected and how many of them are missing. If you have to define data lineage in one line for a governance committee, that is the line to use.
That is also the difference between the lineage of data and a diagram of your architecture. An architecture diagram says which systems are connected. Lineage says which field in which table produced which number on which dashboard, which is the question people actually ask at two in the morning.
Without lineage, answering a basic data question means interrogating engineers, reading SQL at 2am, or staring at a broken dashboard the night before a board meeting. With lineage, the answer is a click away. Lineage is not new: enterprises have tracked data flows in some form for decades. What changed after 2024 is why it matters, because organisations deploying AI now have to show that every model input is accurate, traceable and permitted.
Data lineage is the record. Data lineage tracking is the system that keeps producing it. The distinction matters because a lineage diagram drawn once in a workshop is accurate for about a fortnight, and a lineage graph rebuilt automatically every time a pipeline runs is accurate for as long as the capture keeps working.
Tracking has four moving parts, and a gap in any one of them shows up as a hole in the graph:
The fourth part is the one teams skip, and it is why so many lineage projects look successful in month one and are quietly distrusted by month nine.
Modern data teams work with four distinct lineage types, each serving a different audience and use case. Knowing which type you need, and when, prevents building far more than the question requires and delivering far less than it needs.
| Lineage type | Who uses it | The question it answers | Where it stops |
|---|---|---|---|
| Technical lineage | Data engineers, platform teams, site reliability engineers | What job touched this table and what did it do to this column? | It says nothing about what the column means to the business. |
| Business lineage | Data stewards, business analysts, chief data officers | Which systems and definitions produce the number Finance signs off? | It depends on a glossary being maintained, so it decays faster than technical lineage. |
| Operational lineage | Data engineers, data operations teams | Which upstream job failing caused this dashboard to go stale? | It tracks runs and dependencies, not the field level logic inside them. |
| End to end lineage | Chief data officers, compliance officers, AI and machine learning teams | Can I trace this reported figure back to the transaction that produced it? | It is only as complete as the least instrumented tool in the chain. |
Technical lineage tracks data movement at the table and column level across systems: databases, ETL pipelines, dbt models, Snowflake, Databricks and Spark jobs. This is what data engineers live in. Its primary uses are debugging, impact analysis before a schema change, and pipeline root cause analysis.
Business data lineage connects data assets to business definitions, metrics and key performance indicators. It translates CUST_REV_ADJ_V3 into Adjusted Customer Revenue as defined by Finance in the first quarter of 2025. Business lineage lives at the intersection of the data catalog, the business glossary and technical lineage, and its primary uses are regulatory reporting, metric validation and letting non engineers answer their own questions.
One practical warning about business lineage: it is the only type that cannot be fully automated, because the mapping from a column to a business definition is a human judgement. Treat it as a maintained asset with a named owner rather than as something the platform produces on its own.
Operational lineage shows how pipelines and jobs process data: scheduling, dependencies, service level tracking and failure cascades. It answers which upstream job failing caused a dashboard to go stale, and it is what incident management and service level enforcement run on.
End to end data lineage combines the three types above across systems, from raw source data ingested from a customer relationship system or a transactional database, through transformation layers, all the way to a business intelligence dashboard or the feature store behind a model. This is what regulatory audits and AI model explainability need, and it is the hardest of the four to hold together, for reasons the section on what end to end really requires sets out below.
Decube maps all four types in a single connected canvas, from source tables through transformations to dashboards and AI feature pipelines. You can see how the graph behaves on a real stack in the Lineage Canvas.
Most enterprises have worked out that AI results depend far more on data engineering discipline than on model selection. When an AI system produces an answer or takes a decision, lineage is what shows which data contributed to it and how that data was changed on the way. Without it, models are fed stale, incorrect or misclassified inputs and nobody can say so afterwards.
Decube built TrustyAI on this idea. It uses field level lineage as the context layer that lets AI agents reason about data safely, explain their outputs, and recognise when to escalate rather than act.
Lineage documentation is now a legal requirement for many organisations rather than a good habit:
In Asia Pacific financial services the same requirement arrives through the local supervisor rather than through Brussels. APRA in Australia, OJK in Indonesia, MAS in Singapore, BNM in Malaysia and BSP in the Philippines all increasingly ask for data provenance documentation as part of model risk and governance review, and in United States insurance the NAIC asks for the same evidence for underwriting and claims models. These are the regulators Decube customers report to, and they are almost absent from the material published on lineage.
Consider a credit risk model producing anomalous output the week before a regulatory submission. Without lineage the team spends days working out by hand whether the anomaly came from a source system change, a transformation bug or a feature calculation error. With field level lineage the cause is found in minutes: a schema change upstream silently altered a join key and changed the downstream feature. The cost of the gap is rarely the incident itself. It is the days of senior engineering time spent proving what happened, repeated every time it happens.
This is the part almost no lineage article covers, and it is the part that decides whether the graph you are looking at is trustworthy. There are four data lineage techniques in common use. Most platforms combine two or three of them, and the combination they choose determines exactly which parts of your stack go dark.
The warehouse already records every statement it executed. A lineage system reads that history, parses each statement, and derives the edges from the SQL itself. If a query wrote to ORDERS_DAILY by selecting three columns from ORDERS and one from CUSTOMERS, the edges follow directly from the text.
This is the most complete method inside a warehouse, because it observes what actually ran rather than what somebody intended to run. It also captures the ad hoc work: the analyst who built a table by hand at the end of a quarter appears in the graph without anyone declaring anything.
Where it fails is outside the warehouse and inside dynamic SQL. A statement assembled at runtime by a Python script, or a stored procedure that builds column lists from a variable, parses to an edge the system cannot resolve to real fields. Log retention is the second limit: if the warehouse keeps ninety days of query history, a table that is only rebuilt annually has no visible parent.
Transformation frameworks describe their own graphs. A dbt project publishes a manifest naming every model, its sources and its columns. Spark exposes a query plan. An orchestrator such as Airflow or Azure Data Factory records which task reads which dataset and writes which other. Reading those artefacts gives lineage without touching the warehouse at all.
The advantage is precision and cheapness. The manifest is authoritative about what the transformation layer believes it is doing, it is available before anything runs, and parsing it costs nothing in warehouse compute.
The weakness is that it only knows what the framework knows. Any transformation that happens outside dbt, outside Spark and outside the orchestrator is invisible, and in most estates that means a meaningful share of the real logic. It also describes intent rather than execution, so a model that failed last night still appears in the graph as though it produced its output.
Instead of reading logs after the fact or manifests before it, the system observes pipeline runs as they happen and emits a lineage event per run. The OpenLineage specification is the common format for this, and it records the job, the inputs, the outputs and the run status together.
The strength is that runtime events carry facts nothing else has: whether the run succeeded, how many rows it moved, and when. That turns lineage from a static map into something you can reason about during an incident, because a stale edge and a failed run are distinguishable.
The cost is instrumentation. Every job has to emit events, which means a change to each pipeline, and any system nobody instrumented simply does not appear. In practice teams instrument the pipelines they already trust and leave the awkward legacy jobs, which are exactly the ones an auditor asks about.
Someone states the relationship: this report is built from that extract, this field maps to that definition. Declarations are entered in the catalog or loaded from a specification file.
Manual declaration is the only method that can cover a system with no readable metadata at all, which describes most vendor applications, most file drops, and every spreadsheet that quietly feeds a financial model. It is also the only way to attach meaning, which is why business lineage always contains a declared component.
It goes stale the day after it is written and nothing tells you when it did. Declared edges should carry an author, a date and a review interval, and a lineage graph should show them differently from derived edges so a reader can see which parts of the picture are somebody remembering rather than the system observing.
| Capture technique | What it reads | What it gets right | Where it goes blind |
|---|---|---|---|
| Query log parsing | Warehouse query history | Observes what actually ran, including ad hoc and undeclared work | Dynamic SQL, anything outside the warehouse, and anything older than log retention |
| Code and pipeline metadata | dbt manifests, Spark plans, orchestrator definitions | Precise column level detail, available before a run, no warehouse compute cost | Logic outside the framework, and it shows intent rather than what executed |
| Runtime observation | Events emitted by jobs as they run | Adds run status, timing and row counts, so incidents are diagnosable | Any job nobody instrumented, which is usually the oldest and most awkward ones |
| Manual declaration | What a person states | Covers systems with no readable metadata, and carries business meaning | Accuracy decays from the day it is written and nothing signals when |
A practical rule follows from this table. Ask any lineage vendor which of the four techniques their graph is built from for each system in your stack, and treat a general answer as a warning. The realistic pattern is query log parsing plus framework metadata inside the warehouse, runtime events where instrumentation exists, and declared edges at the ragged edges. Knowing which one produced a given edge is what lets you judge it.
Capture produces edges. Data lineage mapping is what turns those edges into something a person can follow, and it involves three decisions that are usually made by default rather than deliberately.
If you take one habit from this section, make it this: when you run an impact analysis, set the depth to unlimited before you trust the answer. The default depth is the most common reason a schema change that was checked still broke a report.
A complete data lineage framework has five components working together. The table below names each one, what it contributes to the graph, and the question to ask when you are checking whether your own coverage is real.
| Component | What it contributes | The coverage question to ask |
|---|---|---|
| Data sources | The origin systems: operational databases, application programming interfaces, software as a service platforms such as Salesforce and SAP, file systems and streaming sources such as Kafka. Lineage begins here, capturing schema, ownership and ingestion time. | Which sources feed a reported number but have no connector at all? |
| Transformations | Every operation that modifies data: SQL joins, dbt models, Spark jobs, Python scripts and stored procedures. Field level tracking here is what separates surface mapping from lineage you can act on. | How much of the transformation logic lives outside the frameworks the platform reads? |
| Data pipelines | The orchestration layer: Airflow directed graphs, Azure Data Factory pipelines, Fivetran syncs and AWS Glue jobs. Operational lineage maps these dependencies so a pipeline failure can be traced to the assets it cascades into. | Do failed runs show differently from successful ones in the graph? |
| Destinations | Where data lands: warehouses such as Snowflake, BigQuery and Redshift, business intelligence tools such as Tableau, Power BI and Looker, feature stores and downstream interfaces. | Does the trace continue inside the reporting tool, or stop at the table it reads? |
| Metadata | The connective layer: data types, owners, freshness, quality scores, business definitions and policy tags. Metadata is what turns a technical map into a governance record. | Can you filter the graph to only the nodes carrying personal data? |
The fifth component is where lineage stops being an engineering artefact. Metadata management attaches owners, sensitivity tags and business definitions to the nodes, and it is the reason a governance team can use the same graph an engineer debugs with.
Four stages, in order. Teams that skip straight to stage two spend the following year discovering sources nobody listed.
Catalog every data source that matters. This includes the obvious one, the primary warehouse, and the less obvious ones: the spreadsheets that feed financial models, the exports that power marketing analytics, and the operational databases behind AI training pipelines. Modern platforms automate discovery through connectors, and Decube supports more than a hundred integrations including Snowflake, Databricks, dbt, BigQuery, Tableau and AWS Glue, but discovery still needs human judgement about what is business critical rather than peripheral.
Document the relationships between sources, transformations and destinations. At table level this gives a high level flow map. At field level it gives the traceability that compliance and AI work require. Use the three mapping decisions above, and record which capture technique produced each region of the graph, because that is what tells you which regions to distrust.
Attach business context to the technical graph: link assets to the glossary, assign owners, tag personal and sensitive fields, describe transformation logic in plain language, and record service level expectations. This is the stage that turns lineage from an engineering artefact into something a governance team can use, and it is the stage most often deferred and never done.
Lineage that is not maintained becomes misleading, which is worse than having none, because people act on it. Validation means automated checks that the graph stays accurate as pipelines change, alerts when an upstream schema change could break a downstream path, and regular audits comparing documented lineage against observed data flows. The section on verifying a graph below gives four checks to run.
Five data lineage use cases, each written as the sequence a team actually follows. If you want a single data lineage example to test a platform with, use the third one, because it is the one that exposes gaps.
An engineer wants to rename a column in a source table. Without lineage they either ask in a group chat, which is unreliable, or push the change and wait for the breakage reports. With column level lineage they open the graph, set depth to unlimited, and see that fourteen downstream tables, three transformation models and two dashboards depend on that field, then plan the change or automate its propagation.
A revenue dashboard shows a spike that does not match operational data. With end to end lineage the team traces the number back through the reporting layer, the aggregation model and the transformation job, and finds that a currency conversion lookup table was loaded with incorrect values two days earlier. The trace takes minutes instead of the hours it takes to read the pipeline by hand.
A customer asks for every record held about them. The team filters the graph to nodes tagged as personal data, walks downstream from the source table, and produces the list of every asset carrying a copy, including the two extracts sitting in a reporting tool that nobody remembered. This is the example worth testing a platform against, because it fails the moment coverage stops at the warehouse edge.
A financial institution has to show that a reported figure can be traced to source systems. Lineage provides the chain: this regulatory metric, from this aggregation view, from these source transactions, from this operational database, ingested at this timestamp with this quality score. Without it that evidence is assembled by hand under time pressure.
A fraud detection model starts drifting. With lineage the team identifies which features changed and traces them back to source, discovering that a third party provider altered an interface response format and silently changed a feature. Where the model is an agent that acts rather than a model that scores, the same idea extends one layer further into agent lineage, which traces a decision back through the tools and prompts behind it as well as the data.
A lineage graph rarely announces that it is wrong. It keeps rendering, keeps looking complete, and quietly stops describing reality. These are the specific events that cause it, with the symptom to watch for and the test that catches each one.
| What happens | Why the graph goes wrong | How to catch it |
|---|---|---|
| A view is dropped and rebuilt | The new object gets a new internal identifier, so the old edges point at something that no longer exists and the new object appears with no parents. | Look for nodes with downstream children and no upstream parents. A rebuilt view is the most common cause of an orphan. |
| A transformation lives in a hand written script | A Python or shell job that reads one table and writes another leaves nothing for a manifest parser to read, and often nothing resolvable in the query log either. | Compare the list of tables that are written to against the list of tables with a known producer. The difference is your script population. |
| A tool sits outside the warehouse | A reporting tool, a reverse pipeline or a vendor application transforms data where no connector reads it, so the trace ends at the last table the warehouse saw. | Pick a number from a report and try to trace it. If the graph ends at a table rather than at the report field, coverage stops there. |
| SQL is assembled at runtime | Dynamic statements and stored procedures that build column lists from variables parse to edges that cannot be resolved to real fields. | Check whether the platform reports unresolved statements. If it silently discards them, the graph is missing them without telling you. |
| Query log retention expires | A table rebuilt quarterly or annually loses its parents once its creating statement ages out of the warehouse history. | Compare the age of the oldest edge in the graph against your log retention window. |
| A declared edge is never reviewed | Somebody mapped a source to a report two years ago. The report changed. The edge did not. | Filter the graph to declared edges and sort by age. Anything older than its review interval is a claim, not a fact. |
| A pipeline fails but the edge remains | Lineage derived from definitions rather than runs shows the path as though data flowed through it last night. | Check whether the graph shows run status. If an edge cannot be stale, the graph is describing intent. |
Every one of these produces the same reader experience: a graph that looks finished. That is why the verification section below matters more than any feature list.
End to end is the most overused phrase in this category. In practice it usually means complete inside one warehouse. Real end to end lineage crosses six boundaries, and the trace is only as good as the weakest of them.
| Layer | What has to be traced | The gap that usually appears |
|---|---|---|
| Ingestion | Which source object produced which landed table, and when it arrived | File drops and vendor extracts arrive with no producing system recorded |
| Transformation | Field level derivation through every model and job | Logic in scripts and stored procedures outside the transformation framework |
| Orchestration | Which run produced which output and whether it succeeded | Lineage built from definitions rather than runs, so failures are invisible |
| Warehouse | Table and column relationships including views and temporary objects | Rebuilt views and objects created outside the modelled pipelines |
| Business intelligence | Which report field reads which column, through the semantic layer | The trace stops at the table the reporting tool reads, not the field on the report |
| Model features | Which columns became which features, and which model version used them | Feature engineering code sits outside every connector, so the chain ends at the feature store |
A test that settles the argument quickly: pick a single number on an executive report, and ask the platform to show its full upstream path down to the source system that created it. If the answer stops at a warehouse table, you have warehouse lineage. If it reaches the operational system and names the ingestion time, you have end to end lineage.
A lineage graph is read in four passes, and doing them in this order stops the sprawl from being overwhelming.
Two visual habits are worth building. Prune the branches you have ruled out rather than scrolling past them, because a pruned graph is a record of your reasoning. And note where the graph shows an edge you cannot explain, because an unexplained edge is either a data flow nobody documented or a resolution error, and both are worth an hour.
Trust in lineage is usually granted rather than earned. These four checks take a few hours between them and will tell you more about a platform, including one you already own, than any demonstration.
| Check | How to run it | What a failure means |
|---|---|---|
| Trace one known field by hand | Pick a field whose derivation you already know from the code. Ask the graph for its full upstream path and compare it against the truth you know. | A missing hop means the capture technique does not read that part of your stack. Find out which one and assume the same gap exists everywhere that technology is used. |
| Count the orphans | List nodes that have downstream children but no upstream parent. Express it as a share of all nodes. | A high orphan share means rebuilt objects, expired logs or unreadable transformations. Each orphan is a trace that will end early during an audit. |
| Check the age of the newest edge | For a handful of tables you know changed this week, ask when their edges were last written. | If the newest edge predates the change, refresh is not keeping pace and the graph is a historical document being read as a current one. |
| Test one schema change against the impact list | Take a change that has already happened, ask the graph what it would have affected, and compare against what actually broke. | Anything that broke and was not on the list is the exact shape of your blind spot, and it is the most useful diagnostic in this list. |
Run these before a compliance deadline rather than during one. A graph that fails the fourth check is not useless, but it should not be the only evidence behind a statement to a regulator.
Table level lineage says that table A fed table B through process C. Column level lineage says which field produced which field. The difference decides whether you can answer why two systems report a different customer lifetime value, where a customer acquisition cost calculation is defined, or which assets carry a copy of a personal data field you need to mask.
Table level is useful for orientation and insufficient for a conclusion. For the full treatment, including how field level tracking is built and what it costs to run, see our guide to column level lineage.
Lineage and observability are complementary rather than competing. Observability tells you that something is wrong. Lineage tells you where it started and what it affects. Lineage without observability gives you the map but not the weather, and observability without lineage tells you there is a storm without saying where it formed.
The five pillars of data observability, which are freshness, volume, schema, quality and lineage, treat lineage as a native dimension of data health rather than a separate concern. When a freshness alert fires on a reporting table, lineage surfaces the upstream pipeline responsible. When a schema change is detected, lineage shows which downstream consumers will break. This is why standalone lineage tools keep being consolidated into unified platforms: Decube runs observability and lineage on a single metadata graph, so lineage context is present the moment an alert fires and health signals are visible inside the lineage view.
A catalog without lineage is a library with no record of where the books came from or how they relate. The integration runs both ways. Lineage enriches the catalog, so a user sees not only what a dataset is but where it came from, what logic produced it and what depends on it. The catalog enriches lineage, because glossary terms, owner metadata, quality rules and personal data classifications attach to lineage nodes and turn a technical graph into a governance record.
This is the join between data governance and data lineage in practice. Policy states that personal data must not leave a jurisdiction; lineage is what shows whether it did. Decube runs metadata management and data governance on the same lineage graph, so context recorded in the catalog is available in the lineage view and the other way round.
Six practices, in the order they pay off.
Evaluation criteria rather than a shortlist. The criteria below are the ones that separate data lineage solutions that hold up in an audit from the ones that demonstrate well. We compare the market itself in a separate article, Best Data Lineage Tools, so this section stays on what to test.
Decube runs data lineage as a single connected graph across the stack, from source tables through transformations to dashboards and AI feature pipelines, at field level rather than table level. Because observability, metadata management and governance sit on that same graph, an alert arrives with its lineage context attached and a governance question is answered from the same picture an engineer debugs with.
The Lineage Canvas is built for the reading habits described above: pin the asset you are investigating, prune the branches you have ruled out, and keep the node in view while you trace personal data downstream. If you want to run the four verification checks against your own stack, request a demo and bring a field whose derivation you already know.
Data lineage is what every other data programme rests on. Governance, quality work and AI readiness all assume you can say where a value came from, what changed it and what depends on it, and none of them survives contact with a regulator if you cannot.
The part worth carrying away is narrower than the definition. Lineage is only as good as the technique that captured it, and the graph will not tell you where it stopped looking. Ask which technique produced which region of your graph, learn the events that break it, and run the four checks before you rely on it. Teams that treat lineage as a maintained system rather than a diagram are the ones whose lineage still works a year later.
Data lineage is the end to end record of where a piece of data came from, every transformation it went through, and every downstream asset that depends on it. Technically it is a set of edges: each one states that a field in one table was produced from a field in another by a given operation at a given time. A lineage graph is those edges drawn so a person can follow them.
Data lineage tracking is the working system that keeps the lineage record current, as opposed to the record itself. It has four parts: capture, which reads transformation logic from query logs, pipeline metadata or runtime events; resolution, which turns references into real objects; storage, which writes timestamped edges to a graph; and refresh with expiry, so old paths age out instead of accumulating.
The practical data lineage meaning is being able to answer three questions about any number in your business: which source produced it, what changed it on the way, and what breaks if the source changes. The lineage of data is the trail that connects a figure on a report back to the transaction that created it.
Four are in common use. Query log parsing reads the warehouse history and derives edges from the SQL that ran. Code and pipeline metadata parsing reads dbt manifests, Spark plans and orchestrator definitions. Runtime observation emits a lineage event per pipeline run, usually in the OpenLineage format. Manual declaration is a person stating a relationship. Most platforms combine two or three, and the combination decides which parts of your stack go dark.
Data lineage mapping is turning captured edges into a graph a person can follow. It involves three decisions: granularity, meaning table level or field level; identity, meaning when two references across tools are treated as the same object; and direction and depth, meaning upstream or downstream and how many hops are shown. Set depth to unlimited before trusting an impact analysis, because a capped default is the usual reason a checked change still breaks something.
An engineer wants to rename a column in a source table. With field level lineage they open the graph, set depth to unlimited, and see that fourteen downstream tables, three transformation models and two dashboards read that field, so the change is planned rather than discovered through breakage. A harder example is a privacy request: filter the graph to nodes tagged as personal data and walk downstream to list every asset holding a copy.
Impact analysis before a schema change, root cause analysis during an incident, privacy requests that need every copy of a personal data field located, regulatory reporting that has to trace a figure back to source, and AI model governance where a drifting model has to be traced to the feature and the source that changed.
Business data lineage connects data assets to business definitions, metrics and key performance indicators, translating a column name such as CUST_REV_ADJ_V3 into the definition Finance signed off. It is used for regulatory reporting and metric validation. It is also the only lineage type that cannot be fully automated, because mapping a column to a business meaning is a human judgement, so it needs a named owner and a review interval.
End to end data lineage traces a value across every layer rather than within one system: ingestion, transformation, orchestration, warehouse, business intelligence and model features. The test is simple. Pick a number on an executive report and ask for its full upstream path. If the answer stops at a warehouse table you have warehouse lineage. If it reaches the operational system and names the ingestion time, it is end to end.
Governance sets the policy and lineage supplies the evidence. A policy stating that personal data must not leave a jurisdiction is an intention until lineage shows whether it did. In practice the catalog contributes owners, glossary terms and sensitivity tags to lineage nodes, and lineage contributes provenance and dependency context to catalog assets, which is why they work best on a single shared graph.
The sections above describe what a maintained lineage record contains and how the edges are captured. This two minute walkthrough shows that record in use inside Decube: tracing an asset upstream and downstream, hovering an edge to see whether the relationship came from Snowflake SQL query lineage or a dbt job, then opening a column to read its downstream mappings field by field. It also toggles open incidents and PII classifications onto the same graph, so the dependency map and the risk sitting on it are read together. Watch it if you want to see what the verification checks in this article look like on a real graph.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Book a 30-min demo with us and see how lineage, quality, governance, and compliance come together in a single platform.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)