What is the Blueprint?
Think of blueprints as templates that teach ADocs model exactly what to look for in your document.
You have two options:
Prebuilt Blueprints - We've already created templates for common documents like insurance forms, work orders, passports, etc.
Custom Blueprints - You can create your own templates for literally any document type.
👨🏫 Learn more about ADocs
How to create a Blueprint
Accessing the Blueprint Generator
Navigate to Inbox → Any Docs
Click on Blueprints to view the blueprint management interface
✨ AI-Powered Blueprint Creation 🔮: Say goodbye to manual setup. Just press Add Blueprint, upload a document and Veryfi AI will instantly analyze it and pre-build a blueprint and JSON schema for you.
What gets auto-generated
Blueprint name
Document type
Field groups
Individual extraction fields
A confirmation pop-up will appear once the blueprint has been pre-populated, so you always know when AI has done the heavy lifting.
🤖 How it works
Click "Add Blueprint" and upload your document
Veryfi AI scans the document and infers what data matters
Your blueprint is pre-populated in seconds
Review, adjust, and save
You stay in control. Every suggested field, name, and group can be edited before saving.
Not happy with the suggestions?
Click "Delete all fields" to wipe all groups and fields and start from scratch. Works on both new and existing blueprints.
Step-by-Step Guide: How to Create a Blueprint
Step 1️⃣ : Initialize Blueprint Creation
Click Add Blueprint to open the blueprint creator
The system will display a file uploader interface
Step 2️⃣ : Upload Document
Upload your document by selecting the appropriate file type and choosing your file. Supported file formats: JPEG, PNG, PDF (including multi-page documents)
Step 3️⃣ : Configure Blueprint Settings
Blueprint Name: Use descriptive document names that express purpose and context. Prefer explicit names: “bank account verification letter” instead of “verification letter”.
Document Type: Use an accurate document type; it gives the LLM strong contextual priors to work from.
Fields Creation
You have two options for adding a new field:
Draw Selection Box: Click and drag to draw a box around the text area you want to extract and it will automatically recognise text. Set it as a field example value. {For context, bounding boxes do not give the model enough context about the fields, so a comprehensive description is required}
Use ADD FIELD option to manually provide the field name, example values, and description.
Configure Field Properties:
Text: Review and edit the automatically detected text
JSON Field Name: Enter a unique key name for this field
Must be lowercase alphanumeric characters
Spaces are automatically converted to underscores
Uppercase letters are automatically converted to lowercase
Type: Select from available field types
Description: Add a description for the field, think of it as a prompt
Click Save to add the field to your blueprint
Step 4️⃣ Field Management
Editing Fields
Visual Editing: Click on any drawn box to edit field properties
Table Editing: Click directly into table cells to modify values inline
Field List: View all fields in the fields table at the bottom of the interface
Field Requirements
JSON field names must be unique across all fields
All key names follow lowercase alphanumeric format with underscores
Working with Groups
Groups allow you to organize related fields into logical collections, which affects the JSON output structure.
Creating Groups
Click Add Group
Configure group properties:
JSON Key: Unique identifier for the group
Type: Choose between:
Object: Creates a single object containing grouped fields
List of Objects: Creates an array of objects
Group Requirements
Each group must contain at least one field
Groups without fields will display a warning icon
How to Assign Fields to Groups?
Method 1: Direct assignment
Click on a field box
Select group from the dropdown menu (appears when groups exist)
Method 2: Move the existing field
Click the menu icon for any field
Select Move to Group
Choose the target group from the modal
Group Management
Expand/Collapse: Click the folder icon to show/hide group contents
Visual Indicators: Alert icons indicate groups needing fields, folder icons show properly configured groups
Object vs List of Objects
Simple rule of thumb
Ask: “Can there be several of these in a single response?”
No → Object
Yes / maybe → List of Objects
Apply that to every top‑level key when you’re choosing between the two options in the blueprint UI.
Use Object when…
There is a single entity per response expected
Object because each prescription has one patient and one pharmacy.
"patient": {
"name": "John, Doe",
"address": null
}
"pharmacy": {
"name": "KAISER PERMANENTE",
"address": "...",
"phone_number": "..."
}
-> Use List of Objects when there can be zero, one, or many of the same kind of thing.
You expect multiple repeating items of the same structure
"medication_list": [
{ ... one medication ... },
{ ... another medication ... }
If you need to create a List of Objects or an Object:
Go to Blueprint:
Add a new group by selecting Add Group
Type: Object or List of Objects
Give it a good name
Add a NEW field to the existing Object ot List of Objects
Add a new field
Select the group where to add
If you need to change the existing Fields location
Open Blueprint
Navigate to the Field and More option
Select Move Group if you want to move a field from object A to object B
Managing Blueprints and versions
Saving Your Blueprint
Enter a descriptive name for your blueprint, something straightforward a
Click Save to create the blueprint
The blueprint will appear in the blueprints list with your specified name and type
Viewing Saved Blueprints
Scroll down to the blueprints list
Click View on any blueprint to open it
The system will automatically:
Display the original document
Draw all saved field boxes
Show group organization
Expand grouped fields for easy viewing
Can blueprints be modified after creation?
Yes, existing blueprints can be edited by selecting the "View" option, making necessary changes, and saving the updated version.
Blueprints Edits, Versioning & Management
We’ve introduced new capabilities to make changes and iterating on blueprints easier
After you edit or update a Blueprint, you now can choose to Save and Make active or Save as Version
Saving and Making Active will immediately update the blueprints, so any new API calls made to this blueprint will use the most recent active version. Make sure you adjust API consumption on your side before making a new version active in production.
If you are not yet ready to make the edits live, use the Save as Version option
You can always make this Version live or roll back the versions using options available inside the Versions tab
Compare versions
This option will give you a summary of changes and modifications
Import Version option can come in handy if
You have created a fine-tuned version of a Blueprint outside Veryfi
You created a Blueprint in a different Profile and want to move v.12 Blueprint version from your Dev profile to v.1 of your Blueprint in Prod profile
For that, use the Export option
Moving Blueprints between Profiles / Environments
Let's say you created an ideal Blueprint in one of the lower environments of your account in the Veryfi Ecosystem. To move this blueprint from your DEV to Production profile, you can now simply use the PORT option.
Porting available from different places
1. From the list of Blueprints inside Inbox as extra options
2. From Versions tab, inside a Blueprint
Select Port to Profile and choose Profile from the dropdown:
NOTE: Your user needs admin access to the Target profile for it to appear in the dropdown. If not appearing, please request your Administrator to add you to the target profile with Admin rights.
Best practices for creating Effective Blueprints
Core Principles
Design for generality and reuse: favor semantic descriptions over positional cues or visual hints. The model won't understand coordinates or layout as it will process plain text.
Keep field descriptions concise but informative, optimize for clarity and LLM reasoning speed.
Treat the description as prompt engineering: remove redundancy already implied by the document type.
Rely on verifiable data: the anti-hallucination layer rejects outputs not supported by the source document.
Blueprint Naming & Document Types
Use descriptive document names that express purpose and context.
Prefer explicit names: “bank account verification letter” instead of “verification letter”.
Select an accurate document type; it provides the LLM with stronger contextual priors.
Field Design Best Practices
Descriptions guide the model and function as prompts. Write them to be model-friendly and reusable.
Be descriptive and concise. Avoid long narratives that distract the model and increase latency.
Avoid positional language: “date at the bottom/right/green box” as won’t provide context the way you think (ocr is plain text, single lined as input to the llm).
Describe the field’s semantic role broadly so it works across variants (letters, forms, statements).
Expand abbreviations in parentheses to teach the model: e.g., “GM (General Motors)”.
Field names matter, but descriptions matter more. Keep names short.
Choosing Field Types
String: free-form text; use for labels, IDs that may include letters/numbers/symbols.
Float: use for monetary totals/amounts, rates, taxes. Avoid integer for currency.
Date: normalized date output (see “Dates & Localization”).
Format can be defined by editing the blueprint and hardcoding the field typeThe date format by default is US, but can be changed in the field type by using "
ddmm" or "mmdd" in the scenario that the model isn’t extracting it from context.
List of strings: multiple similar values where order may matter (e.g., line item notes).
Parsed address: prefer this over a single string when downstream needs structured address parts. Consider adding a parallel “raw_address” string when you must preserve exact OCR text.
Bounding Boxes
Boxes aid your authoring workflow and help visualize OCR regions but are not passed to the LLM as contextual anchors. Do not rely on coordinates or shapes in prompts.
Prompt Engineering & Model Interaction
Field descriptions act as targeted prompts, keep them minimal, explicit, and domain-focused.
Do not specify exact punctuation requirements (quotes, commas). Natural variation is okay.
Avoid visual terms (color, location). LLMs do not “see” layout; they rely on text and semantic insights.
Limit conversions in-prompt (e.g., “twice” should be “two”); prefer explicit field types and post-processing rules. The anti-hallucination layer blocks unverifiable transformations.
Prompt Limits, Debugging, and Versions
Prompt size: keep descriptions short; excessively long prompts increase latency and may alterate context depending on model limits.
Prompt debugging: direct inspection tools may be limited. Favor small, isolated edits and regression tests to confirm impact.
Accuracy & Regression Testing during Fine-tuning
Use Accuracy Reports Functionality to Proof Test Blueprint Fine-tuning
Assemble a gold set of diverse documents per blueprint (locales, layouts, qualities). Include edge cases (noise, stamps) not less than 30 documents or more to have a good sampling set.
Freeze expected outputs by setting Ground Truth (the expected extraction values in Document Details)
Compare outputs on each field, not only the ones modified in the blueprint, the model will have an entire new context input, which can modify other fields' output. Add guardrails as needed.
Prioritize high-value fields (totals, dates, account numbers) and fields historically prone to locale issues (decimals, separators).
Never modify a live blueprint without a rollout plan. Use versioning, stage changes, and validate with regression tests before promoting.
Field Description Templates (Examples)
currency_code (string): “Three-letter ISO 4217 currency code (e.g., CAD, USD) found on the document; use as context to format monetary values and decimals.”
total_amount (float): “Grand total payable on the document; prefer labeled totals over subtotals; interpret separators per document’s locale and currency_code.”
issue_date (date): “Official document issuance date; choose the primary issuance label over received/printed dates.”
signature_present (bool): “True if the document includes a handwritten or electronic signature indicator (e.g., signature line signed, ‘Digitally signed by’).”
Troubleshooting & Common Pitfalls
Symptoms often trace back to ambiguous or overly long descriptions, or to locale/currency assumptions. Iterate with small, testable changes.
Amounts off by a factor of 100 or 1000: check separators and ensure currency_code is present and described; confirm float type.
Wrong date chosen: clarify primary semantic (issue vs. due vs. received) and avoid positional hints.
Missing line items: model your group as a list of objects and ensure each required child field has clear, short descriptions.
🧑🏻🏫 How does multi-page PDF support work?
For PDF documents with multiple pages it includes navigation controls for multi-page PDFs. Users can move between pages and define different extraction fields for each page as needed. Field assignments are page-specific and remain associated with their designated pages.
Navigation
Page Footer: Use the navigation controls at the bottom right
Page Jumping: Enter a specific page number and press Enter or click away to jump directly
Page-Specific Fields: Fields are associated with specific pages where they were created
Page Management
Each page maintains its own set of field boxes
Navigate between pages to see relevant field overlays
Fields created on one page won't appear on others
🛡 What security measures are in place?
Veryfi maintains GDPR, HIPAA, and SOC 2 Type 2 compliance with bank-level security protocols. Documents and extracted data remain within Veryfi's infrastructure and are not shared with external AI providers. Only In-house AI models are powering Veryfi Adocs API.