Skip to content
Luiz Hogrefe

ERQYO

Event Rhythm Qualifier · Yoked Operator · Adaptive Decision Runtime

Reference implementation · not deployed

ERQYO is a runtime architecture for agentic systems that have to decide not only what to do, but when, and whether they are allowed to. It has a reference implementation in the AnyLAI repository.

ERQYO

Rhythm influences qualification. Constraints govern operation.

The research problem

Agentic systems increasingly choose their timing: follow up now or wait, act or ask, escalate or hand over. Timing learned from past behaviour is useful.

It is also exactly the kind of signal that must never be able to grant itself permission. ERQYO separates the two, and makes the separation structural rather than a matter of good intentions.

ERQ · YO

ERQ · Event Rhythm Qualifier

What appears appropriate next, given the event, the state, the rhythm and the temporal context?

The adaptive side. It reads event and state context, rhythm, actor clocks and relationship context, and proposes a qualified candidate. Its output type has no field in which a permission could be expressed.

YO · Yoked Operator

Is that qualified outcome permitted to proceed, and how, under authoritative constraints?

The governed side. It is yoked to authoritative constraints, not to ERQ itself: authority, policy, evidence, safeguards and hard temporal limits reach it directly and never pass through the qualifier.

The decision path

The decision path
Rhythm · actor clocks · temporal context
→ ERQ
  1. Event / state change
  2. Operational state
  3. Candidate outcomes
  4. ERQ
    qualifies
  5. Qualified candidate
  6. YO
    operates
  7. Qualified outcome
Authority · policy · evidence · safeguards · hard constraints
→ YO · direct, never through ERQ

Learned rhythm can influence only the proposal. Authority, policy and evidence reach the operator directly.

Text description of the diagram

An event or state change updates the operational state. Rhythm, actor clocks and temporal context feed the qualification of candidate outcomes in ERQ, which produces a qualified candidate. The Yoked Operator checks that candidate against authority, policy, evidence, safeguards and hard constraints, which reach it directly, and produces the qualified outcome.

Ten outcomes

A closed vocabulary. Each outcome means something different, and the differences are the point.

ACT
Perform the action now.
RESPOND
Reply to the counterpart: a communicative form of acting.
WAIT
Not yet. The wait records when and on which events to reassess; it is semantic, never a sleep.
ASK
Required input or evidence is missing.
REASSESS
A dependency has moved; qualify again.
DELEGATE
Hand over to another actor who holds the authority.
ESCALATE
Raise to a higher authority, for example near a deadline or a limit.
HANDOFF
Give the case to a person, because the runtime holds no authority for it.
ABSTAIN
Confidence is insufficient to decide. Not the same as BLOCK.
BLOCK
A policy or a hard constraint forbids it.

The live illustration on this site uses eight of them. RESPOND, a communicative form of acting, and DELEGATE, a hand-over to another actor with authority, complete the vocabulary.

Temporal envelopes

The earliest and latest moments are hard bounds: a contractual window, a regulatory deadline, a cooling-off period. The preferred moment is soft, and it is the only place where rhythm may have an opinion. The operator reads the hard bounds and never the preference, so a learned habit cannot turn into a deadline.

Dynamic WAIT

A WAIT is recorded together with the conditions that reopen it: a moment, or a kind of event. Learned rhythm may move a wait only inside the hard bounds that apply.

Authority

Authority is a mandate to perform operations in a scope, for a period. The reference implementation knows six approval modes, from single approval to dual control; a board-reserved decision can never be satisfied by the runtime and always escalates. A proposal whose rationale claims that the checks passed still goes to a person, because the operator never reads the rationale.

Decision replay

Each decision trace records the contract version under which it was made, so it can be replayed later. Replay refuses a trace it cannot interpret, and human overrides are recorded, never inferred.

RhythmBench

Nine deterministic scenarios compare the runtime with a rhythm-blind, governance-blind baseline defined inside the benchmark. No comparison with any other product or framework has been made, and none may be read into the numbers.

  1. 1Eager follow-up
  2. 2Deadline under patience
  3. 3Unmandated action
  4. 4Cooling-off period
  5. 5Stale evidence
  6. 6Over the limit
  7. 7Quiet hours
  8. 8Duplicate delivery
  9. 9Prohibited operation

Try the separation

A simplified model of the idea runs below, in your browser. Change the rhythm and watch only the probabilities move; change a constraint and watch the outcome change regardless of them.

Change the situation

Rhythm only moves the probabilities.

Evidence

event customer.message.received 23:40

ERQ · proposed

  • ACT56%
  • WAIT30%
  • HANDOFF14%

YO · decided

  1. Hard limit
  2. Evidence not contradicted
  3. Qualification confident enough
  4. Evidence present
  5. Authority bound
  6. Window open

outcome

WAITNot yet; reopen at a defined moment

The action is allowed, but not now. The runtime waits for the window, and the wait is recorded.

ERQ: ACTYO: WAIT

An illustration computed in your browser: a simplified model of the ERQ → YO separation with illustrative numbers and eight of ERQYO's ten outcomes. It is not the ERQYO reference implementation.

Current implementation

The AnyLAI repository contains a reference implementation: contracts, qualifier, operator, rhythm model, runtime and RhythmBench, merged in September 2026 and covered by 64 tests.

It is not deployed. There is no API, no user interface and no production caller. The only integration runs in shadow mode inside the AnyClinical prototype, behind flags that are switched off.

  1. 0Contracts and decision traceimplemented
  2. 1Deterministic ACT, WAIT, ESCALATE and BLOCKimplemented
  3. 2Clocks, temporal envelopes and semantic WAITimplemented
  4. 3Rhythm model (median baseline) and shadow modeimplemented
  5. 4Relationship rhythm: quiet hours, reply cadenceimplemented
  6. 5Authority, delegation and dual controlimplemented
  7. 6RhythmBenchimplemented
  8. 7Public reference specification and SDKnot started
  9. Deploymentnone

ERQYO sits next to COADF: COADF describes how AI-assisted software is built and governed, ERQYO how a runtime decides under that governance.

It builds on established ideas, such as keeping policy as data and separating a proposal from the permission to execute it, and it does not claim to be the first to separate them.

Limitations

Limitations

  • Rhythm learning is a deterministic median baseline, not a trained model.
  • Not deployed: no API, no user interface, no production integration.
  • RhythmBench compares only against its own built-in baseline.
  • ERQYO provides no legal or organisational authority of its own; authority has to come from the organisation that uses it.
  • The public specification and SDK have not been written.
  • COADFPublished framework

    A published framework for building AI-assisted software under explicit governance: eight principles, a control manifest and CI-enforced fences.

    COADF
  • AnyClinicalWorkflow-governance prototype · unpublished

    Governance of a clinical-coordination workflow: consent, escalation, handoff and abstention. No diagnosis.

    AnyClinical
  • Trust ArchitectureImplemented platform architecture

    Provenance, evidence, confidence, authority and audit, arranged so that trust can be checked at every boundary.

    Trust Architecture