AI Usage-Quota Consumption Timing Integrity Automation: Billed Before It Happened

Charging for a unit of usage makes sense only once the specific thing being metered has genuinely occurred, or is guaranteed to occur as a direct consequence of the charge. The moment a metering step runs earlier than that — before a decision is made, before an identifier is confirmed valid — it necessarily also counts every case where the underlying work never actually happens: a request that gets rejected, redirected, or fails validation still gets charged, purely because charging happened first and the actual outcome was discovered second.

Writing the usage-consumption call at the very start of a request handler is often the simplest possible structure — it reads as "make sure they haven't hit their limit, then do the work," which sounds like the correct order at a glance. The problem only becomes visible once you separately ask a second question: does every code path that reaches this point definitely result in the metered work happening? When the honest answer is no — some paths reject the request, redirect it elsewhere, or fail a downstream check — the charge has already been applied to all of them regardless, and that gap tends to stay invisible because the charge itself never produces an error; it simply produces a slightly smaller remaining quota than the customer's real usage would justify.

This was found during the same pre-launch certification audit that identified the CRITICAL conversation-ownership gap and the HIGH-severity dual-approval defect covered on this pillar's companion pages — the review specifically traced not just whether a feature worked, but exactly when each metering call fired relative to the work it represented.

In the AI chat function, usage was being consumed as an early step, before the system had done any of the work of deciding how to handle the question — including the genuine possibility that no AI model would be called at all, because the question was outside the module's scope, needed to be routed to a human tax professional, or was answered with a clarifying follow-up question instead of a model call. Every one of those non-model outcomes had still been charged the same as a fully-answered question. The fix moves the quota-consumption call to after that determination is made, so quota is only spent on a question that genuinely reaches a model.

In the document-reading function, usage was being consumed before the system confirmed the requested document actually existed and belonged to the requester — a check enforced by the database's own row-level security when the read happens under the requesting user's own access, not the backend's elevated one. A wrong or someone else's document identifier would consume a unit of quota and return only a not-found response — charging for a document that was never actually read. The fix moves quota consumption to after that existence-and-ownership confirmation succeeds, and separately makes the charge idempotent by the document's own identifier, so deliberately re-reading the same already-processed document — a legitimate part of reprocessing a failed extraction — doesn't consume quota a second time.

A third, related defect lived in the same chat function's own duplicate-charge protection. The mechanism meant to stop an accidental double-charge — a double-click, a retried network request — built its uniqueness key using the exact current time, precise to well under a second. Two calls arriving a few milliseconds apart, which is exactly what an accidental double-click produces, generated two different keys and were treated, and billed, as two entirely separate questions. The fix rebuilds that key around a ten-second time window instead of an exact instant: two calls landing inside the same ten-second window are recognized as the same attempt and charged once, while a genuinely new question asked more than ten seconds later — even about the same topic — is correctly treated and charged as new.

Someone asks the Income Tax AI chat a question that turns out to be outside the module's scope and gets routed to a human tax professional instead of an AI-generated answer. Before the fix, that question would still have consumed a unit of the organization's monthly quota, identical to a question the AI genuinely answered. After the fix, quota is only consumed once the system has determined a model will actually be called — a question redirected before that point costs nothing.

An organization's AI usage quota for the Income Tax module now reflects genuine, completed work — questions actually answered by a model, documents actually read and processed — rather than every attempt regardless of outcome. A rejected request, an invalid document reference, or an accidental double-click no longer erodes a limited monthly allotment for work that never happened.

This fix corrects WHEN usage is charged relative to the work it represents — it does not change the underlying plan limits or pricing themselves, which remain a separate, published commercial decision. It also covers the specific AI chat and document-reading paths of the Income Tax module; usage metering in other Centriu Gauge features or other modules is governed by its own, independently verified logic.

Metering usage at the earliest possible point in a request is simple to write and looks correct at a glance, but it silently bills every downstream rejection, redirection, or invalid reference the same as a fully completed unit of work. Centriu Gauge's fix moves each charge to the specific point where the metered work is confirmed to be genuinely happening — after the engine's own routing decision, after ownership is confirmed under row-level security — so the meter reflects outcomes, not attempts.