BEACON — the distribution of the audit trail

01Transporting the audit trail without creating a second one #sec_699483b6

BEACON is the distribution channel for REVIEWIT audit events to customer tools: SIEM, object storage or API consumer. It does not produce the proof and does not own the events. Audit Trail proves; BEACON transports.

The ordered audit trail directly constitutes its distribution log. BEACON only keeps the destinations, their reading position and the manifests of the delivered batches. If its state had to be reconstructed, no business event would be lost: the source remains the trail.

This separation protects the audit base from the version cycles specific to Splunk, Sentinel, Elastic or other connectors. A new SIEM dialect is translated on the periphery; it does not modify either the canonical form or the integrity chain.

02One canonical format, several destinations #sec_a182be39

All delivery modes tell the same story. BEACON emits a canonical envelope, aligned with security standards, which carries the audit event in its verifiable form and normalized attributes that are easy to exploit.

The adaptations to CIM, ASIM, ECS, UDM, CEF or LEEF belong to the connector packages. The server chain thus retains a single versioned contract and an additive evolution policy.

Two families of transport cover the main uses:

• HTTP push, including profiles compatible with a collector such as Splunk HEC;
• the deposit of compressed batches and their manifests in the customer's object storage.

The pull exposes the same envelope, paginated by cursor. It can serve as a nominal or catch-up mode. Switching from pull to push does not change the dictionary, the verification tool, or the meaning of the events.

03No silent hole #sec_39c1a83b

Delivery is at least once: after a network uncertainty, the same batch may be presented again. Its deterministic identifier and the stable identifier of each event allow the consumer to deduplicate it.

BEACON never skips a difficult-to-deliver event. After exhausting attempts, the destination is paused and an incident is raised. The resumption starts from the last acknowledged checkpoint. The failure of a destination does not affect the other destinations, the writing of the trail, or the business act at the origin of the event.

If the interruption exceeds the hot window of the trail, the destination goes into an explicit state of required recovery. A traced operation then reconstitutes the range from the archive before resuming the current flow. The absence of a hole remains true even in the degraded case; it does not rely on the hope that the destination will come back quickly enough.

A filter does not create any more disruption. Events outside the scope are replaced by minimal milestones that preserve cryptographic continuity without revealing their content. The customer can therefore limit the data received while verifying that the sequence has not been amputated.

04A manifest to exercise the proof #sec_0b739556

Each batch is accompanied by a manifest that describes its sequence range, its input and output fingerprints, the number of events and milestones, as well as the integrity rules used. When the range is covered by a seal, its reference is included.

The BEACON verification tool recalculates the chain, checks the continuity between several batches and produces a dated report. It announces the level actually demonstrated: continuity by chaining, coverage by a seal, or external anchoring when it exists. The presence of a transport signature is never presented as stronger proof than the trail itself.

The acknowledgment of a batch, the persistence of its manifest and the advancement of the checkpoint form a coherent operation. A restart may cause a new identical delivery, never a declared delivered range without the manifest that documents it.

05Residence and security boundary #sec_0a77479b

BEACON workers run in the subscription region and push to the destination declared by the customer. The flow does not transit through a parent region. When the actual region of an endpoint cannot be technically verified, the inter-regional choice is subject to explicit and audited recognition.

Transports use HTTPS, mTLS when the destination allows it, and an anti-replay signature per batch. Destination secrets are kept in a vault, referenced by the configuration, never placed in clear text in the parameters or logs.

The governance of the channel is itself audited: creation, modification, pause, resumption and deactivation of a destination become events. The system that exports the trail therefore remains subject to the trail.

06In summary #sec_1d392ef5

BEACON delivers the proof without duplicating it. Its unique format, its checkpoints, its manifests and its milestones guarantee an ordered, resumable and verifiable flow to the customer's security tools, without putting the SIEM on the path of business operations.