Authority · evidence · effect · recovery

An agent should earn authority with evidence.

BitEvo audits the action layer of AI systems: what a workflow is allowed to change, what evidence must exist before it acts, how the external result is confirmed, and what the system does when certainty disappears.

Map one workflow See worked proof

Browser-local mapping first · staging/test by default · written Rules of Engagement before testing

DECISION TRACE / SYNTHETIC LAB-001 SYNTHETIC WORKED CASE

INTENTexternal change proposed

captured

AUTHORITYscope + approval matched

bounded

EVIDENCEsource freshness stopped advancing

insufficient

DECISIONdo not expand authority

constrain

WORKED FINDING CLASSCapability exceeded the evidence available to justify the action.

Synthetic worked scenario only. No customer environment, production execution or observed private infrastructure is represented.

Start with the smallest step

Map. Challenge. Then scope.

You do not need to buy an audit to understand the model. Draft one action chain locally, inspect worked evidence, and only turn the unresolved gates into scope when the decision is worth testing.

01 · LOCAL

Map one workflow

Draft the Authority Ledger and Evidence Contract in the browser. No testing authorization is created.

02 · PROOF

Challenge the model

Inspect three synthetic worked action classes and see how evidence changes an owner decision.

03 · SCOPE

Turn gaps into scope

When the unresolved gates matter, prepare a bounded scope brief. The public intake still does not authorize testing.

OBJECTOne action-capable workflow

QUESTIONWhat may it do — and why?

TEST10–20 agreed failure scenarios

DECISIONExpand · constrain · repair · retest

BitEvo vocabulary

Three concepts define the operating philosophy.

The terminology is intentionally narrow. It describes recurring control problems in action-capable workflows without pretending every problem is a vulnerability or every passing test is a safety guarantee.

Read the full doctrine →

Authority Budget

Every write permission, integration, autonomous step and retry path expands the authority surface. Capability does not automatically justify permission.

Evidence Before Effect

Critical effects should depend on evidence available at decision time. Logs after the fact can reconstruct an event; they cannot retroactively justify it.

False Green

A workflow can look healthy or successful while required evidence is stale, missing, attached to the wrong object or never confirmed externally.

The operating problem

Capability grows faster than proof.

Every new tool, write permission and autonomous step increases the authority surface. If the evidence chain does not grow with it, the team accumulates authority it cannot reliably justify, reconstruct or contain. BitEvo treats that gap as an engineering problem.

Before authority expands

A workflow is about to gain a new write-capable tool, integration, approval path or external side effect.

When evidence lags capability

The agent can do more than the team can reliably reconstruct, confirm or explain after the fact.

Before a pilot becomes infrastructure

A useful workflow is becoming operationally important, but duplicate execution, stale state or ambiguous approval would still be hard to contain.

The control loop

Permission is only the first gate.

A reliable workflow needs four linked answers: was the action authorized, was the evidence sufficient, did the intended external effect occur, and can the system recover when any of those answers becomes uncertain?

Authority

Define what the workflow is permitted to change, which object that permission applies to, and where human authorization is required.

Evidence

Identify the minimum evidence required before an action is allowed: inputs, approvals, source freshness, tool state and version context.

Effect

Verify the external result instead of treating an internal run status or tool response as proof that the intended change actually happened.

Recovery

Test what happens when certainty disappears: retry, interruption, partial execution, stale state, duplicate actions and rollback.

Proof discipline

A finding must change a decision.

BitEvo does not sell a generic “AI safety” score. A useful finding connects an observed failure to the authority boundary, the evidence available at decision time, the external effect and the owner action that follows.

LAB-001SYNTHETIC · WORKED

False Green: healthy surface, stale truth.

In this worked scenario, a service surface is treated as apparently healthy while source freshness stops advancing. The modeled finding is not “the agent is unsafe.” It is that the workflow could appear operable after the evidence required to justify action had become stale. The modeled owner decision is therefore to constrain the Authority Budget until freshness and confirmation are made explicit.

Inspect evidence strength →

Proof Matrix

Synthetic worked packs plus an explicit evidence-strength ladder showing what method, build and observed evidence can — and cannot — establish.

Internal dogfood

Bounded internal self-audit evidence from BitEvo’s own control stack — not customer proof, independent certification, or production-wide security evidence.

Build + 10/10 Standard

The public engineering index and reusable quality contract, with machine gates kept separate from human visual review.

BitEvo Doctrine

Authority Budget, Evidence Before Effect and False Green — the vocabulary behind the audit model.

Audit methodology

The four-plane model, finding anatomy, failure plan and Rules of Engagement.

Reviewed research

A curated public set of engineering notes on agent reliability, isolation, drift and tool boundaries.

BitEvo Universe

A static map of current public projects and proof surfaces — not a live operations dashboard.

Decision-artifact spine

A1–A4 structure the owner decision.

Authority Ledger, Evidence Contract, Finding Record and Decision Memo are the canonical decision-artifact spine. They organize the method; they are not the complete commercial delivery package.

Authority Ledger

A bounded map of critical actions, tools, objects, approvals and explicitly prohibited transitions.

Evidence Contract

The evidence that must exist before, during and after each critical action for the result to be trusted.

Finding Record

Reproducible findings tied to observed consequence, evidence quality and recovery behavior — with hypotheses kept separate.

Decision Memo

A bounded owner decision with supporting evidence, residual uncertainty, required control change and retest criterion.

Complete Primary Audit delivery package

Eight deliverables. One bounded audit.

The Primary Audit commercial package is exhaustive at eight deliverable classes; the A1–A4 artifact spine remains the internal decision structure used across them.

Executive report

Authority / effect map

Test inventory and scenario results

Reproducible evidence pack

Finding cards with impact, evidence, limitations, and confidence

Prioritized repair backlog

One retest

Evidence manifest / hashes where applicable

5 working days after complete evidence/access + written scope

Move from “it works” to “we know why it may act.”

No testing begins from a public form alone. Scope, access approval, allowed tests, prohibited actions, data handling and replay conditions are agreed first. The phases below describe the audit method, not a guaranteed day-by-day allocation.

See the full method →

Phase A
Map authority
Identify actor and identity, tools and credentials, read/write surfaces, approval gates, target binding, scope/expiry and recovery path.
Phase B
Agree failure scenarios
Select the bounded safe scenarios that challenge approval, object binding, scope, replay, external effects and recovery without turning the engagement into an unbounded pentest.
Phase C
Collect evidence
Preserve the minimum necessary scope, configuration, identity, execution, state, approval, recovery, finding and retest receipts for material scenarios.
Phase D
Make the owner decision
Translate accepted findings into observable behavior, impact, evidence class, limitations, repair recommendations, retest criteria and residual risk.
After repair
Retest the claim
Re-run the agreed finding criteria after relevant remediation is available. One retest is included in the Primary Audit.

Primary engagement

Agent Authority & Evidence Audit

For teams that need to decide whether one write-capable workflow is ready for more authority — or needs to be constrained first.

$4,900fixed · 5 working days after complete evidence/access + written scope

Prepare Primary Audit scope Map the workflow Compare decision scopes

Object1 staging/test workflow

Authority BudgetUp to 3 tools / APIs / MCP servers

Failure plan10–20 agreed scenarios

EvidenceAuthority Ledger + Evidence Contract + reproducible Finding Records

DecisionExpand / constrain / repair backlog

VerificationOne retest

FAQ

The boundary is part of the product.

What exactly is being audited?

A concrete agent workflow with an external effect. The object of the audit is the action chain — not an abstract model score.

What is an Authority Budget?

A BitEvo concept: consequential capability is treated as a finite permission surface that should expand only when evidence, confirmation and recovery controls justify the expansion.

What is a False Green?

A BitEvo term for an operational evidence mismatch: the workflow appears healthy or successful while a required source, confirmation or state condition is no longer trustworthy.

Is this a penetration test?

No. The standard engagement is a bounded engineering review in an agreed staging/test workflow. Production penetration testing is not included by default.

Do you certify an agent as safe?

No. The result is scoped engineering evidence and owner decisions — not certification, a universal trust score, or a guarantee of security or defect absence.

Do you need production secrets?

No. Public intake excludes credentials and customer secrets. Access, data boundaries and replay conditions are agreed separately in writing.

PRIMARY AUDIT$4,900 · 5 working days after complete evidence/access + written scopePrepare scope ↗