An accountability trail for AI decisions

---

---

Splitting it this way also makes the record harder to tamper with. If the app that makes the decisions also owned the record of them, nothing would stop it from quietly editing that record later. Since the record lives in Langfuse instead, the app can write a decision but can’t go back and change it. An auditor doesn’t have to take the app’s word for anything.

What you end up with is one record per decision. It holds information auditors need: what was decided, on what basis, which model produced it, whether it was flagged for review, and if so, what the reviewer concluded. The decision might be a benefits case in a government program, a loan approval, or a content takedown. Either way, there is now one place to look.

How a decision moves through the tool

Here is how a decision travels from an app’s code into Langfuse, and then to a reviewer.

Marking a decision in code. A developer marks the decision point in their own code. This has to be deliberate, because the tool can’t work out on its own which of an app’s many model calls are the ones that actually decide something about a person. The developer wraps the decision in a context manager or a decorator and fills in what the raw model call can’t know: the type of decision, an anonymous id for the person it concerns, and the options on the table. The outcome is recorded once it’s known. The layer captures everything else on its own: the model, its version, how long the call took, and a confidence signal if there is one.

In practice, marking a decision looks like this:

import ai_flight_recorder

with ai_flight_recorder.decision(
    decision_type="loan_eligibility",
    subject_ref="cust_1001",       # an opaque id, not raw personal information
    options=["approve", "deny"],
) as d:
    resp = d.completion(
        model="gpt-4o-mini",
        messages=[
            {
                "role": "system",
                "content": (
                    "You are a loan underwriting assistant. Review the application "
                    "and respond with exactly one word: approve or deny."
                ),
            },
            {
                "role": "user",
                "content": (
                    "Applicant: John Smith\n"
                    "Annual income: $42,000\n"
                    "Requested loan amount: $35,000\n"
                    "Purpose: home renovation\n"
                    "Credit score: 640\n"
                    "Existing monthly debt payments: $1,100\n\n"
                    "The requested amount is high relative to income, but there have "
                    "been no missed payments in the last three years. Approve or deny "
                    "this application?"
                ),
            },
        ],
        logprobs=True,
    )

print(d.emit_result.trace_id)

Running the bundled example against a local Langfuse instance produces a decision and prints the trace id it was recorded under:

The pipeline. Once the block finishes without error, the decision runs through a fixed set of steps before it reaches Langfuse. The rule engine checks it and redacts any personal data, a hash is taken, the record is written to Langfuse, and if the decision was flagged it goes into a review queue.

Deciding what needs review. The rule engine runs first, because we need to know whether a decision needs review before the record is finalized. Its job is to point a human’s attention at the right decisions. It doesn’t judge whether a decision was good; that is the reviewer’s job. It looks at the finished record and flags the ones worth a human’s time, for reasons a governance reviewer would recognize:

Rule	Fires when
Low confidence	The recorded confidence signal is below a configured threshold
High-stakes type	The decision type is one the organization has marked as consequential
Sensitive outcome	The outcome is one the organization has marked as sensitive, such as a denial
PII in inputs	The prompt contained personal information

When a rule fires, it records why. Any fired rule marks the decision for review. The organization sets the thresholds and picks which decision types and outcomes count as sensitive.

The other rules only flag; the personal-data rule can also act on what it finds. When it detects personal data in a prompt, it replaces each piece with a labelled placeholder before the record is stored, so the record never becomes a store of raw personal data, which would be its own problem. Detection is pluggable: a simple pattern-based detector ships by default, and a stronger one built on Microsoft’s Presidio is available if you want it.

Sealing the record with a hash. Next we take a short fingerprint of the record, which proves it hasn’t been changed. We compute it after redaction, so it matches what actually gets stored rather than an earlier version that still held personal data. The fingerprint covers the AI’s decision and nothing more. The reviewer’s verdict is added later, in Langfuse, so it isn’t part of the hash. That means the hash proves the decision itself wasn’t altered; who signed off on that decision rests within Langfuse’s own accounts and audit log.

Writing it into Langfuse. With the record sealed, it gets written to Langfuse. This is the trickiest part of our implementation. Langfuse has different places for different kinds of data, each with its own constraints, so we split the record across them deliberately rather than dumping all into one:

Part of the record	Where it goes	Why
Decision id and type, subject reference, integrity hash, flag names	Filtering fields (tags, propagated metadata)	Short and searchable, so a reviewer can find decisions by them
Prompt and outcome	Trace input and output	No size cap, so full text is safe
The “needs review” signal	Score	The mechanism Langfuse uses for evaluations attached to a trace
Confidence signal, full flag reasons, model version	Regular metadata	Detail worth keeping for the audit trail

Getting a flagged decision to a reviewer. A flagged decision only goes into the review queue after the record is safely stored, since a queue item has to point at a trace that already exists. Reviewers open the queue in Langfuse and work through the flagged decisions one at a time, marking each one approved, overridden, or escalated. Decisions that weren’t flagged stay recorded but never enter the queue, so they don’t take up a reviewer’s time. The queue step comes last on purpose: if it fails, the record still exists and a reviewer can find it the normal way. The record is the thing that must not be lost; the queue is only a convenience for getting a human to look.

What we noticed about the reviewer’s experience. Langfuse’s screens are built for developers debugging an app. The default trace view is packed with detail that helps an engineer and gets in the way of someone who just needs to approve or reject a decision. The review queue is better, since it shows one flagged item at a time with the review fields right there, but the content underneath is still a developer’s trace.

A developer can work with that screen. A non-technical reviewer struggles with it. The fix is a purpose-built review screen that pulls the flagged decisions out of Langfuse, shows only what matters for the call, and writes the verdict back, while Langfuse stays the system of record. We didn’t build that screen in this experiment. It is a separate design problem from the capture pipeline, and a working pipeline leaves it entirely open.

---