Translate the task into labels
List the exact information the model should extract or classify, with positive and negative examples. Distinguish a supplier address from a shipping destination and an invoice date from a payment deadline. Use business definitions that remain stable when the visual layout changes across organizations.
Keep evidence close to labels
Decide whether annotations require text spans, page coordinates, table cells, normalized values, or relationships. Preserve an explicit connection between an output and its supporting source. For repeated fields, specify whether labels attach to individual occurrences, a preferred occurrence, or a consolidated document-level value.
Define ambiguity handling
Write rules for unreadable text, conflicting totals, absent fields, and partial documents. Allow uncertain labels when the source does not justify a definitive answer. Review disagreement cases early and update the schema with examples, rather than treating every disagreement as an annotator error to be overwritten.
Test the schema on a pilot
Have reviewers independently label a varied sample and compare decisions by field and document family. Revise unclear rules before expanding the batch. Send Fiund a draft schema and difficult examples so a sourcing discussion can account for the evidence, source quality, and review effort your task needs. Try labeling a document that contains two supplier addresses and an invoice number repeated in a footer. Ask independent reviewers which occurrence supports the output and why. Their reasoning can expose whether the schema describes the business entity clearly or merely relies on where a field appeared in the first example.
Review checklist
- Define each label with counterexamples
- Choose evidence and coordinate formats
- Write uncertainty and conflict rules
- Adjudicate a varied pilot before expansion