Answer lineage pins the certified metric version behind a disputed EUR 18.6M

In the completed lineage object from the dev.to post "Building Answer Lineage for Enterprise Data Agents", semantic_resolution records the metric name Recognized Revenue, version v4 and owner Finance; the semantic evidence example adds the id metric.recognized_revenue and status certified ^[8]. Those fields come from a governed metric store. An agent that writes SQL straight from table DDL resolves "revenue" against a column name, and none of the five signals it already logs records that decision ^[24].

Version v4 is what makes an answer defensible six weeks later. The post lists version history among what an append-only stream gives you, along with auditability, ordering, replay and debugging ^[10]. A replay against an unpinned metric answers with the definition in force today, not the one that produced 18,600,000 EUR ^[7][22].

The path from question to answer has nine stages: Question, Resolved Intent, Semantic Objects, Selected Data, Relationship Path, Query Plan, SQL, Execution Result, Answer ^[5]. The event list has eight types ^[9]. Selected Data is the stage with no event of its own ^[20]. The fields it would carry, finance_revenue.recognized_amount and customer.country_code, show up in the aggregate object and in the semantic query plan, which also holds the SUM aggregation and the country_code = DE filter ^[11][18].

The relationship path is the piece I would instrument first. The example stores path_id rp_4821 over four nodes: customer, account, sales_order and finance_revenue. Each edge is tagged status trusted ^[13]. The object's path field writes the same walk as three hops ^[12][21]. The post gives the reason for keeping this out of the SQL: "Because the relationship decision is a reasoning artifact. SQL is only its execution representation." ^[14] It adds that when an answer is inflated by fanout, the path is often the first artifact to inspect ^[15].

Ambiguity gets stored instead of silently resolved: the metric arrives with status ambiguous and candidates recognized_revenue and invoice_amount ^[16]. The stated reason is blunt. "Otherwise engineers may blame SQL for what was actually an intent-resolution failure," the post says ^[17]. Anyone who has bisected a revenue discrepancy will recognise the pattern.

The post does not include measured failure rates ^[23]. Its argument is a single sentence: "The SQL can be valid while encoding the wrong business meaning." ^[3] So the case for eight events rests on which disputes you actually get. If yours are about what revenue means, the intent and semantic blocks are where the answer sits ^[2][4]. If they are timeouts and stale partitions, execution status already covers it ^[1].