Delivery, capacity and retries

1. The SDK accepts an observation into its bounded memory queue.
2. The configured product agent or internal HTTPS transfer service accepts durable custody.
3. The processing layer assembles, seals and verifies the transaction.
4. Kafka delivery and batched ClickHouse persistence complete.
5. The portal exposes the record for review.

Capture success at the first stage does not establish completion of the fifth.

The shared default SDK budget is 64 MiB / 1,024 records. Pending packages and encoding space count towards that budget. At capacity, business execution is not blocked; observation loss is reported. Delivery is not an unlimited-memory or unconditional zero-loss guarantee.

The SDK reuses the same delivery identity and package bytes. Pending memory records are not released without a verified custody receipt. When a local agent is selected, agent failure does not silently switch delivery to the remote endpoint.

close/Dispose stops new observations without adding network or flush waits to the business path. If a process exits before the first durable acceptance, its in-memory records can be lost. An abrupt shutdown does not guarantee complete central evidence.

Python sdk.status, Java diagnostics() and .NET Status expose startup, acceptance, pending, loss and last-error information. Inspect metrics without logging content or credentials. Local durable custody and remote durable acceptance are separate counters.