published / methodology / 0.4
Evidence Path Protocol for Verifiable AI
Version 0.4 of a minimal contract connecting a source, data version, transformation, test outcome, and accountable human decision.
01 / PURPOSE
Question and purpose
Evidence Path Protocol 0.4 is a minimal demonstration pattern for a result that can be traced from source to decision. It is neither certification nor a universal schema; it helps a team name missing connections in a particular workflow.
02 / SOURCES
Source and input registry
A minimal record contains source_id, data_version, transformation, test_outcome, and approval_role. The fields create a checkpoint, but they do not replace source content, access policy, or accountable review.
The protocol applies to a representative result and its actual artifacts, not to a narrative description of a system. Source identifier, data version, and transformation should lead to material an authorised person can revisit under the relevant access rules.
03 / METHOD
Method steps
Each result names a source ID, data version, transformation rule, test outcome, and approving person or role.
First select a result that requires control, then record the five minimum fields and check whether they form a continuous path from source to decision. A missing field, ambiguous version, or approval without a role is a test result requiring correction or a stop in use.
03A / EXAMPLE
Worked verification example
For one representative output, prepare a record with source_id, data_version, transformation, test_outcome, and approval_role. Then traverse those fields backwards: from the approving role to the test, transformation, version, and source. If one reference does not reach accessible material or approval_role does not name an accountable function, the record ends with incomplete status rather than a green confirmation of use.
04 / TEST
Validation and negative cases
Validation asks whether the named field exists for a representative result, leads to real material, and distinguishes a test outcome from an author’s assertion. Negative cases include a missing field, ambiguous version, or decision without an approving role.
05 / REPRODUCE
Reproduction instructions
To reproduce the path, another person should be able to read the source identifier, recreate the version and transformation, inspect the test outcome, and see who decided to use the result and in which role.
06 / VERSION
Version and change record
The 0.4 number denotes a working draft. When an organisation adds fields or changes their semantics, it must retain the contract version and document compatibility so older packages do not pretend to be new ones.
07 / LIMITS
Limitations
This is a demonstration pattern that requires domain and policy adaptation.
The 0.4 contract does not replace security policy, retention governance, a regulatory audit, or independent model-quality assessment. It exposes a minimum trace for one workflow; an organisation still has to decide who can access material, what it retains, and how it verifies claims beyond that trace. When the trace is incomplete, the proper outcome is to complete the contract or stop use, not an automatic authorisation for data processing or deployment.
08 / CITE
Citation
Citation should state version 0.4 and its demonstration-pattern status. The protocol does not establish regulatory compliance, data quality, or decision correctness beyond the scope of an explicitly performed test.
DOBROVOLA. Evidence Path Protocol. Version 0.4, 2026-08-02.BibTeX
@misc{dobrovola2026evidencepathprotocol,
author = {DOBROVOLA},
title = {Evidence Path Protocol},
year = {2026},
version = {0.4},
url = {https://dobrovola.dev/en/research/evidence-path-protocol}
}