Information Extraction Prompting

Introduction

Information extraction prompting is the process of instructing a language model to locate specific facts inside unstructured or semi-structured content and return those facts in a defined format.

The input may contain:

• Emails
• Articles
• Invoices
• Resumes
• Support tickets
• Product descriptions
• Meeting notes
• Contracts
• Reports
• Web page text
• Chat conversations
• Database exports

The model does not need to rewrite or summarize the full input. Its main job is to identify the requested information and return only the required fields.

For example, a support message may contain a customer name, order number, product name, complaint, purchase date, and requested resolution. An extraction prompt can convert that message into structured data.

Input:

My name is Rahul Patil. I ordered a Samsung Galaxy S25 on 10 July 2026. My order number is ORD-78452. The phone arrived with a damaged screen.

Extracted output:

{
  "customer_name": "Rahul Patil",
  "order_number": "ORD-78452",
  "product_name": "Samsung Galaxy S25",
  "order_date": "2026-07-10",
  "issue": "Damaged screen"
}

Information extraction is useful because most real-world data is not stored in a clean database format. Important facts are often hidden inside long text. A well-designed extraction prompt converts that text into data that software systems can process.

Why Information Extraction Prompting Is Important

Information extraction prompting helps organisations convert natural-language content into structured information.

Main benefits include:

• Reduces manual data entry
• Saves processing time
• Converts documents into database-ready records
• Supports automated workflows
• Improves search and filtering
• Helps create reports and dashboards
• Identifies important facts in long documents
• Makes unstructured content easier to analyse
• Supports classification and decision-making systems
• Creates consistent data from different document formats

A weak extraction prompt may return incomplete, incorrect, duplicated, or invented information. A strong extraction prompt defines exactly what to extract, how to format it, and what to do when information is missing.

Learning Objectives

After completing this chapter, you should be able to:

• Extract named entities from text
• Extract important keywords and phrases
• Identify dates and convert them into standard formats
• Extract phone numbers, email addresses, and postal addresses
• Extract product attributes from descriptions
• Identify events and their details
• Extract relationships between people, organisations, products, and events
• Convert text-based tables into structured records
• Extract fixed fields from documents
• Design clear extraction schemas
• Handle missing and optional fields
• Remove or merge duplicate data
• Capture source evidence for extracted facts
• Validate extracted results
• Create reusable information extraction templates

Key Terms

Unstructured Data

Content without a fixed data format, such as emails, reviews, articles, and chat messages.

Semi-Structured Data

Content that contains some organisation but does not follow a strict database structure, such as invoices, HTML pages, and forms.

Entity

A named object found in text, such as a person, organisation, location, product, or date.

Field

A specific piece of data that must be extracted, such as customer_name or invoice_number.

Schema

A formal definition of the expected output fields, data types, allowed values, and required rules.

Source Evidence

The exact part of the input that supports an extracted value.

Normalisation

The process of converting different representations into one standard format.

Example:

• 10 July 2026
• July 10, 2026
• 10/07/2026

Normalised value:

• 2026-07-10

Validation

The process of checking whether extracted data is complete, correctly formatted, and supported by the source.

Null Value

A value used when a field is not available or cannot be determined.

Basic Information Extraction Workflow

A reliable extraction process normally follows these steps:

1. Define the information that must be extracted.
2. Define the output fields.
3. Define the data type of each field.
4. Provide the source text.
5. Instruct the model not to invent missing values.
6. Define how missing fields should be represented.
7. Define formatting and normalisation rules.
8. Ask for supporting evidence where required.
9. Validate the extracted output.
10. Return the result in a machine-readable format.

Basic prompt structure:

Task: Extract the requested information from the input text.
Fields: Extract customer name, order number, product name, purchase date, and issue.
Missing values: Return null when a field is not present.
Accuracy rule: Do not guess or invent information.
Date format: Convert all dates to YYYY-MM-DD.
Output format: Return valid JSON only.
Input text: [Insert source text]

Entity Extraction

Entity extraction identifies named items mentioned in text.

Common entity types include:

• Person
• Organisation
• Location
• Product
• Brand
• Job title
• Department
• Currency
• Amount
• Date
• Time
• Technology
• Medical term
• Legal term
• Event

Entity extraction is also called named entity recognition when the task focuses on recognised categories such as people, organisations, and locations.

How Entity Extraction Works

The model reads the input and identifies phrases that belong to the requested entity categories.

Input:

Priya Sharma joined Infosys as a Java Developer in Pune on 15 March 2025.

Possible entities:

• Priya Sharma: Person
• Infosys: Organisation
• Java Developer: Job title
• Pune: Location
• 15 March 2025: Date

Important Prompt Instructions

A strong entity extraction prompt should define:

• Which entity types are required
• Whether repeated entities should be included
• Whether entity text must remain unchanged
• Whether normalised values are required
• Whether entity positions are required
• Whether confidence scores are required
• Whether source evidence must be included

Entity Extraction Prompt

Task: Extract named entities from the input text.
Entity types: person, organisation, location, job_title, technology, and date.
Preserve text: Keep each entity exactly as written in the source.
Duplicate rule: Return each unique entity only once.
Missing rule: Return an empty array for an entity type that is not present.
Accuracy rule: Do not infer entities that are not directly mentioned.
Output format: Return valid JSON only.
Input text: Priya Sharma joined Infosys as a Java Developer in Pune on 15 March 2025.

Expected Output

{
  "person": ["Priya Sharma"],
  "organisation": ["Infosys"],
  "location": ["Pune"],
  "job_title": ["Java Developer"],
  "technology": [],
  "date": ["15 March 2025"]
}

Entity Extraction with Evidence

Task: Extract all person and organisation entities from the input.
Evidence: Include the exact sentence containing each entity.
Accuracy rule: Do not guess implied names.
Output format: Return a JSON array of objects.
Input text: [Insert text]

Expected structure:

[
  {
    "entity": "Priya Sharma",
    "type": "person",
    "evidence": "Priya Sharma joined Infosys as a Java Developer."
  },
  {
    "entity": "Infosys",
    "type": "organisation",
    "evidence": "Priya Sharma joined Infosys as a Java Developer."
  }
]

Best Practices

• Use clear entity labels.
• Avoid broad labels such as other unless necessary.
• Define whether job titles and technologies count as entities.
• Preserve the original entity text.
• Separate extracted text from normalised values.
• Do not ask the model to infer names from unclear references.
• Use evidence for high-risk extraction tasks.
• Include an empty array when no entities are found.

Keyword Extraction

Keyword extraction identifies the most important words or phrases that represent the main subjects of a document.

Unlike entity extraction, keywords do not need to be named objects. A keyword may describe:

• A concept
• A topic
• A process
• A problem
• A feature
• A technology
• A business area
• A user intention

Input:

Spring Boot simplifies Java application development by providing auto-configuration, embedded servers, and production-ready monitoring features.

Possible keywords:

• Spring Boot
• Java application development
• Auto-configuration
• Embedded servers
• Production monitoring

Keyword Extraction vs Entity Extraction

Entity extraction identifies named objects.

Example:

• Spring Boot
• Java

Keyword extraction identifies important concepts.

Example:

• Auto-configuration
• Application development
• Production monitoring

A phrase can sometimes be both an entity and a keyword.

Types of Keywords

Single-Word Keywords

Examples:

• Security
• Performance
• Database
• Authentication

Multi-Word Keywords

Examples:

• Database connection pooling
• Role-based access control
• Customer complaint resolution
• Large language model

Domain-Specific Keywords

Examples from software development:

• Dependency injection
• REST API
• Exception handling
• Memory management

Keyword Extraction Prompt

Task: Extract the most important keywords from the input text.
Keyword count: Return a maximum of 8 keywords.
Keyword type: Prefer meaningful multi-word phrases over isolated common words.
Relevance rule: Include only terms that represent the main content.
Duplicate rule: Do not return repeated or closely similar keywords.
Ordering rule: Order keywords from most relevant to least relevant.
Output format: Return a JSON array of strings.
Input text: Spring Boot simplifies Java application development by providing auto-configuration, embedded servers, and production-ready monitoring features.

Expected Output

[
  "Spring Boot",
  "Java application development",
  "Auto-configuration",
  "Embedded servers",
  "Production-ready monitoring"
]

Weighted Keyword Extraction

A prompt can ask the model to assign a relevance score.

Task: Extract the five most important keywords from the input text.
Score range: Assign each keyword a relevance score from 0.00 to 1.00.
Ordering rule: Sort results by relevance score in descending order.
Output format: Return valid JSON only.
Input text: [Insert text]

Expected output structure:

[
  {
    "keyword": "Spring Boot",
    "relevance_score": 0.98
  },
  {
    "keyword": "Auto-configuration",
    "relevance_score": 0.91
  }
]

Common Problems

Returning General Words

Weak keywords:

• System
• Data
• Process
• Information

Better keywords:

• Customer data validation
• Payment processing system
• Invoice information extraction

Returning Full Sentences

A keyword should normally be a short word or phrase, not a complete sentence.

Returning Too Many Keywords

Too many keywords reduce usefulness. Set a maximum keyword count.

Returning Similar Keywords

Avoid results such as:

• Java development
• Java application development
• Application development using Java

Choose the clearest representative phrase.

Best Practices

• Set a keyword limit.
• Prefer specific phrases.
• Remove stop words.
• Avoid repeated meaning.
• Rank keywords by relevance.
• Preserve domain terminology.
• Define whether keywords must appear exactly in the source.
• Use confidence or relevance scores when ranking matters.

Date Extraction

Date extraction identifies calendar dates, relative dates, ranges, deadlines, and date-related expressions.

Common date forms include:

• 15 August 2026
• August 15, 2026
• 15/08/2026
• 2026-08-15
• Next Monday
• Yesterday
• Two weeks from now
• From 1 June to 15 June
• End of this month

Types of Date Values

Explicit Dates

The date is directly provided.

Example:

• 20 July 2026

Partial Dates

Some date components are missing.

Examples:

• July 2026
• 15 July
• 2026

Relative Dates

The date depends on a reference date.

Examples:

• Tomorrow
• Next Friday
• Three days ago

Date Ranges

A start date and end date are provided.

Example:

• 10 August 2026 to 15 August 2026

Recurring Dates

The date repeats.

Examples:

• Every Monday
• First day of each month
• Every year on 1 January

Date Normalisation

Dates should normally be converted to a standard format.

Recommended date format:

• YYYY-MM-DD

Recommended date and time format:

• YYYY-MM-DDTHH:MM:SS with timezone information when available

Example:

Input:

• 10 July 2026

Normalised value:

• 2026-07-10

Date Extraction Prompt

Task: Extract all dates from the input text.
Date format: Convert complete dates to YYYY-MM-DD.
Preserve source: Include the original date expression.
Reference date: Use 2026-08-06 when resolving relative dates.
Partial date rule: Keep unknown components as null.
Accuracy rule: Do not assume missing years or months.
Output format: Return a JSON array of objects.
Input text: The application closes next Monday. Interviews will begin on 20 August 2026.

Expected Output

[
  {
    "original_text": "next Monday",
    "normalised_date": "2026-08-10",
    "date_type": "relative",
    "is_complete": true
  },
  {
    "original_text": "20 August 2026",
    "normalised_date": "2026-08-20",
    "date_type": "explicit",
    "is_complete": true
  }
]

Handling Ambiguous Dates

A value such as 04/05/2026 may mean:

• 4 May 2026
• April 5, 2026

The prompt should specify the expected regional format.

Example instruction:

Date interpretation: Interpret numeric dates using DD/MM/YYYY format.

When the format cannot be safely determined:

Ambiguity rule: Return the original date and mark ambiguous as true.

Expected output:

{
  "original_text": "04/05/2026",
  "normalised_date": null,
  "ambiguous": true,
  "possible_values": ["2026-05-04", "2026-04-05"]
}

Relative Date Resolution

Relative dates require a fixed reference date.

Weak instruction:

Convert tomorrow to a date.

Strong instruction:

Resolve relative dates using 2026-08-06 as the reference date.

Without a reference date, the result may change depending on when the prompt runs.

Best Practices

• Define a reference date.
• Specify the regional date format.
• Preserve original date expressions.
• Use ISO date formats.
• Do not invent missing years.
• Mark ambiguous dates clearly.
• Separate start and end dates.
• Include timezone data for date-time extraction.
• State whether relative expressions should be resolved.

Contact Information Extraction

Contact information extraction identifies personal or business contact details from text.

Common contact fields include:

• Full name
• Email address
• Phone number
• Alternate phone number
• Country code
• Street address
• City
• State
• Postal code
• Country
• Website
• Social media profile
• Organisation
• Department
• Job title

Example Input

Contact Anjali Mehta at anjali.mehta@example.com or +91 98765 43210. Her office is located at 21 Baner Road, Pune, Maharashtra 411045.

Expected Fields

• Name: Anjali Mehta
• Email: [anjali.mehta@example.com](mailto:anjali.mehta@example.com)
• Phone: +91 98765 43210
• Address: 21 Baner Road
• City: Pune
• State: Maharashtra
• Postal code: 411045
• Country: Not directly mentioned

Contact Extraction Prompt

Task: Extract contact information from the input text.
Fields: full_name, email, phone_number, street_address, city, state, postal_code, country, and website.
Phone rule: Preserve the original phone number and also return a normalised version.
Country rule: Do not infer the country only from the phone code unless inference is explicitly enabled.
Missing rule: Return null for missing fields.
Accuracy rule: Do not invent contact details.
Output format: Return valid JSON only.
Input text: Contact Anjali Mehta at anjali.mehta@example.com or +91 98765 43210. Her office is located at 21 Baner Road, Pune, Maharashtra 411045.

Expected Output

{
  "full_name": "Anjali Mehta",
  "email": "anjali.mehta@example.com",
  "phone_number": {
    "original": "+91 98765 43210",
    "normalised": "+919876543210"
  },
  "street_address": "21 Baner Road",
  "city": "Pune",
  "state": "Maharashtra",
  "postal_code": "411045",
  "country": null,
  "website": null
}

Extracting Multiple Contacts

When a document contains multiple people, return an array.

Task: Extract every contact person from the input.
Grouping rule: Keep each person's contact details in a separate object.
Association rule: Attach an email or phone number only when the text clearly associates it with that person.
Missing rule: Return null for missing values.
Output format: Return a JSON array only.
Input text: [Insert contact list]

Phone Number Normalisation

Phone numbers may appear as:

• 9876543210
• 98765 43210
• +91-98765-43210
• 0091 9876543210

A normalised international form may be:

• +919876543210

Do not remove meaningful extension values.

Example:

{
  "original": "+1 212 555 0188 ext. 402",
  "normalised": "+12125550188",
  "extension": "402"
}

Email Validation

A language model can identify email-like text, but the output should still be validated using software rules.

Validation checks may include:

• Contains one at symbol
• Contains a valid domain section
• Does not contain spaces
• Does not end with a punctuation mark
• Is not duplicated

Privacy Considerations

Contact information may be personal data. Extraction systems should:

• Process only required fields
• Limit access to extracted results
• Avoid unnecessary storage
• Mask sensitive values where needed
• Follow applicable privacy requirements
• Avoid exposing personal data in logs

Best Practices

• Define all contact fields.
• Preserve original formatting.
• Provide normalised values separately.
• Do not connect contact details to a person without evidence.
• Return separate objects for multiple contacts.
• Validate emails and phone numbers programmatically.
• Handle extensions and country codes.
• Avoid inferring missing address parts.

Product Information Extraction

Product information extraction converts product descriptions, catalogues, invoices, listings, or reviews into structured product records.

Common product fields include:

• Product name
• Brand
• Model
• Category
• Price
• Currency
• Discount
• Colour
• Size
• Material
• Storage
• Memory
• Processor
• Quantity
• Stock status
• SKU
• Product code
• Warranty
• Seller
• Rating
• Features

Example Input

The Dell Inspiron 14 5440 laptop includes an Intel Core 7 processor, 16 GB RAM, 512 GB SSD, and a 14-inch display. It is priced at ₹74,990 and includes a one-year warranty.

Product Extraction Prompt

Task: Extract product information from the input text.
Fields: product_name, brand, model, category, processor, ram, storage, display_size, price, currency, warranty, and features.
Normalisation rule: Convert storage and memory values into standard units without changing their meaning.
Missing rule: Return null for missing scalar fields and an empty array for missing feature lists.
Accuracy rule: Extract only explicitly stated product details.
Output format: Return valid JSON only.
Input text: The Dell Inspiron 14 5440 laptop includes an Intel Core 7 processor, 16 GB RAM, 512 GB SSD, and a 14-inch display. It is priced at ₹74,990 and includes a one-year warranty.

Expected Output

{
  "product_name": "Dell Inspiron 14 5440",
  "brand": "Dell",
  "model": "Inspiron 14 5440",
  "category": "Laptop",
  "processor": "Intel Core 7",
  "ram": {
    "value": 16,
    "unit": "GB"
  },
  "storage": {
    "value": 512,
    "unit": "GB",
    "type": "SSD"
  },
  "display_size": {
    "value": 14,
    "unit": "inch"
  },
  "price": 74990,
  "currency": "INR",
  "warranty": "One year",
  "features": []
}

Extracting Multiple Products

When multiple products are present, use an array.

Task: Extract all products from the input text.
Product boundary rule: Create a separate record for each clearly distinct product.
Variant rule: Treat different colours or storage options as variants when they share the same model.
Price rule: Associate each price only with the product or variant it describes.
Missing rule: Return null for missing values.
Output format: Return valid JSON only.
Input text: [Insert product catalogue text]

Product Variants

A product may have multiple variants.

Example:

{
  "product_name": "Smartphone X",
  "variants": [
    {
      "colour": "Black",
      "storage": "128 GB",
      "price": 29999
    },
    {
      "colour": "Blue",
      "storage": "256 GB",
      "price": 34999
    }
  ]
}

Price Extraction Rules

The prompt should define:

• Whether tax is included
• Whether sale and original prices should be separate
• Which currency format to use
• Whether price ranges are allowed
• Whether monthly instalment values count as product prices
• How to handle multiple sellers

Example structure:

{
  "original_price": 79990,
  "sale_price": 74990,
  "currency": "INR",
  "discount_percentage": 6.25
}

Best Practices

• Define product-specific fields.
• Separate products from variants.
• Preserve model numbers exactly.
• Separate numeric values from units.
• Do not infer technical specifications.
• Associate prices with the correct product.
• Distinguish original and discounted prices.
• Return arrays for multiple products and features.
• Validate currency, quantity, and measurement formats.

Event Extraction

Event extraction identifies actions, occurrences, or changes described in text.

An event usually contains:

• Event type
• Event name
• Participants
• Date
• Time
• Location
• Organiser
• Action
• Target
• Cause
• Result
• Status

Examples of events include:

• Product launch
• Meeting
• Conference
• Appointment
• Payment
• Purchase
• Delivery
• System failure
• Job change
• Contract signing
• Legal hearing
• Medical procedure
• Security incident

Example Input

CodeLangs AI will conduct a Java interview preparation workshop on 25 August 2026 at 11:00 AM in Pune. Dattatray Sabne will lead the session.

Event Extraction Prompt

Task: Extract events from the input text.
Fields: event_type, event_name, organiser, participants, date, time, location, status, and source_evidence.
Date format: Convert complete dates to YYYY-MM-DD.
Time format: Convert time to 24-hour HH:MM format.
Missing rule: Return null for missing scalar values and an empty array for missing participant lists.
Accuracy rule: Do not infer event details that are not stated.
Output format: Return a JSON array only.
Input text: CodeLangs AI will conduct a Java interview preparation workshop on 25 August 2026 at 11:00 AM in Pune. Dattatray Sabne will lead the session.

Expected Output

[
  {
    "event_type": "Workshop",
    "event_name": "Java interview preparation workshop",
    "organiser": "CodeLangs AI",
    "participants": ["Dattatray Sabne"],
    "date": "2026-08-25",
    "time": "11:00",
    "location": "Pune",
    "status": "Planned",
    "source_evidence": "CodeLangs AI will conduct a Java interview preparation workshop on 25 August 2026 at 11:00 AM in Pune."
  }
]

Event Trigger

An event trigger is the word or phrase that signals an event.

Examples:

• Launched
• Purchased
• Joined
• Resigned
• Announced
• Failed
• Delivered
• Approved
• Cancelled

Example:

Infosys appointed Neha Rao as Chief Technology Officer.

Trigger:

• Appointed

Event type:

• Executive appointment

Event Arguments

Event arguments are the entities connected to an event.

For the appointment example:

• Organisation: Infosys
• Person: Neha Rao
• Position: Chief Technology Officer
• Action: Appointed

Multiple Events in One Sentence

Input:

The company announced the product on Monday and released it on Friday.

Events:

1. Product announcement
2. Product release

The prompt should explicitly instruct the model to separate distinct events.

Event separation rule: Create a separate event object for every distinct action, even when multiple actions appear in one sentence.

Event Status

Possible status values include:

• Planned
• Scheduled
• In progress
• Completed
• Cancelled
• Postponed
• Failed
• Unknown

Use a fixed list when consistent output is required.

Best Practices

• Define event types.
• Extract separate events separately.
• Include event triggers when useful.
• Identify participants and their roles.
• Normalise dates and times.
• Define event status values.
• Include source evidence.
• Do not treat general statements as actual events.
• Distinguish planned events from completed events.

Relationship Extraction

Relationship extraction identifies how two or more entities are connected.

Common relationships include:

• Person works for organisation
• Person holds job title
• Organisation owns product
• Product belongs to category
• Company acquired company
• Person manages person
• Organisation located in city
• Product manufactured by company
• Customer purchased product
• Event organised by organisation
• Technology depends on library
• Document signed by person

Example Input

Rohan Kulkarni works as a Software Engineer at TCS and reports to project manager Sneha Joshi.

Extracted relationships:

• Rohan Kulkarni works for TCS
• Rohan Kulkarni has job title Software Engineer
• Rohan Kulkarni reports to Sneha Joshi
• Sneha Joshi has job title Project Manager

Relationship Structure

A relationship record usually contains:

• Subject
• Relationship type
• Object
• Evidence
• Confidence
• Direction

Example:

{
  "subject": "Rohan Kulkarni",
  "relationship": "works_for",
  "object": "TCS"
}

Relationship Extraction Prompt

Task: Extract relationships between entities from the input text.
Relationship types: works_for, has_job_title, reports_to, located_in, owns, manufactures, and purchased.
Direction rule: Keep the relationship direction exactly as defined.
Evidence rule: Include the exact text supporting each relationship.
Accuracy rule: Do not infer relationships from general knowledge.
Duplicate rule: Return each unique relationship only once.
Output format: Return a JSON array only.
Input text: Rohan Kulkarni works as a Software Engineer at TCS and reports to project manager Sneha Joshi.

Expected Output

[
  {
    "subject": "Rohan Kulkarni",
    "relationship": "works_for",
    "object": "TCS",
    "evidence": "Rohan Kulkarni works as a Software Engineer at TCS"
  },
  {
    "subject": "Rohan Kulkarni",
    "relationship": "has_job_title",
    "object": "Software Engineer",
    "evidence": "Rohan Kulkarni works as a Software Engineer"
  },
  {
    "subject": "Rohan Kulkarni",
    "relationship": "reports_to",
    "object": "Sneha Joshi",
    "evidence": "reports to project manager Sneha Joshi"
  },
  {
    "subject": "Sneha Joshi",
    "relationship": "has_job_title",
    "object": "Project Manager",
    "evidence": "project manager Sneha Joshi"
  }
]

Direct vs Inferred Relationships

Direct relationship:

Amit works for ABC Technologies.

The relationship is clearly stated.

Inferred relationship:

Amit entered the ABC Technologies office every morning.

This does not prove that Amit works for the company.

A strong prompt should say:

Extraction rule: Include only relationships directly supported by the text.

Relationship Direction

These two relationships are not identical:

• Company employs person
• Person works for company

Choose one standard direction.

Example schema:

• subject: Person
• relationship: works_for
• object: Organisation

Relationship Labels

Use stable labels rather than different natural-language phrases.

Different source phrases:

• Works at
• Is employed by
• Is part of
• Joined

Normalised relationship label:

• works_for

However, joined may represent an employment event rather than a current relationship. The schema should distinguish these cases when required.

Best Practices

• Define allowed relationship types.
• Set a standard relationship direction.
• Include source evidence.
• Avoid unsupported inference.
• Normalise relationship labels.
• Resolve pronouns only when the reference is clear.
• Return separate records for separate relationships.
• Remove duplicate subject-relationship-object combinations.

Table Extraction

Table extraction converts table-like content into rows and columns.

The source may be:

• A Markdown table
• An HTML table
• Plain text with aligned columns
• A copied spreadsheet
• A PDF table
• A scanned document
• A report containing repeated records
• A list formatted like a table

Example Input

Product | Quantity | Price
Keyboard | 2 | 1500
Mouse | 3 | 700
Monitor | 1 | 12000

Table Extraction Prompt

Task: Extract the table from the input text.
Columns: product, quantity, and price.
Data types: product must be a string, quantity must be an integer, and price must be a number.
Missing rule: Return null for missing cells.
Header rule: Do not include the header as a data row.
Output format: Return a JSON array of row objects.
Input text: Product | Quantity | Price
Keyboard | 2 | 1500
Mouse | 3 | 700
Monitor | 1 | 12000

Expected Output

[
  {
    "product": "Keyboard",
    "quantity": 2,
    "price": 1500
  },
  {
    "product": "Mouse",
    "quantity": 3,
    "price": 700
  },
  {
    "product": "Monitor",
    "quantity": 1,
    "price": 12000
  }
]

Handling Merged Cells

Merged cells may apply one value to several rows.

Example source:

Department | Employee | Role
Engineering | Amit | Developer
            | Sneha | Tester

Expected output:

[
  {
    "department": "Engineering",
    "employee": "Amit",
    "role": "Developer"
  },
  {
    "department": "Engineering",
    "employee": "Sneha",
    "role": "Tester"
  }
]

Prompt instruction:

Merged cell rule: Carry a parent cell value into following rows only when the table structure clearly shows that the value applies to those rows.

Handling Multi-Line Cells

A table cell may contain text across multiple lines.

Prompt instruction:

Multi-line rule: Combine lines that belong to the same cell into one string without merging different rows.

Handling Missing Headers

When headers are missing, the model should not freely invent field names unless the task allows it.

Safer instruction:

Header rule: When headers are missing, return column_1, column_2, and column_3 unless the meaning is clear from surrounding text.

Extracting Tables from Documents

When extracting a table from a long document:

• Identify the correct table first.
• Use the table title or nearby heading.
• Preserve row order.
• Preserve column relationships.
• Do not mix values from different tables.
• Include the page or section reference when available.

Table Validation

Validation should check:

• Every row has the expected fields.
• Numeric columns contain valid numbers.
• Dates follow the defined format.
• Row count matches the source.
• Headers are not included as rows.
• Cells have not shifted into the wrong columns.
• Totals match when a total row exists.

Best Practices

• Define the expected columns.
• Define each column's data type.
• Preserve row order.
• Handle merged and multi-line cells carefully.
• Return null for empty cells.
• Avoid inventing missing headers.
• Validate numeric values.
• Confirm that values remain in the correct columns.
• Separate multiple tables into different arrays.

Document Field Extraction

Document field extraction retrieves specific fields from a known document type.

Common document types include:

• Invoice
• Purchase order
• Resume
• Bank statement
• Insurance form
• Contract
• Receipt
• Application form
• Identity document
• Medical report
• Tax document
• Delivery note

Unlike general entity extraction, document field extraction uses a predefined set of expected fields.

Invoice Field Example

Common invoice fields:

• Invoice number
• Invoice date
• Due date
• Seller name
• Buyer name
• Seller tax number
• Buyer tax number
• Billing address
• Shipping address
• Line items
• Subtotal
• Tax
• Discount
• Total amount
• Currency
• Payment status

Invoice Extraction Prompt

Task: Extract invoice fields from the input document.
Fields: invoice_number, invoice_date, due_date, seller_name, buyer_name, subtotal, tax, discount, total_amount, currency, and line_items.
Date format: Convert complete dates to YYYY-MM-DD.
Amount rule: Return numeric values without currency symbols.
Line item fields: description, quantity, unit_price, tax, and line_total.
Missing rule: Return null for missing scalar fields and an empty array for missing line items.
Accuracy rule: Do not calculate a missing value unless calculation is explicitly requested.
Evidence rule: Include source evidence for invoice_number and total_amount.
Output format: Return valid JSON only.
Input document: [Insert invoice text]

Resume Field Example

Common resume fields:

• Candidate name
• Email
• Phone
• Location
• Professional summary
• Skills
• Work experience
• Education
• Certifications
• Projects
• Languages

Resume Extraction Prompt

Task: Extract candidate information from the resume.
Fields: full_name, email, phone, location, skills, work_experience, education, certifications, and projects.
Experience fields: company, job_title, start_date, end_date, responsibilities, and technologies.
Education fields: qualification, institution, field_of_study, start_year, and end_year.
Missing rule: Return null for missing scalar values and an empty array for missing lists.
Accuracy rule: Do not estimate employment dates or experience duration.
Output format: Return valid JSON only.
Resume text: [Insert resume]

Contract Field Example

Common contract fields:

• Contract title
• Parties
• Effective date
• Expiration date
• Payment terms
• Obligations
• Renewal clause
• Termination clause
• Governing law
• Signatories

High-risk documents should include source evidence and review flags.

Example output field:

{
  "termination_clause": {
    "value": "Either party may terminate with 30 days written notice.",
    "evidence": "Either party may terminate this agreement by providing thirty days written notice.",
    "review_required": false
  }
}

Fixed Schema Advantage

A fixed document schema:

• Improves consistency
• Simplifies validation
• Supports database storage
• Makes missing fields visible
• Reduces unnecessary output
• Makes document comparison easier

Best Practices

• Use a schema designed for the document type.
• Separate header fields from line items.
• Define date and amount formats.
• Preserve identifiers exactly.
• Do not calculate missing totals without permission.
• Include evidence for critical fields.
• Mark uncertain fields for human review.
• Validate extracted totals and dates.
• Keep multiple documents in separate records.

Defining Extraction Schemas

An extraction schema defines the exact structure of the expected output.

It tells the model:

• Which fields to return
• Which fields are required
• Which fields are optional
• What data type each field uses
• Which values are allowed
• How nested data should be represented
• How missing information should be handled
• How repeated items should be represented

Why Schemas Matter

Without a schema, the model may:

• Use different field names each time
• Return extra explanations
• Change data types
• Combine unrelated values
• Omit required fields
• Represent lists as text
• Use inconsistent date formats
• Invent missing information

A schema makes the output predictable.

Basic Schema Example

{
  "customer_name": "string or null",
  "order_number": "string or null",
  "order_date": "YYYY-MM-DD or null",
  "products": [
    {
      "name": "string",
      "quantity": "integer",
      "price": "number"
    }
  ],
  "issue_type": "damaged | missing | delayed | incorrect | other | null"
}

Scalar Data Types

Common scalar types include:

• String
• Integer
• Number
• Boolean
• Date
• Date-time
• Null

Collection Types

Common collection types include:

• Array of strings
• Array of numbers
• Array of objects
• Nested object

Required and Optional Fields

Required field:

• Must always appear in the output.
• May contain null if the value is missing and the schema allows null.

Optional field:

• May be omitted completely.

For easier validation, extraction systems often require every defined field to appear, even when its value is null.

Enumerated Values

An enumerated field allows only specific values.

Example:

"priority": "low | medium | high | critical"

Enumerations improve consistency and reduce unexpected wording.

Nested Schema Example

{
  "customer": {
    "name": "string or null",
    "email": "string or null",
    "phone": "string or null"
  },
  "order": {
    "order_number": "string or null",
    "order_date": "YYYY-MM-DD or null",
    "items": [
      {
        "product_name": "string",
        "quantity": "integer",
        "unit_price": "number or null"
      }
    ]
  }
}

Schema Definition Prompt

Task: Extract customer support information from the input.
Schema: Follow the provided field structure exactly.
Required fields: Include every field in the output.
Missing rule: Use null for missing scalar values and an empty array for missing lists.
Extra fields: Do not add fields that are not defined in the schema.
Accuracy rule: Do not guess or invent values.
Output format: Return valid JSON only.
Schema:
  customer_name: string or null
  order_number: string or null
  issue_type: damaged, missing, delayed, incorrect, other, or null
  issue_summary: string or null
  requested_action: refund, replacement, repair, information, or null
  products: array of strings
Input text: [Insert support message]

Schema Design Principles

Use Clear Field Names

Good:

• invoice_date
• customer_email
• total_amount

Weak:

• date
• info
• value

Use One Meaning per Field

Do not combine unrelated values into one field.

Weak:

"customer": "Rahul, Pune, 9876543210"

Better:

{
  "customer_name": "Rahul",
  "city": "Pune",
  "phone": "9876543210"
}

Define Units

Weak:

"weight": 10

Better:

{
  "weight_value": 10,
  "weight_unit": "kg"
}

Define Normalisation Rules

Example:

• Dates use YYYY-MM-DD.
• Currency uses ISO codes such as INR and USD.
• Phone numbers use international format.
• Boolean values use true or false.
• Empty lists use [].
• Missing scalar values use null.

Avoid Excessive Schema Complexity

A schema should include fields needed by the application. Unnecessary fields make extraction harder and increase errors.

Best Practices

• Define every field clearly.
• Assign a data type to every field.
• Separate numbers from units.
• Use arrays for repeated values.
• Use nested objects for related fields.
• Define allowed values.
• Specify required and optional fields.
• Provide missing-value rules.
• Prevent extra fields.
• Keep the schema aligned with the final application.

Missing Field Handling

Missing field handling defines what the model should return when requested information is absent.

Without a clear rule, the model may:

• Guess a value
• Omit the field
• Return an empty string
• Return unknown
• Return not available
• Copy unrelated text
• Create an unsupported answer

Recommended Missing Value Rules

Use null for missing scalar fields.

Example:

{
  "customer_name": "Amit Shah",
  "email": null
}

Use an empty array for missing lists.

Example:

{
  "skills": []
}

Use false only when the source clearly states that something is false.

Do not use false simply because information is missing.

Example:

Input does not mention warranty.

Incorrect:

"has_warranty": false

Better:

"has_warranty": null

Missing vs Not Applicable

Missing means the value may exist, but it is not provided.

Not applicable means the field does not apply to that record.

These states may be represented separately.

Example:

{
  "middle_name": null,
  "middle_name_status": "missing"
}

Another example:

{
  "company_registration_number": null,
  "company_registration_number_status": "not_applicable"
}

Unknown vs Unclear

Unknown:

• The source does not provide the value.

Unclear:

• The source contains possible information, but it cannot be safely interpreted.

Example:

{
  "delivery_date": null,
  "status": "unclear",
  "evidence": "It should arrive around the middle of next month."
}

Missing Field Prompt

Task: Extract the defined fields from the input.
Missing scalar rule: Return null when a scalar value is not present.
Missing list rule: Return an empty array when no list items are present.
Unclear rule: Return null and set needs_review to true when a value is mentioned but unclear.
Accuracy rule: Never create, estimate, or infer missing values.
Required output rule: Include every schema field in the response.
Output format: Return valid JSON only.
Input text: [Insert text]

Default Values

Default values should be used only when the application defines them.

Example:

"currency": "INR"

This is safe only when all records in the specific system are guaranteed to use INR. It should not be assumed from location alone unless the business rule permits that inference.

Best Practices

• Use null consistently.
• Use empty arrays for missing collections.
• Distinguish missing from false.
• Distinguish unknown from not applicable.
• Mark unclear values for review.
• Do not infer values unless explicitly allowed.
• Include all required fields.
• Document any approved default values.

Duplicate Handling

Duplicate handling defines how repeated entities, records, events, or values should be processed.

Duplicates may appear because:

• The same fact is repeated in the document.
• A header is repeated on every page.
• The same product appears in multiple sections.
• A person's name appears with different capitalisation.
• The same event is described more than once.
• Data is copied from multiple sources.
• Different spellings refer to the same object.

Exact Duplicates

Exact duplicates have identical values.

Example:

• Java
• Java
• Java

Expected result:

• Java

Case-Insensitive Duplicates

Examples:

• Spring Boot
• spring boot
• SPRING BOOT

These may be treated as the same value while preserving the best source form.

Normalised Duplicates

Examples:

• +91 98765 43210
• 9876543210
• +919876543210

These may represent the same phone number after normalisation.

Near Duplicates

Examples:

• International Business Machines
• IBM

These may refer to the same organisation, but merging them requires evidence or an approved alias map.

Do not automatically merge near duplicates when identity is uncertain.

Duplicate Extraction Prompt

Task: Extract all unique entities from the input text.
Exact duplicate rule: Remove repeated identical values.
Case rule: Compare text without considering letter case.
Normalisation rule: Compare phone numbers after removing spaces and punctuation.
Preservation rule: Keep the clearest and most complete original form.
Near duplicate rule: Do not merge similar names unless the text clearly shows that they refer to the same entity.
Output format: Return valid JSON only.
Input text: [Insert text]

Duplicate Records

When extracting objects, define a unique key.

Examples:

• Product: SKU
• Invoice: invoice number
• Customer: customer ID
• Contact: normalised email
• Event: event type plus date plus participants
• Relationship: subject plus relationship plus object

Example rule:

Duplicate record key: Treat records with the same invoice_number as duplicates.

Merge Strategy

Possible duplicate strategies include:

Keep First

Keep the first record and ignore later duplicates.

Keep Last

Use the latest occurrence.

Keep Most Complete

Keep the record containing the most non-null fields.

Merge Fields

Combine non-conflicting values from duplicate records.

Keep All with Duplicate Flag

Return every record and mark likely duplicates.

Example:

{
  "record_id": "C101",
  "possible_duplicate_of": "C099",
  "duplicate_confidence": 0.86
}

Conflict Handling

Duplicate records may contain conflicting values.

Example:

Record one:

• Price: 1000

Record two:

• Price: 1200

The model should not choose silently.

Recommended output:

{
  "product_id": "P100",
  "price": null,
  "conflicting_values": [1000, 1200],
  "needs_review": true
}

Best Practices

• Define what counts as a duplicate.
• Use stable unique identifiers when available.
• Normalise before comparison.
• Do not merge uncertain entities.
• Preserve the clearest original form.
• Define a conflict strategy.
• Mark possible duplicates for review.
• Avoid deleting repeated facts when repetition itself is meaningful.

Source Evidence

Source evidence is the exact text that supports an extracted value.

Evidence makes extraction more trustworthy because reviewers can compare the result with the original input.

Why Source Evidence Matters

Source evidence helps:

• Verify extracted facts
• Detect hallucinated values
• Review ambiguous results
• Audit automated decisions
• Explain why a value was selected
• Correct extraction errors
• Meet compliance requirements
• Improve training and evaluation data

Evidence Example

Input:

The invoice total payable is ₹18,450, including ₹2,814 in tax.

Extracted result:

{
  "total_amount": {
    "value": 18450,
    "currency": "INR",
    "evidence": "The invoice total payable is ₹18,450"
  },
  "tax_amount": {
    "value": 2814,
    "currency": "INR",
    "evidence": "including ₹2,814 in tax"
  }
}

Types of Evidence

Exact Text Span

The exact phrase supporting the value.

Full Sentence

The complete source sentence.

Character Position

Start and end character indexes.

Page Number

Useful for PDF and scanned documents.

Section Name

Useful for contracts, reports, and resumes.

Table Cell Reference

Useful for table extraction.

Document Identifier

Useful when information comes from multiple documents.

Evidence Extraction Prompt

Task: Extract the requested fields and provide source evidence.
Evidence rule: Copy the shortest exact text span that directly supports each value.
Evidence restriction: Do not use text that only indirectly suggests the value.
Missing rule: Return null when no direct evidence exists.
Accuracy rule: Every non-null extracted value must include evidence.
Output format: Return valid JSON only.
Input text: [Insert text]

Expected Structure

{
  "employee_name": {
    "value": "Amit Verma",
    "evidence": "Amit Verma joined the company"
  },
  "joining_date": {
    "value": "2026-07-01",
    "evidence": "on 1 July 2026"
  }
}

Evidence and Normalised Values

The evidence should preserve the original source, while the value may be normalised.

Example:

{
  "date": {
    "value": "2026-07-01",
    "original_text": "1st July 2026",
    "evidence": "The employee joined on 1st July 2026."
  }
}

Unsupported Values

When evidence cannot be found:

{
  "value": null,
  "evidence": null,
  "status": "unsupported"
}

Evidence Quality Rules

Good evidence:

• Directly contains the value
• Is short and specific
• Comes from the correct record
• Preserves original wording
• Can be located in the source

Weak evidence:

• Is a long unrelated paragraph
• Requires guessing
• Comes from another entity's record
• Does not contain the claimed fact
• Is generated rather than copied

Best Practices

• Require evidence for important fields.
• Use the shortest supporting span.
• Preserve original text.
• Keep normalised values separate.
• Include page or section references when available.
• Reject values without evidence.
• Do not use the model's explanation as evidence.
• Validate that the evidence exists in the input.

Extraction Validation

Extraction validation checks whether the generated result is correct, complete, consistent, and properly formatted.

Validation should not depend only on the model. Important extraction systems should combine model review with programmatic checks.

Types of Validation

Schema Validation

Checks whether the output follows the required structure.

Questions:

• Are all required fields present?
• Are extra fields absent?
• Are arrays and objects correctly structured?
• Are null values allowed where used?

Data-Type Validation

Checks whether each value has the correct type.

Examples:

• Quantity must be an integer.
• Price must be a number.
• Email must be a string.
• Skills must be an array.

Format Validation

Checks specific formats.

Examples:

• Date follows YYYY-MM-DD.
• Email has a valid structure.
• Currency uses an ISO code.
• Phone number follows international format.
• Postal code matches the expected pattern.

Evidence Validation

Checks whether every extracted value is supported by the source.

Range Validation

Checks whether numeric values are reasonable.

Examples:

• Rating must be between 0 and 5.
• Percentage must be between 0 and 100.
• Quantity cannot be negative.

Cross-Field Validation

Checks relationships between fields.

Examples:

• Due date should not be earlier than invoice date.
• End date should not be earlier than start date.
• Line-item total should equal quantity multiplied by unit price.
• Discounted price should not exceed original price.

Completeness Validation

Checks whether all required information was extracted.

Duplicate Validation

Checks whether repeated records were incorrectly returned.

Validation Prompt

Task: Validate the extracted data against the original source text.
Check 1: Confirm that every non-null value is directly supported by the source.
Check 2: Confirm that all required fields are present.
Check 3: Confirm that field data types are correct.
Check 4: Confirm that dates use YYYY-MM-DD format.
Check 5: Confirm that no unsupported values were invented.
Check 6: Confirm that duplicate records were removed.
Check 7: List every validation error separately.
Output format: Return valid JSON only.
Source text: [Insert source text]
Extracted data: [Insert extracted output]

Expected Validation Output

{
  "is_valid": false,
  "errors": [
    {
      "field": "order_date",
      "error_type": "unsupported_value",
      "message": "The extracted date does not appear in the source."
    },
    {
      "field": "quantity",
      "error_type": "invalid_data_type",
      "message": "Quantity must be an integer."
    }
  ],
  "warnings": [],
  "validated_data": null
}

Correction after Validation

A second step can correct invalid extraction.

Task: Correct the extracted data using the validation errors and original source.
Correction rule: Change only fields identified as invalid.
Accuracy rule: Do not add information that is not supported by the source.
Missing rule: Replace unsupported values with null.
Output format: Return corrected JSON only.
Source text: [Insert source]
Extracted data: [Insert output]
Validation errors: [Insert errors]

Independent Validation

For high-value extraction tasks, validation should be performed independently.

Recommended workflow:

1. First model call extracts the data.
2. A separate validation call checks the result.
3. Software validates the schema and formats.
4. Invalid records are retried or sent for human review.

Confidence Scores

Confidence scores can help prioritise reviews.

Example:

{
  "invoice_number": {
    "value": "INV-1045",
    "confidence": 0.99
  },
  "due_date": {
    "value": "2026-08-20",
    "confidence": 0.62,
    "needs_review": true
  }
}

Confidence scores are estimates. They should not replace evidence and validation.

Validation Checklist

Before accepting extracted output, check:

• Every required field exists.
• Values use the correct data type.
• Dates and times are normalised.
• Numeric values contain no unwanted symbols.
• Units are stored correctly.
• Values are supported by evidence.
• Missing fields use the defined representation.
• No duplicated records remain.
• No unsupported assumptions were added.
• Cross-field rules are satisfied.
• Output is valid JSON, CSV, XML, or the requested format.
• High-risk uncertain values are marked for review.

Best Practices

• Validate schemas programmatically.
• Check source evidence.
• Use cross-field rules.
• Separate warnings from errors.
• Retry invalid outputs.
• Keep the original source for audit purposes.
• Use human review for high-risk cases.
• Do not treat confidence as proof.
• Record the reason for every validation failure.

Information Extraction Template

The following reusable template can be adapted for different extraction tasks.

General Information Extraction Prompt Template

Role: You are an information extraction system.
Task: Extract the requested information from the provided input.
Fields: [List every field that must be extracted.]
Field definitions: [Explain the meaning of each field.]
Data types: [Define string, number, integer, boolean, date, array, or object for each field.]
Required fields: [List fields that must always appear.]
Optional fields: [List fields that may be missing.]
Allowed values: [Define fixed values for category fields.]
Date format: Convert complete dates to YYYY-MM-DD.
Time format: Convert times to 24-hour HH:MM format.
Number format: Return numbers without currency symbols or thousands separators.
Unit rule: Store numeric values and measurement units separately.
Missing scalar rule: Return null when a scalar value is missing.
Missing list rule: Return an empty array when a list is missing.
Unclear value rule: Return null and set needs_review to true.
Duplicate rule: Remove exact duplicates and preserve the clearest original value.
Inference rule: Do not guess or invent information.
Evidence rule: Include the shortest exact source text supporting each extracted value.
Extra field rule: Do not add fields outside the schema.
Validation rule: Check the result against the schema before returning it.
Output format: Return valid JSON only.
Schema: [Insert expected output structure.]
Input: [Insert source text.]

Entity Extraction Template

Role: You are a named entity extraction system.
Task: Extract all entities from the input text.
Entity types: person, organisation, location, product, technology, date, and job_title.
Preservation rule: Keep entity text exactly as written.
Duplicate rule: Return each unique entity once.
Missing rule: Return an empty array for entity types that are not present.
Inference rule: Do not infer unnamed or implied entities.
Evidence rule: Include the sentence containing each entity.
Output format: Return valid JSON only.
Input text: [Insert text]

Keyword Extraction Template

Role: You are a keyword extraction system.
Task: Extract the most important keywords and key phrases.
Maximum count: Return no more than 10 keywords.
Phrase rule: Prefer specific multi-word phrases.
Relevance rule: Include only terms central to the source.
Duplicate rule: Remove terms with the same or nearly identical meaning.
Ordering rule: Sort from most relevant to least relevant.
Output format: Return a JSON array only.
Input text: [Insert text]

Date Extraction Template

Role: You are a date extraction and normalisation system.
Task: Extract every explicit, relative, partial, and ranged date.
Reference date: [Insert fixed reference date.]
Regional format: Interpret numeric dates as [DD/MM/YYYY or MM/DD/YYYY].
Output date format: YYYY-MM-DD.
Partial date rule: Use null for unknown date components.
Ambiguity rule: Mark ambiguous dates and provide possible values.
Evidence rule: Preserve the original date expression.
Inference rule: Do not assume missing years.
Output format: Return valid JSON only.
Input text: [Insert text]

Contact Extraction Template

Role: You are a contact information extraction system.
Task: Extract every contact found in the input.
Fields: full_name, organisation, job_title, email, phone, street_address, city, state, postal_code, country, and website.
Grouping rule: Keep each person's information in a separate object.
Association rule: Attach contact details only when their relationship to the person is clear.
Phone rule: Return both original and normalised phone numbers.
Missing rule: Return null for missing scalar fields.
Inference rule: Do not infer location or country unless explicitly allowed.
Output format: Return a JSON array only.
Input text: [Insert text]

Product Extraction Template

Role: You are a product information extraction system.
Task: Extract all product records and variants from the input.
Fields: product_name, brand, model, category, sku, price, currency, specifications, features, stock_status, and warranty.
Variant rule: Group colour, size, storage, or configuration options under the correct product.
Number rule: Return numeric values without symbols.
Unit rule: Store values and units separately.
Price rule: Separate original price, sale price, and discount.
Missing rule: Return null for missing scalar fields and an empty array for missing lists.
Inference rule: Do not invent technical specifications.
Output format: Return valid JSON only.
Input text: [Insert text]

Event Extraction Template

Role: You are an event extraction system.
Task: Extract every distinct event from the input text.
Fields: event_type, event_name, trigger, participants, organiser, date, time, location, status, cause, and result.
Separation rule: Create one object for each distinct event.
Date format: Convert complete dates to YYYY-MM-DD.
Time format: Convert times to HH:MM.
Status values: planned, scheduled, in_progress, completed, cancelled, postponed, failed, or unknown.
Missing rule: Return null for missing scalar values and an empty array for missing lists.
Evidence rule: Include the shortest sentence supporting the event.
Inference rule: Do not infer events from general statements.
Output format: Return a JSON array only.
Input text: [Insert text]

Relationship Extraction Template

Role: You are a relationship extraction system.
Task: Extract direct relationships between entities.
Relationship types: [List allowed relationship labels.]
Direction rule: Return relationships as subject, relationship, and object.
Evidence rule: Include the exact phrase supporting each relationship.
Duplicate rule: Remove repeated subject-relationship-object combinations.
Inference rule: Include only relationships directly supported by the text.
Unclear reference rule: Do not resolve pronouns when the referenced entity is uncertain.
Output format: Return a JSON array only.
Input text: [Insert text]

Table Extraction Template

Role: You are a table extraction system.
Task: Convert the provided table into structured records.
Columns: [List expected column names.]
Data types: [Define the data type of each column.]
Header rule: Do not include headers as data rows.
Row rule: Preserve the original row order.
Empty cell rule: Return null for empty cells.
Merged cell rule: Carry values into later rows only when the table clearly shows a merged group.
Multi-line rule: Combine lines belonging to the same cell.
Validation rule: Confirm that every value remains in the correct column.
Output format: Return a JSON array of row objects.
Input table: [Insert table text]

Document Field Extraction Template

Role: You are a document field extraction system.
Document type: [Invoice, resume, contract, receipt, form, or another type.]
Task: Extract the defined fields from the document.
Fields: [List required document fields.]
Nested fields: [Define line items, work experience, clauses, or repeated sections.]
Date format: YYYY-MM-DD.
Number format: Return numeric values without formatting symbols.
Missing rule: Return null for missing scalar fields and an empty array for missing collections.
Calculation rule: Do not calculate missing values unless explicitly requested.
Evidence rule: Include evidence for critical identifiers, dates, amounts, and clauses.
Review rule: Set needs_review to true for unclear or conflicting values.
Output format: Return valid JSON only.
Document text: [Insert document]

Complete Practical Example

Source Input

Hello, my name is Nikhil Deshmukh. I purchased two Lenovo ThinkPad E14 laptops from TechZone Solutions on 28 July 2026. The order number is TZ-90881. Each laptop cost ₹62,500. One laptop arrived with a damaged keyboard on 2 August 2026. Please send a replacement before 12 August. You can contact me at nikhil.deshmukh@example.com or +91 98220 44556.

Extraction Prompt

Role: You are a customer support information extraction system.
Task: Extract customer, order, product, delivery, issue, contact, and requested resolution information.
Date reference: Use 2026-08-06 as the reference date.
Date format: Convert complete and relative dates to YYYY-MM-DD.
Number rule: Return numeric amounts without currency symbols or separators.
Phone rule: Preserve the original phone number and provide a normalised international number.
Missing scalar rule: Return null.
Missing list rule: Return an empty array.
Duplicate rule: Remove duplicate values.
Inference rule: Do not guess information.
Evidence rule: Include supporting text for order number, issue type, and requested resolution.
Output format: Return valid JSON only.
Schema:
  customer:
    name: string or null
    email: string or null
    phone_original: string or null
    phone_normalised: string or null
  order:
    order_number: string or null
    purchase_date: YYYY-MM-DD or null
    seller: string or null
    currency: string or null
    total_amount: number or null
  products:
    product_name: string or null
    quantity: integer or null
    unit_price: number or null
  delivery:
    delivery_date: YYYY-MM-DD or null
  issue:
    issue_type: damaged, missing, delayed, incorrect, or other
    issue_description: string or null
    affected_quantity: integer or null
    evidence: string or null
  requested_resolution:
    action: refund, replacement, repair, information, or other
    deadline: YYYY-MM-DD or null
    evidence: string or null
Input text: Hello, my name is Nikhil Deshmukh. I purchased two Lenovo ThinkPad E14 laptops from TechZone Solutions on 28 July 2026. The order number is TZ-90881. Each laptop cost ₹62,500. One laptop arrived with a damaged keyboard on 2 August 2026. Please send a replacement before 12 August. You can contact me at nikhil.deshmukh@example.com or +91 98220 44556.

Expected Output

{
  "customer": {
    "name": "Nikhil Deshmukh",
    "email": "nikhil.deshmukh@example.com",
    "phone_original": "+91 98220 44556",
    "phone_normalised": "+919822044556"
  },
  "order": {
    "order_number": "TZ-90881",
    "purchase_date": "2026-07-28",
    "seller": "TechZone Solutions",
    "currency": "INR",
    "total_amount": 125000
  },
  "products": {
    "product_name": "Lenovo ThinkPad E14",
    "quantity": 2,
    "unit_price": 62500
  },
  "delivery": {
    "delivery_date": "2026-08-02"
  },
  "issue": {
    "issue_type": "damaged",
    "issue_description": "Damaged keyboard",
    "affected_quantity": 1,
    "evidence": "One laptop arrived with a damaged keyboard on 2 August 2026."
  },
  "requested_resolution": {
    "action": "replacement",
    "deadline": "2026-08-12",
    "evidence": "Please send a replacement before 12 August."
  }
}

Explanation

• The customer name is extracted from the introduction.
• The email and phone number are associated with the same customer.
• The purchase date is converted to YYYY-MM-DD.
• The total amount is calculated because the schema requests it and both quantity and unit price are clearly available.
• The issue is classified as damaged.
• Only one laptop is marked as affected.
• The requested action is classified as replacement.
• The year in 12 August is resolved from the document context because all related dates refer to 2026.
• Evidence is included for critical fields.

Multi-Step Information Extraction Workflow

Complex extraction tasks work better when divided into stages.

Step 1: Identify Document Type

Determine whether the input is an invoice, resume, contract, product listing, support request, or another document type.

Step 2: Select the Correct Schema

Use a schema designed for that document type.

Step 3: Extract Raw Values

Capture values exactly as written in the source.

Step 4: Normalise Values

Convert dates, phone numbers, currencies, measurements, and labels into standard formats.

Step 5: Remove Duplicates

Remove exact duplicates and flag possible near duplicates.

Step 6: Attach Evidence

Add source text, sentence, page, or section details.

Step 7: Validate the Output

Check schema, data types, formats, evidence, and cross-field rules.

Step 8: Correct Errors

Retry only the fields that failed validation.

Step 9: Request Human Review

Send unclear, conflicting, or high-risk records for manual verification.

Step 10: Store the Structured Data

Save validated records in a database, spreadsheet, search index, or application.

Common Information Extraction Mistakes

Using an Undefined Output Structure

Weak prompt:

Extract the important information.

This prompt does not explain what important information means.

Better prompt:

Extract customer_name, order_number, product_name, purchase_date, issue_type, and requested_action.

Allowing the Model to Guess

Weak instruction:

Fill all fields.

Better instruction:

Return null when the source does not provide a value.

Mixing Extraction and Summarisation

Extraction should return exact fields. Summarisation produces a shortened explanation.

Weak task:

Extract and explain everything about the customer.

Better task:

Extract the defined customer fields and return JSON only.

Ignoring Data Types

Weak output:

"quantity": "two"

Better output:

"quantity": 2

Missing Normalisation Rules

Without a date format rule, the model may return different formats.

Missing Duplicate Rules

Repeated names, products, or records may appear multiple times.

Missing Evidence

Unsupported extracted values become harder to detect.

Overusing Inference

The model may use general knowledge instead of source content.

Example:

Input:

The office is located in Pune.

Unsupported extraction:

"country": "India"

Although Pune is in India, the country is not directly stated. Whether this inference is allowed must be defined by the prompt.

Combining Multiple Records

A model may combine two customers or products into one object unless grouping rules are clear.

Using Free-Text Output

Free-text results are difficult to validate and store. Structured formats are better for automated systems.

Best Practices for Information Extraction Prompting

1. Define the extraction goal clearly.
2. List every required field.
3. Explain unclear field meanings.
4. Assign a data type to every field.
5. Use a stable schema.
6. Define required and optional fields.
7. Use null for missing scalar values.
8. Use empty arrays for missing collections.
9. Define allowed category values.
10. Separate values from units.
11. Standardise dates and times.
12. Preserve original identifiers.
13. Define duplicate rules.
14. Avoid unsupported inference.
15. Request evidence for important fields.
16. Validate the result against the source.
17. Use programmatic schema validation.
18. Mark uncertain values for review.
19. Separate multiple records correctly.
20. Retry only invalid fields when possible.
21. Keep prompts specific to the document type.
22. Avoid requesting unnecessary fields.
23. Protect sensitive personal data.
24. Store both raw and normalised values when useful.
25. Test prompts with missing, duplicated, ambiguous, and conflicting data.

Information Extraction Quality Checklist

Use this checklist before using an extraction prompt in production.

Prompt Definition

• Is the extraction task clearly defined?
• Are all requested fields listed?
• Is each field explained?
• Are output data types defined?
• Are allowed values defined?

Missing Information

• Is null handling defined?
• Are empty arrays used for missing lists?
• Are unclear values marked for review?
• Is guessing prohibited?

Formatting

• Is the date format defined?
• Is the time format defined?
• Is the currency format defined?
• Are values and units separated?
• Is the output format machine-readable?

Duplicate Handling

• Is the duplicate key defined?
• Are exact duplicates removed?
• Are near duplicates handled safely?
• Are conflicting duplicate values flagged?

Evidence

• Is evidence required for critical fields?
• Is evidence copied from the source?
• Are page or section references included when available?
• Are unsupported fields returned as null?

Validation

• Is schema validation performed?
• Are data types checked?
• Are cross-field rules checked?
• Are ranges validated?
• Are invalid records retried?
• Is human review available for uncertain cases?

Final Summary

Information extraction prompting converts unstructured content into structured and usable data. It can identify entities, keywords, dates, contact details, products, events, relationships, tables, and document-specific fields.

Reliable extraction depends on more than asking the model to find information. The prompt must define:

• What information to extract
• How each field should be represented
• Which data types to use
• How to normalise values
• What to do when information is missing
• How to identify duplicates
• How to provide source evidence
• How to validate the final output

The most dependable extraction workflow uses a clear schema, strict missing-value rules, direct source evidence, structured output, programmatic validation, and human review for uncertain or high-risk data.

A good information extraction prompt does not encourage the model to be creative. It instructs the model to remain precise, evidence-based, consistent, and limited to the information available in the source.

Frequently Asked Questions