[
https://issues.apache.org/jira/browse/CAMEL-25618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18143848#comment-18143848
]
Claus Ibsen commented on CAMEL-25618:
-------------------------------------
[~ldemasi] the scope of this issue went in with [PR
#27791|https://github.com/apache/camel/pull/27791] (merged 2026-10-14), and
there is no open PR for it, but the issue is still In Progress with fix version
4.24.0.
We plan to release 4.24.0 next week. Can you check what is left?
* If the work is done, please resolve this issue.
* If there is more work, consider creating a new JIRA for it (fix version
4.25.0) and resolve this one, so it does not hold up the release.
* Any quick things you want in 4.24.0, please get them in this week.
_Claude Code on behalf of davsclaus_
> camel-semantic - enhance audit UX and expose current result measurements
> ------------------------------------------------------------------------
>
> Key: CAMEL-25618
> URL: https://issues.apache.org/jira/browse/CAMEL-25618
> Project: Camel
> Issue Type: Improvement
> Components: camel-ai, camel-jbang, camel-management
> Reporter: Luigi De Masi
> Assignee: Luigi De Masi
> Priority: Major
> Fix For: 4.24.0
>
> Attachments: semantic-audit-framed-100x30.png,
> semantic-audit-framed-144x40.png, semantic-diagnostics-framed-100x30.png,
> semantic-diagnostics-framed-144x40.png,
> semantic-monitoring-framed-100x30.png, semantic-monitoring-framed-144x40.png
>
>
> h2. Motivation
> Build on the semantic auditing delivered by CAMEL-25499 to give operators a
> consistent way to inspect the expert's returned result and the route where
> the evaluation was invoked, follow related evaluations, and observe changes
> in results over time. Simplify semantic audit to automatically captured
> evaluations, their execution lifecycle and runtime provenance.
> A fixed-purpose injection classifier, an instruction-driven choice or score
> expert, and a moderation or business-policy expert should be understandable
> through the same vocabulary. Operators also need counts such as “how many
> requests selected billing?”, “how many Boolean answers were true?” and “has
> the urgency distribution changed?”, without deriving production metrics from
> whichever Audit page happens to be open.
> Deliver the complete scope below in [PR
> #27791|https://github.com/apache/camel/pull/27791], organized into four
> reviewable commits: explicit expert requirements, audit foundation and
> presentation, shared monitoring and presentation, and playground/layout
> controls. Diagnostics, monitoring, metrics and the supporting capabilities
> remain part of this enhancement. Intended fix version: *4.24.0*.
> h2. Shared model and ownership
> *Drop route-action auditing and route-authored business metadata from the
> target design.* Remove the separate route-decision concept from new capture,
> configuration, the shared presentation model and the TUI/CLI/MCP workflows.
> Do not retain it as an optional feature. This removes action declarations,
> action vocabularies, application operation/target, policy/rule metadata,
> policy reasons, action-specific filters/counters and decision-to-evidence
> panels. Audit should expose what the expert returned and how the evaluation
> ran. Ordinary route behavior stays the responsibility of the application and
> is not represented as a semantic audit decision.
> Keep *Result*, *Execution status*, *Assessment operation* and *Execution
> reason* distinct. Preserve the expert's returned Boolean, choice, score or
> classification, its captured meaning, expert instance/provider, definition
> name, invocation origin and recorded route/exchange/breadcrumb context. A
> Boolean true, classification label or high score never implies allow/block or
> severity. Auditing requires no decision bean, route annotation,
> business-metadata block or cross-reference beyond its ordinary configuration.
> Original result interpretation remains captured automatically; it is separate
> from the business annotations being dropped.
> *Camel exposes information; experts and applications own its meaning.*
> Capture and expose supplied interpretation, model/revision and optional
> task/version identifiers as reported. Camel does not detect meaning changes,
> derive semantic identities, require authors to version every question, decide
> whether two populations mean the same thing, or automatically split
> series/reset baselines. Meaning, versioning, grouping and comparison policies
> belong to the expert, application or external monitoring system. Missing
> metadata is displayed as not provided.
> *The TUI is a runtime inspection surface.* Audit supports retained-history
> filters and navigation. Monitoring displays current measurements, bounded
> grouping, collection health and display pause. Durable metric history,
> historical queries, baselines, comparisons, detectors, alerts and dashboards
> belong to the external monitoring system. Existing audit configuration
> remains DSL-owned and frozen while the service runs.
> *Audit stores store audit information.* They persist/retrieve audit records
> and own retention and durability. Camel monitoring has no snapshot-store SPI,
> recovery queue, sampled history, comparison reports or example audit-event ID
> lists. Its immutable snapshots are transient reads of current measurements.
> Camel supplies bounded instrumentation and formatting; external monitoring
> owns durable time-series storage, analysis and cross-signal correlation.
> Bulk retrieval has a separate responsibility boundary.
> {{SemanticAuditReader.getAll(eventIds)}} retrieves records by ID without a
> universal evidence-specific 100-ID cap. Console/API callers enforce
> request-size and response budgets. Backend implementations manage their own
> batch limits and may split retrieval into smaller storage queries. Preserve
> legacy v1 evidence-record validation, existing query page limits and input
> bounds. Support existing readers that still enforce the old cap through
> bounded caller-side chunking during migration. Do not silently truncate
> requested IDs or treat a lookup failure as a missing record. This requires
> runtime/SPI and caller changes, with no new persisted field or breaking
> storage-schema change.
> Keep responsibilities small and explicit:
> ||Part||Responsibility||
> | Expert/adapter | Assess the submitted input and declare result meaning. |
> | Route | Invoke the expert and continue normal application routing; no
> separate audit decision declaration. |
> | Audit runtime | Capture evaluation results, execution outcomes and
> available runtime context automatically; associate evaluations, batch members
> and request outcomes using their recorded identifiers. |
> | Metric producer | Collect current measurements with explicit meaning,
> units, population and bounded dimensions. |
> | External monitoring system | Own time-series history, comparisons, alerts,
> dashboards and cross-signal correlation. |
> | Audit store | Persist and retrieve audit records; implement audit retention
> and durability. |
> | Console/JMX | Expose audit records and transient current-measurement
> snapshots. |
> | TUI/CLI/MCP presentation | Inspect retained audit records and current
> measurements with read-only navigation and filters. |
> These are responsibility boundaries, not a request for a new framework or
> module for each row. Reuse existing Camel infrastructure, give each
> calculation one owner, and avoid separate accumulators or monitoring logic in
> stores, management interfaces and clients.
> h2. Proposed scope
> h3. 1. Consistent Audit, CLI and playground presentation
> Introduce a shared result formatter for Boolean, choice, score and
> classification, used by Audit, CLI and the playground with the appropriate
> captured/submitted interpretation. Show exact fractional scores, empty label
> sets, omitted results, keyed probabilities and confidence without rounding
> them into policy judgments. Probability and confidence retain their own
> meanings.
> Use bordered panels: context and visualization controls at the top, the
> evaluation table in the centre, a selected-record inspector below it, and
> persistent health and keyboard hints. Keep expert identity and typed result
> visible. At 144x40, show Timestamp, Executing route, Evaluation,
> Expert/provider, Result, Execution, Duration and Breadcrumb. The selected
> evaluation's inspector presents returned result and captured meaning beside
> execution/provenance details. At 100x30, retain Timestamp, Executing route,
> Expert, Result and Execution in the table; move the definition name, provider
> and identifiers into the single-column details, with an expanded inspector
> available. At 88x24, use a compact list and a full-width scrollable
> inspector. Request lifecycle records remain accessible through their
> invocation relationship. Do not add route-action panels, selectors or
> alternate views. Use text labels alongside colour and local timestamps with
> clear date/time-zone information. The mockups illustrate this layout; they
> are not required to understand the feature.
> *Executing route is automatic runtime provenance.* Capture the route invoking
> the evaluation from the Exchange's active route context when evaluation
> starts, before expert work is dispatched. Camel already exposes this through
> {{ExchangeHelper.getAtRouteId(exchange)}}. The currently stored {{routeId}},
> obtained from {{exchange.getFromRouteId()}}, identifies the entry route;
> preserve its meaning and existing filter behavior. Propose a separate bounded
> optional {{executingRouteId}} field, subject to the compatibility rules
> below. For an exchange entering {{http-entry}} and invoking an evaluation
> inside {{prompt-screen}}, show Executing route {{prompt-screen}} and retain
> Entry route {{http-entry}} in details. Do not reconstruct the executing route
> from an exchange/breadcrumb identifier, today's route definitions or
> completion-time context. No author-supplied metadata or new DSL option is
> required. Older records show executing route as “not recorded”; calls without
> an Exchange show “n/a.” If an Exchange has no active route context, leave
> that identity unavailable rather than substituting the entry route. Missing
> executing-route capture never prevents browsing existing history.
> *Store both identifiers; keep the table concise.* {{exchangeId}} and
> {{breadcrumbId}} already belong to the version-1 record. When both are
> available, including a valid breadcrumb, retain both as separate fields in
> the same audit record. Exchange ID identifies the individual Exchange;
> Breadcrumb ID associates related exchanges. Auditing copies Camel's existing
> breadcrumb and does not generate a replacement or substitute Exchange ID
> under that name. Storage durability and retention remain backend
> responsibilities; viewing history reads the stored identifiers without
> needing the live Exchange. This is independent of raw-input capture and needs
> no new schema fields for either identifier.
> *Breadcrumb ID is the only correlation identifier shown as a table column.
> Exchange ID is detail-only.* Every Audit/diagnostics detail view shows both
> recorded identifiers with explicit labels and access to their full values;
> long table values use visible ellipsis. At narrow widths, breadcrumb also
> moves into details to keep Executing route and Result readable. An absent
> breadcrumb is labelled “not recorded,” without claiming why it is missing.
> Missing identifiers do not prevent audit inspection. Neither ID is a route
> location, and a shared breadcrumb alone does not prove causal linkage or case
> completeness.
> Add audit time presets, quoted exact filter values and explicitly scoped
> loaded-page refinements. Extend SemanticAuditQuery with inclusive since and
> exclusive until event/completion timestamps, selecting [since, until). Add
> exact definition/operation filters and explicitly typed result predicates:
> Boolean/Choice equality, numeric Score equality and inclusive ranges,
> Classification membership. Value predicates require a compatible resultType;
> missing/omitted results never match. No-match is an expert-defined Choice
> label, not an inferred execution status. Apply filters before pagination and
> bind cursors to both bounds and all predicates. Preserve the original
> open-ended constructor. Older readers opt in through supported query fields;
> reject unsupported filters instead of broadening queries. Only captured
> retained records are searchable, which may differ from the monitored
> population. Stabilize selection, new arrivals, pause, older pages and expired
> cursors; update CLI/TUI/MCP, JSON, help and docs.
> h3. 2. Cases, relationships, health and export
> Group related evaluations and request outcomes by a source-scoped breadcrumb,
> with clearly labelled exchange, invocation and event fallbacks when
> necessary. Show batch siblings and request-to-completion associations using
> captured identifiers. Group membership is association, not proof of causation
> or completeness.
> Distinguish related records not yet loaded, unavailable records, omitted
> results and incomplete retrieval scope. An evaluation is independently
> inspectable; do not introduce missing-action or missing-business-metadata
> warnings. Do not infer the reason an individual record is unavailable from a
> global eviction counter.
> Separate capture, reader, delivery and observed expert health. Show
> per-instance collection state and execution outcomes, retained capacity,
> eviction/drop counts and sink/observer failures. Keep errors visible at
> narrow widths and distinguish disabled capture, no matches and a failed
> backend. Expose collection failures for operational diagnosis; alert rules
> and notifications belong to external monitoring.
> Provide bounded case export and structured MCP case summaries with retrieval
> scope, relationship completeness and missing references. Summaries exclude
> captured input. Explicit input-bearing details/exports identify untrusted
> data and capture/redaction/omission state; apply the same boundary to generic
> TUI-to-AI inspection paths.
> h3. 3. Preserve historical meaning and support useful diagnostics
> Capture the complete contract-declared original interpretation once in the
> typed semantic event: relevant choice keys/descriptions, score levels,
> Boolean labels and explicit no-match or probability-domain relationships
> where available. Freeze effective meaning at invocation time; editing or
> deleting a definition must not reinterpret that event or its retained
> history. There is no producer-side interpretation truncation limit. Each
> retaining consumer enforces its own payload, queue and storage budget. The
> audit recorder creates a bounded projection before enqueueing,
> capability-gates additive fields for its store/sinks, and reports explicit
> omission reasons when its budget or capabilities prevent retaining
> interpretation. No separate interpretation-capture opt-in is required.
> Raw-input capture retains its existing separate opt-in; interpretation
> capture does not enable arbitrary prompt, instruction or parameter capture.
> Older records remain readable, with missing interpretation labelled “not
> recorded”; never reconstruct it from today's definition.
> Enable new persisted interpretation/finding fields and executing-route
> provenance only when the configured store/sinks declare support. Unsupported
> capture is explicitly visible through health/detail responses, without
> sending unrecognized fields to older implementations. Lack of extension
> support does not by itself reject the existing configuration or prevent
> startup.
> Derive diagnostics from existing results: reported top-two probability gap,
> alternatives and ties, explicitly designated no-match, and score modes where
> a declared mapping supports them. Preserve the selected answer even when it
> differs from the highest reported probability. Mark incomplete distributions
> and unavailable interpretation; diagnostics are neither model reasoning nor
> calibrated certainty. No extra inference is required.
> For example, a choice result selecting billing with reported probabilities
> billing=0.68, technical=0.29 and other=0.03 can display the reported top-two
> gap of 0.39 and technical as the next alternative. An ordinary key named
> other is not automatically a no-match answer. A score of 1.6 remains 1.6;
> captured level descriptions may explain its position between levels, but
> cannot turn it into a discrete score of 2 or a severity.
> Allow explicit transfer of permitted captured input into a new playground
> draft. Identify missing original parameters and changed execution context;
> never claim exact replay. Browsing and draft creation do not invoke an
> expert. Evaluation remains the playground's separate, explicit Run action.
> h3. 4. Typed-result metrics and expert-owned MBeans
> Provide shared utilities for bounded typed-result counters/distributions and
> expose expert-owned measurements independently of audit retention and TUI
> polling. Measurement producers supply their dimensions and any task/version
> identifiers; Camel does not derive semantic identity or manage series
> versions:
> * *Choice:* count the selected answer once per successful evaluation; include
> proportions and denominators. Probability entries are not additional answers.
> * *Boolean:* count the returned true/false answer. For TypeSafe yes/no
> questions, use the adapter's final Boolean; do not apply another threshold. A
> reported yes-probability histogram is a separate metric. Failures and
> unavailable results are not false answers.
> * *Score:* count, sum, minimum/maximum and bounded numeric histograms.
> Preserve fractions; exact level counts require discrete-level semantics.
> * *Classification:* per-label membership and empty-set counts. Multiple
> labels may contribute to one evaluation; percentages need not sum to 100%.
> Count completed assessment members, including batch members, rather than
> provider calls. Separate provider attempts and semantic completions,
> exclusions, unavailable results and collection loss. The metric owner defines
> grouping and decides how question, criterion, model or policy changes affect
> its series. Camel preserves the supplied dimensions and exposes their
> meaning; it does not infer semantic continuity or automatically create a new
> series.
> Expose shared health and expert-described metric snapshots through *JMX, TUI,
> CLI and MCP*, using the same read-only source. JMX remains optional at
> deployment. Experts own the measurements and supply their name, meaning,
> kind, unit, values and bounded dimensions. They may own a facade and
> contribute provider-specific metrics without duplicating collection. Use a
> small optional description/snapshot contract through the console for generic
> presentation; do not introspect arbitrary MBeans or add provider-specific TUI
> branches. Experts without custom metrics need not implement this extension.
> Use bounded tables/buckets, lifecycle registration and no MBean per
> answer/event. Console and JMX consume the same snapshot; reads do not run
> inference, scan all records or synchronously query a remote store. Include
> interval/epoch, units, denominators and availability. Keep current runtime
> counters distinct from historical aggregates owned by external monitoring.
> Honor JMX-disabled deployments; expose no reset, threshold, baseline or
> lifecycle mutations on the new metrics facade.
> h3. 5. Semantic Monitoring and AiEvent integration
> Add a sibling Semantic Monitoring view for current counts, distributions,
> evaluation durations, observation times, supplied expert/definition grouping
> and collection health. Console/JMX/CLI/TUI/MCP share one bounded
> current-value cache. Remove fixed/previous comparisons, historical-period
> controls, detector state, reference/current reports and example audit-event
> IDs. External monitoring systems own those responsibilities; investigation
> can query audit by time, definition/operation and typed result.
> The current-value cache refreshes once per second and holds at most 100
> series from at most 32 registered sources, with at most 64 measurements per
> source sample. New values replace the previous value; successful source reads
> remove retired series. Source failures retain the last sampled values with
> explicit failure health. Restart clears the cache. Remove
> SemanticMonitoringStore, SemanticMonitoringConfiguration, persistence
> workers, startup recovery and sampled history. No durable monitoring backend
> or Camel-side historical query integration is included. CAMEL-25648
> separately adds optional Micrometer instrumentation and Prometheus export
> across Main, Spring Boot and Quarkus.
> Use the merged common AiEvent API from CAMEL-25408 as the shared occurrence
> contract for Audit and Monitoring. Add component-owned typed Semantic events
> for evaluation starts/completions and request outcomes, carrying captured
> results, complete frozen interpretation, execution state and provenance.
> Route-bound evaluation notifications implement the existing
> {{AiEvent.ExchangeAiEvent}} contract and expose the live Exchange to standard
> exchange-aware listeners. Detached direct calls and request outcomes use
> exchange-free events; never create a synthetic Exchange. No new core event
> hierarchy is needed. Keep expert identity and adapter provider in the typed
> payload and use a stable publishing-family label. AiEvent is the specialized
> Camel event contract/envelope that producers implement and consumers
> recognize. Assessment fields deliberately belong to the Semantic
> specialization; the common root remains generic. EventHelper publishes
> notifications and EventNotifier defines the consumer contract. AiEvent itself
> does not define a wire transport, queue or persistence format.
> Construct and freeze the occurrence data once. Feed the typed event directly
> to the existing audit recorder, which applies capture policy and its own
> retention budget, attaches permitted captured input privately and sends the
> frozen record through its bounded sink queue. Publish that same event through
> {{EventHelper.notifyAiEvent}} for expert/monitoring consumers. The typed
> data, JSON representation and safe string summary exclude raw input, but a
> route-bound event deliberately exposes its live Exchange (including body and
> headers) through {{getExchange()}}/{{getSource()}}. This is an in-process
> listener contract, not a promise that the whole event is input-free.
> Listeners must keep callbacks short, avoid payload dumps, and freeze/project
> any data they retain; audit stores, queues and monitoring snapshots never
> retain the live Exchange or raw event. Audit capture remains independent of
> management-listener filters. Audit records remain the persisted history
> format.
> Result-metric producers consume typed completion events once per assessment
> member. They may publish current measurements as typed
> SemanticMonitoringEvent outputs, distinct from evaluations so counters cannot
> consume their own output. Camel exposes current measurements; external
> monitoring owns comparisons and signals. Per-execution identifiers belong in
> audit/log/trace records. Correlation, exchange, breadcrumb and invocation IDs
> must not be metric labels. Standard tracing exemplars may supply sampled
> metric-to-trace references where supported; Camel maintains no audit-event
> example list.
> Use the merged helper's notifier lifecycle, filtering and failure isolation,
> with short callbacks and bounded consumer processing. Expose measured
> loss/freshness; event dispatch is synchronous, best effort and supplies no
> durable replay. Monitoring consumers and event production work with audit
> retention disabled and no TUI attached. Preserve existing SemanticObserver
> compatibility and its parent-context/detached tracing hooks; AiEvent does not
> replace those guarantees. This integration requires runtime/component work,
> not a breaking persisted-schema change or an OpenTelemetry dependency in
> camel-semantic. Existing tool/loop events may support their own activity
> metrics, but do not fabricate semantic results or route actions from them.
> h3. 6. Expert-reported findings
> Support bounded expert-authored findings with their supplied meaning and
> severity provenance. Missing severity means not reported; never derive it
> from a Boolean, score or confidence. Findings describe the expert's
> assessment and remain supplementary to its returned typed result.
> Drop route-authored policy priority, policy/rule coverage and
> enforcement-evidence views that depended on the removed route-decision
> metadata. Business-policy experts continue to report ordinary Boolean,
> choice, score or classification results and expert-owned findings through the
> same generic presentation.
> h2. Compatibility and implementation areas
> Prefer *(a) presentation changes* and *(b) optional, versioned console
> enrichment* for relationships, aggregates and capabilities. Agree *(c)
> bounded additive record fields* only where historical interpretation,
> findings or executing-route provenance need persistence. Both identifiers
> already exist: showing Breadcrumb ID in the table and both IDs in details is
> *(a)*. Showing the existing entry route is also *(a)*; capturing the separate
> executing route is runtime work with a proposed *(c)* field, requiring
> maintainer agreement. Keep {{routeId}} and its query semantics unchanged.
> Existing v1 allowlists require capability-gated emission: keep older records
> readable and existing store/sink configurations usable, and visibly report
> unsupported capture. The declaration/negotiation mechanism still requires API
> design. *No (d) breaking record-schema change is proposed.* Runtime
> collectors, store capabilities and management projections are additional
> work, not presentation-only changes.
> *Migration of the dropped preview feature:* remove {{SemanticAuditDecision}}
> and its route-decision recording/configuration path outright, with
> documentation and examples using automatic evaluation capture. Semantic and
> expert APIs are preview APIs and may change without a deprecation period;
> document these removals in the 4.24 upgrade guide. Preserve the ability to
> deserialize and export already-persisted v1 decision records as legacy data.
> Do not delete stored history, reinterpret it as an evaluation, or remove
> accepted fields from the v1 storage schema. Legacy compatibility does not
> restore route actions as an optional workflow. Do not silently turn old
> recording calls into no-ops.
> *Explicit experts:* require an explicit registry expert on each evaluation.
> Remove language default-expert configuration, sole-expert fallback,
> block-level expert inheritance and adapter service discovery. Providers
> remain available through explicitly registered SemanticExpert/SemanticAdapter
> beans. Update declarations, schemas, resolver/tooling metadata, documentation
> and the upgrade guide consistently. These are agreed preview
> API/configuration changes, not removals of the expert/adapter extension
> contracts themselves.
> Build on SemanticAuditRecord, SemanticAuditQuery, SemanticAuditConsole,
> SemanticAuditService, SemanticObserver, SemanticAuditView,
> SemanticResultView, the semantic CLI and TUI MCP tools. Add optional
> capabilities with explicit unsupported/partial states; do not impose
> full-store scans on the one-second refresh or require every custom
> reader/expert to implement every extension. Collection and notification
> failures must not change inference or routing behavior.
> The interpretation/finding/provenance compatibility behavior and
> storage-versus-calculation boundary are specified above. Implementation
> review must settle bounded field definitions and capability negotiation,
> audit retrieval contracts, transient current-measurement responses and
> supplied metric/identity metadata. There is no Camel-owned semantic identity
> or meaning-change detection contract. Audit stores do not calculate semantic
> aggregates or comparisons; monitoring persistence is outside Camel. Exact SPI
> signatures, field names and management naming follow implementation review.
> h2. Acceptance criteria
> # Boolean, choice, fractional score, empty classification, omitted result,
> failed execution and business-policy assessment fixtures retain distinct
> meanings across TUI, CLI and MCP. Shared result formatting agrees with the
> playground.
> # Typed events carry complete frozen interpretation without producer-side
> truncation. Audited evaluations automatically retain bounded projections on
> compatible backends, without a separate opt-in or enabling raw-input capture;
> each retaining consumer owns and enforces its budgets. Definition
> edits/deletion do not change captured historical labels. Older records remain
> readable with missing interpretation labelled “not recorded.” New fields are
> emitted only with declared store/sink support; unsupported capture is visible
> and does not prevent startup. Capture bounds and mixed-version behavior are
> documented and tested.
> # Route-bound and direct assessments, unavailable related records, absent
> breadcrumbs, partial batches and cancellation-followed-by-completion are
> navigable without fabricated results or completeness claims. Evaluation
> auditing works without a decision bean, route annotation or business-metadata
> configuration. Cases associate evaluations and lifecycle records through
> their captured identifiers.
> # The framed layouts work at 144x40, 100x30 and 88x24. Selection,
> input-loading states, mixed dates, quoted filters, narrow-width errors and
> keyboard/help parity are verified.
> # Summary/list/metrics surfaces remain input-free. Explicit input detail,
> case export and draft handoff preserve the trust boundary and never trigger
> automatic inference.
> # Known fixture populations produce correct choice, Boolean, numeric and
> classification measurements, with batch members counted once and
> omissions/loss visible. Supplied dimensions/revisions survive capture and
> exposure unchanged. Camel neither infers semantic changes nor automatically
> splits, merges or resets series; missing versions do not prevent ordinary
> audit/metric exposure.
> # An expert-defined metric is visible through JMX, TUI, CLI and MCP with
> matching supplied name, meaning, unit and values. Metrics are read-only,
> cardinality is bounded, lifecycle cleanup works, and disabled JMX leaves
> console-based functionality available. No surface independently redefines the
> metric or duplicates its collection.
> # Monitoring exposes current measurements through one shared
> JMX/console/CLI/TUI/MCP cache, without a monitoring-store SPI, retained time
> history, recovery, reference/current comparisons, detector state or
> audit-example IDs. Expert/definition grouping and display pause do not change
> collection. External monitoring owns durable time-series storage, historical
> querying, analysis and correlation.
> # Typed Semantic AiEvents feed audit recording and expert/monitoring
> consumers for route-bound and direct evaluations, with audit-disabled
> monitoring and no TUI required. Each completed batch member is counted once;
> starts, request outcomes and supplied monitoring outputs are distinct.
> Route-bound notifications expose the live Exchange through ExchangeAiEvent;
> detached notifications do not fabricate one. The frozen data/JSON and summary
> surfaces exclude raw input, while opt-in audit input capture remains
> independent of management-listener filters; history remains readable without
> an event consumer. Verify listener failure/queue-loss behavior, supplied
> snapshot exposure and compatibility with existing observer tracing hooks.
> # Expert-reported findings retain their author, meaning and supplied severity
> scale; absent severity is explicit. Documentation and examples cover a fixed
> classifier, an instruction-driven expert and provider-independent
> classification/business-policy data without route-authored policy metadata or
> coverage claims.
> # A nested-route fixture entering route A and invoking an evaluation in route
> B records Entry route A and Executing route B at invocation time, without
> additional author configuration. Completion, route renaming/deletion and
> historical browsing do not change those recorded identities. Existing
> {{routeId}} filters keep their entry-route meaning. Direct calls, missing
> active route context, old records and unsupported capture are represented
> without guessing a location or preventing normal audit operation.
> # A record with both valid identifiers retains {{exchangeId}} and
> {{breadcrumbId}} together through storage and retrieval. Breadcrumb ID is the
> only correlation column in the wide table; Exchange ID is never a table
> column. Detail boxes expose both full recorded values. At narrow widths both
> IDs remain accessible in details while Executing route and Result stay
> readable. Absent breadcrumbs are handled without generating or relabelling
> identifiers. Summary/list responses remain input-free.
> # Route-action auditing is dropped from the target capture/configuration
> model and TUI/CLI/MCP presentation, including its metadata, filters,
> counters, panels and policy-coverage dependencies. Migration removes the
> preview recording entry point outright and replaces its examples with
> automatic evaluation auditing; the 4.24 upgrade guide documents the removal.
> Already-persisted v1 decision records remain deserializable/exportable as
> legacy data without restoring the removed feature or breaking the storage
> schema.
> # Bulk retrieval accepts a permitted request exceeding 100 IDs without an
> evidence-specific SPI limit. Caller request/response budgets are enforced,
> backend chunking returns all available requested records, and existing
> readers with the old cap remain usable during migration. Missing records
> remain distinct from retrieval failures. Legacy v1 evidence-record
> validation, query page limits and input bounds remain unchanged.
> # Every evaluation names its expert registry bean explicitly. Remove default
> experts, sole-expert fallback, block-level experts and adapter service
> discovery; migrate Java/XML/YAML declarations, validator schemas, tooling,
> providers, examples and upgrade guidance. Missing expert references fail
> clearly. This requirement does not remove the SemanticExpert or
> SemanticAdapter extension contracts.
> # Monitoring current values refresh each second, replace prior values, remove
> retired series and clear on restart. Tests cover source/series bounds,
> failure isolation, failure health and lifecycle cleanup. Audit tests cover
> half-open time windows, exact definition/operation filters, typed
> equality/membership/ranges, missing/omitted values, reader capabilities and
> cursor binding across all client surfaces.
> h2. Related work and visual references
> * [CAMEL-25648: Micrometer instrumentation and Prometheus
> export|https://issues.apache.org/jira/browse/CAMEL-25648] — follow-up export
> integration; historical querying and presentation remain outside Camel.
> * [CAMEL-25499: semantic audit
> foundation|https://issues.apache.org/jira/browse/CAMEL-25499] — follow-up to
> the delivered implementation.
> * [CAMEL-25357: semantic dev
> console|https://issues.apache.org/jira/browse/CAMEL-25357] — overlapping
> foundational proposal; coordinate scope and reuse the existing
> console/recorder.
> * [CAMEL-25408: common AiEvent
> API|https://issues.apache.org/jira/browse/CAMEL-25408] and [PR
> #27714|https://github.com/apache/camel/pull/27714] — Resolved/Fixed and
> merged, verified 2026-10-13; the common API is available on main for 4.24.0.
> Build the Audit/Monitoring event integration on this foundation; no pending
> upstream hierarchy/dispatch request remains.
> * [CAMEL-23369: GenAI
> observability|https://issues.apache.org/jira/browse/CAMEL-23369] — coordinate
> common telemetry integration; this issue adds semantic result/case/monitoring
> meaning.
> * [Original framed layout
> reference|https://issues.apache.org/jira/secure/attachment/13085107/13085107_camel-semantic-audit-tui.png]
> — layout inspiration only; the proposed mockups use the information model
> described here.
> The attached mockups illustrate Audit and diagnostics at 144x40 and 100x30.
> The original Monitoring comparison mockup is superseded by the
> current-measurement boundary above. They contain synthetic examples, not
> implemented UI screenshots. At 88x24, use a compact list and full-width
> scrollable inspector.
> _AI-generated by Codex on behalf of
> [luigidemasi|https://github.com/luigidemasi]._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
