Hyperscience extracts text from documents using Optical Intelligent Character Recognition (OICR). On top of this, the system applies a Transcription model to decide how extracted values are handled — whether they are accepted automatically or sent for human review (e.g., Transcription Task). To learn more about OICR, see Text Segmentation.
A Transcription model does not perform text extraction
It acts as a decision layer that evaluates how reliable extracted values are, based on historical QA data and system configurations.
When text is extracted, not every value is equally reliable. Some predictions are clearly correct, while others are uncertain or incorrect.
Without a transcription model, the system relies on fixed confidence thresholds to decide:
accept the value automatically
or send it for manual review.
Transcription models change how predictions are evaluated
If no transcription model is configured, the system uses the threshold set in the flow.
If a transcription model is configured, the threshold is no longer used, and decisions are based on model behavior and target accuracy.
In this article, you’ll learn:
What a transcription model is and what it does.
How the system decides whether to accept a value or send it for review.
The difference between thresholds and transcription models.
How Target Accuracy controls the balance between Automation and manual review.
Understanding Transcription models
A transcription model is a machine-learning model that helps the system adapt how it decides whether to accept extracted values automatically or send them for review.
When text is extracted, the system assigns a confidence score to each value. Instead of relying only on static thresholds, the transcription model uses QA feedback to learn how reliable those predictions are over time.
This learned behavior is then used to decide whether a value should be:
accepted automatically, or
sent for human review.
Transcription models and flows
Each Document Processing flow can be associated with a transcription model.
A single transcription model can be reused across multiple flows, depending on how it is configured.
Within a flow, the assigned transcription model controls how extracted values are evaluated and whether they are accepted automatically or sent for review.
By default, the system includes a transcription model named IDP.
This model is trained on transcription QA data collected across all Workflows, in which extracted values are reviewed and corrected during QA tasks. Learn more in Managing Transcription Models.
.png?sv=2026-02-06&spr=https&st=2026-06-22T22%3A46%3A44Z&se=2026-06-22T23%3A08%3A44Z&sr=c&sp=r&sig=3wCAAP1LcH8oukRe18ZdbDe9Hddc1jVA75yiZwKZUPM%3D)
Process
For each extracted value, the system determines whether it should be accepted automatically or sent for human review.
1. The system extracts text using OICR.
2. A confidence score (between 0 and 1) is assigned to the extracted value.
Confidence score
A confidence score is a value between 0 and 1 that represents how confident the system is in a prediction.
Higher values indicate higher confidence.
Lower values indicate more uncertainty.
3. The system evaluates the prediction based on the configuration of your flow:
If no transcription model is configured:
The system uses the confidence threshold set in the flow.
Values with a confidence score above the threshold are accepted automatically.
Values below the threshold are sent for review.
If a transcription model is configured:
The system no longer uses the manually configured threshold (even if it is still visible in the UI).
Instead, it compares:
the model’s learned performance (based on QA data), and
the target accuracy configured in the flow.
4. Based on this evaluation, the system decides whether to:
accept the value automatically, or
send it for review.
The confidence score is used internally to compare predictions.
It is not directly equivalent to a percentage and should not be interpreted as an exact probability.
Thresholds
If no transcription model is used, the system relies on static thresholds.
A threshold defines the minimum confidence required for a value to be accepted automatically.
Example 1:
Confidence score: 0.82
Threshold: 0.80 → value is accepted.
Example 2:
Confidence score: 0.82
Threshold: 0.90 → value is sent for review.
This approach is fixed and does not adapt over time.
When a transcription model is deployed:
Static thresholds are no longer used to make decisions (even if they are still visible in the UI).
The system instead relies on learned behavior from QA data.
In practice, the model replaces static thresholds with a dynamic decision mechanism that adapts based on past performance.
Target accuracy
Target accuracy defines how many errors are acceptable for your use case.
For example:
95% target accuracy allows up to 5 incorrect values per 100 fields.
99% target accuracy allows up to 1 incorrect value per 100 fields.
This setting controls how strict the system is when deciding whether to accept values automatically or send them for review.
Lower target accuracy → higher automation, more errors.
Higher target accuracy → more review, fewer errors.
QA data and transcription models
The transcription model learns from Quality Assurance (QA) data over time. QA records show the system:
when predictions were correct
when predictions were incorrect.
This information is used to adjust how strictly the system evaluates extracted values and decides whether to accept them automatically or send them for review.
QA data does not immediately change model behavior. Instead, it is used during training cycles that update how the system evaluates predictions. For this process to take effect:
Sufficient QA data must be available.
Training must be enabled in the flow configuration or
triggered from Models > Transcription.
The system trains on a subset of recent QA data
QA data should be representative of real-world documents:
If QA data is limited or not representative, model behavior may not match expectations.
If there are no incorrect examples, the model has no signal to learn from. Incorrect examples are necessary for the system to learn effectively.
Having large volumes of QA data does not guarantee better results.
Data quality and distribution are more important than raw volume.
QA inputs should reflect the correct value for the use case. Depending on the field, this may include Normalization or formatting applied by the system.
In some cases, adding QA data may not lead to noticeable changes:
No incorrect examples:
Incorrect examples are particularly valuable because they show the system where predictions should not be trusted.
However, even when QA records are correct, the system still learns from them. It uses these examples to determine how confident it should be in automatically accepting similar values.
As a result, a lack of incorrect examples does not prevent learning, but it may limit how effectively the system adjusts to prediction errors.
Limited or non-representative data:
If QA data does not reflect actual usage, model behavior may not align with expectations.
Training has not been applied:
QA data alone does not change behavior unless the system processes it.
QA data requirements
To enable model training, a minimum number of QA records is required:
For Identification models:
Fields and table cells: at least 5,000 QA records.
Checkboxes: at least 2,000 QA records.
For Structured models:
Checkboxes and signatures: at least 2,000 QA records.
These values represent the minimum data needed for the system to begin learning. More data does not always result in better behavior.
Maximum number of QA records used for training
The system uses up to 50,000 QA records when training a transcription model.
If more QA data is available, only the most recent subset (up to the limit) is used.
Configuring a transcription model
A transcription model is configured at the flow level. This determines how extracted values are evaluated and handled within that flow.
Assign a transcription model to a flow
To use a transcription model, you need to assign it to your Document Processing flow.
Export your flow by following the steps in the interactive walkthrough below:
Open the Document Processing Flow on your machine.

Find the transcription_model property in the .JSON file.

Set the name of your model and save the changes on your machine.

Import the .JSON into the system and find your transcription model in Models > Transcription Models. See the interactive walkthrough below for guidance:
Field-Level Accuracy Targets (FLAT)
In addition to flow-level target accuracy, you can define field-level accuracy targets for structured and semi-structured documents.
These allow you to require higher or lower accuracy for specific fields (for example, stricter handling for account numbers and more relaxed handling for less critical fields).
Field-level targets override the flow-level target accuracy for the selected fields.
These targets influence how the system balances automation and review for each field. They are applied as part of the same decision logic, based on the system’s learned behavior from QA data and the configured accuracy targets.
Feld-level transcription accuracy targets are only applied when a transcription model is present.
If no model is assigned, the system relies on static transcription threshold-based behavior instead.
To learn more, see Accuracy and Document Processing Flow in V43.
Training a transcription model
Training in the context of transcription models is the process through which the system uses QA data to improve how it evaluates extracted values. As described above, the system learns from QA records over time.
During training, it:
analyzes which predictions were correct
identifies where mistakes occurred
adjusts how confident it should be in similar cases.
This results in more informed decisions about when to trust extracted values and when to require human review.
Training does not happen automatically after every QA action. For training to start:
Sufficient QA data must be available.
Training must be enabled in the flow configuration (Transcription Automation Training). To learn more, see Flow Blocks.
.jpg?sv=2026-02-06&spr=https&st=2026-06-22T22%3A46%3A44Z&se=2026-06-22T23%3A08%3A44Z&sr=c&sp=r&sig=3wCAAP1LcH8oukRe18ZdbDe9Hddc1jVA75yiZwKZUPM%3D)
Once these conditions are met, the system periodically updates model behavior based on the available QA data.
Daily autotraining enabled
If you enable the Daily autotraining enabled setting, the models will be updated daily based on latest QA records.
Model behavior
The system compares the model’s learned performance (based on QA data), and the configured target accuracy.
Based on this, you may observe:
High automation (few or no review tasks):
when target accuracy is lower than model performance.
High review volume:
when target accuracy is very strict.
Balanced behavior:
when target accuracy aligns with model performance.
For example, if a flow is configured with Target accuracy: 95%, over time, based on QA data, the system will learn that its predictions are generally reliable for this use case. As a result:
The system accepts most values automatically.
Few values are sent for review.
This can lead to high automation, even if some incorrect values are still present.
Transcription models do not affect how text is extracted
They do not improve how the system reads the document. Instead, they influence how confident the system is in extracted values and how those values are handled.
Recalibration
Recalibration updates how the system evaluates extracted values after changes to the underlying models. This typically happens after a platform upgrade, when internal model behavior may change. Recalibration helps the system stay aligned with changes in underlying models, ensuring that past QA data remains useful whenever possible.
After upgrades, you may notice changes in the behavior
Recalibration helps align previous QA data with the upgraded system.
When the system is upgraded:
predictions may change
previously collected QA data may no longer reflect current behavior.
Recalibration ensures that the system:
re-evaluates existing QA records using the updated models
aligns its behavior with the latest model performance.
During recalibration, the system:
reprocesses available QA records
compares new predictions with the recorded QA values
updates how it evaluates prediction reliability.
This allows the model to continue learning from existing data instead of relying only on new QA inputs.
Recalibration may not be possible if:
required crop data is missing.
data retention policies have removed necessary inputs. Learn more in PII Data Deletion.
In these cases:
previously collected QA data cannot be reused.
QA collection may need to start again.
Requirements
Recalibration depends on:
Training components (Trainer).
Recalibration requires the appropriate training setup to be available. If it is not configured, recalibration cannot be performed. Contact your Hyperscience representative for more information.
Availability of crops:
The system must be able to reprocess the original document regions. If this data is missing, recalibration may not be possible.
Recalibration does not always start from scratch
Existing QA data may still be reused, depending on availability.
In some cases, additional QA work may be required.
Troubleshooting and common scenarios
This section addresses common situations observed in real-world usage and explains why they occur. If the system behaves differently than expected, it is usually due to the relationship between target accuracy, QA data, and recent system behavior.
No values are sent for review
You may observe that all values are accepted automatically, even when some incorrect extractions are present.
Why this happens:
Target accuracy is set too low.
The system is allowed to accept more errors.
Based on QA data, the system determines that most predictions fall within the allowed error tolerance.
What to do:
Increase the target accuracy.
Monitor how many values are sent for review.
Adjust until you reach the desired balance between automation and accuracy.
High automation but incorrect results
It is possible to observe 100% automation while still having incorrect values.
Why this happens:
The system is configured to prioritize automation.
Target accuracy allows a higher error rate.
The system is operating within the defined tolerance.
What to do:
Increase the target accuracy.
Review QA data to ensure it reflects correct values.
No improvement after QA
You may perform QA tasks but not see any change in system behavior.
Why this happens:
Training has not been applied.
There are no incorrect examples in the QA data.
QA data is not representative of real-world documents.
What to do:
Ensure training is enabled in the flow.
Include both correct and incorrect examples in QA.
Verify that QA reflects actual document content.
Threshold values appear incorrect or unusually low (for example, 0.03)
You may notice that threshold values in the UI appear unexpectedly low or inconsistent.
Why this happens:
Thresholds are not used when a transcription model is deployed.
The value shown reflects the last manually configured threshold.
It does not affect current system behavior.
What to do:
Do not rely on threshold values when a transcription model is active.
Focus on target accuracy and QA data instead.
Model behavior changes unexpectedly
You may observe changes in automation or review patterns over time.
Why this happens:
New QA data has influenced model behavior.
Recent data differs from earlier patterns.
System updates or recalibration have changed how predictions are evaluated.
What to do:
Review recent QA data for consistency.
Monitor performance metrics.
Adjust target accuracy if needed.
Training does not produce expected results
In some cases, training may not lead to improvements.
Why this happens:
QA data is limited or not representative.
The system uses a subset of recent QA data.
There is insufficient variation in the dataset.
What to do:
Ensure QA data covers realistic document scenarios.
Include edge cases and error scenarios.
Continue collecting QA data over time.
