AIBAI Behavioral Provenance EngineEngineering case study
PUBLIC · AI PROVENANCE

AI Behavioral Provenance Engine

A vendor-neutral runtime evidence system for making AI, LLM and agent behavior changes inspectable without treating correlation as causation.

Publicv0.2 AlphaReference implementationApache-2.0

The problem

Why this project exists

AI systems change because prompts, models, retrieval, memory, tools, policies and environments change. AIBPE makes those dependencies and the resulting behavioral evidence explicit.

Verified capabilities

What is actually implemented

These capability descriptions are intentionally limited to the evidence-backed implementation surface.

01

Evidence capture

Canonical event envelopes, hashing and dependency metadata make runtime observations comparable.

02

Behavioral provenance

Run manifests and behavioral fingerprints support structural comparison across runs.

03

Controlled intervention

Intervention execution and trajectory comparison provide evidence for controlled changes.

04

Boundary capture

OpenAI-compatible HTTP and MCP-style recorder paths capture important runtime boundaries.

05

Runtime explorer

SQLite indexing plus an optional FastAPI/browser explorer expose recorded evidence.

06

Verification

Schemas, examples, tests and CI provide executable evidence for the reference implementation.

Architecture

How the system is structured

The diagram below represents the current verified architecture boundary; planned or environment-dependent components are described in the engineering notes rather than silently promoted.

AI / Agent Runtime
↓
AIBPE Recorder
↓
Behavioral Provenance
↓
Intervention
↓
Evidence Artifact
↓
Explorer
BOUNDARY

Evidence and authority

Canonical event structures replace free-form logs as the comparison surface.

Production hardening still requires authentication, encryption, retention, multi-tenancy and trust-boundary signing.

Engineering deep dive

Decisions, trade-offs and boundaries

Technology names matter less than the engineering contracts they enforce.

E1

Canonical event structures replace free-form logs as the comparison surface.

E2

Model/version, prompts, retrieval, memory, tools, policy and environment remain explicit dependencies.

E3

Model-generated explanations are not promoted to causal facts.

E4

Production hardening still requires authentication, encryption, retention, multi-tenancy and trust-boundary signing.

Deployment paths

Public demonstration stays separate from customer production.

The portfolio exposes a read-only synthetic cloud explorer for the open-source runtime. Customer deployments are provisioned only after a request, with their own storage, authentication, retention and observability boundary.

Project status

Public · evidence-backed status

v0.2 Alpha reference implementation; implemented evidence capture, provenance, interventions and explorer surfaces are verified.

ClassificationPublic implementation
EvidenceRepository implementation, tests and project records cross-checked
ClaimsCurrent, planned and limitations kept separate
DeploymentNot changed by portfolio integration
PUBLIC IMPLEMENTATION

Inspect the implementation directly.

Public implementation — source can be inspected directly.