Document workflows

Turn documents into structured work.

Reading a PDF is the start. The useful outcome is a file received, fields extracted, values checked, a person reviewing what is uncertain, and a recorded decision about what happens next. PrimeLabs builds that path. Optical character recognition alone is not the product.

The value is the path after the file arrives

A document workflow takes an incoming file and produces a structured record someone can act on. Information is extracted, validated against rules and against records the business already holds, reviewed where confidence or a rule says so, routed to the right person, and only then used to update something else. The original file stays attached, so the fields can be checked against the page they came from.

That is a different problem from workflow automation, which is about state, waits and coordination across a whole process. A certificate review can be one stage of an onboarding or a site upgrade. It can also be the entire application, if the job really is “this kind of document, checked and filed, every week”.

Invoices, forms, applications, contracts, certificates, compliance packs, purchase orders, statements, reports, onboarding files, identity or supporting documents, and service records are all plausible inputs. They are examples of the shape, not a list of completed projects.

Intake is a chosen channel, not a promise of every channel

Files typically arrive through a portal upload, an internal upload, an API, or another system that already holds them. Email ingestion is possible when a specific application is built to accept it, with a known mailbox, a known type of attachment, and a rule for everything else. It is not a default, and this website does not claim it is switched on.

Whatever the door, the file becomes an object with an owner, a type and a link to a business record. A certificate that cannot be tied to a site upgrade is an exception, not a successful intake.

The file is stored as evidence, not as a loose upload

Access is decided in the application: who may open this file, not who can guess the address. Retention is a business decision — how long the certificate must be kept, and what happens when that period ends — recorded with the file rather than left as a folder policy nobody can see.

The file stays associated with the record it supports. In the example, that record is site upgrade SU-4821. Replacing the fields does not delete the PDF. The audit history can show who confirmed the site line and who approved the review.

Extraction is a proposal made from more than one method

A known form can be parsed deterministically: this box, this label, this date format. A scan needs document understanding or OCR. A model can propose fields when the layout varies. The field list itself should be defined by the business — contractor, licence, issue date, site — so the extractor is filling a schema, not inventing columns.

The methods can be combined on one document. A licence number that matches a pattern does not need a model. A site line in an unexpected format might. The stored result keeps the proposed value and where it was read, which is what the example shows when you select a field.

Confidence is a reason to look, not a guarantee

Extracted data is not always correct. A high-confidence field can proceed when a rule also accepts it. A low-confidence field should stop for review even if it looks plausible. In the certificate, the contractor at 99% and the site at 81% are treated differently on purpose. The percentage is shown as text, not as colour alone.

Rules catch combinations a confidence score will not. A total that does not add up, a date outside the allowed range, an identifier that fails a check, a duplicate of a file already processed, or a site line that does not match the project record. The example flags the last of those: “18 Henderson Rd” against “18 Henderson Road, Fremantle WA”.

The source stays available. Review is a comparison between the page and the field, not a form that has forgotten the PDF.

Review should make the decision cheap to check

A reviewer needs the source document, the extracted value, the confidence, the validation message, an editable field, and a clear approval state. Hiding any of those turns the review into a guess. Editing the site line is not the same as approving the document. The example keeps those as two actions, and says when neither of them changed a project record.

Who may review, and who may approve, are different permissions when the risk deserves it. A junior check of a missing page is not the same authority as accepting a compliance certificate onto a live job.

After approval, the next action is chosen

An approved document may update a record, create a task, start a workflow, send a notification, call another system, or appear in a report. Those are options for the design, not a default that every field is written everywhere.

A high-impact write stays behind the approval. A low-risk step, such as filing the original against the job, can be automatic once the rules have passed. The application should say which is which. An internal business application is often where staff see that queue. A customer portal is where the other party uploads the file and later sees that it was accepted.

The model proposes fields. Rules decide whether they count.

AI and document models help with classification, extraction, a short summary, and anomaly detection: this page does not look like the certificates we usually see. They do not replace checks the business can state exactly. Required fields, known identifiers, totals, allowed statuses, and the relationship to an existing record are ordinary validation.

That split matters. A confident extraction of the wrong site is still the wrong site if the project record disagrees. The review screen is where a person sees both. The wider boundary — what a model may read, and what it may never write — is the subject of AI application development.

Files are where the sensitive data usually is

Authorisation is per file and per action, inside the account or tenant that owns the record. A reviewer in one organisation does not browse another’s certificates. Sensitive fields can be masked for people who only need to see that a document is present.

Storage location and retention are decisions, not leftovers: where the object lives, how long it is kept, and who can export it. If a model provider processes the file, that handling is part of the design — what is sent, whether it is retained there, and which documents are too sensitive to send. The audit trail records upload, extraction, edits, approval and any downstream write. The web application around the pipeline is what enforces those limits. This marketing site does not store those files.

Start from one document type that already gets retyped

A useful first note names the file, the fields that matter, the rule that would reject a bad one, and what is allowed to happen after a person accepts it. There is no account on this website.

Discuss a document workflow

Straight answers