The General Prompting Block lets a custom flow send instructions and document images directly to an ORCA (Optical Reasoning and Cognition Agent) Vision Language Model (VLM). It is useful when the task is easier to describe with a prompt than with fields and tables defined in a layout.
Accessing this feature
Your access to the feature described in this article depends on your license package and pricing plan.
To learn which features are available to your organization and how to add more, contact your Hyperscience representative.
General Prompting is a building block for custom solutions, not a complete document-processing experience by itself. The surrounding flow determines which images and instructions are sent to ORCA and what happens to the model's response. For example, the flow can transform the response, add it to submission output, display it for human review, or send it to another system.
The Table Extraction flow is one reference implementation built with the General Prompting Block. It adds table-specific instructions, structured results, and optional Table Review as a Custom Supervision task to the underlying prompt-and-response capability.
General Prompting in Hyperscience
In Hyperscience, general prompting takes place inside a flow. A custom flow prepares one or more message threads for ORCA. These messages can include:
System instructions: Rules and context that describe how ORCA should complete the task.
User instructions: The task to complete, such as summarizing a page, classifying a document, or extracting a table.
Document images: The page images that ORCA should interpret.
Previous model responses: Optional assistant messages that provide conversational context for a later prompt.
The General Prompting Block sends these messages to an installed ORCA base model on a GPU-enabled application machine. ORCA returns a response to the flow, where later blocks can process it.
This prompt-driven approach differs from standard ORCA VLM field extraction. A standard ORCA VLM extraction flow uses fields, motes, layouts, model definitions, and releases to define the expected output. General Prompting uses the messages prepared by the custom flow to define the task at runtime.
Approach | How the task is defined | What the approach provides |
|---|---|---|
Standard ORCA field extraction | Fields and Notes in a Semi-structured Layout | Layout-based field extraction with the standard training, Automation, Flexible Extraction and Quality Assurance (QA) capabilities. |
General Prompting Block | Messages containing text instructions and document images | Direct access to ORCA's prompt-and-response behavior. The custom flow must decide how to structure, review, store, and use the response. |
Table Extraction flow | Table-extraction instructions sent through the General Prompting Block | A reference flow that structures ORCA's response as tables and can display it in a Custom Supervision task. |
Example uses
You can use the General Prompting Block as the foundation for solutions such as:
Table extraction: Identify and extract tables without defining them in a layout or training a Table Identification model.
Document Chat: Use ORCA in place of a third-party LLM or VLM. This can support environments that cannot connect to the internet or use cases where third-party models cannot be used for security reasons.
Tasks across pages or documents: Apply multiple prompts to complex tasks that span several pages or documents without redeploying layouts.
Tasks beyond extraction: Summarize or classify documents, normalize or combine data, and add another validation step before human review.
Table extraction with ORCA
Tables appear in many document-processing use cases, from invoice line items to bank statements and insurance claims. Extracting them can be challenging when their structure changes between documents, when they do not have visible grid lines, or when they continue across multiple pages.
Table Identification is well suited to established use cases with known document structures, but it requires a Semi-structured layout, annotated examples, and model training. Using the General Prompting Block by itself requires less setup, but its raw response does not provide a table-specific review experience.
The Table Extraction flow provides a middle ground. It uses the General Prompting Block to extract tables without defining them in a layout or training a Table Identification model. By default, the flow asks ORCA to return every table it detects. It then converts the response into a table structure that can be reviewed or sent to downstream systems.
Reference flow for custom solutions
The Table Extraction flow is a reference implementation for custom flow development. It is not part of the standard Document Processing flow. Your solution may require additional configuration or integration work to process the flow's output. Contact your Hyperscience representative to evaluate the flow for your specific use case.
When to use the Table Extraction flow
Consider the amount of setup your use case can support and the consistency of its documents when choosing an extraction approach.
Approach | Best suited for |
|---|---|
Table Extraction with ORCA | Evaluating a new use case, processing variable document formats, extracting tables that continue across pages, or implementing a solution that does not require a layout-based model. |
Table Identification | Established use cases with similar document structures that can support layout configuration, annotated examples, model training, and confidence-based automation. |
Table extraction examples
The flow can support documents with table structures such as:
Invoices — Extract every table in an invoice, or limit the result to an items table and the columns your downstream process needs.
Bank and investment statements — Extract transaction tables that continue across multiple pages.
Insurance documents — Extract coverages, endorsements, and other tables that may lack visible grid lines or are split across pages.
Variable document formats — Process documents whose tables cannot be reliably described by a single pattern and layout.
How table extraction works
When a submission enters the flow, Hyperscience corrects the page images and sends them, along with table-extraction instructions, to ORCA through the General Prompting Block. ORCA identifies the tables and returns their headers, rows, and cell values. The rest of the flow converts that response into the structure used by Custom Supervision and downstream systems.
The flow does not require per-document layout configuration. If you do not provide additional instructions, it asks ORCA to extract every table it finds.
Depending on how the flow is configured, the extracted tables follow one of these paths:
Machine-only processing — The flow completes the submission with ORCA's results and makes them available to downstream systems.
Processing with review — The flow creates a Custom Supervision task that displays ORCA's results.
Control what the flow extracts
Use the flow's Notes input when you need only part of the document's tabular data. Your instructions can identify a particular table, specify the columns to return, or clarify how ORCA should interpret the table.
For example, you can instruct the flow to extract only an items table and return its order title, item description, unit, and price columns. ORCA applies these instructions without requiring you to create or redeploy a layout.
Test your instructions with representative documents, including documents with missing columns, unexpected table structures, and tables that continue across pages. To learn how to inspect a Flow Run, see Testing and Debugging Flows.
Review extracted tables
For submissions that require review, the Custom Supervision task presents ORCA's predictions as rows and columns. This gives keyers a visual result to verify instead of requiring them to interpret the model's raw response.
In the task, a keyer can:
Edit cell values.
Insert rows.
Delete rows.
After the keyer submits the task, the reviewed table data continues through the flow and becomes available to downstream systems.
Multi-page and complex tables
ORCA can continue extracting a table when its rows extend onto later pages within the images sent to the model. It can also interpret tables without visible grid lines. The number of pages that can be processed together depends on page density, response length, token settings, and available GPU memory.
Nested-table behavior depends on the model's response and the document. In observed examples, ORCA returned the child tables as separate regular tables without preserving their relationship to the parent table. If your use case requires that relationship, add downstream processing that links the results.
Table extraction limitations
Consider the following limitations when evaluating the current reference flow:
Table Review editing: Keyers can edit cells and rows, but they cannot edit the table's column structure.
Source highlighting: The current reference flow does not map location information into Table Review. Selecting a value does not highlight its location on the document image. The General Prompting Block can optionally return location hints, but using them requires additional flow and review-interface integration.
Confidence-based routing: The flow does not apply confidence thresholds to individual cells. It either sends the complete result for review or processes it without review.
Table names: The flow labels tables sequentially instead of deriving names from the document.
Nested-table relationships: The flow does not reliably preserve relationships between parent and child tables.
Document length: Longer or denser documents may require more GPU memory or a custom approach that processes pages in batches and combines the results.
General Prompting considerations
The behavior of a General Prompting solution depends on both the prompt and the surrounding flow.
Output handling: The block returns the model's response to the flow. It does not automatically add the response to the submission output or create a Supervision task. If the flow does not transform or store the response, you can inspect it in the block's Output tab for that flow run.
Response structure: The prompt and any downstream parsing determine whether the response is free-form text or follows a structure expected by later blocks.
Image detail: The maximum image-token setting controls how much model capacity is allocated to each image. Higher values may help with dense or difficult-to-read images, but they increase GPU-memory usage.
Response length: The maximum new-token setting limits how much content ORCA can return. Longer or more complex outputs may require a higher value and more GPU memory.
Location hints: The block can optionally return location-related output for downstream tasks that require bounding boxes. Enabling location hints increases GPU-memory usage and inference time.
Prerequisites
To use the General Prompting Block, you need:
Access to ORCA and the General Prompting Block.
An installed ORCA base-model asset.
A GPU-enabled application machine.
A custom flow that supplies the message threads and handles the model's response.
The messages can be defined directly in the flow or produced dynamically by a Code Block or another processing block. An Install LLM/VLM Block can supply the model information when the solution uses the LLM Install Flow, but the model can also be referenced through the flow's configured ORCA inputs.
To use the Table Extraction reference flow, you also need a solution that sends submissions to that flow and consumes its table results.
You can learn more about the General Prompting Block's messages, model inputs, token settings, and location hints in the Flows SDK documentation.