Describe the business event
A consumer should receive an operational event rather than an internal tensor or detector response. A practical contract defines event type, time, source, attributes, evidence references, scenario version and diagnostic context.
Choose the transport
An API, message queue, Kafka, file export or specialist adapter is selected for the receiving system. The delivery specification provides endpoints, authentication and exact schemas. Do not infer transport compatibility from the existence of an event.
Respect the contract boundary
| Boundary | Authoritative contract |
|---|---|
| Model output | Model protocol and output structures |
| Scenario block output | Installed block definition and required attributes |
| Stored BOX 3.x event | StoredViolationEvent in the target OpenAPI |
| External system | Agreed integration payload and delivery rules |
Platform 4.0 run results use the event-creation block’s structure. This must not be replaced with the stored BOX 3.x event schema.
Retries and polling
Use a stable event identifier for deduplication. Page number and array position are not event IDs. Track verification-state changes separately from first delivery. Define timeouts, retries, unavailable recipients and idempotency.
Test failure cases
- Empty result sets and missing evidence media.
- Repeated delivery of the same event.
- An event’s verification status changing after initial delivery.
- Removed events and expired evidence links.
- Schema changes and validation failures.