Reference table
Delivery guarantees
States the guarantees on every exchange, covering at-least-once transport, single recording, acknowledgements, retries and the outcome when a send runs out of time.
Pensieve keeps a fixed set of guarantees on every exchange it carries, and this page lists them for each direction with the place where each one holds. It ends with how the order of arrival is treated and what a sending system does to rely on the guarantees.
Inbound from the bridge
orophin, the bridge, acknowledges an HL7 v2 or FHIR message only after it holds it, and lets go of any message only after the platform holds it. The link between them runs at least once: a message may cross more than once, and the receipt key makes every crossing after the first harmless.
| Guarantee | What it means | Where it holds |
|---|---|---|
| Stored before acknowledged | An HL7 v2 or FHIR sender hears that a message is safe only after it sits encrypted in the bridge's queue. When the bridge cannot store it, a negative acknowledgement tells the sender to keep it. An analyser's frames are acknowledged at the link, as the section on sending systems describes. | The bridge host |
| Resent, then held | A queued message survives a dropped link or a restart and goes again with jittered backoff until the platform confirms its durable write. Once its attempts run out, the bridge sets it aside, held for review, until an operator acts on it. | The bridge queue |
| Recorded once | A repeat within seven days, matched on the receipt key of site, bridge, sending system and the message's own identifier, settles to its first receipt and is acknowledged again. | The receipt transaction |
| All or nothing at receipt | The raw message, its SHA-256 integrity record, its boundary record and its received event commit in one transaction, and the bridge clears its entry only after that commit. | The receipt transaction |
| Acknowledged in two steps | A receipt from the bridge once the message is queued, then the platform's verdict on the sender's held connection: AA, AE or AR in an original-mode HL7 v2 acknowledgement, or a FHIR OperationOutcome. | The sender's held connection |
| Kept and replayable | The raw bytes are stored before meaning runs, so a message that fails validation or waits for a route is kept, and replays from those bytes once its mapping or route is in place. | The platform's message store |
An HL7 v2 batch is counted message by message. Each member is received and answered on its own, and a batch sent again after a partial failure settles every member already recorded to its first receipt.
Receipt and meaning are explained in the trust boundary, each step to the verdict in from message to record, and the handling of held messages in message failure and replay.
Outbound through the governed path
A send to a hospital system or partner, such as an order or a claim, takes the governed outbound path that outbound exchanges follows step by step. Its guarantees run from the requesting tool's transaction to the response event, and every outcome also updates the connection's health in Westron.
| Guarantee | What it means | Where it holds |
|---|---|---|
| Committed with its change | A send exists only if the change that called for it commits, so an order that rolls back leaves no request behind. | The requesting tool |
| Queued once | One request makes one queue entry however often the event log delivers it, because the entry is named by the request's idempotency key. | The target's queue |
| One key on every attempt | Each attempt carries the same idempotency key, an HMAC-SHA256 over the payload serialised under RFC 8785 and scoped to the site, so the receiver can recognise a retry. | The request, from the moment it is recorded |
| Held while the target is away | A send whose target cannot be reached stays in that target's durable queue, within the queue's size cap and time limit, and is attempted again from there. | The target's queue |
| Each attempt bounded | Every delivery attempt runs inside a fixed budget of seconds, and a timeout counts as a failed attempt. | The sending worker |
| Always settled | Every send closes with a response event. It holds the target's answer, or an error when the send could not be delivered within the queue's limits, and staff see that error in the requesting tool and in Westron. | The requesting tool and Westron |
| Recorded once at the boundary | However many attempts a send takes, the boundary holds one outbound record for it, keyed to the send. | The integration records |
| Isolated by target | Sends to other targets keep moving while one target answers slowly, because each target is queued and limited on its own. | The target's queue |
A send's error takes the platform's single error shape, with a category from errors and a reference to the request's trace.
Inside the platform
Only the platform's own tools and the outbound path subscribe to the event log, and every committed change reaches them through it. How tools react to those changes is described in events.
| Guarantee | What it means | Where it holds |
|---|---|---|
| Emitted with the change | An event is staged inside the transaction that commits its change, so the event and the change exist together or neither does. | The committing transaction |
| Delivered at least once | Each event is delivered to every subscriber, and a failed delivery is retried with backoff. | The event log |
| Applied once by each subscriber | A subscriber recognises an event it has already handled, by the event's identity or by its own natural key, so a second delivery finds the work already done. | Each subscribing tool |
Provider adapters
The payment gateway and the messaging providers are reached through dedicated adapters, each of which verifies what its provider sends before reading it, as payments and messaging providers describe.
| Guarantee | What it means | Where it holds |
|---|---|---|
| Payment notifications verified first | The gateway's HMAC-SHA256 signature over the raw body is checked before the body is parsed, and a notification that fails the check is refused at that point. | The payment adapter |
| Repeated notifications recognised | A second copy of a notification is matched on the gateway's payment identifier to the payment it already settled. | The payment adapter |
| Payment requests keyed | The gateway order is created with the invoice receipt as its idempotency key, and a refund is keyed separately from the payment it reverses. | The payment adapter |
| Delivery receipts forward-only | Each messaging receipt's signature is verified before it is read, and a message's status only moves forward, so a late or repeated receipt never moves it back. | The messaging adapter |
Ordering
Each message, send and event is delivered on its own, and the order of arrival sits outside the guarantee. A message that waited out a dropped link can land after one sent later, and a target receives several sends at a time.
Each record settles once and is matched on its own keys. An HL7 v2 result finds its order through the accession and the placer and filler numbers, and a retried send is recognised by its idempotency key. A tool acts on a settled fact by reading the mapped record it points to.
What a sending system does
- 1
Send and hold the connection
Keep the connection open after each message. The bridge's receipt acknowledgement arrives first, and the platform's verdict follows on the same connection once the message is mapped and validated. An HL7 v2 verdict names the control identifier it answers, so the sender matches it to its message.
- 2
Resend unchanged when no acknowledgement arrives
Send the message again exactly as before, keeping its original identifier, such as its HL7 v2 control identifier. The receipt key recognises the resend, so the message is recorded once.
- 3
Resend when the bridge cannot store it
A negative acknowledgement from the bridge means it did not store the message. Keep the message and send it again. An AE or AR verdict from the platform is a different answer: by then the message is stored on the platform, as the inbound table above sets out.
A verdict that finds the sender's connection closed stays with the message, where an operator reads it in the Westron message inspector.
An analyser on ASTM is acknowledged frame by frame: the bridge checks each frame's checksum and answers ACK, or NAK so the analyser sends that frame again. The bridge then queues the completed record block for the platform.
Common confusions
Is delivery exactly once?
Each hop carries a message at least once. Inside Pensieve a repeat has no second effect: a repeated message settles to its first receipt, and a repeated event is recognised by the subscriber that already handled it. A repeated send carries the key its receiver needs to recognise it.
How long is a resent message recognised?
For seven days from its first receipt. A message sent again after that window is received as a new message.
Read how an operator works the messages held for review in message failure and replay, and how one send is queued, keyed and settled in outbound exchanges.