Skip to main content
← Answers Hub
Answer

How Does the Delivery Ledger Work?

Every Export Flow export writes a ledger entry recording the files, destination and state. Kora separates Confirmed — the work is finished — from Delivered, which requires both the upload and the delivery email, so follow-up never chases a delivery that never landed.

How Does the Delivery Ledger Work?

Direct answer: Every export through Export Flow writes a ledger entry recording which files went out, to which destination, and what state the delivery is in. The useful part is that finishing a deliverable and actually delivering it are separate states — a rendered, validated file is Confirmed, and it only becomes Delivered once it has been uploaded and the delivery email has gone out.

That distinction is why the follow-up engine never chases a client about a file that never reached them.

The states, and what each one means

StateWhat it means
DraftAn entry exists but the delivery has not been completed
ConfirmedExport Flow finished the work — rendered to the target format, metadata embedded, naming and folder structure applied
DeliveredIt reached the client — files uploaded and the delivery email sent
NeedsChangesThe client asked for revisions through a review link
ReplacedA newer delivery supersedes this one
ArchivedClosed out and kept for the record

Approval is tracked separately, as its own field: none, pending, approved or changes_requested. A delivery can be Delivered and still awaiting approval — those are different questions, and conflating them is how “did they ever reply?” becomes unanswerable.

Why Confirmed and Delivered are not the same thing

Promotion to Delivered requires both halves: the upload and the email. An upload with no email stays Confirmed.

That looks pedantic until you consider what the follow-up ladder does with it. Rule 2 fires when something was delivered under 14 days ago with no approval, escalating to high urgency after seven days. If an interrupted upload counted as delivered, Kora would start chasing a client about a file they were never told about — and you would look disorganised for a reason you could not see.

So the ledger is deliberately conservative about the strongest claim it can make.

What a ledger entry records

Each entry holds the files that went out — filename, output path, size, checksum and mix type — with the destination, the timestamp and the state above.

Two things it does not hold, worth stating because they are easy to assume:

  • No per-file version number. A deliverable file records what it is, not which revision it is. Version identity has to live in the filename — which is what the naming templates are for.
  • No revision index or per-file date beyond the delivery timestamp.

How the ledger drives follow-up

The ledger is not a passive log. Three of the eight follow-up rules read from it:

RuleTriggerUrgency
2Delivered under 14 days ago, no approvalHigh after 7 days
3Entry marked NeedsChangesHigh
5Linked project completedMedium

That is the practical difference between a delivery log and a delivery ledger. A log tells you what happened. This one changes what Kora puts in front of you tomorrow.

Frequently asked

What is a delivery ledger?

A timestamped record of every handoff — which files went out, to which destination, when, and what state the delivery is in. In Kora it is written automatically by Export Flow rather than maintained by hand, and it feeds the follow-up engine.

Does the ledger track file versions?

No. An entry records filename, path, size, checksum and mix type, but there is no version number or revision index. Version identity lives in the filename, applied by the naming template.

What is the difference between Confirmed and Delivered?

Confirmed means Export Flow finished the work — rendered, tagged, named. Delivered means it reached the client, which requires both the upload and the delivery email. An upload without the email stays Confirmed.

Will Kora chase a client automatically?

No. It surfaces the follow-up as a suggestion with the reason attached; sending is always yours. Rule 2 raises a delivery to high urgency after seven days without approval, but nothing goes out on its own.

What happens when a client asks for changes?

The entry moves to NeedsChanges, a high-urgency trigger on the follow-up ladder, so the revision request surfaces rather than sitting in an inbox.

Authority hubs

Next step

Ready to put this into practice?

Kora is the system this path is built around.

A project-lifecycle platform purpose-built for music workflows — project tracking, delivery validation, and client relationship continuity in one place.