Evidence against a claim

AnyVerify

A verification result is worth something only if it keeps apart two sources that disagree, and a check that could not be performed.

Status: Research concept · unpublished prototype

The model, interactively

Claim: this consignment's origin declaration matches an independent registry record. The profile compares five attributes, each with its own comparator. Change what the registry returned and watch the result.

What the registry returnedEverything lines upThe registry reference is missingThe producer names differA reviewer settles the disagreement

Attribute	Declaration	Registry	Comparator	Check
Origin country	BR	BR	exact	Match
Producer name	Cooperativa São João	COOPERATIVA SAO JOAO	normalised text	Match
Quantity	19,200 kg	19,450 kg	number, ±2%	Match
Harvest date (optional)	2026-06-10	2026-06-12	date, ±3 days	Match
Registry reference	BA-0427-7731	BA-0427-7731	exact	Match

Result

Corroborated: the two sources agree on every required attribute.

Agreement ratio

1.00

5 / 5

The research question

Does the available evidence actually support a specific claim, attribute by attribute, and how should a system say so when it cannot tell?

Which attributes do the sources agree on?
Where do they disagree, and by how much?
What could not be checked at all?
When does a person have to settle it?

Core primitives

Verification case
AnyVerifyCase
One claim about one subject, verified against one versioned profile, linked to the case it verifies.
Profile
profiles/*.yaml
Which attributes to compare, between which two sources, with which comparator and tolerance, and which are required. Data, validated on load, default-deny.
Check
AnyVerifyCheck
One attribute compared: match, mismatch, absent or inconclusive, with the values seen and a reason code.
Result
VerificationResult
Corroborated, contradicted, insufficient, resolved by review, or pending. Insufficient and contradicted are never collapsed.
Agreement ratio
attribute-agreement-ratio
The share of checked attributes that agree, named as a method, not presented as a probability.
Review and attestation
kernel authority act
A person with the capability records a decision and its reason. The machine's result is kept, not replaced.

One scenario, step by step

What happens between a declaration arriving and a result anyone can rely on.

Step 1 of 6: Open a case against a profile

The claim, the subject it concerns, and the profile version are fixed at the start, so the result can always say what it was measured against.
The supplier's declaration and the registry record are attached as evidence, each with its source and time.
Five comparisons, each recorded separately. A missing value is recorded as absent, not as a mismatch.
The rule evaluator reads the checks. Sources that disagree on a required attribute give contradicted; a required attribute that could not be compared gives insufficient.
A contradiction opens a review task. The reviewer's attestation resolves the case and sits beside the machine's result, which stays readable.
Every result has a validity window from the profile. After it, the result is stale and has to be reassessed rather than reused.

What makes it different

AnyValid

Its question

What did the authoritative source itself say?

Why this is not that

AnyVerify compares sources with each other. It asks no authority for a verdict and does not look anything up.

AnyTrace

Its question

Where has this thing been?

Why this is not that

AnyVerify takes a trace case as its subject and says whether a claim about it holds up.

AnyUSMCA

Its question

Does origin evidence meet a named rule set?

Why this is not that

AnyUSMCA uses AnyVerify's results as inputs; AnyVerify knows nothing about trade rules.

Limits and non-goals

Two sources agreeing is corroboration, not proof. Both can be wrong.
It is not a lookup engine and queries no authority.
A result is not a certificate and draws no legal conclusion.
The two profiles are reference profiles, not anybody's official checklist.

What exists, and what does not

In the repository

app/products/anyverify/{service,compare}.py: comparators, checks, decision, review, expiry, reuse
Two reference profiles: origin-declaration.v1 and supplier-identity.v1
anyverify_cases and anyverify_checks tables
10 authenticated routes
tests/any_family/test_anyverify.py: the four comparator outcomes, insufficient vs contradicted, review, expiry (36 tests)

Research agenda, not built

A connection to any real registry; sources are supplied by the caller
Comparison across more than two sources for one attribute
Any calibration of the agreement ratio against outcomes

Where it sits in AnyLAI

AnyVerify

Application kernelChecks, results and reviews are kernel evidence, events, tasks and authority acts.
AnyTraceLinks to the trace case it verifies.
AnyUSMCAIts results are the origin evidence AnyUSMCA's rules rely on.
Trust architectureThe same principle as the trust architecture: a person where the evidence is uncertain.

case link through the kernel
direct use of another module or system
shadow-mode call: recorded, never executed

Current state

Research status

Research concept · unpublished prototype
Unpublished: routes switched off
No production use, no real data
36 tests in the repository

A prototype module over the shared kernel with two reference profiles, a service, tables, routes and tests. Switched off, not published, not used on real data.

Test suite: python-backend/tests/any_family/test_anyverify.py

Research project · Independent R&D · Not a commercial offering