OBSERVE · CORRELATE · DECIDE
Agent telemetry events: validate correlation fields
Quarantine events whose trace or tenant context is missing.
Apply an explicit application policy
Policy selects Require trace and tenant or Allow missing trace. Fixture chooses Complete events or Missing correlation fields. Both policies require a tenant in this particular application; only the strict policy additionally requires a trace label. Complete events supplies both fields on all twelve records. The missing-fields fixture removes the trace from E02, E05 and E10 and also removes the tenant from E05. The model validates those actual fields and records each failed requirement. Quarantine is a displayed classification: no collector, queue, database or network endpoint receives these records.
Find the first rejected event
Choose Require trace and tenant with Missing correlation fields and seek to nine seconds. Only E01 is complete, so one event is accepted and none is quarantined. At ten seconds E02 completes with its trace missing; the summary becomes one accepted and one quarantined. Seek to twenty-five seconds to inspect E05: both tenant and trace requirements fail, but this is one quarantined event, not two. At sixty seconds the strict policy accepts nine events and quarantines three. All three missing traces remain visible in the summary; validation does not manufacture a correlation identifier.
Relax one requirement without erasing another
Select Allow missing trace and the missing-fields fixture. At sixty seconds eleven events are accepted and only E05 is quarantined, because the tenant requirement remains. E02 and E10 are accepted despite missing traces. This increases accepted coverage but leaves two accepted records without that correlation link. Return to Complete events under either policy: all twelve records pass. Changing a policy always restarts the inspection, so seek to the same completion boundary before comparing totals or capturing a baseline. The text on each completed card includes the actual field values and rejection reasons.
Inspect the completed prefix and record evidence
Play events reveals one completed record every five seconds across a sixty-second inspection. Pause events freezes elapsed time; Resume events continues. Restart clears time while retaining your chosen scenario and speed. Replay events begins again after completion. Timeline seeks and pauses; at nineteen seconds only three records have completed, while twenty seconds includes E04. Speed selects half, normal or double pace and settles the elapsed interval at the previous rate before changing. A hidden tab pauses. Changing Policy or Fixture starts again at zero. Expand experiment enters full screen and Exit full screen restores the page. Capture baseline saves the visible result and settings; Replace baseline updates it and Clear baseline removes it. Notes persist in this browser and Export notes downloads the observations. Read the text as well as the card colors: waiting and active cards expose no outcome before their completion boundary.
Distinguish this policy from a telemetry standard
OpenTelemetry log records may omit trace context. A missing trace is therefore not automatically a violation of the OpenTelemetry data model. Requiring a tenant and trace here illustrates a stricter application ingestion contract. The readable trace labels are synthetic identifiers, not validated W3C hexadecimal trace IDs. This exercise checks presence only; it does not prove identifier authenticity, tenant authorization, schema version compatibility, timestamp validity or event delivery. Accepting an untrusted tenant label is not access control. A real ingestion system also needs trusted attribution, bounded storage, schema migration, redaction, retry and quarantine handling. There are no real user records or credentials in this fixture.