Skip to content

Independent R&D project · Cologne

AnyLAI

Applied research overview

Governed workflows in a high-consequence setting

AnyClinical

In a setting where the consequences are clinical, the most important thing an AI-assisted workflow can know is where its authority ends, and the design has to make that boundary impossible to skip.

Status: Research concept · workflow-governance prototype, unpublished

What AnyClinical is not

  • It does not diagnose.
  • It does not recommend or decide treatment.
  • It is not a medical device, and it makes no medical-device claim.
  • Clinical judgement stays with clinicians. The system has no place to record a clinical finding, by design.

The research question

How can a workflow around clinical care stay evidence-bound, authority-aware and explicitly handed to people at the right boundaries, including by declining to act?

  • Is there a recorded permission for this step?
  • Who holds the capability to act?
  • What happens when a window closes unattended?
  • Where must the system stop and hand over?

The model, interactively

The coordination around one scheduled study visit: logistics only. Step through the case and watch what the workflow allows, what it blocks, and what ERQYO would have decided, recorded in shadow mode beside it.

First-class outcomes

  • ACT
  • WAIT
  • HANDOFF
  • ESCALATE
  • ABSTAIN
  • BLOCK
HANDOFF
The system holds no authority for this: a person takes it.
ABSTAIN
Declining to decide is a legitimate result, not a failure.

Step 1 of 6: Confirm the appointment with the site

  1. Workflow: Allowed: no participant is contacted, so no permission is needed.

    ERQYO, shadow mode: ACT

    Audit trail: step.completed by a coordinator

  2. Workflow: Blocked: no recorded permission to telephone. The step cannot open.

    ERQYO, shadow mode: BLOCK

    Audit trail: step.blocked, reason CONSENT_NOT_RECORDED

  3. Workflow: The participant's permission to be contacted by phone is recorded, with its scope.

    ERQYO, shadow mode: WAIT

    Audit trail: consent.granted, scope contact-by-phone

  4. Workflow: Allowed and completed by a coordinator.

    ERQYO, shadow mode: ACT

    Audit trail: step.completed

  5. Workflow: The window closed with no record: the workflow escalates to the person holding the escalation capability.

    ERQYO, shadow mode: ESCALATE

    Audit trail: escalation.raised, acknowledgement due in 4 hours

  6. Workflow: Nothing in the workflow can express it. The case is handed to a clinician, and the system records that it declined.

    ERQYO, shadow mode: HANDOFF

    Audit trail: handoff, the system holds no authority

Shadow mode: ERQYO's outcome is recorded next to what the kernel did. Nothing executes it.

Step 6 is illustrative of the boundary rather than a step in the workflow file: the schema has no way to express a clinical question, which is the point.

One scenario, step by step

The same visit, read as the audit trail a reviewer would see.

Step 1 of 5: Open the case under a versioned workflow

  1. trial-visit-coordination v1: four logistics steps, nothing clinical.

  2. The notification step cannot open until permission to telephone is recorded. The permission is the precondition, not a box ticked afterwards.

  3. An unattended window escalates to the holder of the escalation capability, who must acknowledge within four hours.

  4. Late paperwork expires rather than escalating: a reportable fact, not something to wake a clinician for.

  5. In shadow mode, ERQYO's outcome for each closed window is recorded next to the kernel's action. The expected disagreement is kept: where the workflow expires a step, ERQYO escalates a passed hard deadline.

Core primitives

  • Case

    AnyClinicalCase

    One coordination case under one workflow at one version. Holds no clinical content, because the schema has nowhere to put it.

  • Workflow definition

    workflows/*.yaml

    Steps with the capability that may act, the consent each requires, timing windows, and what happens when a window closes: escalate or expire.

  • Consent as precondition

    AnyClinicalConsent

    Narrowly scoped permissions: not recorded, granted, refused, withdrawn, expired. A step that needs one cannot open without it.

  • Capability

    clinical.coordinate, clinical.escalate

    Authority is a named capability held by a role in the tenant, not a free-text field.

  • Escalation

    EscalationState

    Raised, acknowledged, unacknowledged, resolved, with an acknowledgement deadline.

  • ERQYO shadow comparison

    erqyo.shadow_compared

    ERQYO's decision and trace, recorded beside the kernel's action, including where they disagree.

What makes it different

ERQYO

Its question

What should a system do next, and under whose authority?

Why this is not that

AnyClinical is the applied setting in which that question is asked, in shadow mode. ERQYO is the runtime architecture.

AnyValid

Its question

What did an authority say, and is it still current?

Why this is not that

AnyClinical's permissions come from the participant and its authority from roles, not from an external registry.

Trust architecture

Its question

How do confidence, review and one audit trail fit together?

Why this is not that

AnyClinical applies that architecture where a missed handoff has human consequences.

What exists, and what does not

In the repository

  • app/products/anyclinical/{service,workflows}.py: the scope boundary, consent as precondition, timing, escalation, sweep
  • workflows/trial-visit-coordination.v1.yaml: logistics only
  • anyclinical_cases and anyclinical_consents tables; 11 authenticated routes
  • The ERQYO shadow caller through app/core/kernel/erqyo_bridge.py, behind two switches that are off
  • tests/any_family/test_anyclinical.py (33 tests) and the ERQYO bridge suite (30 tests)

Research agenda, not built

  • Any AI-assisted step: no model is called anywhere in the module
  • A scheduler for the sweep: it is callable and tested, not timed
  • Notification delivery: notifications are recorded, not sent
  • Anything clinical, deliberately

Where it sits in AnyLAI

AnyClinical

  • ERQYOThe one module with an ERQYO caller: the closed-window sweep, in shadow mode, recorded and never executed.
  • Application kernelSteps are tasks, consents and escalations are evidence and events, decisions are authority acts.
  • Trust architectureA person where the system holds no authority: the trust architecture's rule, applied.
  • COADFWorkflows as versioned data and a deterministic path: COADF's principles, applied, without a conformance claim.
  • case link through the kernel
  • direct use of another module or system
  • shadow-mode call: recorded, never executed

Limits and non-goals

  • Logistics around care only. No diagnosis, no treatment, no clinical content.
  • Not a medical device, and not built or validated as one.
  • No AI model is called. The research question is how one could be, safely.
  • ERQYO decides nothing here; it is recorded beside the workflow.

Current state

Research status

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

A prototype module over the shared kernel with one logistics workflow and a shadow-mode ERQYO caller. Switched off, not published, never used with a real participant.

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

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