Exactly — and "decision receipt" is the better name. A log answers what happened. A receipt answers was this admissible, by which rule, at the moment it crossed into execution — and only the gate that made the allow/deny call can emit that, because it's the one thing holding the inputs, the active policy, and the verdict at decision time.

Post-hoc reconstruction can't recover that even in principle: the policy may have changed since, and the counterfactual ("checked against rule X v3, denied") was never captured unless something recorded it at the boundary. Your field list is the right schema — inputs observed, rule applied, authority boundary, allow/deny, accountable gate.

That maps almost 1:1 onto what a PreToolUse gate can write per decision (rule + version, timestamp, verdict, reviewer path). The two I'd push to make first-class are the two you named that systems usually drop: the explicit authority boundary and a named accountable gate — not just "denied," but "denied by gate G under boundary B." Those are the fields a reviewer always wishes existed six weeks later.

Are you building toward this? I'd genuinely like to compare notes on the receipt schema.

Yes, partly in nxusKit SDK, though I think the pattern matters independently of any one implementation. The key constraint, to me, is that the receipt has to be emitted by the boundary component, not reconstructed later by the agent that wanted the tool call. I’d separate observed facts, requested action, policy/rule id + version, authority boundary, gate identity, verdict, reviewer/escalation path, and the repair/appeal packet if denied. The hard part is keeping it small enough to emit on every consequential action while still being useful six weeks later. I’d be glad to compare notes on the schema.