Field guide 002InteroperabilityNovember 2, 2026

Bring a component.
Define the boundary.

Choose the role, pin the software, specify the expected result, and make both success and failure inspectable.

Begin with one useful integration

A wallet/app team starts with ISI-4 and the ToDo lifecycle. An overlay implementer targets ISI-2. A remote storage team targets ISI-3. A team testing the connected transaction-processing application targets ISI-1. The program register records the prerequisites and which cases remain draft.

For overlay and storage work, implementing an unfinished driver or independent expected-state check is itself a useful contribution. Do not label a planned matrix cell as an executed result.

Identify exactly what will run

  1. Record the release, platform, artifact digest and configuration. Distinguish a source build from a publisher binary.
  2. Declare the interfaces, service endpoints and limitations. Pin supporting components and fixtures.
  3. Provide supported installation, onboarding, funding and reset paths. Retain native permission decisions.
  4. Record reproduction permissions and third-party dependencies through the intake process.

Software intake and current candidates ↗

The adapter observes; the evaluator judges

The common adapter contract covers describe, verify, install, configure, initialize, fund, ready, drive, observe, reset and stop. An adapter may be written in any language. It drives the system through the declared public interface and returns observations or a typed infrastructure error.

The evaluator applies separately versioned expected outcomes. An adapter must preserve transaction semantics and user decisions; it cannot replace a wallet method with its own implementation or manufacture a successful response.

Read the adapter lifecycle ↗

Worked plan: replacing an overlay host

This is a proposed integration plan, not an executed result. Put the candidate image in the overlay role, keep the reference peer and topic/lookup rules pinned, and declare one synthetic record set.

  1. Submit a valid record and independently check admitted outputs and lookup results.
  2. Repeat the submission and verify the specified duplicate behavior.
  3. Interrupt synchronization, restart the candidate and resume from its checkpoint.
  4. Compare the resulting topical state to an independent expected-state projection.
  5. Repeat in a clean environment. Retain failed, blocked and inconclusive attempts alongside passes.

Only report the cells actually run. Two implementations sharing the same faulty reference assumption do not establish correctness.

Make the next contribution concrete

Open an issue or pull request naming the ISI, exact role, artifact, missing requirement or reproducible discrepancy. Include public synthetic fixtures and evidence references. Keep credentials, private wallet records and sensitive exploit details out of public reports.

Contribution guide ↗ · Start with offline evidence verification →