Observation Manual

This manual teaches operators how to read CLARIXO signals without misreading healthy, degraded, fallback, or review-needed behavior.

Use it to interpret overview metrics, queues, breakdowns, provider attribution, and runtime-detail pages correctly.

Inspect Runtime Flow Back to API Next: Troubleshooting Manual Back: Calibration Manual
Layer 1

Overview page

Read total volume, healthy rate, fallback rate, low-confidence rate, and review counts as operating signals, not vanity metrics.

Layer 2

Queues

Use queues to find what needs operator action now: review backlog, degraded clusters, and unstable segments.

Layer 3

Breakdowns

Use breakdowns by source, module, scene, provider, or status to see where instability is actually concentrated.

Layer 4

Runtime detail

Use runtime-detail pages when the overview shows a signal but operators still need cause-level explanation.

Healthy does not mean perfect
Healthy means the turn stayed within the accepted operating contract for that scene.
Fallback is not always failure
Fallback may still be an acceptable degraded outcome, but operators should still see that the chain relied on degraded handling.
Low confidence is an attention signal
Treat low confidence as a signal to inspect concentration, drift, or calibration mismatch.
Needs review is an operator contract
It is only useful if the organization has agreed what reviewable means and who owns actioning it.
Queue Detail

Read Queue Detail as the second operator layer after overview

What Queue Detail is for
Use Queue Detail after overview shows that a queue is non-zero. It is the page where operators inspect the actual queue items behind fallback, low-confidence, manual-review-pending, or contract-issue counts.
What fields operators should read first
Start with time, module, scene, provider, final status, and queue reason. Those fields tell you whether the queue is concentrated in one host role, one traffic segment, or one provider path.
How to interpret the current Confidence column
If Confidence shows Not captured, treat it as missing observation depth rather than as a hidden failure. The queue item is still real even when confidence is not yet surfaced.
What the current runtime button means
Open Runtime Detail now opens the precise runtime-detail page for that queue item by carrying the item event identifier into Runtime Detail. Operators should use it when they need exact cause-level inspection for a specific fallback, low-confidence, manual-review, or contract-issue row.
How Queue Detail and Runtime Detail now work together
Queue Detail is the item list layer; Runtime Detail is the exact event-reading layer. Start in Queue Detail to identify the row that needs review, then open Runtime Detail from that row to inspect the corresponding event payload, routing path, provider outcome, guard summary, and captured runtime context.
How to use each queue type correctly
Fallback Queue shows degraded path usage. Low Confidence Queue highlights unstable or weak-answer segments. Manual Review Pending shows turns that still require operator action. Contract Issues usually point to integration-boundary or schema-preservation mistakes.
Operator reading order:
    1. Start with overview rates
    2. Open Queue Detail for the non-zero queue
    3. Read item concentration by module / scene / provider / final status
    4. Open Runtime Detail from the specific queue row that needs exact diagnosis
    5. Use the event-level runtime detail for cause-level interpretation
    6. Decide whether this is calibration, troubleshooting, or optimization work
Previous Manual

Calibration Manual

Read it first when you still need to align meanings, degraded interpretation, and review logic.

Next Manual

Troubleshooting Manual

Use it when the observation layer exposes a symptom and you need to trace back to the broken layer.

Companion

Optimization Assistant Manual

Use it after observation identifies a concentration or instability that may justify structured optimization work.