An evidence ladder for accepting an integration

An integration card can help you choose what to investigate, but it cannot tell you that a particular client can read a particular account. Use an acceptance worksheet to record the strongest evidence actually available for each step. Leave missing steps visible; do not promote a later-looking claim without its supporting result.

Five distinct questions

1. Directory metadata: What capability is documented, and where did the description come from? The integration directory is useful for finding candidates. Its catalog describes 772 applications and 8,300 actions and triggers as documented capabilities, not enabled connections.
2. Local implementation: Is there an implementation or configuration for the proposed operation? Record its version and the boundary it claims. Existence alone does not show that a client invoked it.
3. Protocol or client-library test: Did an actual client exchange the expected request and response with the implementation? Preserve the input, result and failure cases. A mock host can establish a bounded interaction without establishing a real account connection.
4. Actual host or IDE: Did the intended environment load and use the integration? Record the host, configuration and observed result. A library test does not establish this step.
5. Named sandbox vendor read: Did the intended client authenticate to a specified sandbox and retrieve an expected, non-sensitive record? Record the permitted target, response and check against the expected record. This is evidence for that scoped read, not for every operation or customer deployment.

These questions form a practical sequence, although evidence may arrive out of order. Label each row independently. The isolated mock-host exercise recorded on 30 October 2026 used four read-only catalog tools. It is evidence of that bounded test; it did not verify the full IDE or CLI path, real vendor authentication or a vendor read.

Exercise: classify five fictional receipts

For a fictional inventory lookup, make a table with receipt, stage, acceptance criterion, result and next proof. Use these invented examples:

• A directory card describes item lookup. Stage 1: accept the metadata if its source and date are recorded. Next: inspect an implementation.
• A local tool definition lists a lookup function. Stage 2: accept existence when the version and definition are inspectable. Next: call it through a client.
• A client calls a mock and receives the expected synthetic item. Stage 3: accept the specified exchange if request and response match. Next: test the intended host.
• The intended IDE loads the tool and displays the synthetic result. Stage 4: accept that host path if the actual invocation is recorded. Next: authorize a sandbox read.
• A named sandbox returns the expected fictional item through the intended client. Stage 5: accept that read if identity and response match the prewritten criterion. Next: test any additional operation separately.

If a tool list contains no write tool, record absence. That is different from an attempted write being rejected; only an observed rejection supports the latter statement. Preserve errors and unexpected results beside successes, including what was attempted and what remains unknown. A failed test may reveal a boundary, but it does not prove every route is blocked.

For the policy decisions around a test, see permissions-first practice. The Odoo guide illustrates a specific proposed integration; apply the same evidence distinctions to its actual environment. Use evidence scorecards to compare acceptance criteria without turning a synthetic exercise into a customer outcome.

The directory summarizes overall readiness states. This worksheet expands the testing part into separate client-library, host and vendor checks; it does not replace the directory status.