A field guide to connected systems

Before you connect two systems, map their promises.

Short, evidence-led case notes for product teams: who acts, what changes, what can be observed and what still needs checking.

system boundariesobservable stateproduct language
Built onclear evidencevisible boundariescareful language
Case note 01 / Wallet state

One action. Three different receipts.

A proposed field-note format for the existing integration guide. A wallet signature, a network submission and an observed stake-account state are different evidence.

Wallets × Solana staking · 8 min read

A wallet can sign a staking request — but your web app cannot promise the outcome.

A hypothetical product walkthrough of signing authority, transaction status and the words a product team can safely put on screen.

Read the case note
A matte-black phone with an abstract wallet approval screen, three metallic staking tokens and a luminous lime glass loop on a pale green desk.

Continue to the current Integrations or browse the guide library.

Integration coverage check

Find the unanswered questions before launch.

Use five short prompts to review who owns the data, who can change it, how outcomes are confirmed and what happens when delivery fails.

This discussion aid scores documented coverage only. It is not a security audit, certification or guarantee that an integration is ready.

Review the integration contract

Score each area: 0 = not yet, 1 = partly documented, 2 = documented and checked. Each prompt is weighted equally; the result is a conversation starter, not a measure of safety or success.

Answer the five questions to begin.— / 10
The method

Six questions before a promise.

Each field note follows the same compact canvas so teams can examine an integration before turning it into a product flow.

01—02 / ACT

Who initiates and who signs?

Name the human and system that begin the action. Keep signing authority where it actually sits.

03—04 / CHANGE

What can the app observe?

Separate a request or receipt from a state change the product has independently checked.

05—06 / VERIFY

What can fail, and how would you know?

Write a useful recovery state, then name the evidence that would justify the next message.

Responsibility boundary

Three systems.
Three different jobs.

A browser can prepare and display. A wallet controls its own signing decision. The network determines whether a transaction is processed and what state follows.

Boundaries
WEB APPprepare · explain · observe
WALLETreview · approve · sign
NETWORKprocess · confirm · record
OBSERVED STATEread again · report carefully
Integration review worksheet

Map an integration before you write the interface.

Capture intent, authority, data, state changes, failure recovery and verification. Includes prompts and a decision summary for a focused team review.

6 contract fieldsRisk and open questionsNext-step checklist
New case-note format

Four small studies. One practical method.

Each note examines an integration pattern through observable evidence, recovery choices and clear user-facing language.

IF—01 / Wallet state

A signature is not a staking outcome

Separate wallet approval, network submission, confirmation and account state.

Read the case note
IF—02 / Safe retries

The reply timed out. Did the action?

Design a retry path that cannot quietly create a second payment or booking.

Read the case note
IF—03 / Event delivery

Arrival order is not business order

Handle duplicate and late events without moving a record backwards.

Read the case note
IF—04 / Data freshness

Every status has a time window

Show when an observed value is recent enough to support a decision.

Read the case note

Browse all fieldnotes or visit the guide library.