---
name: datasheet-to-constraints
description: Use when asked to derive interface or operating constraints for an exact board or component from supplied primary technical documents. Does not apply to unrelated prose or general coding tasks.
---

# Datasheet to constraints

Identify the exact part, board variant, document title/revision and sections supplied. Distinguish silicon limits from board-level connections and typical values from guaranteed limits. If a required source or revision is missing, state the gap and complete only the supported portion; do not invent pin mappings, addresses or timing.

Return a concise table with **claim**, **value and unit**, **source section/link**, **confidence or missing data**, and **design consequence**. Attribute each row to the document that establishes it. If documents conflict, show the conflict, prefer the applicable pinned board source for that build, and leave unresolved physical-revision questions explicit. A family name is not an exact variant.

For examples of unit/condition handling, source identity and missing mappings,
read [extraction rules](references/extraction-rules.md).

Separate documentary constraints from observations requiring a bench. End with only the unresolved questions that affect the requested interface decision. Do not turn a constraints request into firmware edits, purchases, uploading or hardware operation. For Sensor Monitor context use `docs/hardware.md` and `dependencies.json` relative to the repository root; source documents supplied in the task take precedence over stale notes.