ARIA · getting started

How to create your log

ARIA inspects a recording of your AI system doing its job. If nobody has set that recording up yet, this page walks you through making one - start to finish, no prior tracing experience assumed. Pick your setup below and follow the steps; each option gives you a complete file to copy, not a fragment to assemble. The field-by-field reference is at the bottom if you need it, and this page is safe to forward to whoever runs the system.

Pick your setup

Choose whichever line below is closest to what you already run, then follow the steps in order. Each one ends with a file you can upload.

OpenTelemetry Collector

You already send OTLP, or can. The cleanest route - no application code changes.

ARIA reads this as: otel_json

Save the config below as otel-collector.yaml on the machine that will collect traces.
Create the output folder: mkdir -p /var/log/aria.
Start the collector: otelcol --config otel-collector.yaml (or add the config to your existing collector's exporters and service.pipelines.traces).
Point your application's OTLP endpoint at this collector - http://<collector-host>:4318 for HTTP, :4317 for gRPC.
Run your AI system normally for a representative period. An hour of real traffic beats a day of idling; aim for at least 20–30 complete requests.
Stop the collector, then upload /var/log/aria/traces.json. Done: the file should be a few hundred KB and each line should start with {"resourceSpans".

otel-collector.yamlyaml

# ARIA-ready OpenTelemetry Collector config.
# Point your app's OTLP exporter at this collector, run it for a representative
# period, then upload the file it writes.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 5s

exporters:
  # Writes OTLP JSON, one record per line - exactly what ARIA reads.
  file:
    path: /var/log/aria/traces.json

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [file]

Done when you have a single file on disk covering a stretch of real traffic. Upload it on the New scan page - ARIA tells you which format it recognised before it runs anything.

Tell us what you have

None of the setups above match what you run? Tell us, in whatever words you have. We read every one of these and we add formats based on them.

Will my log be enough?

A thinner log still produces a report - it just produces a thinner one. Here is what each chapter reads, so you can tell in advance which parts will be strong.

What each report chapter needs from your log
Chapter	What it needs
EU AI Act	Span identity and timing, status, and - for the disclosure and prohibited-practice rules - prompt/response text. Several rules also need documents ARIA cannot read from a log; those report as 'not assessable'.
Compliance	Span identity, service names, status and errors. Prompt/response text improves the privacy and oversight findings.
Agentic Patterns	Parent/child span relationships above all - the call graph is what patterns are read from. Tool names and errors sharpen it.
Prompt QA	Real prompt and response text. Without content capture this chapter has almost nothing to read.
Design	The call graph, model per step, and prompt text where available.
Financials	`gen_ai.request.model` and the token counts - without them spend cannot be sized at all. Add a `cost` field per call to have spend reported as measured rather than assumed.

What ARIA needs, and why

ARIA reads one thing: a file recording your AI system actually running - every request, every model call, every tool call. Each recorded step carries a handful of fields. The list below is every field ARIA looks for, in the order you should care about them.

Essential

Without these, the file cannot be read at all. Start here.

trace_id
What it is
An id shared by every step of one request.
Why it matters
Groups steps into a single conversation or task, which is how ARIA maps your system.
Without it
The file cannot be read at all.
span_id
What it is
A unique id for each individual step.
Why it matters
EU AI Act Article 12 requires each logged event to be individually identifiable.
Without it
The file cannot be read at all.
name
What it is
What the step was - e.g. chat, retrieve_docs, call_pricing_api.
Why it matters
Names are how the system map labels each component.
Without it
The file cannot be read at all.

Important

The file still reads, but whole chapters of the report get thinner.

start_time / end_time
What it is
When the step started and finished.
Why it matters
Temporal traceability - Article 12 needs each event placed in time.
Without it
Logging & Traceability rules cannot be assessed, and durations are unavailable.
parent_span_id
What it is
Which step called this one.
Why it matters
Turns a flat list into the actual call graph, so orchestration patterns are visible.
Without it
The Agentic Patterns chapter sees steps but not how they connect.
service.name
What it is
The name of the service or agent emitting the step.
Why it matters
ARIA groups a log into separate AI systems by this field, then asks which to scan.
Without it
Everything collapses into one unnamed system.
status
What it is
Whether the step succeeded or failed.
Why it matters
Outcome per event - several Article 12 and robustness rules read it directly.
Without it
Rules about failure behaviour drop to WATCH.
error / exception attributes
What it is
The error type and message when a step fails.
Why it matters
Article 12(2)(a) risk identification needs more than a bare failure flag.
Without it
Risk-monitoring rules are evaluated on partial evidence.
gen_ai.request.model
What it is
Which model served the step - e.g. claude-sonnet-5.
Why it matters
Model-task alignment and the whole Financials chapter key off it.
Without it
Financials cannot attribute spend; design rules cannot judge model fit.
gen_ai.usage.input_tokens / output_tokens
What it is
Tokens consumed by each model call.
Why it matters
Lets ARIA size your spend by pricing the tokens against published per-model rates.
Without it
Financials cannot size spend at all - the chapter reports that it had nothing to measure.
cost
What it is
What the call actually cost, if your provider or tracing tool reports it.
Why it matters
Turns assumed pricing into measured spend - Financials labels every figure as one or the other.
Without it
Cost is still computed from token counts, but marked ASSUMED rather than measured.
version / build id
What it is
A release or build identifier on the service.
Why it matters
Article 16 change-control rules check that a version reaches production telemetry.
Without it
Change-control rules drop to WATCH.

Unlocks more

Only needed for the chapters that read the actual prompt and response text.

Turn content capture on, or this stays empty

Most tracing tools deliberately leave prompt and response text out of exports. If you want the chapters that read real text, you have to switch content capture on - and you must be comfortable that the text is in the file you upload.

input_messages / output_message
What it is
The actual prompt sent and the response returned.
Why it matters
Prompt QA, the AI-disclosure checks and the prohibited-practice checks read real text.
Without it
Those rules report 'not assessable'. Everything else still works.

Got your file? Start a scan. Uploaded logs and generated reports are deleted automatically after 48 hours.