A detected checkbox state tells you whether a mark appears selected; it does not by itself identify the business answer. Link the mark to its intended question and option before converting it into a stored value such as Yes, No or Approved.
This guide concerns selection marks from the Document Intelligence Layout model. It is not a claim that checkbox recognition proves consent or validates a signature. Use generic forms without personal information and compare the actual model output with a known answer sheet.
Separate the mark from the nearby wording
A form may contain two boxes labeled Yes and No, several independent options or a grid of repeated choices. The selected state is meaningful only after you identify which option the box belongs to. A nearby word in reading order is not always the correct label.
Microsoft's Layout documentation describes selection marks, their state, confidence and geometric information. Use those fields as evidence for a mapping, not as a complete business decision. A mark recognized correctly beside the wrong option still produces an incorrect answer.
Start with one question and two options
Use a harmless sample where Yes is selected and No is unselected, then a second sample with the states reversed. Keep the printed labels distinct and inspect their positions. This catches a mapping that always interprets the first selected mark as Yes.
Include no selection and conflicting selections
Create cases with neither box selected and both boxes selected. The process owner must decide how those states are handled. Do not silently coerce either case into a single boolean value if the form requires one unambiguous answer.
Inspect structured output before rendered text
The top-level textual representation can differ from the structured selection state and from Markdown rendering. Use the schema matching the API or connector version rather than searching a text string for a checkbox glyph and assuming its position is stable.
The official Analyze Document API reference defines the versioned response contract and related output structures. Check the model and version used by the application. Old examples for a deprecated model should not silently determine the parser for a current Layout result.
| Output or context | Question to resolve |
|---|---|
| Selection state | Does the mark appear selected or unselected? |
| Geometry and source page | Which printed option does it belong to? |
| Confidence | Does this detection require review? |
| Business rule | What do no selection or multiple selections mean? |
Define a stable option mapping
For a known fixed layout, document how marks correspond to question and option positions. Validate that mapping across representative scans with small shifts or rotations. If the form varies substantially, use an appropriate supported extraction design rather than assuming one set of coordinates fits every version.
Preserve ambiguity as an exception
An unclear, crossed-out or partially filled mark may need human review. Keep the source region available through an authorized reference. Do not guess the intended answer from other fields simply to satisfy a required destination column.
Keep recognition separate from consent
A selected box can be extracted from a document without establishing who marked it, whether the form is current or whether the record meets a legal requirement. Those questions belong to the organization's approved validation process, not to a generic OCR state.
Verify the final stored value
Trace each test case from source mark to model output, option mapping and destination record. Confirm that Yes and No are not reversed, that unanswered forms remain distinct and that conflicting selections follow the intended review route.
Check a second question on the same page if the real form has repeated answer groups. A parser that works for the first group can accidentally reuse its label or state for every later question.
Our SharePoint metadata guide can help define destination choices that preserve unanswered and needs-review states where appropriate. A single checkbox column may be too limited if the process needs those distinctions.
Repeat the mapping check whenever a new form revision changes the question wording or option positions.
Recognized checkbox states still require validation of their business meaning. The related guide is AI Builder Confidence vs Required-Field Validation.
Keep a short mapping specification with version, question identity, option relationship and exception rules. Accept the integration when the stored business meaning matches the known samples and uncertainty remains visible, rather than treating every detected selected mark as an automatically valid affirmative answer.
