Skip to content

Integrate with your stack

ORF is implementation-agnostic. Reuse approved application, security, observability, and data platforms when they can preserve ORF meaning, correlation, protection, and evidence quality.

Capability map

Platform capability ORF use
Application logging structured request, error, timeout, change, security, and governance events
Distributed tracing query–task–model–retrieval–tool–service relationships
Metrics backend rates, latency, availability, resource use, cost, drift, evaluation results
Security monitoring/SIEM policy, privacy, credential, permission, abuse, and incident signals
LLM/agent observability prompt/model/tool/retrieval views and evaluation workflows
Data/evaluation platform labelled samples, baselines, segment analysis, scheduled evaluation
GRC or delivery tracker obligations, waivers, ownership, evidence, review dates

No one tool needs to contain all evidence. The investigation experience does need stable links across tools.

OpenTelemetry integration

Use standard spans for HTTP, RPC, database, messaging, and infrastructure calls. Use the current OpenTelemetry GenAI attributes where they fit the chosen SDK and record the semantic-convention version in the telemetry design.

Add an organisation namespace only for attributes that are not covered, for example:

orf.session.id
orf.query.id
orf.task.id
orf.policy.version
orf.data.classification
orf.human_review.decision

Avoid placing large or sensitive content in span attributes. Prefer linked events or a restricted evidence reference because spans are often widely accessible and heavily indexed.

Structured logging integration

  • emit JSON or another schema-enforced structured format;
  • use UTC timestamps with sufficient precision;
  • include event and schema versions;
  • log stable IDs instead of mutable display names;
  • allowlist fields for tool parameters and results;
  • centralise redaction libraries and test them with adversarial values;
  • separate human-readable messages from machine-queryable fields; and
  • prevent multi-line content from breaking record boundaries.

Metrics integration

Control cardinality. Do not use raw user, session, prompt, document, or trace IDs as metric labels. Keep high-cardinality identifiers in logs or traces and expose bounded dimensions such as service, model version, tool, outcome, policy category, environment, and approved user segment.

Publish numerator, denominator, coverage, and sample size alongside derived rates. Version metric calculations so trend discontinuities can be explained.

Security integration

Route security-relevant ORF events to the established security workflow:

  • prompt injection or abuse detections;
  • privacy/classified leakage;
  • unauthorised privileged tool attempts;
  • role, permission, token, and credential events;
  • mutable or missing audit evidence; and
  • repeated policy-control bypass attempts.

Use security severity and incident taxonomy consistently. Keep the application trace link so responders can retrieve the surrounding AI context through an authorised path.

Evaluation integration

Build evaluation jobs from versioned samples, labels, prompts, models, retrieval indexes, and metric code. Record:

  • dataset and sampling version;
  • execution time and environment;
  • model, prompt, policy, and retrieval versions;
  • evaluator type and version;
  • human-review protocol where used;
  • metric outputs, denominators, uncertainty, and segments; and
  • release or remediation decision.

Environment strategy

Environment Main purpose
Development schema/unit tests using synthetic content; no copied production prompts by default
Staging end-to-end trace, redaction, alert, retention, and runbook tests
Production approved telemetry, strict access, loss monitoring, operating dashboards
Offline evaluation governed samples, reproducible metrics, restricted reviewer access

Integration acceptance

Confirm that:

  • correlation survives every service, queue, callback, and tool boundary;
  • clocks and timestamps are consistent enough to reconstruct order;
  • duplicate events are identifiable;
  • pipeline retries do not inflate business metrics;
  • redaction occurs before data reaches broadly accessible stores;
  • access and evidence export are audited;
  • retention and deletion work across every destination; and
  • the team can retrieve evidence without platform-administrator access.

Next: Tier 1 foundations