Skip to content

Independent R&D project · Cologne

Applied research overview

Origin evidence against versioned rules

AnyUSMCA

An assessment against trade rules is only explainable if it keeps apart a condition that failed and a condition that could not be evaluated, and records which version of which rules it used.

Status: Research concept · unpublished prototype

What it does not determine

It does not determine that goods qualify for anything, and it makes no legal or customs determination. Its rule-pack is synthetic and says so. Whether a rule applies, and what follows from it, remains a decision for the people and authorities responsible.

The research question

How can origin evidence, material relationships and versioned trade rules be represented so that a qualification assessment is explainable and reconstructable?

  • What went into the good, and from where?
  • Which inputs have evidence for their origin?
  • Which condition of which rule-pack version failed, and why?
  • Which conditions could not be evaluated at all?

The model, interactively

A finished good with four inputs, assessed against the repository's synthetic reference rule-pack. Change where one input comes from and whether another has origin evidence, then select a condition to see the inputs it reads.

Control unit sourced from
Wiring harness origin evidence

Finished good

Assembly, transaction value 12,000

Rule-pack: usmca-reference 2026.1 (synthetic)

Bill of materials

  • Steel frame

    Declared origin
    US
    Value
    4,200
    Heading
    7308
    Origin evidence
    Verified
  • Wiring harness

    Declared origin
    MX
    Value
    1,100
    Heading
    8544
    Origin evidence
    No verification
  • Control unit

    Declared origin
    CN
    Value
    1,900
    Heading
    8537
    Origin evidence
    Verified
  • Seat assembly

    Declared origin
    CA
    Value
    800
    Heading
    9401
    Origin evidence
    Verified

Conditions

Select a condition to highlight the inputs it reads.

Determination

Conditions not met: a condition failed. The evidence gap, if any, is still listed beside it, separately.

One scenario, step by step

Assessing one good, and what the record can explain afterwards.

Step 1 of 6: Fix the rules

  1. The assessment names its rule-pack and version. Swapping the pack later changes nothing already assessed.

  2. Four bill-of-materials lines, each pointing at the trace case of its input.

  3. Each input's origin relies on an AnyVerify result. Three have one; the wiring harness does not yet.

  4. With the control unit from outside the territories, the territory condition fails. Value content is computed by the named method from the good's own value. The evidence condition cannot be evaluated for the harness.

  5. A failed condition gives conditions not met, with the gap still listed beside it. Had nothing failed, the same gap would give evidence incomplete, never a failure.

  6. A person reviews the assessment. The module refuses to record a claim that the goods qualify.

Core primitives

  • Assessment

    AnyUsmcaAssessment

    One good, one rule-pack at one version, and a determination: conditions met, conditions not met, evidence incomplete, reviewed, or pending.

  • Bill-of-materials line

    AnyUsmcaBomItem

    An input with declared origin, value and heading, linked to the trace case of that input.

  • Rule-pack

    rulepacks/*.yaml

    Conditions as data, each with a kind, parameters and a reason code. Versioned, validated on load, with a source note.

  • Condition kinds

    origin_in_territory, regional_value_content, tariff_shift, origin_evidence_present

    The shapes origin rules take. The method is named, because the same goods pass one method and fail another.

  • Evidence gap

    gaps

    A condition that cannot be evaluated is a gap, not a failure, and the determination says evidence incomplete.

  • Recorded computation

    computations

    The arithmetic behind each condition is kept with the assessment, so the number can be checked by hand.

What makes it different

AnyVerify

Its question

Does this origin declaration match an independent record?

Why this is not that

AnyUSMCA consumes those results as evidence and adds the rules, the arithmetic and the materials.

AnyTrace

Its question

Where has each input been?

Why this is not that

AnyUSMCA links inputs to their traces; it evaluates rules over them.

AnyDPP's EUDR rule-packs

Its question

Does a consignment's evidence meet EU deforestation requirements?

Why this is not that

The corridor's packs evaluate one regulation's evidence. AnyUSMCA studies materials, value arithmetic and origin conditions over a bill of materials.

What exists, and what does not

In the repository

  • app/products/anyusmca/{service,rulepack}.py: rule arithmetic, gaps vs failures, the refused claim
  • rulepacks/usmca-reference.2026.1.yaml: synthetic conditions with a source note saying so
  • anyusmca_assessments and anyusmca_bom_items tables; 9 authenticated routes
  • tests/any_family/test_anyusmca.py: rule arithmetic, gaps vs failures, the refused claim, composition (25 tests)

Research agenda, not built

  • A rule-pack from any legal source
  • Multi-level materials: inputs of inputs
  • More than one value-content method per assessment

Where it sits in AnyLAI

AnyUSMCA

  • AnyVerifyUses AnyVerify's service directly: each input relies on a verification result.
  • AnyTraceEach bill-of-materials line incorporates the trace case of its input.
  • Application kernelAssessments are kernel cases; reviews are authority acts.
  • COADFRule knowledge in versioned packs, never in code: COADF's rule 4, applied.
  • case link through the kernel
  • direct use of another module or system
  • shadow-mode call: recorded, never executed

Limits and non-goals

  • No legal or customs determination, and no statement that goods qualify.
  • The only rule-pack is synthetic.
  • Origin evidence is only as good as the verification behind it.
  • One level of materials only.

Current state

Research status

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

A prototype module over the shared kernel with one synthetic rule-pack. Switched off, not published, not used on real goods.

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

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