From a field submission to a result you can report
Numbers arrive from the field faster than anyone can check them — and once they are in a spreadsheet, nobody can tell which ones were reviewed.
The damage is rarely a wrong number. It is a number nobody can trace: no record of who submitted it, who accepted it, or whether the version in the donor report is the version that was approved. This chain keeps submission and acceptance as separate, recorded events.
How the chain runs
Every step names the role that acts, the rule the server enforces at that moment, the record it leaves behind, and who holds it next.
-
Who acts
A MEAL lead holding the write capability for the project
Opens a collection link for a project indicator and period.
What the server enforces
Creating or revoking a link requires the MEAL write capability; the link is scoped to one tenant, and a partner collects through its own bounded session rather than a staff account.
- What it leaves behind
- A tokenised collection link, listed and revocable.
- Next owner
- The field team or partner doing the counting.
-
Who acts
A field enumerator or partner
Submits the value for that indicator and period through the link.
What the server enforces
The submission is stored as pending. A retry carrying the same idempotency key returns the original submission instead of creating a second one — the database, not the browser, enforces this with a unique key per link and per partner session, so a dropped connection on a bad line cannot double-count.
- What it leaves behind
- A pending submission, with its submitter, note and timestamp.
- Next owner
- The reviewer for that project.
-
Who acts
A reviewer holding the MEAL approve capability for that project
Reads the submitted value beside the current recorded actual, then approves or rejects it — with a note.
What the server enforces
Approval authority is project-scoped: a tenant-wide MEAL grant does not hand you every project. Only a pending submission can be reviewed, and the update re-checks that state as it writes, so if two reviewers act at the same moment the second is told the submission was already reviewed by someone else rather than silently overwriting the first decision.
- What it leaves behind
- A decision recorded on the submission with its reviewer, timestamp and note.
- Next owner
- The results record itself.
-
Who acts
The system, on approval only
Writes the approved value into the indicator actual for that project, indicator and period.
What the server enforces
Only the approve decision writes an actual. A pending or rejected submission never reaches results at all. The write carries its provenance — whether the value came in through a collection link or a partner portal — and it replaces the existing actual for that exact project, indicator and period rather than adding to it, so a corrected figure supersedes the old one instead of inflating it.
- What it leaves behind
- An indicator actual carrying the source it came from.
- Next owner
- Reporting and rollups.
-
Who acts
Programme and MEAL reporting
Reads the rollup across the project’s indicators.
What the server enforces
A custom indicator that has not been approved is skipped by the reconcile and rollup entirely, so an indicator somebody invented last week cannot move the score until somebody with the authority approves it.
- What it leaves behind
- A rollup built only from approved indicators and accepted actuals.
- Next owner
- End of the chain
What holds it together
Four guarantees that are true of the chain as a whole, not of one step.
Access is a capability, checked per project
Opening a collection link needs the MEAL write capability; approving a submission needs the MEAL approve capability for that specific project. A tenant-wide grant admits you to the module, not to every project in it.
Submitting and accepting are separate events
Pending is a real, stored state with its own record. Nothing becomes a result without a second person making a decision that is written down with their name, the time and their note.
A retry is not a second count
Idempotency is enforced by a unique key in the database, not by the form. Resubmitting after a dropped connection returns the original submission rather than creating a duplicate.
Two reviewers at once is a handled case
The approval re-checks the pending state as it writes. The second reviewer is told the submission was already reviewed by someone else instead of overwriting the first decision.
What you end up holding
The records this chain produces — the ones an auditor or a donor will ask to see.
- A submission register: every value that was ever offered, with its submitter, its decision, the reviewer and the note.
- Indicator actuals that only ever came from an approved submission, each carrying the channel it arrived through.
- A rollup that excludes unapproved custom indicators by construction, not by convention.
- Field reports as a separate narrative record, with their own review chain and their own no-self-approval rule.
Scope and availability
What this chain does not do. None of it is behind a toggle, and none of it is coming "soon" unless we say so.
Not available today
- Returns a collection submission to its submitter for revision.
- A collection submission can be approved or rejected — not returned for revision. The revision route exists on field reports, which move through draft, submitted, reviewed and approved, and where a report’s own author cannot approve it.
- Field reports do not write indicator actuals. They are the narrative record. Results come only from approved collection submissions.
- MEAL periods are not locked. Finance has period locks; the results side does not, so a later approval can still replace an actual in a period you already reported on. Treat your report as a point-in-time cut.
- Totals are not unique reach. A sum of submitted values or distributed items is a count of transactions, not a count of distinct people, and nothing in this chain deduplicates beneficiaries.
- A collection link is a web form with a token, not a system-to-system connector. There is no live integration with a third-party data-collection platform in this chain.
About the images on this page
The three views on this page are captures of the current application running on synthetic seed data. There is no capture of the review decision itself yet; that step is described in text rather than mocked up.
Capture
Capture
Capture
Open a free workspace and run the chain end to end on sample data, or ask us to walk you through the review step on a call.
The other workflow
From a requisition to a posted, balanced journal