Run Detail is the working area for one application. It combines collection, automated results, officer review, corrections, audit history, and the final decision.

Route: /flows/runs/<run-id>/

Example:

https://default-company.localhost/flows/runs/4fd97bd4-1b74-4cf9-b5fb-f44b53b2d914/

The run UUID identifies one application inside the current company tenant.

Header¶

The page title uses the run reference. When there is no reference, it displays (no reference). Beside the title, a badge shows the run status or final officer decision.

The subtitle identifies:

• the source flow;
• the submitter type, when present;
• when the run was created; and
• who created it.

Header actions:

Upload documents¶

The upload dialog accepts one or more ZIP packs or individual documents.

For one individual file, Document type can preset an accepted type. Leave it on Classify automatically when the engine should identify the type. A preset type cannot be used when more than one file is selected.

Select Upload & process to stage the files and queue processing. Uploading additional documents resets any previous officer decision because the evidence has changed.

What happens to an uploaded file¶

During processing, a file can move through Pending, Classifying, Classified, Extracting, Extracted, and Validated. It can instead become:

• Ignored when its document type is configured as irrelevant engine output;
• Unmatched when it cannot be connected to an accepted flow type; or
• Failed when classification or extraction stops with an error.

Application Progress¶

Application Progress is a fixed lifecycle. It is deliberately broader than the technical pipeline and is not a list of the Steps configured in the flow.

Inside Automated review, the pipeline performs:

1. document classification;
2. extraction of fields that feed profile variables;
3. profile reconciliation;
4. manifest resolution;
5. extraction and validation of the remaining documents;
6. cross-document checks; and
7. recommendation aggregation.

These stages produce several distinct kinds of result. The technical overview in How validation works explains how field errors, document rules, manifest states, and cross-document checks interact.

Completed phases have ticks, the current phase is highlighted, and future phases are muted. A failed run shows Automated review in red with a technical failure message.

Live status strip¶

While processing, the page reports how many documents are processed and how many remain in flight. It refreshes automatically every eight seconds.

Live updates pause when a section is expanded or a modal is open, protecting unsaved review work. Select Refresh now for an immediate update. When processing ends, the page refreshes its full run content once.

After processing, the strip becomes a set of shortcuts when relevant:

• blocking cross-check mismatches;
• flagged mismatches;
• missing required documents;
• documents with validation issues;
• checks needing human review; and
• checks already resolved manually.

Selecting a shortcut opens the relevant location in Next actions or Checks.

Run sections¶

Run Detail has six sections. Next actions is the default URL. The others use a section query parameter:

An unknown section value returns a not-found page.

Next actions¶

Next actions brings the run's open findings into one officer-facing summary.

System recommendation¶

Once processing completes, the system displays a recommended outcome and the number of supporting findings. The recommendation is deterministic; the most serious configured action wins in this order:

1. Recommend rejection
2. Send back
3. Flag to officer
4. Proceed

The recommendation can be influenced by:

• unresolved profile conflicts;
• missing required Steps and each Step's missing action;
• unmatched or failed files;
• schema and document-validation failures;
• document checks requiring human review; and
• cross-document mismatches and their mismatch actions.

This recommendation does not make the final decision.

Officer decision¶

The decision form appears only when the run is Ready for decision. The officer selects Proceed, Send back, or Reject and must enter a reason. Saving records the officer and time in the audit trail and changes the run to Decided.

On a decided run, this card becomes read-only and displays the decision, reason, officer, and date.

Required fixes¶

Open findings are grouped by purpose:

Buttons beside findings open the exact requirement, file, profile, or check that needs attention.

When processing is complete and there are no findings, a success message says that all required documents are present and every cross-check passed.

Vetting report¶

Select Download PDF report to create a point-in-time assessment report for the run. The report includes:

• application context and the resolved profile;
• required-document coverage and the files reviewed;
• per-document and cross-document check results with available evidence and SOP references;
• open findings and the system recommendation; and
• the officer decision and audit trail.

The PDF is marked confidential and can also be downloaded while processing is in progress, in which case it reflects the results available at that time.

Copy Email¶

When applicant-facing fixes exist, the system builds a plain-text email draft. It can contain:

• missing documents;
• documents that need correction or resubmission; and
• document values that do not match.

Internal-only human review items and manually resolved checks are not included. Select Copy to clipboard and paste the draft into the approved email tool. The draft is not sent automatically.

Application¶

The Application tab shows the run's effective Profile Variables.

Each value is labelled as:

• defined: supplied by an operator;
• derived: calculated or extracted by the system; or
• officer override: an explicit manual value taking precedence.

Defined, derived, and override values are stored separately so that the source of a value remains clear. An unanswered variable displays as such.

Select Edit answers to change values. Saving:

1. stores defined values as operator answers;
2. stores manual changes to derived variables as explicit overrides;
3. clears any previous officer decision;
4. records the change in the audit log; and
5. queues the run for re-evaluation.

Use this carefully: changing a profile value can change which Steps are required in the manifest.

Requirements¶

Requirements is the resolved manifest for this run. Unlike Manifest Preview in the flow builder, it uses the run's actual profile and uploaded evidence.

Filter badges show totals and can limit the table to one state. Select an active filter again, select All, or use Clear to remove it.

Every row shows the Step order, document requirement, optional bundle, reviewer notes, status, and an explanatory note. The note may identify the file that satisfied the Step or the profile answer still needed.

Documents¶

The Documents tab lists every stored file. Its heading includes the file count.

Each collapsed row shows:

• original filename;
• classified document-type slug;
• matched document requirement;
• processing status;
• number of validation issues; and
• whether an officer has reviewed it.

Open a row to see status details, validation errors, extracted values, review metadata, and available actions.

Classification correction¶

For an Unmatched or Failed file, choose an accepted document type and select Re-process as type. The document returns to Pending and the run is queued again.

Remove a document¶

Remove deletes both the stored file and its run record after confirmation, then reprocesses the run. This can make a previously satisfied requirement missing.

Review a document¶

Select Review to open the full-screen document-review workspace.

The left pane previews an image or embeds another supported file such as a PDF. The right pane displays editable extracted data:

• text fields use text inputs;
• Boolean fields use Yes, No, or not set; and
• lists and objects use JSON text areas.

When opened from a check, the workspace also displays the relevant rule, observed and expected evidence, comparison values, SOP reference, and the other documents used by the check. Cross-document comparisons can display two documents side by side.

Footer actions:

Saving reruns local field validation and refreshes the manifest. Changed fields are audited and queue full processing so dependent profile rules and checks can be recalculated.

Field-validation errors describe values that are missing or incorrectly shaped. They are different from named SOP checks and cannot be dismissed with a document-rule override. See Extraction and field validation.

Checks¶

The Checks tab contains two different kinds of result.

Both are business-rule results rather than field/schema errors. The validation overview explains why this separation preserves factual extracted values and supports auditable officer resolutions.

Document checks¶

Document checks test one document against its own requirement or an SOP rule. Each result shows:

• rule name and key;
• Pass, Fail, Needs human review, or Insufficient data;
• resolution, when an officer has resolved it;
• message and affected document;
• SOP reference;
• the action used if failure is confirmed;
• observed and expected values; and
• reviewer instructions.

Select Review evidence to open the source file. An unresolved result can be resolved as:

• Confirm as passing;
• Confirm failure; or
• Not applicable.

A reason is required and the action is audited.

Cross-document checks¶

Cross-document checks compare values taken from different sources. A source can be document fields or resolved Profile Variables, such as authoritative NIDMS values derived from the Residence Application Form. Summary badges count passed, mismatched, needs-review, insufficient-data, and manually resolved checks.

Open a result to see its full message, evidence table, participating fields or Profile Variables, extracted values, reference markers, fuzzy scores or AI adjudication when available, and a shortcut into the evidence review workspace for document sources.

Result states:

For Mismatch or Needs review, an officer can:

• Mark as OK when the evidence really matches;
• Confirm mismatch when the difference is real; or
• Ignore when the check is not relevant to this run.

Every manual action requires a short reason. Accepted and ignored checks stop counting as open findings. Revert override restores the original computed status. Reprocessing also clears a manual override if the underlying computed status changes.

Activity¶

Activity is the audit trail for officer and system actions. Open the panel to see the actor, readable action, target, time, reason, and changed extracted fields when applicable.

It records actions including:

• profile overrides;
• document reviews and extracted-data corrections;
• document-check resolutions;
• cross-check acceptance, confirmation, ignoring, and reverts;
• automatic clearing of stale overrides; and
• the final officer decision.

When no auditable action has occurred, the panel says No activity recorded yet.

Safe review sequence¶

For a completed automated review, a practical sequence is:

1. Read Next actions and the system recommendation.
2. Open Application and resolve profile conflicts.
3. Use Requirements to understand missing or deferred documents.
4. Use Documents to correct classifications and extracted values.
5. Use Checks to resolve evidence-based findings with reasons.
6. Re-process after evidence or profile changes and wait for completion.
7. Confirm that the recommendation and open findings are current.
8. Record the officer decision and reason.
9. Use Activity when the audit history needs to be reviewed.