Documents

What this chapter covers

A corridor run generates paper: customs forms stamped at the border, a signed delivery note at the depot, a fuel receipt at the station, a photo of a broken part on the shoulder. This chapter describes the full life of that paper as Korido handles it — a driver captures a document on the phone, it uploads when the network allows and attaches to the mission and truck it belongs to, an owner reviews it in a document review center, and a decision to send it back reaches the driver as a directed retake request. It is the evidentiary half of a mission: where segments and traversals are the measured record of the run, documents are its human-readable proof.

The picture

Capture and review are two people working the same document from opposite ends — the driver on the road, the owner at the desk — joined by an upload that survives poor coverage and a directed request that closes the loop when paper needs redoing.

The two ends never block each other. A driver captures whether or not there is signal; an owner reviews whenever they get to it; the retake request waits in the driver's notification center until the driver acts.

Capturing on the road

Capture is built for a tired driver on a bad connection, so it is deliberately short: four large tiles, a camera in one tap, and an optional location tag. The four capture presets cover what a corridor run actually produces:

• "Carburant" — a fuel receipt, with an optional prompt for the price and litres shown on the slip.
• "Dépenses" — any other paid expense: a toll, a weighbridge fee, a repair bill.
• "Douane / livraison" — the mission paperwork: a customs document, a cargo manifest, a road-control paper, or a signed delivery note.
• "Camion / permis" — the vehicle and driver papers: registration, insurance, a driving licence, or a photo of a broken or replacement part.

The two document-rich presets open a short type picker so a capture is filed precisely; the two expense presets can carry an amount, a vendor, and — for fuel — a litre count. Under the tiles, every capture is sorted into one of seven categories (mission, delivery, expense, vehicle, driver, maintenance, other) and a specific document type, so the owner's filters later have something exact to bite on.

Each captured photo carries an optional location tag — where the phone was when the picture was taken — purely as context. It is never a fleet position: truck position comes only from the hardware tracker, and a document's location is a convenience stamp on an image, nothing more.

Surviving the corridor

The corridor has long stretches with no usable data, so capture works fully offline. Every photo is copied into the app's own storage the moment it is taken and entered into a local upload queue.

A queued document is visible in the driver's own history immediately, with a working preview, before it has reached the backend at all. Uploads retry on their own when connectivity returns, backing off between attempts and surviving an app restart; a genuinely stuck one can be re-sent by hand. Because each upload carries a stable identity, a retry that arrives twice is recognised as the same upload, so one capture always becomes exactly one document. A single photo is capped at 5 MB.

The review center

On the fleet side, documents land in a review center — a filterable list beside a preview-and-decision panel. The ordinary loop is driver capture and owner review, but platform admins can also list, preview, upload, and review tenant documents through the admin portal for support and operations work.

The list is built to be sorted through fast. An owner filters by category and by status, narrows to a specific mission, vehicle, trailer, or driver, or searches across titles, plates, mission references, and driver names. Selecting a row opens the photo with its metadata — the capture context, any expense figures, and the automatic quality read — and, beneath it, the decision controls under the heading "Décision propriétaire".

A document moves through a small, honest set of states, and the owner's three decisions are what move it:

• "Valider" accepts the document. It is marked "Validé" and its quality reads as acceptable; the driver sees the validation in their app.
• "À corriger" asks for a fix and requires a note explaining what is wrong — a correction request with no reason would be no help to the driver.
• "Rejeter" refuses the document outright, behind a confirmation step, with an optional note for the reason.

Every decision is recorded twice over: the outcome, the note, the reviewer, and the moment are stamped onto the document itself, and a separate append-only audit trail captures the review as its own event. Nothing about a review is silent — the review center always answers "who decided what, and when."

The retake loop

A "À corriger" or "Rejeter" decision is a request back to the person who took the photo. When either lands on a document that has a related driver, Korido raises a directed retake request — a "Documents à reprendre" notification pushed to that driver — carrying enough context (the document, its type, the mission and truck) to deep-link straight to a recapture.

On the driver's phone the request appears as "Retour du bureau": the office's note, the outcome ("Validé", "À reprendre", or "Refusé"), the mission and truck it concerns, and a "Reprendre le document" action that opens the camera or gallery to send a fresh one.

A single document can be reviewed more than once — rejected, recaptured, rejected again — and each rejection is a distinct request the driver must see: every deliberate correction or rejection raises its own fresh notification. The request is produced after the review is safely recorded and is isolated from it, so a delivery hiccup on the notification never undoes or delays the owner's decision. A "Valider" decision ends the review immediately, and a document with no related driver simply has no one to notify.

Edge cases

• Captured with no signal. A photo taken offline is stored, queued, and shown in history with a preview at once; it uploads when coverage returns. Closing or restarting the app does not lose it.
• The same upload arrives twice. A retry that reaches the backend after the first attempt already succeeded is recognised by the capture's stable identity and ignored — one capture becomes exactly one document.
• Rejected again and again. Each rejection or correction request is its own notification, so a driver working through several bad captures sees each request distinctly rather than one stale badge.
• A rejected document with no driver. A document that carries no related driver can still be reviewed and filed; there is simply no retake request to send, because there is no one to send it to.
• The photo file is missing from storage. The review center still shows the document's metadata and says plainly that the image itself is not present, rather than failing the whole row.

Known limitations

• Quality checking is a light first pass, not extraction. Each capture gets a simple quality read — flags like blurry, too dark, or cropped — but Korido does not yet read the document: it does not extract the amount from a fuel slip, the reference on a customs form, or the signature on a delivery note. The figures a driver types into the expense prompt are the figures Korido has; the image is proof for a human, not yet data for a machine.
• Driver captures are photos. A driver capture is an image up to 5 MB. Multi-page PDFs and scanned files are outside the phone capture flow today, though the document store itself can hold private document objects such as admin-uploaded PDFs.

What's ahead

• Documents that read themselves. The natural next step is turning the photo into structured facts: reading the litres and amount off a fuel receipt to reconcile against the tank sensor, matching a customs reference to the border waypoint it was stamped at, confirming a delivery note against the mission it closes. The quality flags captured today are the groundwork for that intelligence.
• A wider owner capture net. The same review center already supports platform-admin document work. The next owner-facing step is letting a fleet add documents from beyond the driver's phone — attaching vehicle papers, importing from another channel — so paperwork gathers in one reviewed place rather than several.

How it connects

• The driver app — the capture surface, its offline queue, and the notification center where a retake request arrives.
• The fleet app — the owner surface the review center lives in, beside the live map, diary, and alerts.
• The mission lifecycle — the run a document is captured against and attached to.
• Fleet assets — the vehicle, trailer, and driver a document files itself under.
• Segments and traversals — the measured record of a run, of which documents are the evidentiary counterpart.