Document & Image Intelligence

Document and Image Intelligence

Three capabilities read content the platform cannot otherwise interpret: text and structure out of documents, the language a piece of text is in, and what an image contains.

Where to find it

Architect Panel → Data:

• Documents — the documents this reads
• Data Extraction — a different feature, for structured files

Architect Panel → Automation:

• Tasks — Document Text Extraction, every 15 minutes

Not the same as data extraction

Worth settling first, because the names invite confusion. Data Extraction ingests structured files — CSV, JSON, XML — where a value sits at a known path. This reads unstructured content, where nothing is at a known position and the answer is a best interpretation.

If your source is a spreadsheet, use data extraction. If it is a scanned invoice, use this.

Extraction always runs in the background

Reading a document takes seconds to tens of seconds. Doing that while somebody waits for an upload to finish would make every upload feel broken, so work is queued and drained by a scheduled task.

The practical consequence: text is not available the instant a file is uploaded. Anything depending on it should react to the text arriving rather than assume it is there.

The Document Text Extraction task drains that queue every fifteen minutes and ships disabled — with it off, documents queue and nothing is ever read.

The three capabilities

• Document reading — text, and structure such as tables and form fields, out of PDFs and images.
• Language detection — which language a piece of text is in, with a confidence score.
• Image analysis — what an image contains, including text within it.

They produce likelihoods, not facts

Everything here returns a best interpretation with a confidence, and that shapes how it should be used. Treat a result as a strong suggestion: pre-fill a field, propose a tag, route something for review. Do not treat it as verified input to a decision nobody checks.

Accuracy is high on clean documents and falls off with photographs, handwriting and poor scans — which is exactly the material people upload.

Where it earns its place

Not in eliminating a human step, but in making one much faster. Somebody checking pre-filled fields against a document works several times quicker than somebody typing them, and is more accurate than either the machine or unaided typing.

Uploads are the material

Quality in is quality out. A scan at a sensible resolution, right way up, reads well; a photograph taken at an angle in poor light does not. Where you control the capture, guidance to whoever uploads is worth more than any configuration.

Worked example

A finance team uploads supplier invoices. Extraction runs in the background and pre-fills supplier, date, reference and total. A clerk checks each against the document and corrects perhaps one field in ten. Processing time per invoice falls by two thirds, and nothing is posted without somebody having looked.

Recommendations

• Enable the extraction task, or nothing is ever read.
• Do not assume text is available at upload — it arrives later.
• Use results to pre-fill, with a person confirming.
• Improve capture quality before tuning anything else.

Reading Documents

Document reading returns the text of a document and, where it can, its structure — tables and labelled fields rather than just a wall of words.

Where to find it

Architect Panel → Data:

• Documents — the documents being read
• Datastores — where extracted values are put

Architect Panel → Automation:

• Tasks — Document Text Extraction

Structure is what makes it useful

Raw text tells you an invoice mentions a number. Structure tells you which number is the total, because it was in a field labelled "Total" or in the last column of a table.

That difference is most of the value. Locating a value by its label survives a supplier changing their layout in a way that hunting for a pattern in raw text does not.

What it handles well

• Machine-generated PDFs — invoices, statements, orders.
• Clean scans of printed documents.
• Consistent forms, where the same fields appear in the same places.

What it handles badly

• Handwriting.
• Photographs taken at an angle, in poor light, or partially obscured.
• Dense layouts with overlapping tables.
• Poor-quality faxes and repeated photocopies.

Be realistic about which of these your actual traffic looks like before promising anybody a hands-off process.

Build the workflow around review

The pattern that works:

1. The document is uploaded and queued.
2. Extraction runs and pre-fills a draft record.
3. A person confirms or corrects, with the document beside the form.
4. The record is saved and the document stays attached.

Step three is the one to design carefully — the document and the fields need to be visible together, or the reviewer is worse than somebody typing from scratch.

Keep the document attached

Always. The extracted values are an interpretation; the document is the evidence. When somebody disputes a figure a year later, the answer is the original, not what was read from it.

Track corrections

Which fields reviewers change most is the most useful measurement you can take. A field corrected half the time is not saving anybody anything and might be better left blank; consistent errors on one supplier's layout is a specific, fixable problem.

Without that, you have no evidence about whether the feature is helping.

Expect variation between senders

Layouts differ, so accuracy differs. It is normal to read one supplier's invoices well and another's poorly, and worth measuring per sender rather than as one overall figure that hides both.

Start with your highest-volume sender

Prove the workflow on the documents you receive most, where consistency is highest and the saving is largest, then widen. Starting with the awkward ones proves nothing except that awkward documents are awkward.

Worked example

A team processes invoices from 40 suppliers. Six account for 70% of volume, so the workflow is built and tuned on those. Correction rates per supplier show one whose layout reads poorly; they are asked to send PDFs rather than scans, and the rate drops to match the rest.

Recommendations

• Design the review screen properly — document and fields together.
• Always keep the original attached.
• Measure correction rates per field and per sender.
• Start with your highest-volume source.

Language and Image Analysis

Two smaller capabilities sit alongside document reading: identifying the language of a piece of text, and identifying what is in an image.

Where to find it

Architect Panel → Data:

• Datastores — where results are stored
• Documents — uploaded images

Architect Panel → Communication:

• Message Log — correspondence that may need routing by language

Language detection

Given text, it returns the most likely language with a confidence score, and the alternatives it considered. Useful for routing correspondence to somebody who speaks it, deciding which language to reply in, or tagging free-text records.

Use the confidence score

Short text is genuinely ambiguous — a three-word message may plausibly be several languages, and the model is right to be unsure. Acting on a low-confidence result produces exactly the error a customer notices, such as a reply in the wrong language.

Set a threshold, and below it fall back to a default rather than guessing. A confident wrong answer is worse than an admitted uncertainty.

Send a sample, not everything

Only a limited amount of text is analysed at once and longer text is trimmed automatically. A representative sample — the opening of a message rather than an entire thread with quoted replies in another language — gives a better answer than sending everything.

Image analysis

Given an image, it detects what is in it. Three uses come up repeatedly:

• Tagging photographs so they can be found later.
• Reading text within an image — a sign, a serial plate, a label.
• Screening user-uploaded images before they are published.

Screening is assistance, not a guarantee

If you are using it to keep unsuitable content off a public page, understand what you are getting. It will catch a good deal and it will not catch everything, and it will occasionally flag something harmless.

Use it to prioritise a review queue rather than to publish automatically. "The system checked it" is not a defence you would want to rely on.

Tagging is where it is safest

Because a wrong tag is a minor annoyance. A photograph tagged with what it appears to contain makes an archive searchable in a way filenames never do, and nobody is harmed by an occasional odd tag.

Store the confidence, not just the answer

Whatever you use these for, keep the score alongside the result. It lets you tune your threshold later using real data, and it lets somebody looking at an odd result see whether the system was confident or guessing.

Discarding it means every result looks equally authoritative, which is the opposite of what these produce.

Tell people when it is in use

Where automated analysis affects how somebody is treated — routing, screening, prioritisation — that belongs in your privacy information. It is also simply fairer, and it is a question that gets asked.

Worked example

A service detects the language of inbound messages and routes anything above 80% confidence to a speaker of that language; below that it goes to the general queue. A dashboard shows the distribution of scores, and after a month the threshold is lowered to 70% because almost nothing fell between the two.

Recommendations

• Set a confidence threshold and a fallback below it.
• Store the score with the result.
• Use screening to prioritise review, never to publish.
• Disclose automated analysis where it affects people.