Evidence

What makes an exit test defensible?

A useful technical record says exactly what was tested, against which target, when it ran, what passed and what remained outside scope.

DORA does not turn a green dashboard into proof. Commission Delegated Regulation (EU) 2024/1773 says exit plans for relevant contractual arrangements should be realistic, feasible, based on plausible scenarios and reasonable assumptions, and periodically reviewed and tested. The related continuity standard requires testing to challenge assumptions, cover relevant third-party ICT services and document deficiencies.

Those requirements sit inside a much wider governance programme. But they point to a useful engineering question: what would another person need to understand and challenge a technical exit test?

Keep seven things together

  1. Scope: the exact workload boundary and architecture revision.
  2. Scenario: the source condition, intended target and assumptions being exercised.
  3. Material: the package, source, image or declared mock used in the run, identified by version and digest.
  4. Checks: the required observable behaviours and the version of each rule.
  5. Execution: where and how the test ran, including whether original code, a simulator or a mock was used.
  6. Result: per-check outcomes, timestamps, logs or measurements that are safe to retain, and cleanup status.
  7. Limits: dependencies, data migration, operating processes or failure modes that were not proven.
A defensible result is deliberately narrow: this workload revision passed these checks in this execution mode at this time.

Freshness is part of the claim

A test result does not become false merely because time passes, but it becomes less useful as the workload, provider and target change. Evidence should therefore carry its execution date and the versions it binds to. Monitoring can identify material change and prompt review without silently rewriting the historical result.

Mocks are evidence—with a smaller claim

A customer-supplied or inferred safe mock can prove that a portable contract is internally consistent. It cannot prove that unavailable original application code ran successfully. The execution mode belongs beside the result, not in a footnote.

What PortabilityLabs captures now.

Observed source architecture, reviewed workload boundaries, portable checks, target assessments, versioned package identity, run status, per-check results, timestamps, caveats and cleanup evidence. Business criticality, contracts, legal applicability and management approval remain outside the normal product setup.