> ## Content Index > Fetch the complete content index at: https://samp-protocol.org/llms.txt > Use this file to discover other available public pages before exploring further. # SAMP Engineering Notes #11 - URL: https://samp-protocol.org/event-delivery-is-not-a-durable-audit-log/ - Published: 2026-11-06T16:43:12.000Z - Updated: 2026-11-06T16:43:12.000Z - Description: Receiving an event is not the same as recording it. Explore SAMP PUSH notifications, subscription ownership, duplicate delivery, recovery limits, and the boundary between events and durable audit records. - Author: Stelio E. Efstathiou - Tags: Engineering Notes, SAMP Articles ## Event Delivery Is Not a Durable Audit Log *Understanding SAMP PUSH notifications, subscription ownership, duplicate delivery, transport failures, and the boundary between operational events and authoritative records.* ### 1\. The Event Arrived. But Was It Recorded? Consider an AI agent operating in a Security Operations Center. The agent detects an abnormal runtime condition and sends an event to its management system. The notification contains a unique event identifier, a severity indication, and information describing the observed condition. The SAMP Manager receives the notification over HTTPS. The HTTP request completes successfully. A moment later, the Manager crashes before the event is committed to persistent storage. Was the event delivered? At the transport layer, the HTTP exchange completed. Was the event durably recorded? Not necessarily. Can an incident-response system safely conclude that the event is available for later investigation? No. Now consider the opposite failure. The same event arrives twice through two overlapping subscriptions. The Manager processes both deliveries independently and creates two incident records. The event was not lost. Instead, its duplication produced an incorrect operational result. These two scenarios reveal an important distinction: **Event delivery, event processing, and durable event recording are different properties.** SAMP makes this distinction explicit. Its event-management mechanisms provide structured communication, but they do not claim to implement a reliable distributed event broker or an append-only audit database. Understanding this boundary is essential when building monitoring, SOC automation, incident management, or AI-agent orchestration systems on top of SAMP. ### 2\. PUSH Is a Notification, Not an Acknowledged Transaction SAMP defines PUSH as an Agent-to-Manager asynchronous notification. Unlike QUERY, CONFIG, or EXEC, PUSH does not use a SAMP request-response exchange. Its direction is `notification`. The PUSH payload identifies the event and its operational context through fields including: | Field | Purpose | | --------------- | ----------------------------------------------------------------- | | event | Event type | | event\_id | Stable UUID identifying the event | | category | Relevant exposed profile category | | data | Event-specific JSON object | | severity | Optional operational severity | | correlation\_id | Optional association with an action, request, or state transition | The event identifier is particularly important. The same logical event must retain its `event_id` across multiple deliveries. However, the event identifier is not the same as the envelope's `request_id`. The two identifiers serve different purposes. `request_id` belongs to the common PDU envelope and its correlation and replay-processing rules. `event_id` identifies the operational event being reported. Confusing the two can cause incorrect deduplication and incident correlation. SAMP v0.2 defines no separate acknowledgment PDU for PUSH. A successful HTTP response completes the transport request. It does not prove that the receiving application has durably stored, investigated, or acted upon the event. This remains true when PUSH is transported through WebSocket. A WebSocket connection can provide efficient continuous communication, but its existence does not introduce a durable event acknowledgment mechanism. **Transport success is not durable acceptance.** An implementation requiring durable ingestion guarantees must provide additional mechanisms outside the core PUSH contract. ### 3\. Subscription Ownership Is a Security Boundary SAMP also defines SUBSCRIBE and UNSUBSCRIBE. These operations allow a Manager to establish and terminate delivery of selected event categories or event types. A SUBSCRIBE request identifies: - The exposed event `category`. - Optional `event_types` filtering. - A requested `ttl_seconds` lifetime. The endpoint validates the request, applies relevant authorization and capacity rules, and, if accepted, creates a subscription. The response includes a `subscription_id`, the accepted TTL, and an absolute `expires_at` timestamp. The subscription belongs to the authenticated Manager that created it. This has several important consequences. First, possession of a subscription identifier does not confer authority. Another Manager cannot use that identifier to inspect or cancel a subscription belonging to somebody else. A request targeting a known foreign subscription must be denied without disclosing its filters or state. Second, subscription identifiers are opaque and unique within the Agent enrollment. They must not be reused within that enrollment. Third, SAMP deliberately limits where `subscription_id` may appear. It belongs in the SUBSCRIBE response payload, the UNSUBSCRIBE request payload, or the common envelope of a subscription-associated PUSH. It must not be duplicated inside the PUSH payload. This provides a consistent distinction between event content and subscription-delivery context. An event describes an observation. A subscription identifies an authorized delivery relationship. Those are not interchangeable concepts. ### 4\. Subscription Expiration Is Not Renewal A subscription has a fixed lifetime. Suppose a Manager requests event delivery for 300 seconds, and the endpoint's declared bounds permit that value. The endpoint accepts the request and creates a subscription that expires 300 seconds after its committed creation time. Now suppose the Manager does not receive the SUBSCRIBE response. The Manager retransmits the original authenticated request. Should the endpoint allocate a new subscription? No. SAMP v0.2 requires recorded-state duplicate protection for SUBSCRIBE and UNSUBSCRIBE. A genuine retry reuses the original authenticated request bytes, including its `request_id`, timestamp, and authentication information. The endpoint returns the original recorded subscription payload inside a freshly generated, authenticated response envelope. It does not create another subscription. It does not extend the existing expiration. Even when the original subscription has already expired, a valid recorded duplicate returns its original subscription result, subject to the protocol's authenticated recovery rules. **A retry is not a renewal.** Core SAMP v0.2 does not define subscription renewal. To maintain continuous event delivery, the Manager must create a replacement subscription before the previous one expires. That replacement is a new SUBSCRIBE operation with a new request identifier. This distinction prevents communication retries from silently changing subscription lifetime or creating additional state. ### 5\. The Duplicate Delivery Problem Replacing subscriptions creates another engineering challenge. Consider the following illustrative sequence. | Time | Event | | -------- | ------------------------------------------- | | 10:00:00 | Manager creates subscription A | | 10:04:30 | Manager creates replacement subscription B | | 10:04:40 | Agent generates event E | | 10:04:41 | Event E is delivered through subscription A | | 10:04:42 | Event E is delivered through subscription B | | 10:05:00 | Subscription A expires | The Manager has received two PUSH notifications. But only one logical event occurred. SAMP requires the Agent to preserve the same `event_id` across copies of that event. Managers should deduplicate using the combination: **`agent_id` \+ `event_id`** Not the subscription identifier. If the Manager deduplicates by `subscription_id`, the two deliveries may appear unrelated even though they describe the same event. Nor should a Manager assume that two messages with different envelope request identifiers represent two different operational events. The event identity is the relevant key. A practical implementation can retain an event-identity index to prevent duplicate incident creation. The storage mechanism, retention period, and transaction boundaries of that index remain implementation decisions. Deduplication also has an important limitation. It can prevent duplicate processing of events that arrive. It cannot reconstruct events that were never delivered. ### 6\. Cancellation Does Not Recall In-Flight Events UNSUBSCRIBE introduces another subtle boundary. A Manager sends an authenticated request to cancel an active subscription. The endpoint processes it and confirms cancellation. Should the Manager reject every subsequent PUSH associated with that subscription? Not necessarily. SAMP requires the endpoint to stop generating new PUSH deliveries for the successfully cancelled subscription. However, notifications already committed to transport or already in flight may still arrive. The Manager must tolerate this condition. It should apply normal authentication, freshness, validation, and deduplication handling rather than assuming every post-cancellation arrival is an attack. The UNSUBSCRIBE response also distinguishes between several conditions: | Subscription condition | Cancellation result | | ------------------------------------------- | ------------------------------------------- | | Active and owned by Manager | cancelled: true, status cancelled | | Already expired | cancelled: false, status expired | | Previously cancelled | cancelled: false, status already\_cancelled | | Unknown identifier | cancelled: false, status unknown | | Known subscription owned by another Manager | policy\_denied | These distinctions matter for reconciliation. An expired subscription is not necessarily an unknown subscription. A repeated cancellation is not a new cancellation event. And successful cancellation does not retroactively invalidate every message already in transit. ### 7\. Sequence Numbers Can Reveal Gaps, Not Repair Them SAMP provides an optional `sequence` field for subscription-associated PUSH notifications. When present, sequence numbers are per subscription and begin at 1. This supports a useful operational diagnostic. Suppose the Manager observes: | Sequence | Observation | | -------- | ------------ | | 41 | Received | | 42 | Received | | 43 | Not observed | | 44 | Received | The gap may indicate a missed notification. But the Manager cannot automatically conclude why the gap occurred. Possible explanations include lost transport delivery, processing failure, or other stream disruptions. Nor does the gap establish that the missing event was permanently lost. SAMP v0.2 allows receivers to detect sequence gaps but does not permit rejecting a PDU solely because a gap exists. The core protocol does not define an event-replay request or a standard historical stream-retrieval operation. A Manager may record the gap and mark the affected observation interval as potentially incomplete. It cannot assume the protocol will automatically retrieve sequence 43. **Gap detection is not gap recovery.** A future event-stream profile could define explicit replay, cursors, epochs, or durable delivery acknowledgments. Those mechanisms would require additional specification. They must not be silently assumed to exist in core SAMP v0.2. ### 8\. What Happens After a Disconnection or Restart? Persistent connections make event delivery efficient, but introduce their own failure cases. Consider a Manager receiving PUSH notifications over WebSocket. The connection drops. The underlying Agent remains enrolled and trusted. What happens to its subscription? Core SAMP v0.2 does not guarantee subscription persistence across WebSocket reconnects or endpoint restarts. Unless both peers explicitly support an appropriate persistence extension, the Manager must re-establish the connection and subscribe again. Nor does the core protocol require the Agent to buffer missed events during the outage. A useful recovery implementation therefore distinguishes several states: | Condition | Management interpretation | | ------------------------------ | -------------------------------- | | Connection lost | Event transport unavailable | | Subscription no longer active | Replacement required | | Connection restored | Transport communication restored | | Replacement SUBSCRIBE accepted | New subscription established | | Missing historical events | Completeness remains unverified | An important operational consequence follows. Reconnecting successfully does not prove that all events generated during the interruption have been recovered. Likewise, a lost WebSocket connection does not automatically revoke the Agent's trust state. Connection loss, management liveness, subscription state, and event-history completeness remain distinct concerns. A well-designed dashboard should represent those distinctions rather than collapsing them into one green or red status indicator. ### 9\. Event Streams and Audit Records Serve Different Purposes An event stream reports observations. An authoritative audit record preserves evidence of a decision, action, or state transition in a form that can be examined later. The distinction becomes particularly important when SAMP CONFIG or EXEC operations are involved. SAMP v0.2 requires specific audit information for consequential management operations. When a Manager makes a decision based on a CONFIG or EXEC outcome, the audit record must bind that decision to relevant authenticated identities, operation identifiers, request digests, captured context, outcomes, and timestamps. The protocol also distinguishes execution outcome from audit persistence. For CONFIG and EXEC, `audit_persistence` may indicate: - `complete` - `failed` - `unknown` These values do not describe the delivery status of ordinary PUSH notifications. They belong to the consequential-operation outcome model. An execution may have succeeded even when associated audit persistence failed. Conversely, a successfully received PUSH event does not establish that a consequential operation succeeded or that its audit record exists. The core protocol requires particular audit semantics but does not mandate one database product, distributed-log technology, or external evidence store. An implementation may therefore use different technologies for event ingestion and authoritative audit storage. What matters is preserving the required distinctions. **An event notification is not an execution receipt.** **An execution receipt is not automatically proof of the intended external effect.** **And neither is automatically evidence of durable audit persistence.** ### 10\. Designing a Responsible Event-Ingestion Pipeline A practical SAMP Manager can implement a stronger event-processing architecture without changing the core protocol. One possible design separates the following stages. **Stage 1: Admission** Receive the PUSH notification. Validate its envelope, authenticated sender, freshness, expected enrollment context, and payload structure. A PUSH event must not be treated as trusted merely because a transport connection is established. **Stage 2: Event Identity** Extract `agent_id` and `event_id`. Consult a bounded event-identity store to determine whether the same logical event has already been accepted. **Stage 3: Durable Recording** Commit the event and its required ingestion metadata to an application-selected persistent store. Where necessary, record its authenticated source and processing context. This stage is an application-level reliability mechanism, not a SAMP PUSH acknowledgment. **Stage 4: Correlation** Associate the event with relevant management observations, requests, operational incidents, or independently verified evidence. The optional `correlation_id` may assist, but does not itself prove causality. **Stage 5: Decision Processing** Apply monitoring, alerting, or incident-management policy. If corrective action is required, use the appropriate authorization and management-operation mechanisms. A PUSH event must never become an implicit authorization to invoke CONFIG or EXEC. **Stage 6: Audit** Record resulting management decisions and consequential-operation outcomes according to the applicable audit requirements. An application may choose to make ingestion and event-processing transactions idempotent and durable. Doing so improves operational reliability. It does not alter the guarantees provided by core SAMP. ### 11\. Failure Conditions Worth Testing The event-management model becomes more interesting when subjected to failures. The following scenarios provide a practical starting point for implementers. | Test | Required or expected behavior | | -------------------------------------------------- | ------------------------------------------------------------------------------------- | | Repeated identical SUBSCRIBE request | Original recorded subscription returned; no additional allocation or expiry extension | | Overlapping subscriptions | Event copies retain the same event\_id; Manager should deduplicate | | Subscription TTL exceeded | Subscription expires; new SUBSCRIBE required for continued delivery | | UNSUBSCRIBE from another Manager | Denied without disclosing foreign subscription state | | PUSH already in flight during cancellation | Manager tolerates delivery and deduplicates appropriately | | Sequence gap | Gap may be detected; no mandatory rejection solely because of the gap | | WebSocket disconnection | Reconnect and re-subscribe unless persistence extension is supported | | Endpoint restart | No core guarantee of subscription recovery or buffered event replay | | Per-Manager subscription quota exceeded | rate\_limited | | Global subscription capacity exhausted | back\_pressure | | Manager crash before application-level persistence | Core PUSH provides no guarantee of durable recovery | These scenarios intentionally include both normative protocol behaviors and application-level reliability considerations. For example, stable event identifiers and subscription ownership are protocol requirements. An atomic database transaction for local event ingestion is an implementation choice. Similarly, a Manager may use persistent deduplication state, a transactional queue, or another suitable architecture. The protocol does not prescribe those choices. A proper test report should distinguish: 1. What the SAMP specification requires. 2. What the implementation additionally guarantees. 3. What was actually exercised and verified. Without that separation, an implementation may accidentally present its own storage or recovery mechanisms as protocol-level guarantees. ### 12\. Security, Privacy, and Event Flooding Operational events may contain sensitive information. A PUSH notification can expose internal error details, resource usage, infrastructure characteristics, or aspects of an agent's operating environment. Exporting every event to external logging or ticketing systems without filtering can create unnecessary information exposure. SAMP recommends classifying and filtering event data before external export. Evidence references must also avoid embedding reusable credentials. Event-ingestion security requires attention to volume as well as content. A compromised or malfunctioning Agent could generate excessive notifications and exhaust Manager resources. SAMP allows rate limiting and back-pressure behavior. An implementation should combine authenticated event admission, resource limits, bounded processing, and suitable storage-retention policies. These are not merely performance optimizations. They prevent event handling from becoming another operational failure domain. ### 13\. The Engineering Lesson SAMP provides a common management interface for heterogeneous AI agents. PUSH allows Agents to report operational events. SUBSCRIBE and UNSUBSCRIBE allow authenticated Managers to control event-delivery relationships. Stable event identifiers support duplicate recognition. Subscription expiration, ownership, and recorded-state retry rules make event-stream management predictable. But none of these mechanisms, individually or together, establishes a durable event-history service. The distinctions are fundamental: **Receiving an event is not the same as recording it.** **Recording an event is not the same as acting upon it.** **Receiving an event twice does not mean the underlying condition occurred twice.** **Detecting a missing sequence number does not mean the missing event can be recovered.** **Reconnecting a subscription does not establish historical completeness.** **And a successful management operation does not automatically establish durable audit persistence.** A management system that respects these boundaries can provide useful operational visibility without making guarantees it cannot support. A management system that ignores them risks confusing delivered notifications, durable evidence, and authoritative operational outcomes. The objective is not to turn SAMP into a message broker, distributed transaction system, or universal audit platform. It is to make the management boundaries explicit so that stronger reliability mechanisms can be introduced where they are genuinely needed. **Operational visibility depends on receiving information. Operational accountability depends on knowing what that information actually proves.** --- ### Specification Reference This Engineering Note discusses the Experimental SAMP v0.2 specification, particularly Sections 7.2, 7.6, 8.1.4, 8.2.4, 8.2.6, 8.2.7, 10.2, 10.3, 11.2, 12.2, 12.3, and 13.2 of: [Simple Agent Management Protocol (SAMP), draft-efstathiou-samp-agent-management-04](https://datatracker.ietf.org/doc/draft-efstathiou-samp-agent-management/04/?ref=samp-protocol.org) SAMP remains an individual Internet-Draft intended for experimental evaluation. It is not an approved IETF standard. The Internet-Draft is authoritative for protocol requirements. The implementation patterns and illustrative test scenarios discussed here do not imply that independent interoperability testing has already been completed. *Stelio E. Efstathiou* *SAMP Protocol Project*