SDK Recovery Conformance Matrix

Wire-format compatibility is not enough for an SDK. The failure choreography must still preserve known spend when a response is lost, a reservation expires, credentials rotate, or the process restarts.

This matrix publishes the current evidence snapshot for every official core SDK against the shared recovery profile 0.3. Each cell links to the machine-readable report containing the exact native tests executed for that scenario. The four implementations are Python, TypeScript, Spring / Java, and Rust.

Python

durable · 12/12

v0.5.2 · verified at a022580

CI run·JSON evidence

Native-test mapping

• CR-CORE-001tests/test_retry.py::TestCommitRetryEngine::test_retries_until_success
• CR-CORE-002tests/test_journal.py::TestLifecycleEventFallbackWiring::test_expired_commit_schedules_event
• CR-CORE-003tests/test_lifecycle.py::TestSyncLifecycleExecution::test_heartbeat_exception_does_not_crash
• CR-CORE-004tests/test_journal.py::TestLifecycleEventFallbackWiring::test_protocol_invalid_2xx_is_ambiguous_and_keeps_same_key
• CR-DURABLE-001tests/test_journal.py::TestLifecycleEventFallbackWiring::test_journal_write_precedes_first_commit_and_success_discardstests/test_journal.py::TestSyncReplay::test_replays_pending_commit_on_set_clienttests/test_retry.py::TestCommitRetryEngine::test_retries_until_success
• CR-DURABLE-002tests/test_journal.py::TestSyncEngineDurability::test_expired_then_event_transient_continues_in_event_modetests/test_journal.py::TestSyncReplay::test_replays_event_mode_entry
• CR-DURABLE-003tests/test_journal.py::TestRateLimitedRetry::test_429_commit_is_transient_and_honors_retry_aftertests/test_journal.py::TestRateLimitedRetry::test_replay_restores_future_retry_after_floortests/test_journal.py::TestRateLimitedRetry::test_429_then_success_discards_journal
• CR-DURABLE-004tests/test_journal.py::TestAuthFailureRetention::test_replay_survives_api_key_rotation_with_tenant
• CR-DURABLE-005tests/test_journal.py::TestCommitJournal::test_corrupt_and_unsupported_records_are_quarantined_without_blocking_valid
• CR-DURABLE-006tests/test_journal.py::TestSyncReplay::test_concurrent_replay_workers_reuse_one_key_and_remove_record
• CR-DURABLE-007tests/test_journal.py::TestCommitJournal::test_colliding_legacy_ids_are_distinct_and_migrate_safely
• CR-BOUNDARY-001tests/test_lifecycle.py::TestSyncLifecycleExecution::test_missing_actual_surfaces_without_settlement

TypeScript

durable · 12/12

v0.4.2 · verified at 110c756

CI run·JSON evidence

Native-test mapping

• CR-CORE-001tests/retry.test.ts > retries on failure then succeeds
• CR-CORE-002tests/journal.test.ts > recovers spend via scheduleEvent on an expired first commit
• CR-CORE-003tests/lifecycle.test.ts > heartbeat logs thrown transport failures and keeps the action alive
• CR-CORE-004tests/journal.test.ts > treats a protocol-invalid 2xx as ambiguous and preserves the key
• CR-DURABLE-001tests/journal.test.ts > journals before the first commit request and discards valid successtests/journal.test.ts > replays pending commits when the first engine appearstests/retry.test.ts > retries on failure then succeeds
• CR-DURABLE-002tests/journal.test.ts > falls back to POST /v1/events when the reservation expiredtests/journal.test.ts > replays event-mode entries via createEvent
• CR-DURABLE-003tests/journal.test.ts > treats 429 as transient, honors Retry-After, and persists the floortests/journal.test.ts > restores a future Retry-After floor and ignores a past one
• CR-DURABLE-004tests/journal.test.ts > survives API-key rotation when a tenant is configured
• CR-DURABLE-005tests/journal.test.ts > quarantines corrupt and unsupported records without blocking valid replay
• CR-DURABLE-006tests/journal.test.ts > concurrent replay workers reuse one key and remove the record
• CR-DURABLE-007tests/journal.test.ts > uses cross-SDK digest names and safely migrates colliding legacy names
• CR-BOUNDARY-001tests/lifecycle.test.ts > throws when actual is undefined and useEstimateIfActualNotProvided is false

Spring / Java

durable · 12/12

v0.3.2 · verified at b221f2d

CI run·JSON evidence

Native-test mapping

• CR-CORE-001JournaledCommitRetryEngineTest#shouldJournalBeforeRetryAndDiscardOnSuccess
• CR-CORE-002JournaledCommitRetryEngineTest#shouldPersistEventModeBeforeDeliveringExpiredFallback
• CR-CORE-003CyclesLifecycleServiceTest#shouldHandleExtendExceptionGracefully
• CR-CORE-004CyclesLifecycleServiceTest#shouldTreatProtocolInvalidCommit2xxAsAmbiguous
• CR-DURABLE-001JournaledCommitRetryEngineTest#shouldJournalBeforeRetryAndDiscardOnSuccessCyclesLifecycleServiceTest#shouldExecuteFullLifecycleJournaledCommitRetryEngineTest#shouldReplayJournaledCommitOnConstruction
• CR-DURABLE-002JournaledCommitRetryEngineTest#shouldPersistEventModeBeforeDeliveringExpiredFallbackJournaledCommitRetryEngineTest#shouldReplayEventModeRecord
• CR-DURABLE-003JournaledCommitRetryEngineTest#shouldTreat429AsTransientHonorRetryAfterFloorAndPersistNotBeforeJournaledCommitRetryEngineTest#shouldHonorFutureNotBeforeFloorOnReplay
• CR-DURABLE-004JournaledCommitRetryEngineTest#shouldSurviveApiKeyRotationWhenTenantScoped
• CR-DURABLE-005CommitJournalTest#shouldQuarantineCorruptAndUnsupportedRecordsWithoutBlockingValidReplay
• CR-DURABLE-006JournaledCommitRetryEngineTest#shouldReplayConcurrentlyWithSameKeyAndRemoveRecord
• CR-DURABLE-007CommitJournalTest#shouldKeepCollidingLegacyIdsDistinctAndMigrateSafely
• CR-BOUNDARY-001CyclesLifecycleServiceTest#shouldThrowWhenActualRequiredButNotProvided

Rust

durable · 12/12

v0.3.2 · verified at 4d14f46

CI run·JSON evidence

Native-test mapping

• CR-CORE-001transient_commit_is_journaled_and_replayed_after_key_rotation
• CR-CORE-002expired_commit_recovers_via_event
• CR-CORE-003heartbeat_transport_timeout_is_observable_nonfatal_and_same_keyheartbeat::tests::fallback_retry_warning_includes_reservation_and_disposition
• CR-CORE-004protocol_invalid_2xx_settlement_responses_remain_durably_ambiguous
• CR-DURABLE-001transient_commit_is_journaled_and_replayed_after_key_rotation
• CR-DURABLE-002expired_commit_persists_event_mode_before_restart_replay
• CR-DURABLE-003rate_limit_retry_floor_is_persisted
• CR-DURABLE-004transient_commit_is_journaled_and_replayed_after_key_rotation
• CR-DURABLE-005journal::tests::corrupt_and_unsupported_records_are_quarantined_without_blocking_valid_records
• CR-DURABLE-006concurrent_replay_workers_reuse_one_key_and_remove_record
• CR-DURABLE-007journal::tests::digest_names_do_not_collide_and_legacy_discard_checks_record_identity
• CR-BOUNDARY-001with_cycles_error_releases_automatically

Level	Scenario	Python	TypeScript	Spring / Java	Rust
Core	CR-CORE-001lost commit response reuses the same key	✓	✓	✓	✓
Core	CR-CORE-002expired commit falls back to an event	✓	✓	✓	✓
Core	CR-CORE-003heartbeat transport failure is observable and non-fatal	✓	✓	✓	✓
Core	CR-CORE-004protocol-invalid settlement success remains ambiguous	✓	✓	✓	✓
Durable	CR-DURABLE-001first commit is journaled before it leaves the process	✓	✓	✓	✓
Durable	CR-DURABLE-002replayed expired commit switches durably to event mode	✓	✓	✓	✓
Durable	CR-DURABLE-003rate-limit floor survives restart	✓	✓	✓	✓
Durable	CR-DURABLE-004tenant journal survives API-key rotation	✓	✓	✓	✓
Durable	CR-DURABLE-005corrupt or unsupported journal record is quarantined	✓	✓	✓	✓
Durable	CR-DURABLE-006concurrent replay remains exactly once	✓	✓	✓	✓
Durable	CR-DURABLE-007journal filenames preserve distinct arbitrary reservation identifiers	✓	✓	✓	✓
Boundary	CR-BOUNDARY-001missing actual is surfaced without settlement	✓	✓	✓	✓

Profile 0.3 · catalog sha256:28792ca09104…. Each result is pinned to the displayed SDK commit; the README workflow badge shows whether current main remains green.

What a pass proves

The shared runner invokes the SDK adapter once per scenario in a fresh process. The adapter must execute named native behavior tests and return their exact identifiers. A pass therefore proves that the SDK's claimed native tests ran successfully at the pinned implementation commit.

The runner deliberately does not disclose the expected request choreography to the adapter. Code review still verifies that each named native test asserts the catalog's expected calls and outcomes. This is native-test-backed conformance, not a claim that a second black-box client independently reproduced the SDK internals.

Status definitions

• Pass — the pinned report passed the scenario and names at least one native behavior test.
• Fail — the runner completed but the scenario or its native tests failed.
• Not claimed — an implementation does not claim that profile level.
• Stale — the displayed SDK or profile commit has moved beyond the report. The pinned result remains historical evidence, but current conformance must be re-established.

The SDK README badge follows the current main CI workflow. The snapshot above is intentionally pinned to exact commits so later source changes cannot rewrite what was tested.

Guarantee boundary

Durable recovery begins only after the lifecycle helper knows the actual amount and persists settlement. If a process dies before the provider returns actual usage, the SDK cannot invent the missing amount. Applications requiring that stronger guarantee must durably checkpoint the provider receipt or usage before acknowledging the downstream operation.

See SDK Settlement Recovery and Durability for the journal, replay, expiry fallback, configuration, and operational contract.