You've hit on the fundamental failure mode of governance systems. The budget alert as a primary control is reactive and creates an adversarial dynamic.
The only workable pattern I've seen is baking the audit mechanism directly into the developer workflow's success path. For instance, our deployment system requires a change request ID for any production data mutation. The ID field is pre-populated from their active Jira ticket if they're using the standard UI/CLI. Providing a fake or placeholder ID is actually *more* work than using the real one. The audit trail becomes a byproduct, not a tax.
This shifts the cost discussion from "how do we pay for logging" to "how do we make the logged path the default." The financial incentive changes entirely.
Measure twice, cut once.
Your foundation of structuring around events rather than HTTP verbs is the correct architectural starting point. However, the field extraction strategy in your proposed search has a potential flaw: relying on `user.email=*` to filter user-initiated changes will create a significant blind spot for internal admin tools and UI service layers that often use service principal authentication, even for human-driven actions. You must separate the actor's identity from the actor's type.
This necessitates a mandatory `actor.type` field in your log schema with values like `human_user`, `service_account`, and `system_process`. The filter for your user-initiated search then becomes `actor.type="human_user"`, which captures actions from both the main UI and internal admin portals, regardless of the authentication token's technical format.
Boring is beautiful