Skip to content
BitExactproduct

Guided demo · one loan decision

One decision, proven, traced to its cause and fixed.

This is the case the story on bitexact.ai tells: loan application APP-7731, declined by an underwriting agent. Every view below is the BitExact inspector's own screen, captured from the recorded run. The model is a local stand-in with seeded answers, so the case records the same way every time.

Walk through the case Verify it yourself
SEALED loan-APP-7731 · 9 entries · sealed and signed

One recorded run

An underwriting agent decides an application. Then someone asks why.

Four steps, each with the view the inspector showed for this run.

  1. 01

    The agent declines the application.

    The agent pulls the application, a credit report and the policy, asks the model, and answers decline: The credit score of 512 is below the 620 minimum.

    BitExact records each of those calls as it happens, and the agent's decision record beside them: an automated adverse action, reason code SCORE_BELOW_MIN, with a retention date committed to the chain.

    The inspector's decision record for the run: an adverse action, solely automated, principal reason SCORE_BELOW_MIN, and the default purge date.
    loan-APP-7731 · the decision record
  2. 02

    The record is intact, sealed and signed.

    Unchanged · sealed · signed

    Nothing recorded has been changed or removed, the run is sealed so steps lost from its end would show, and it is signed by the deployment's recorder key. What the record does not claim is stated on it: that this is every call the agent made.

    The inspector's integrity summary: intact, sealed and signed, unchanged, sealed, signed by the recorder key, and not claimed to be every call.
    loan-APP-7731 · the run's integrity
  3. 03

    The score belonged to someone else.

    Step 4 · pull_credit_report

    Asked for APP-7731, the credit-report tool returned the report of APP-7713, score 512. The bureau mirror holds no file for this applicant yet, so the tool returned the file with the nearest number. The model applied the policy exactly, to the wrong person's score.

    Step 4, the credit-report tool's result: applicant_id APP-7713, score 512, as of 2026-10-30.
    loan-APP-7731 · step 4 · the tool's result
  4. 04

    Fork at that step with the fix, and compare.

    With pull_credit_report matches the applicant exactly, the recorded run is forked at step 4 and re-run live from there. The fork answers refer: The bureau mirror holds no report for APP-7731, so there is no score to apply the policy to; request a fresh bureau pull. The fork is marked synthetic and linked to its source, so it can never pass for what production did.

    Was the decline a fluke? Forked 20 times at the same step:

    • as it was: 19 decline, 1 refer
    • with the fix: 20 refer
    The fork compared to its source: the adverse-action flag changed from yes to no, and the reason code SCORE_BELOW_MIN removed.
    loan-APP-7731-candidate · compared to its source

Verify it yourself

You do not have to take our word for it.

The verifier is a standalone Apache-2.0 tool: the Python standard library plus cryptography and asn1crypto, none of our product code. Whoever is asking runs it on the exported bundle and re-derives every hash and signature themselves, with no BitExact license and no network.

$ python bitexact_verifier.py golden-run.bundle.json --trust-file trust.json --expect-witness witness.example=bcd33f91b6ed…
OK: golden-run - 4 steps (observed 4 / asserted 0 / synthetic 0), chain verified, sealed, signed, recorder-attested, in transparency log bitexact.log/eb0180bca503ff76 (leaf 3 of 66), witnessed by 1 of 1 pinned (1 with ML-DSA-44, post-quantum), signatures: Ed25519 + ML-DSA-65 (post-quantum), post-quantum key pinned
standing when recorded: ok (stated by the producer, not proof)
captured via sdk-python 3, unlabeled 1 (attribution, not proof)
$ echo $?
0

$ python bitexact_verifier.py golden-run.tampered.bundle.json --trust-file trust.json --expect-witness witness.example=bcd33f91b6ed…
FAIL: step 1: data hash mismatch at path result.temp - value tampered or corrupted
$ echo $?
2
The same bytes give the same answer on anyone's machine. Feed the tool a bundle that was corrupted in transit or altered by anyone at all, and it stops at the exact step and field and exits 2. Every line above is the verifier's own output, run on its published test vectors when this page was built; the second bundle is the first with one recorded value changed. Get it at bitexact.org.

How it fits

Evidence beside the stack you already run.

Your observability tools stay where they are. BitExact wraps the interfaces your agents already use. This is how the agent in this case was recorded:

def main():
    client = OpenAI()
    with bitexact.run("loan-APP-7731", workflow="loan-adjudication",
                      workflow_instance="APP-7731", environment="demo",
                      principal="svc:underwriter") as r:
        client = wrap_openai(client, r)
        result = decide(client, "APP-7731")
        record_outcome(r, result)

Plugs into your stack

LangChain, LangGraph, LangSmith, OpenTelemetry, or raw Python. Wrap the client and the tools; the agent code doesn't change.

Stays in your network

Self-hosted, no phone-home. The license is an offline-validated signed file, with no code path that could call out.

Speaks compliance

Automatic, tamper-evident capture for EU AI Act Art. 12; decision records carry reason codes and a retention deadline. The mapping to each regime, with its limits, is on the compliance page.

Next step

Run it on your own traffic.

A design-partner pilot is a full production deployment recording real traffic, with direct engineering support, under a fixed-term license. Continue and the pilot fee is credited in full against your first annual license.

Talk to the team How licensing works Read the docs