01METHOD
Public doctrine
ESTABLISHES
Explains the decision vocabulary and control model.
DOES NOT ESTABLISH
Does not establish that any real workflow passed a test.
BitEvo proof matrix
Different evidence classes. No trust-score shortcut.
Two evidence classes are separated on purpose: synthetic packs demonstrate method structure; bounded internal dogfood documents scoped observations from our own agent/control stack. Neither is customer proof or independent certification.
SYNTHETIC PROOF SURFACE · WORKED PACKS
The three SAMPLE cases below are designed worked examples. No customer environment, production execution, private data or external audit result is represented. Each pack keeps assumptions, expected gates and NOT TESTED states explicit.
Evidence strength
Proof gets stronger only when the evidence class changes.
BitEvo does not collapse method, examples, source, builds, runtime observations and owner decisions into one trust score. Each class answers a different question and stops at a different boundary.
02WORKED
Synthetic pack
ESTABLISHES
Shows how the method is applied to a concrete action class.
DOES NOT ESTABLISH
Does not represent customer evidence or an executed audit.
03MACHINE
Machine-readable example
ESTABLISHES
Makes assumptions, gates and expected outputs inspectable in JSON.
DOES NOT ESTABLISH
Does not turn example data into observed runtime evidence.
04SOURCE / BUILD
Inspectible implementation evidence
ESTABLISHES
Can establish what source, artifact or build was actually published when a receipt is linked.
DOES NOT ESTABLISH
Does not by itself prove the intended external runtime effect occurred.
05OBSERVED
Scoped finding
ESTABLISHES
Ties a reproducible observation to authority, evidence, external effect and recovery inside an agreed test scope.
DOES NOT ESTABLISH
Exists only when the observation was actually collected; public examples cannot substitute for it.
06DECISION
Owner decision + retest
ESTABLISHES
Records EXPAND / CONSTRAIN / REPAIR / RETEST and the criterion required to change that decision.
DOES NOT ESTABLISH
Is bounded to the tested workflow and evidence window; it is not universal certification.
Observed internal proof
A different evidence class from the worked packs.
The synthetic packs explain method structure. The internal dogfood case documents bounded observations from our own agent/control stack: real failure → repair → adversarial retest. It remains redacted and does not become customer evidence or production-wide proof.
Three action classes
Authority breaks differently depending on what the agent can change.
The invariant method stays fixed while object binding, evidence gates, confirmation and recovery become specific to the external effect.
SAMPLE-001CRM write
CRM Qualification Update Agent
EXTERNAL EFFECT
Update two fields on one matched staging lead.
WORKED FAILURE
Internal success without trusted same-object read-back.
FINDING CLASS
False Green / external-effect confirmation gap
OWNER DECISIONCONSTRAIN
SAMPLE-002Outbound message
Approved Outreach Message Agent
EXTERNAL EFFECT
Send one approved message to one resolved recipient.
WORKED FAILURE
Recipient or approval evidence diverges before send.
FINDING CLASS
Authority mismatch / recipient-binding gap
OWNER DECISIONCONSTRAIN
SAMPLE-003Deployment / config change
Staging Configuration Change Agent
EXTERNAL EFFECT
Change one approved staging configuration key.
WORKED FAILURE
Version or environment binding is ambiguous at execution.
FINDING CLASS
Version-context / environment-binding gap
OWNER DECISIONREPAIR
Trust contract
Four substitutions this proof surface refuses to make.
Most evidence inflation happens when two different facts are treated as interchangeable. These boundaries are part of the product, not disclaimer copy hidden after the claim.
Synthetic ≠ observed
A designed failure case can demonstrate reasoning structure. It cannot become customer or runtime evidence by presentation alone.
Build ≠ runtime
A successful source build establishes a build fact. It does not establish that an external system reached the intended state.
Tool acknowledgement ≠ effect
A successful API/tool response must still be reconciled with the intended object, recipient, environment or external state.
Pass ≠ certification
A bounded test can support one owner decision under one evidence window. It is not a permanent safety badge or universal trust score.
Apply the method
Turn your own workflow into the same decision structure.
The local Authority Mapper supports CRM/record writes, outbound messages, deployment/config changes and custom external effects. It generates a draft Authority Ledger, Evidence Contract, action-specific failure scenarios and an owner decision posture.
Method invariants
What does not change across the three packs.
Authority is object-bound
The permission must name the action, target object or environment and the owner of that authority.
Evidence exists before effect
Identity, approval, freshness and version context are decision gates, not post-hoc explanations.
External effect closes the loop
A tool acknowledgement alone does not prove the intended external state exists.
Ambiguity reduces authority
Unknown recipient, object, environment, version or external state routes to constrain, reconcile or repair.
Retest uses the same criterion
A code/config change is not closure; the original decision condition must be replayed.
CRM WRITEsame-object read-back
Primary ambiguity: did the intended record actually reach the intended state?
OUTBOUND MESSAGErecipient + approval binding
Primary ambiguity: was the exact approved content sent to the exact authorized recipient?
CONFIG CHANGEenvironment + version binding
Primary ambiguity: did the approved change land in the intended environment against the expected baseline?
Your workflow
Start from the external effect, not the model name.
Map the action first. If the gates remain unresolved, the diagnostic and intake turn those gaps into an audit-ready scope without treating uncertainty as a pass.