The audit trail as a source of economic truth

Once every operation is traced, the nature of the audit trail changes. It is no longer merely a security mechanism designed to answer 'who did what?' after an incident; it becomes a source of economic truth.

A single source of truth

This idea is compelling because it avoids the need to reconstruct usage patterns from disparate sources: application logs, infrastructure metrics, cloud provider invoices, and team declarations. A consistent history of actions allows for the linking of three elements that are typically separate:

• an identity;
• an operation;
• resource consumption.

An export can thus be associated with the actual volume transferred. A restoration, with the number of objects read and rewritten. A copy, with the requests and additional space it mobilises. An accumulation of versions, with the long-term retention cost it generates.

The platform then does more than simply measure stock; it describes behaviour.

From audit trail to economic ledger

A standard audit trail preserves events: creation, consultation, modification, movement, export, or deletion. To become actionable within an ABC logic, each event must also be translatable into economic units.

This translation does not require the exact cost to be recorded at the moment of the action. Rather, it requires that the event contains sufficient information to enable subsequent calculation:

• the user or service originating the action;
• the date and context of the operation;
• the type of action performed;
• the number and size of the objects concerned;
• the reads, writes or transfers triggered;
• the storage class and retention period;
• any secondary operations generated by the system.

Costs can then be recalculated based on a pricing grid, even if that grid evolves. The audit trail remains factual; the valuation model remains adaptable.

This separation is important. It prevents confusing technical truth — what actually happened — with an accounting convention — how the organisation chooses to value that event.

Measuring behaviours rather than assigning blame

Attributing costs to individual users presents an obvious risk: transforming a tool for understanding into an instrument of individual surveillance. This would be as much a management error as a cultural one.

A high cost is not necessarily indicative of poor behaviour. It may reveal intense activity, a critical function or a legitimate but expensive process. A team responsible for regularly restoring files, producing regulatory exports or analysing large volumes will naturally have a larger footprint.

Measurement therefore only has value if it is placed back into its context. It must make it possible to distinguish between:

• necessary consumption and avoidable consumption;
• heavy business usage resulting from misconfigured automation;
• a temporary spike versus a sustained drift;
• the cost of an individual versus the cost of the process they execute;
• an individual anomaly versus a collective design flaw.

The objective is not to ask why a user 'costs too much', but why an activity consumes so many resources and whether this consumption produces proportionate value.

This nuance determines the acceptability of the system. Without it, transparency breeds mistrust. With it, transparency becomes a basis for dialogue between business units, finance, and technical teams.

Revealing invisible costs

The most immediate value of activity-based accounting often lies in the costs it makes visible.

Take, for example, a process that exports an entire document repository every night even though only a few files have changed. From a capacity metric perspective, this behaviour is invisible: the stored volume remains stable. From an activity perspective, it immediately appears as a repetition of reads and transfers unrelated to the volume actually modified.

The same phenomenon can occur with:

• full restores triggered to recover a single item;
• copies used instead of references or links;
• scripts that continuously query unchanged files;
• versioning policies without appropriate limits;
• redundant synchronisations between buckets;
• massive downloads followed by nearly identical re-imports.

These usage patterns are not necessarily erroneous. They are sometimes the logical consequence of tools that do not make their cost perceptible. When a user sees no difference between viewing a file and exporting several terabytes, they have no signal to allow them to adapt their behaviour.

The audit trail can provide this signal without immediately imposing restrictions.

From chargeback to operational steering

Internal chargeback is one possible use case, but it is probably not the most valuable.

A behavioural source of truth primarily enables the construction of operational indicators: average cost of a restoration, cost of an export, volume of data read without modification, growth of inactive versions, or the monthly cost of an automated process.

These indicators pave the way for more precise decisions:

• correcting a recurring process before purchasing additional capacity;
• moving certain data to a lower-cost storage class;
• limit a specific operation without reducing the overall quota;
• bill an internal service based on its actual usage;
• compare the cost of two processes producing the same result;
• measure the savings achieved following an optimisation.

The question is no longer simply 'how much have we spent?', but 'which activities explain this expenditure and where can we take action?'.

This is where the audit trail truly becomes a management tool.

Building understandable unit costs

To be useful, the model must remain legible. An exact reproduction of every cloud billing line may yield a technically accurate result, but one that is impossible to interpret.

It is often preferable to define a few stable economic units:

These units can be expressed as actual cost, estimated cost, or as an internal index. The essential requirement is that they remain consistent, explainable, and comparable over time.

A robust estimation is often more valuable than illusory precision. If the model becomes incomprehensible, users will debate the calculation rather than the behaviours it reveals.

Technical truth alone is not enough

Even if complete, an audit trail does not automatically constitute a management truth. It describes events observed by the system, but their interpretation depends on organisational rules.

Who should bear the cost of a restoration requested by the legal department but executed by the IT team? To whom should an export triggered by a technical account on behalf of several departments be attributed? How should the cost of a shared file be split between its owner, its readers, and the project to which it belongs?

These questions cannot be resolved by instrumentation alone. They require documented attribution conventions. A credible approach must therefore distinguish between at least three levels:

• 1. The technical event: what happened.
• 2. Functional attribution: for which user, project, or cost centre.
• 3. Financial valuation: according to which rate and accounting rule.

This architecture makes the model auditable. It allows an attribution rule to be corrected or a rate to be updated without rewriting the technical history.

Trust as a prerequisite for operation

A source of truth is only useful if the stakeholders trust it.

This trust relies less on computational sophistication than on a few fundamental properties: traceability, stability of rules, the ability to explain every amount, and the capacity to trace back to the events that produced it.

A user discovering an increase must be able to understand its origin. A financial manager must be able to verify the calculation method. A technical team must be able to distinguish human usage from automated operations. An administrator must not be able to silently modify history to make data align with an expected conclusion.

Immutability, reliable timestamping, and actor identity are therefore not merely security requirements; they are also conditions for accounting quality.

Start with visibility, not sanctions

The natural temptation is to quickly transform metrics into quotas, alerts, or chargebacks. However, an observation phase is indispensable.

Before using data for arbitration, it is necessary to verify:

• that events are correctly attributed;
• that technical accounts do not distort the analyses;
• that shared costs are handled equitably;
• that exceptional activities are identifiable;
• that users can contest or explain an anomaly;
• to ensure the model does not penalise the most critical missions.

Initial reports should therefore be used for learning: which behaviours actually exist, which operations drive costs, and which optimisations are possible without degrading service quality.

Only after this period can the data support budgets, thresholds, or recharge mechanisms.

Steering without blind reduction

Raw capacity remains an important metric. However, it reveals nothing about intent, usage frequency, or the value produced.

By linking costs to activities, an organisation can avoid one-size-fits-all decisions: reducing all quotas, shortening all retention periods, or banning restores beyond a certain threshold. It can target the specific behaviour generating the expense while preserving useful usage.

This is the primary advantage of an event-based source of truth: making costs explainable, responsibilities debatable, and decisions reversible.

The audit trail then ceases to be an archive consulted only when problems arise. It becomes a daily instrument for understanding usage, budgetary dialogue, and process improvement.

The initial question — 'how many bytes?' — does not disappear. It simply finds its rightful place among more important questions: who is using the resources, for what purpose, how often, and with what result?

Going further

Going further:

Read the Challenges article on KARL →

Discover KARL →