Document your integration ​

Begin with what the integration lets an application do and the public interface it uses. State the tested Coordinator DB executable versions and the adapter version. A tested combination is evidence; an untested version range is a promise the example cannot establish.

Make the first example runnable ​

Link to installation, name the database and show the configuration values a caller supplies. Identify the local example's credentials as belonging to the supplied configuration. Keep passwords, API keys and private addresses out of copied output.

Show one complete read with its expected result, then a write if supported. Specify the output format and how database nulls, numeric values and errors map into the application. Explain where the connection is closed and who commits or rolls back a transaction.

State meaningful boundaries ​

Describe cancellation, retries, file input and parameter binding only to the extent the integration actually implements them. In particular, HTTP has independent request sessions and no bound-parameter interface. Refer readers to the HTTP contract rather than implying another database driver's behavior applies.

Include troubleshooting for invalid credentials, an unavailable listener and malformed SQL. Use the same sample dataset as the integration tests so documentation changes can be checked against an observable result.