IDP Build Schema

IDP Build Schema

Type: idp-build-schema  ·  Package: IDP Activities v1.18.0  ·  Output: object

Turns a taxonomy into the JSON Schema that AI Extract consumes. For each field it asks for two things: the interpreted value, and the literal text from the document it comes from — which is what IDP Ground later uses to locate it.

The normal flow no longer uses it

IDP Extract now extracts all fields in a single call (no strict grammar), so it doesn’t split the schema into batches or use this activity. IDP Build Schema remains as a low-level building block for anyone assembling an extraction pipeline by hand.

Required parameters

Parameter	Editor	Description
taxonomy	JSON	The taxonomy: a path to a .json file, or the object itself.

Output

Returns an object holding the JSON Schema, ready to hand straight to AI Extract.

The taxonomy

It describes one type of document, not one layout. That is where the business case lives: the visual layer changes from one hospital to the next, the meaning does not. A single hoja-de-vida-equipo-biomedico.json serves all of them.

{
  "documentType": "hoja-de-vida-equipo-biomedico",
  "description": "Record of a biomedical device. The layout varies between hospitals.",
  "fields": [
    {
      "name": "serial",
      "type": "string",
      "description": "The device's serial number, exactly as printed",
      "minConfidence": 0.95
    },
    {
      "name": "brand",
      "type": "string",
      "description": "The device's brand or manufacturer",
      "minConfidence": 0.6
    }
  ]
}

Key	Required	What it is
documentType	yes	Identifier for the type of document.
description	no	What this document is. Passed to the model as context.
fields[].name	yes	The field’s name in the result.
fields[].type	no	string (default), number, integer, boolean, date or table.
fields[].description	yes	What this field is.
fields[].minConfidence	no	Confidence required to accept it. Default 0.8.
fields[].fields	only on table	The table’s columns.

Tables: fields that repeat

A field of type table is a field that repeats: one row per occurrence in the document. It is what lets you pull out a maintenance history, a parts list, or anything with N entries.

{
  "name": "maintenance",
  "type": "table",
  "description": "The device's maintenance history",
  "fields": [
    { "name": "date",       "type": "date",   "description": "Date of the maintenance",     "minConfidence": 0.8 },
    { "name": "kind",       "type": "string", "description": "Preventive or corrective",    "minConfidence": 0.7 },
    { "name": "technician", "type": "string", "description": "The technician's name",       "minConfidence": 0.7 }
  ]
}

Columns are declared like any other field, with their own description and their own minConfidence — because a date and a technician’s name are not read with the same reliability. The table itself carries no minConfidence: it is not verified as a whole, it is verified cell by cell.

No tables inside tables

Columns can only be scalars. A nested table does not exist in these documents, and allowing one would complicate the schema, the grounding and the review screen for nothing.

An empty table is not an error

If the document has no such rows, the result is an empty list and it is not flagged for review: “this device has had no maintenance yet” is a real and common state, and flagging it would send every new device in the batch to a person.

The description is not documentation — it is the prompt

The model reads each field’s description to decide what belongs in it. That is why it is required. Write it the way you would explain it to someone seeing the document for the first time: “the device’s serial number, exactly as printed” works far better than “serial”.

Thresholds are per field

minConfidence is the confidence required to accept a field without a person looking at it. Higher means stricter.

It is per field on purpose. A serial number is alphanumeric with no linguistic redundancy: it is exactly where OCR fails, and where being wrong is expensive — so it demands near-certainty (0.95). A brand is always read correctly and context corrects it anyway, so demanding the same would only send work to review that doesn’t need it (0.6).

One threshold for the whole document sends everything to review and kills the ROI.

Example

IDP Build Schema   taxonomy = = asset("taxonomies/device-record.json")   → output: schema
AI Extract         credential = = credential("anthropic-key")
                   prompt     = = doc["text"]
                   schema     = = schema
                   → output: extraction

Related activities

• IDP Ground — the next step: locate and validate what was extracted.
• AI Extract — the model call that uses this schema.