Luigi De Masi created CAMEL-25618:
-------------------------------------
Summary: camel-semantic - enhance audit UX, result metrics and
drift monitoring
Key: CAMEL-25618
URL: https://issues.apache.org/jira/browse/CAMEL-25618
Project: Camel
Issue Type: Improvement
Components: camel-jbang, camel-ai, camel-management
Reporter: Luigi De Masi
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. Several implementation PRs are appropriate;
diagnostics, monitoring, metrics and the supporting capabilities remain part of
this enhancement.
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 visualization surface.* Its time windows, filters, comparisons
and display pause affect queries and presentation only. Collection, retention,
thresholds, active detector baselines and notification behavior are configured
outside the TUI. Existing audit configuration remains DSL-owned and frozen
while the service runs.
*Stores store information; calculation belongs to the producer of the
measurement.* Stores persist and retrieve audit records and already-computed
snapshots, and own retention, durability and recovery of stored information.
They do not calculate result statistics, case summaries, coverage or drift.
Camel can provide ordinary counting/formatting utilities and assemble explicit
audit links, but expert/application/monitoring producers own semantic grouping
and comparison policies. Camel exposes supplied measurements and their
availability. Memory and durable stores may offer different retention/recovery
guarantees.
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/monitoring producer | Own measurement semantics, grouping and
comparisons; supply measurements for exposure. The producer can be an expert,
application or external monitoring system. |
| Store | Persist and retrieve supplied records/state; implement retention and
recovery. |
| Console/JMX | Expose the shared records and computed snapshots through their
respective read interfaces. |
| TUI/CLI/MCP presentation | Format and present that data, with read-only
navigation, filters and visualization windows. |
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 visualization time presets, quoted exact filter values, selectors and
explicitly scoped refinements such as text, execution state and result
availability. Preserve the reader's exact-match contract. The existing
{{routeId}} filter remains an Entry route filter; filtering by Executing route
must use an explicitly supported query field or a clearly labelled loaded-page
refinement. Page-local results and counters must be labelled as such. Complete
window counts come from runtime-computed snapshots or a bounded runtime
calculation over sufficiently complete retained data; the store is not required
to calculate them. Stabilize live selection, report new arrivals and make
pause, older pages and expired cursors clear. Update CLI text, JSON, help and
documentation consistently.
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.
Support visible failure notifications and runtime-configured operational
notification hooks without giving the TUI control over them.
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
Whenever an evaluation is being audited, automatically capture its bounded,
contract-declared original interpretation when the configured store/sinks
support it: relevant choice keys/descriptions, score levels, Boolean labels and
explicit no-match or probability-domain relationships where available. No
separate interpretation-capture opt-in is required. Capture effective meaning
at invocation time; editing or deleting a definition must not reinterpret its
history. Raw-input capture retains its existing separate opt-in; this change
does not enable arbitrary prompt, instruction or parameter capture. Agree exact
bounds, field handling and omission representation before emission. 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 runtime cumulative
counters distinct from stored historical aggregates. 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 measurements, comparisons and
signals supplied by an expert/application/monitoring producer, with persisted
snapshots where configured. That producer owns comparison semantics; the store
saves/retrieves supplied state and Camel exposes it. Support visualization
against a supplied fixed reference by default, and a previous-period comparison
when provided or supported by that producer. Show reference/current bounds,
sample counts, exclusions/loss, reported revisions and source-provided
comparison state. Missing information remains not provided. Camel does not
infer comparability or manage semantic changes. A distribution change does not
establish accuracy loss or a security incident and never changes routing
behavior.
Operators may change visualization periods and inspect available comparisons.
Active detector policy remains owned by its producer outside the TUI; a
visualization query does not emit operational signals. Historical windows
depend on the information produced and retained. This enhancement exposes and
visualizes monitoring information without adding a Camel semantic-change
management engine.
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 bounded
captured results, meanings, execution state and provenance. The root supports
exchange-free events; no synthetic Exchange or new core 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 the safe occurrence data once. Feed the typed event directly to the
existing audit recorder, which applies capture policy, attaches permitted input
privately and sends the record through its bounded sink queue. Publish the
input-free event through {{EventHelper.notifyAiEvent}} for expert/monitoring
consumers. This makes the common event contract useful to both features while
preserving audit capture independently of management-listener filters. Audit
records remain the persisted history format; do not store raw event objects or
broadcast captured input.
Result-metric producers consume typed completion events once per assessment
member. They may publish already-computed metric, comparison and signal
snapshots as typed AiEvents; Camel exposes those supplied values through the
existing read-only snapshot surfaces. Distinguish starts, completions, request
outcomes and producer outputs so counters cannot double-count or consume their
own output as another evaluation. Producers retain ownership of calculations,
grouping, comparability and notification policy. Stores persist/retrieve
supplied information, and TUI/CLI/MCP display it.
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
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 feature:* deprecate {{SemanticAuditDecision}} and
phase out its route-decision recording/configuration path, with documentation
and examples using automatic evaluation capture. This API/configuration
lifecycle change requires maintainer agreement; any eventual API removal
follows the normal compatibility process. 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 data compatibility does not restore route actions
as an optional workflow in the proposed model or UI. The runtime transition
must be documented rather than silently turning existing recording calls into
no-ops.
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,
retrieval/persistence contracts, shared snapshot responses and supplied
metric/identity metadata. There is no Camel-owned semantic identity or
meaning-change detection contract. The store contract contains no requirement
to calculate semantic aggregates or comparisons. 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.
# Audited evaluations automatically capture bounded original interpretation on
compatible backends, without a separate opt-in or enabling raw-input capture.
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 displays supplied fixed-reference and previous-period comparisons,
sample counts and source-reported unavailable/incomparable states. Stores
persist/retrieve supplied information; console/JMX expose the same snapshots.
Memory/durable recovery behavior and absent metadata are explicit. Camel does
not infer changes in meaning, impose a versioning scheme or manage comparison
policy. TUI visualization changes do not alter collection, detector state or
notifications.
# 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. Audit capture/input
remain private and 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 deprecates the existing recording
entry point and replaces its examples with automatic evaluation auditing.
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.
h2. Related work and visual references
* [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, diagnostics and Monitoring at 144x40 and
100x30. They contain synthetic examples, not implemented UI screenshots. At
88x24, use a compact list and full-width scrollable inspector.
_AI-assisted content prepared by Codex on behalf of Luigi De Masi
(@luigidemasi)._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
