Skip to content

Independent R&D project · Cologne

AnyLAI

Applied research overview

Answers from an authority, over time

AnyValid

"The authority said no", "the authority did not answer" and "we have no way to ask" are three different facts, and a system that merges them turns its own network trouble into somebody's negative finding.

Status: Research concept · unpublished prototype

The research question

Can a claim, identifier or status be validated against an authoritative source, and is that validation still current?

  • What did the authoritative source say?
  • When did it say it?
  • Is that answer still current?
  • What happens when it says nothing?

The model, interactively

A registration number is sent to a registry. Choose how the exchange ends, then move through time to see what the record does next.

How the exchange ends
  • Requested
  • Source contacted
  • Outcome recorded
  • Validity window
  • Expired
  • Revalidation

Window lengths are illustrative; each authority adapter sets its own.

State on this day · A

Valid

The authority confirmed it

The answer is kept with its time and a validity window. Before the window closes, a revalidation task becomes due.

  1. Day 0Request recorded
  2. Day 0Adapter called
  3. Day 300Revalidation task becomes due
  4. Day 365Window closes: the state moves to expired; the answer itself is untouched
  5. Day 366A new case asks again and points at the one it supersedes

What makes it different

AnyVerify

Its question

Do the available sources agree with each other?

Why this is not that

AnyValid does not compare sources. It asks the one source whose answer counts, and tracks how long that answer lasts.

AnyTrace

Its question

Where has this thing been?

Why this is not that

AnyValid follows an answer through time, not a thing through hands.

AnyDPP's registry checks

Its question

Does this passport's evidence check out now?

Why this is not that

The corridor checks named Brazilian registries inside its own pipeline. AnyValid studies the lifecycle of any authority's answer, independent of one pipeline.

One scenario, step by step

One registration number, from the first question to the second.

Step 1 of 6: Ask

  1. A request records the subject, the authority and the time. If no adapter exists for that authority, the state is unavailable and no request leaves the system.

  2. The response is stored verbatim with its time. Valid and invalid are the authority's words; error means it did not answer.

  3. Error and unavailable open a task for a person. A manual check is an authority act with its reason, never a silent edit of the state.

  4. A valid answer carries a window. Before it closes, a revalidation task becomes due.

  5. When the window closes the state becomes expired. The response payload is not touched: what the authority said is still what it said.

  6. Revalidation opens a new case linked to the one it supersedes, so both answers stay readable in order.

Core primitives

  • Validation request

    AnyValidRequest

    What was asked, of which authority, when, how many times, and what came back, verbatim.

  • Source adapter

    SourceAdapter

    One per authority. It either answers, or says it could not. Every row records whether the adapter was live or a reference over a fixture.

  • Validation state

    ValidationState

    Pending, valid, invalid, error (no response), unavailable (no connector), expired. Six states, because there are six different situations.

  • Validity window

    valid_until, revalidate_after

    How long an answer counts, and when to start asking again.

  • Supersession

    supersedes link

    A revalidation is a new case pointing at the old one. What the authority said in March stays in March's record.

  • Human fallback

    fallback task

    When the exchange cannot be completed, a task goes to a person. A manual check is recorded as an authority act with its reason.

What exists, and what does not

In the repository

  • app/products/anyvalid/service.py: request, ask, settle, fallback, expire, revalidate, manual check
  • One reference adapter over a fixture, labelled mode=reference on every row it writes
  • anyvalid_requests table
  • 8 authenticated routes
  • tests/any_family/test_anyvalid.py: the three non-answers, reference labelling, fallback, revalidation (20 tests)

Research agenda, not built

  • Any live adapter to a real authority
  • A scheduler: expiry and revalidation are callable and tested, and nothing calls them on a timer
  • A per-authority view of attempts and silence

Where it sits in AnyLAI

AnyValid

  • Application kernelRequests are kernel cases; answers are evidence; fallbacks are tasks; manual checks are authority acts.
  • ERQYOERQYO names the same boundary from the other side: ASK when something is missing, HANDOFF when the system holds no authority. AnyValid has no ERQYO caller.
  • case link through the kernel
  • direct use of another module or system
  • shadow-mode call: recorded, never executed

Limits and non-goals

  • No real authority is connected. The only adapter reads a fixture and says so.
  • It records what an authority said; it does not interpret what that answer means for anyone.
  • Nothing expires or revalidates on its own yet.
  • An invalid answer is recorded, not appealed: disputing an authority is outside it.

Current state

Research status

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

A prototype module over the shared kernel with one reference adapter. Switched off, not published, and never connected to a real authority.

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

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