The full amount, at every level above it

Tag a line to a person and it counts in full for that person, for their department, for their division and for the corporation. The same money, looked at from further out — nothing is split and nothing is apportioned.

⛔ That is what removes the reconciliation step. A query at any level of any tree, over any period, is a plain sum of the lines beneath it. There is no roll-up job, no stored subtotal to go stale, and no need to mine anything: the answer is computed from the rows at the moment you ask.

One tag per tree

⛔ A line may carry at most one tag from each tree, and a second is refused. A person sits in one department, so a line tagged to two people in the same org tree would be counted twice by every ancestor — and that double is invisible, because the total still looks like money.

⚠ Different trees are different questions. Tagging a line to a person AND a project AND a client is expected: each dimension sees the whole amount, and two budgets across different trees legitimately add up to more than you spent, because they measure the same money two ways.

Setting, not adding — per tree

⛔ Naming a project tag replaces the project tag and leaves the org tag alone. Only the trees you name are rewritten. A version that cleared everything would silently drop classifications the caller never mentioned.

⚠ Naming no tags at all is not an untag — there is nothing to remove without a tree to remove it from. Untagging a dimension means naming a different tag in it.

Swapping a tag

⚠ Naming a different tag in a tree you already used swaps it, and the line's tag COUNT does not change. The count is only written when it would actually differ — the store refuses an update with no effective change, and that refusal would take the whole write down with it.

Limits

⛔ A tag that does not exist is refused, before anything is written. A row pointing at nothing is money that has left the tag view without leaving the accounts.

⚠ At most 30 tags on one line, and the whole change must fit in one transaction.

It needs FULL access at install

⛔ This recipe is DENIED if the pack was installed with write access — pick all. It drives a batch operation whose allow-list contains a delete (leg_tag.apply — replacing a tag means deleting the old row), and a batch's risk floor is the union of everything it may do, so the whole operation is classed destructive. write does not grant that.

⚠ The refusal is operation_not_granted at the gateway, which reads like a bug in the recipe rather than a scope you chose at install. It is not something the recipe can detect and explain for you — the denial happens before its first step runs.