---
id: M06-L02
title: Plan the interface from documentation
module: M06
chapters: "12"
checkpoint: CP04
---

# M06-L02 — Plan the interface from documentation

Turn the reviewed constraints into a connector-level plan and a software input contract. Start from your CP04 table. The plan describes an optional physical extension; the core project will continue with synthetic samples. No wiring or upload is required.

Draw the exact host board and separate breakout as two named boxes. The Feather guide identifies the QT connector's clock, data, supply, and ground signals. Use those named connections and the applicable breakout guide to trace corresponding endpoints. Do not replace them with remembered GPIO numbers or unsupported cable colors. [Feather STEMMA QT reference](https://learn.adafruit.com/adafruit-esp32-s3-feather/pinouts), [BME280 I2C reference](https://learn.adafruit.com/adafruit-bme280-humidity-barometric-pressure-temperature-sensor-breakout/pinouts).

Label the diagram “documentation-based; physical assembly unverified.” Include the exact example identity, source sections, and the fact that a compatible keyed cable is the intended connection path. If you change to bare wires or another board, the source evidence must expand to cover pin position, orientation, supply, and relevant interface conditions. That is a new plan, not an assumed equivalent picture.

Check one connection at a time against the primary material. Follow clock from host to sensor, then data, then supply and return. If a schematic label is unreadable, enlarge the actual source or locate its text/pinout companion. An AI interpretation of a tiny label cannot substitute for a readable reference. Retain an unresolved item if the exact endpoint is not established.

Next separate acquisition from policy. The future adapter should report a timestamped temperature or an explicit missing input. It should not invent a normal value after a failed read or refresh the age of a cached value. The shared policy decides whether input is current and whether recovery is complete. This contract allows the synthetic adapter and host replay to exercise the same policy later.

Initialization belongs in the plan too. The board guide describes switchable peripheral power; the pinned board-core variant must resolve the actual software symbol and initialization behavior before a physical driver is adopted. Record the unanswered question rather than using an alias from a different example. [Feather I2C/power sections](https://learn.adafruit.com/adafruit-esp32-s3-feather/pinouts), [ESP32 core 3.3.11 variants](https://github.com/espressif/arduino-esp32/tree/3.3.11/variants).

Ask what happens when initialization fails and what bounds an acquisition call. Scheduling work once a second does not establish a driver timeout. A physical adapter needs a selected library/version and evidence about its blocking behavior. These remain optional-extension questions; they do not prevent the required synthetic project from progressing.

The assistant's useful output is a small plan with supported connections, a clear adapter contract, and specific unresolved checks. An unnecessary sensor driver or purchase list expands the task. Review a generated plan against the constraints table and confirm it has not silently changed the board variant, address assumption, or meaning of a timestamp.

## Resources and completion

Use Chapter 12, CP04 `docs/interface-plan.md`, `docs/hardware.md`, and the dependency manifest. Figure references are SS12-03, SS12-04, and D11. Complete [the exercise](exercise.md); inspect [the key](answer-key.md) afterward. Optional photographs HP01–03 are not evidence available in this core activity.