An AI audit record should help a team explain what happened without quietly becoming a copy of everything a person submitted or received. Viotus’s public decisions make that design concrete. Its data-minimization guide requires one boundary chain—classify input as excluded, reduced or protected; choose local or a named controlled processing boundary; prohibit indiscriminate external-model training; then justify the minimum observation fields. Its least-privilege guide adds a real product distinction from Calculator and Valuator: deterministic calculations and structured data stay in controlled systems, while AI may organise information, explain a scenario or suggest exploration, without inheriting the financial engine’s authority. An audit event should preserve those decisions, not the prompt or response.
1. Name the questions before the fields
Start by listing the decisions the log must support. Did the intended capability run? Was it allowed to run against that target? How long did it take? Did it complete, refuse, time out or fail? Did the result pass its required validation? A field earns its place only when a named operator, reviewer or automated check uses it to answer one of those questions. “It might be useful later” is not a sufficient purpose.
This reverses a familiar logging habit. Instead of capturing a request and trying to redact it afterward, define the minimum evidence first. Review the log as its own data product, with a purpose and boundary distinct from the feature input. A careful observation layer cannot repair an AI feature that received unjustified data, but it can avoid creating a second exposure.
2. Build the smallest useful event record
Begin with the Viotus boundary chain, not a generic list of log fields. For a Calculator or Valuator explanation, record an input decision such as reduced, the named processing-boundary class, the permitted reuse purpose, and the observation-field justification. Then identify the bounded AI capability and version, time, duration and correlation reference. This sequence matters: a careful event cannot repair an unjustified input, and a controlled route cannot make open-ended reuse proportionate.
Add fields that preserve the product’s actual authority split: operation class (organise information, explain scenario or suggest exploration), deterministic-source reference, permission decision and validation outcome. Record whether the result was kept distinct from calculated output and professional judgement. Do not log the financial values, selected passage, prompt, generated explanation or provider error text. The resulting record is determined by Viotus’s public design: it can prove that controlled calculation remained authoritative while generated interpretation stayed bounded.
3. Preserve boundaries, not payloads
Consider a request to explain a Valuator scenario. The routine event can say that the explanation capability received a reduced, authorised scenario reference; ran inside the named controlled boundary; had no calculation or write authority; and returned generated interpretation that awaited human interpretation. If the target was outside the authorised class, record a permission rejection. Neither case needs the scenario’s financial values or the generated prose.
This is stronger than recording that a model answered politely. Viotus’s Calculator and Valuator boundary requires calculations, rules and structured data to remain in controlled systems and requires evidence to distinguish deterministic output, generated content and professional judgement. Those distinctions become audit fields because they answer a product-specific review question: did AI explain a controlled result, or did it appear to replace the engine or judgement?
4. Classify outcomes without echoing content
Define a small outcome vocabulary that matches the workflow: succeeded, rejected by permission, rejected by validation, invalid input, timed out or internal failure may be useful classes when those distinctions lead to different action. The exact set should follow the product’s operational needs. Avoid an unbounded error field in the routine record, because exception text can repeat a prompt, response, filename or other sensitive detail.
Separate system health from result acceptability. A provider call may complete while a deterministic validator rejects its result; conversely, an expected bounded refusal can be healthy behaviour. Record execution outcome and validation outcome independently so operators can distinguish transport, permission and quality problems without opening the underlying content.
5. Create an exceptional diagnostic path
Some faults cannot be diagnosed from routine metadata alone. Design that as a separate, deliberate path rather than gradually adding payloads to every event. Define the incident condition that can open it, the narrower collection required, the identity allowed to authorise and inspect it, and the point at which the material is removed. The routine path should remain useful when the exception is closed.
Before collecting deeper detail, ask whether a controlled reproduction, synthetic input or more specific metadata can answer the question. If content is genuinely required, exclude, reduce or protect it before collection where possible. The public Viotus guidance is clear that exceptional troubleshooting must not silently become ordinary retention. A named exception makes that boundary testable.
6. Test the schema as the feature changes
Test the schema against the same public decisions. For Calculator or Valuator, confirm that the event identifies the deterministic-source reference but contains no financial payload; that organise, explain and suggest are allowed operation classes while calculate, write and decide are unavailable; that an unapproved target becomes permission_rejected; and that generated interpretation is never labelled as calculated output or professional judgement. Also test that a provider failure cannot echo the selected passage through free-form error text.
A reviewer should be able to reconstruct the full Viotus boundary chain from the event: input was excluded, reduced or protected; processing used local or a named controlled boundary; reuse stayed within its specific purpose without indiscriminate external training; observation retained only justified fields; and the least-privilege authority split held. The reviewer should not be able to reconstruct the user’s prompt, scenario values or generated response. That is a Viotus-determined audit method, not a generic logging checklist.