Design a field contract before adding an AI extraction step

A paragraph can look correct while being unusable by the next step in a workflow. It may omit the date, collapse two people into one name, or turn a missing amount into an estimated amount. When another system expects structured data, fluency is the wrong acceptance criterion.

The AI building blocks explained on Relay App include extracting data, summarizing text, and classifying information. This independently operated website uses attributed illustrations and examples from the original Relay.app. The discussion here takes those concepts as design material. It does not report a tested extraction result or establish current connector availability on relayapp.org.

Name the fields the next step needs

Consider an illustrative document intake process. The next action needs a document reference, date, contact name, and amount. Start by describing each field, whether it is required, and how absence should be represented. A missing amount should remain missing, rather than become zero because a downstream calculation expects a number.

Separate values from evidence. The amount field can hold a normalized numeric value, while an accompanying reference identifies the passage used to extract it. That gives a reviewer a way to check the interpretation. The source reference also makes correction possible without asking the model to reconstruct the document from memory.

A field contract need not be large. For each field, record its meaning, acceptable format, source, and missing-value behavior. Those four decisions are more actionable than a broad instruction to “extract everything important.” They also make comparisons between implementations easier.

Validate before choosing the next action

A model's output and the application's accepted record are separate objects. A validator can reject an invalid date format, flag an unavailable source reference, or require information that the model did not find. A readable answer does not eliminate the need for those checks.

Relay App's homepage places AI actions beside data transformations and utility blocks. That separation is helpful when planning the process. The AI proposes fields; the validation and transformation stages prepare the values the next step expects. If an implementation combines those stages, its behavior still needs the same explicit requirements.

Do not use a successful parse as proof that an extraction is accurate. A syntactically valid amount can still come from the wrong part of a document. Test meaning as well as format, and keep a review path for cases where the source admits more than one interpretation.

Make ambiguity visible to a person

The site's human-in-the-loop explanations include output review and requests for information. Those are useful options when a required field cannot be established. The process can pause with the source passage and the unresolved field, rather than producing a confident substitute.

For example, a document might contain an issue date and a due date. If the contract requires the due date, the reviewer should see which date the proposed value refers to. A prompt that says “find the date” is too vague for that handoff. Define the business meaning before asking the model to extract it.

Store corrections separately enough to explain what changed. The proposed value, accepted value, reviewer, and reason can be useful when reviewing a sample later. Whether the chosen service supports such a record needs to be checked directly; it is a design requirement, not a verified platform feature.

Use a small reference set

Begin with a few representative documents: an ordinary example, a missing field, competing dates, and an unusual format. Write the expected fields by hand before comparing model outputs. That reference set gives the evaluation a stable target.

Include the downstream step in the test. Check whether it receives a normalized value, a deliberate missing state, or a request for human input. An extraction can pass a visual inspection and still fail when another tool consumes the result.

Public building-block explanations help organize these questions, while run behavior and data accuracy need separate evidence. Once the field contract is clear, model choice becomes a bounded experiment: can this implementation produce the required fields, preserve their sources, and stop when the contract is unresolved?