ƳƤ AI Agent Evaluation & Assurance Framework
Evidence-Bound TEVV for Agentic Systems
A provider-neutral quality-engineering framework for evaluating autonomous agents by observable outcomes, side effects, authority boundaries, approval intent, adversarial conditions, protocol state, authorization behavior, reliability, and reproducible evidence—not persuasive final prose.
Documentation · Architecture · Framework Surface · Evaluation Lifecycle · Evidence Hierarchy · OpenAI Adapter · Evidence & Replay · Security · Limitations
At a glance
| Surface | Framework contract |
|---|---|
| Subject under test | exact model/provider, instructions, orchestration, tools, authority, memory, adapter, and application revision |
| Terminal truth | deterministic policy, side-effect, outcome, reliability, and release logic derived from verified evidence |
| Provider/protocol integration | OpenAI Agents SDK plus deterministic MCP protocol/auth laboratories without transferring grading authority |
| Adversarial assurance | content-addressed attacks, controlled delivery preconditions, authority-preserving derivation, and replayable evidence |
| Evidence | ordered normalized events, typed receipts, content-addressed identities, local persistence verification, replay, and report rederivation |
| Semantic judging | calibrated and subordinate; may only preserve or narrow deterministic success |
| Release assurance | repeated trials, uncertainty-aware statistics, non-compensatory safety rules, and deterministic release gates |
Architecture
flowchart LR
accTitle: Evidence-bound agent evaluation architecture
accDescr: An evaluated agent system interacts with tools and protocols. Controlled adapters normalize observations into evidence. Deterministic evaluators verify preconditions, policy, side effects, outcomes, reliability, and release readiness. Semantic judging is subordinate and cannot rescue deterministic failure.
O[Evaluation objective]
subgraph SUBJECT[Evaluated subject · untrusted for grading authority]
direction TB
A[Agent runtime + model]
T[Tools + application state]
H[Handoffs + approvals + memory]
end
subgraph INTEGRATIONS[Observed integration boundaries]
direction TB
OA[OpenAI Agents SDK]
MCP[MCP protocol + auth labs]
end
subgraph CONTROL[Trusted evaluation control plane]
direction LR
C[Scenario + authority contracts]
D[Controlled delivery + adapters]
E[Evidence + typed receipts]
V[Deterministic verification]
S[Subordinate semantic judging]
R[Reliability + release gate]
end
O --> C
C --> A
A <--> T
A <--> H
A <--> OA
OA <--> MCP
T --> D
H --> D
OA --> D
MCP --> D
D --> E
E --> V
V -->|deterministic closure| S
V -->|failure / blocked| R
S -->|may narrow success| R
classDef neutral fill:#f6f8fa,stroke:#57606a,color:#24292f,stroke-width:1.5px
classDef advisory fill:#fbefff,stroke:#8250df,color:#24292f,stroke-width:2px
classDef authority fill:#ddf4ff,stroke:#0969da,color:#24292f,stroke-width:2px
classDef evidence fill:#dafbe1,stroke:#1a7f37,color:#24292f,stroke-width:2px
classDef untrusted fill:#ffebe9,stroke:#cf222e,color:#24292f,stroke-width:2px,stroke-dasharray:5 3
classDef terminal fill:#dafbe1,stroke:#1a7f37,color:#24292f,stroke-width:3px
class O neutral
class A,T,H untrusted
class OA,MCP advisory
class C,D,V authority
class E evidence
class S advisory
class R terminal
style SUBJECT stroke:#cf222e,stroke-width:2px,stroke-dasharray:6 4
style INTEGRATIONS stroke:#8250df,stroke-width:2px,stroke-dasharray:6 4
style CONTROL stroke:#0969da,stroke-width:2px,stroke-dasharray:6 4
linkStyle default stroke:#57606a,stroke-width:1.5px
Diagram key: red dashed = evaluated/untrusted subject · purple = provider/protocol or semantic boundary · blue = deterministic evaluator authority · green = evidence and terminal release truth. Color is never the only signal.
The deeper trust model, identity domains, OpenAI/MCP bridges, authorization boundaries, replay semantics, and release authority live in Architecture.
Engineering thesis
Agents act. Evaluators observe. Evidence binds. Policy constrains. State proves. Replay regrades. Statistics quantify. Release gates decide.
The evaluated component must not be able to manufacture the authority or evidence that certifies its own success.
Core invariants
- Outcome before rhetoric: independently observed state outranks the agent's claim about state.
- Safety is non-compensatory: critical authorization or policy violations cannot be averaged away.
- Unknown is not green: missing or unverifiable evidence becomes
BLOCKED, not PASS. - Identity is canonical: behavior-bearing subject, scenario, attack, approval, retrieval, protocol, evidence, and report material participates in content-addressed identity.
- Delivery is a precondition: adversarial/protocol conditions are graded only after the required controlled relation is verified.
- Delegation never expands: valid handoff paths preserve or reduce effective authority.
- Approval is relational: evidence must bind the exact pending invocation and accepted authority context.
- Replay is historical: replay revalidates persisted evidence without pretending to rerun provider behavior or side effects.
- Semantic judging is subordinate: it may narrow deterministic success but never rescue deterministic failure.
- Release authority is deterministic: reliability and release decisions derive from verified trial evidence and explicit policy.
See Evaluation Lifecycle, Evaluation Model, and Evidence Hierarchy for the detailed grading/evidence flows moved out of this README.
Executable assurance surfaces
| Lane | What it establishes | Deep dive |
|---|---|---|
| Provider-neutral core | contracts, evidence, replay, deterministic oracles, statistics, reports, release gates | Framework Surface |
| OpenAI Agents SDK | normalized SDK behavior plus handoff, HITL, retrieval, side-effect, semantic-judge, and MCP bridge paths | OpenAI Adapter |
| MCP protocol/auth | official-client fault laboratories, resource-server authorization, OAuth flow, and agent bridges | MCP Lab · Remote Auth · OAuth Flow |
| Adversarial assurance | attack identity, delivery verification, authority-preserving derivation, fail-closed grading | Adversarial Testing |
| Evidence/replay | local evidence integrity, typed receipt verification, historical regrading, report rederivation | Evidence & Replay |
Quick start
The deterministic core runs without model credentials.
python -m venv .venv
source .venv/bin/activate
python -m pip install -e '.[dev]'
pytest
agent-evals doctor
Optional integration lanes are declared in pyproject.toml:
python -m pip install -e '.[dev,openai,mcp]'
Project manifests and repository-owned requirement files are authoritative for interpreter and dependency requirements; the README intentionally avoids duplicating executable version truth.
Documentation
Use the documentation hub for role-based review paths. Key entry points:
| Question | Document |
|---|---|
| Where does authority live? | Architecture |
| What is actually executable? | Framework Surface |
| How does a trial become a verdict? | Evaluation Lifecycle · Evaluation Model |
| What outranks what in the evidence chain? | Evidence Hierarchy |
| How are provider behavior and MCP boundaries normalized? | OpenAI Adapter · MCP Lab |
| How are handoffs/approvals/side effects/retrieval governed? | Handoff Authority · Approval Intent · Side-Effect Idempotency · Retrieval Assurance |
| How is evidence persisted/replayed? | Evidence & Replay · Assurance Reports |
| What is deliberately not claimed? | Security · Limitations |
Repository map
.github/
artifacts/
docs/
src/
tests/
Only top-level ownership boundaries are shown; individual files are documented in the technical pages.
Scope and non-claims
Local deterministic evidence does not by itself prove live-provider correctness, hosted MCP behavior, production IAM, human identity, external target state, distributed exactly-once execution, arbitrary cache coherence/schema migration, universal prompt-injection resistance, or cryptographic publisher attestation.
Those boundaries are intentional. See Security and Limitations.
License
MIT — see LICENSE.
Metadata
Release files for qa-automation-ai-agent-evals 0.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| qa_automation_ai_agent_evals-0.1.0.tar.gz | 1.2 MB | With provenance | Details for qa_automation_ai_agent_evals-0.1.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| qa_automation_ai_agent_evals-0.1.0-py3-none-any.whl | Python 3 | none | any | Details for qa_automation_ai_agent_evals-0.1.0-py3-none-any.whl |
Total release size: 1.6 MB
Release files / qa_automation_ai_agent_evals-0.1.0.tar.gz
| Download URL | qa_automation_ai_agent_evals-0.1.0.tar.gz |
|---|---|
| Size | 1.2 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
85bce179ef26a6d5d195dead1119154ebcd992e11d03fcaa9f7332a85f775bac
|
|
BLAKE2b-256 checksum How to use checksums |
0403d32c8f0391d55e39ee996cb2f16244ae52adc67bcf935c1eb70af803f144
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 7, 2026.
Transparency logRelease files / qa_automation_ai_agent_evals-0.1.0-py3-none-any.whl
| Download URL | qa_automation_ai_agent_evals-0.1.0-py3-none-any.whl |
|---|---|
| Size | 381.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
f1feb1c935d4947a9604d33be0e0209a38b9cae7b073f84d55582890bd3753ca
|
|
BLAKE2b-256 checksum How to use checksums |
9a5c4e61eac17da2c10fdb37ed284da16f835263864c196c7ac5f3de83a953e8
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 7, 2026.
Transparency logSecurity for qa-automation-ai-agent-evals 0.1.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for qa_automation_ai_agent_evals-0.1.0.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 7, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.