[
https://issues.apache.org/jira/browse/CAMEL-24871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-24871 started by Luigi De Masi.
---------------------------------------------
> Add Jev-backed semantic predicates for the Choice EIP
> -----------------------------------------------------
>
> Key: CAMEL-24871
> URL: https://issues.apache.org/jira/browse/CAMEL-24871
> Project: Camel
> Issue Type: New Feature
> Components: camel-ai, eip
> Reporter: Luigi De Masi
> Assignee: Luigi De Masi
> Priority: Major
>
> h2. Motivation
> Support semantic conditions in Camel's Choice EIP using Jev, TypeSafe AI's
> decision model. A route author should be able to express a condition such as
> "Does this message request a refund?" and use the result in
> {{choice().when().otherwise()}} with an explicit probability threshold.
> Jev's Noul primitive evaluates a yes/no proposition against supplied text or
> structured state and returns a probability between 0 and 1. It does not
> return a separate confidence field. This maps naturally to a Camel predicate
> once the route author defines the threshold and how to handle uncertainty.
> h2. Proposed behavior
> Provide reusable Jev evaluation and predicate support, with the public DSL
> and module placement to be agreed during design. The integration should allow
> route authors to:
> * Select the message body or explicitly chosen exchange data as the state,
> and configure the question and optional yes/no criteria.
> * Configure the model, credentials, request timeout, and probability
> threshold; allow pinning a model version.
> * Retain the probability on the exchange so the route can distinguish a
> positive match, a negative result, and an uncertain result while preserving
> the original message body.
> * Evaluate multiple independent questions in one request when they share the
> same state, then reuse their results in successive predicates.
> * Route timeouts, API errors, and invalid or missing results through Camel's
> error handling. These failures must not silently become a false predicate or
> ordinary business fallback.
> h2. Example routing behavior
> For a refund-request question, an illustrative policy is:
> * {{p >= 0.9}}: route to the refund-request handler.
> * {{p <= 0.1}}: route to the normal handler.
> * Otherwise: route to review or another configured fallback.
> These thresholds are examples to validate against the application's data, not
> universal defaults. The predicate classifies intent; downstream code remains
> responsible for deciding and authorizing any business action.
> h2. Design considerations
> {{Predicate.matches(Exchange)}} is synchronous. Making an HTTP call directly
> from each predicate would block the evaluating thread and could introduce
> successive remote calls when several {{when}} branches are checked. A
> preferred starting point is a Jev evaluation step before the choice, followed
> by predicates reading exchange-scoped results. Any direct predicate facade
> should document its blocking behavior and avoid implying automatic batching
> of independent predicate invocations.
> Preserve the Choice EIP's existing first-match behavior: when several
> independent predicates match, branch order determines which handler runs.
> Asking one Jev Choice question for the best category is a different operation
> and should not silently replace that behavior. No change to Camel's core
> Predicate contract is proposed.
> Typed responses do not guarantee correct classifications. Document
> uncertainty handling and the model's limitations, including sensitivity to
> irrelevant or adversarial message content. Keep the submitted state explicit
> rather than forwarding the entire exchange by default.
> h2. Acceptance criteria
> * A documented example routes messages through {{choice/when/otherwise}}
> using Jev results, including an uncertainty branch.
> * Automated tests with a stubbed HTTP service cover threshold boundaries,
> uncertain results, overlapping matches and first-match priority, body
> preservation, and timeout/error/invalid-response handling.
> * Multiple questions can share one evaluation request and their results can
> be reused without a remote call per branch.
> * Documentation describes synchronous predicate constraints, model selection,
> credentials, timeouts, and error handling. Tests do not require live
> credentials.
> h2. References
> * [Jev introduction|https://docs.typesafe.ai/introduction]
> * [Noul primitive and probability
> semantics|https://docs.typesafe.ai/primitives/noul]
> * [HTTP API|https://docs.typesafe.ai/api]
> * [Model limitations|https://docs.typesafe.ai/model-jaggedness/jev-1.13]
> * Camel {{core/camel-api/src/main/java/org/apache/camel/Predicate.java}}
> * Camel
> {{core/camel-core-processor/src/main/java/org/apache/camel/processor/ChoiceProcessor.java}}
> _AI-generated by Codex on behalf of luigidemasi._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
