FinOps Tag Reports: Count Policy Tags Without Faking Coverage
A tag report is only honest if it can tell a tag someone accepted from a tag a policy merely inferred. ZopNight’s Reports → Tags now counts policy-derived values that nobody has accepted yet, and shows them apart from everything else.
Until now, tags such as Application or Owner that came from a tagging policy reached cost reports only after someone accepted them on each resource. A resource the policy could already name stayed unnamed in the report until a person clicked.
The separate-band rule is simple: inferred tag values are counted next to accepted ones but never blended into them. A rising coverage number therefore always shows how much of it is inference. Each section below is one place that rule is enforced.
A Source Filter Widens the Count Only When You Ask
On Reports → Tags, the Source filter has a new option: Policy (not accepted). Select it and the chart, the pair count and the table also count these values. Each carries a dotted policy badge, and the Tag Coverage card shows them as a separate band.
The default view and its numbers do not change. A report you already send keeps producing the same figures until someone chooses the wider source.
| Surface | With Policy (not accepted) selected |
|---|---|
| Chart | Also counts policy values |
| Pair count | Also counts policy values |
| Table | Policy values appear with a dotted policy badge |
| Tag Coverage card | Policy values form their own band |
Precedence Decides Which Value Counts
The daily build writes a derived row only for a key that no other source already covers. The order is cloud tag, then inherited tag, then accepted tag, then policy-derived tag. A policy value can therefore never override one that the cloud or a person already set.
This works when the policy has already run. Derived rows appear after the next daily tag build, so a policy created this morning adds nothing to the wider view until that build completes.
A Rebuild Has to Be Able to Remove Values
The daily build also writes a zero-cost placeholder row, named __none__, for each day that has data. The placeholder matters because a rebuild that finds no derived values for a day still has something to write. That write replaces the old derived rows instead of leaving yesterday’s values behind.
These rows sit in the same daily table that feeds cost allocation by tag key. Derived rows are pruned and replaced together with the ordinary tag rows. The two sets are rewritten in one pass, so they cannot drift apart between builds.
The Default Read Stays Byte-for-Byte the Same
Reads take a tagScope of accepted or all. With accepted, the default, the SQL is byte-identical to before and is still served from the rollup. With all, the filter widens to both kinds of tag row, and a semi-join keeps one build per organization per date so a day is never counted twice.
The pre-aggregated rollup refuses the wider scope, so that view is read from the underlying rows. That is the price of the wider count, and it is why the default stays narrow.
The parameter exists on the tag report endpoints, and the MCP tag tools take an optional tag_scope, so an assistant can ask for the same wider view. There is no migration and no new table or column. Rolling back is a revert, and any leftover derived rows are ignored by accepted-scope reads.
