# Broker lifecycle evidence in SIEM exports

Broker events use a request UUID separate from OpenTelemetry trace identifiers.
A terminal forwarding fault references the durable authorization event UUID;
authorization alone does not prove delivery. Strict shared schema validation
rejects unsupported phases, reasons, self-links and raw content fields.

ECS exports the projected facts under `safetynet.broker`, including request,
connection and original event IDs. Forwarding/inspection faults have an error
type and failure outcome. An authorization has an unknown delivery outcome.

CEF uses the standard custom string `cs2`, labeled `BrokerLifecycle`, for bounded
JSON facts, `cs3` for the original event UUID and `requestContext` for the request
UUID. This preserves the existing rule, file type, trace, span and audit-integrity
fields. Configure the SIEM to parse the custom JSON string when joining causal
events. The standard `outcome` field reflects unknown authorization or failure;
Microsoft documents its mapping to `EventOutcome` in
[CommonSecurityLog](https://learn.microsoft.com/en-us/azure/sentinel/cef-name-mapping).

Typed download records use `download.scan` / `download.block` with the original
request authorization UUID and real file size, magic-derived type and SHA-256.
They never attach a generic request-body hash. A blocked download has a failure
outcome and a denied event type. A successful scan reports inspection success;
it does not prove that the user received or saved the file.

These format and exporter tests do not establish a customer's remote SIEM
deployment, retention, key custody or incident-response configuration. Production
browser-to-broker integration remains a separate acceptance gate.