Rohi MEAL

The first screen after signing in — a live snapshot of the numbers that matter to that person's role. A donor sees a different set of cards than a field officer or a supervisor.

• Opens automatically right after sign-in — there's no menu to find and nothing to set up.
• The set of cards shown is chosen for the signed-in role; a donor, a field officer and a supervisor each see a different dashboard, built for their own job.
• Every number updates from the system directly; anything not yet configured shows a dash instead of a placeholder.

The master list of everyone enrolled in the project, and where new people are registered from the field.

• A new beneficiary is registered through five short sections — identity, household and farm details, financial information, and consent — ending with a signature captured on screen.
• Submitting the form creates the record immediately and returns a reference code on screen.
• The new record then sits in a Verification queue until a MEAL Specialist reviews the full record and either verifies it or rejects it with a written reason.
• A rejection reason is shown directly on the beneficiary's own profile, so the field officer who registered them can see exactly what to fix — not just that something was rejected.
• A profile's full detail — including its attached photos and ID documents, and a complete edit form covering every field the form collects — is reachable from the same record, along with a History button showing every change made to it.

The cooperatives and organisations that beneficiaries belong to.

• A group is created directly — a name and its members are enough to start one.
• Opening a group shows its current member list, drawn live from the system.

The banana-farmer side of the project — profiles, what they've supplied, and their contracts.

• A new farmer is registered the same way as a beneficiary, plus three separate signatures — the farmer, the extension officer, and the supervisor — and can now also carry a photo and a national ID captured straight from the camera or gallery.
• A farmer starts Pending, exactly like a beneficiary, until a MEAL Specialist reviews the full profile and verifies or rejects it — a rejection reason is shown on the farmer's own profile for the field officer to act on.
• A farmer moves to Active automatically once a contract with them is activated, and to Inactive if their only active contract is terminated — nobody sets that status by hand.
• Once registered, deliveries and payments are logged against that farmer under Supply Records as they happen, each one open-able for its full delivery, grading and payment detail — and a Quality tab charts every delivery's grade and acceptance rate over time.
• Contracts are created, activated, renewed, or terminated from the same profile, with a signed document attachable to any of them and every field editable afterward — type, volume, price, dates, notes.

The funded projects that activities and training sit under.

• A project is created with its budget, start and end dates, and a status — everything else in the system is then filed under it.
• Its name, donor, timeline, budget, and regions can all be corrected afterward from an Edit action on the project's own detail page.

The actual fieldwork under a project — what was done, when, by whom, and what it's expected to move toward.

• An activity is planned against a project and, usually, a milestone — its type, dates, region, and budget recorded up front.
• It has to be approved before work can start; the system refuses to let it skip straight from planned to in progress.
• Officers are assigned to it, and a task checklist tracks what's left before it's done.
• It's marked Complete with what it actually reached, or Cancelled with a reason if it isn't — and its own details (title, type, milestone link, dates, budget, location) can be corrected with an Edit action at any point in that lifecycle.
• A calendar view lays out what's planned across a month, and an analytics view rolls up budget, completion and delay by region and by officer.

Scheduling training sessions, taking attendance, running assessments, and tracking how far the programme has reached.

• A session is scheduled, and attendance is taken directly against the people who show up — its own topic, venue, facilitator, and schedule can be corrected afterward from an Edit action.
• An assessment is recorded per session, and a register entry can be amended after the fact — status and note — if it was taken down wrong.
• Overview and Analytics update automatically from that — attendance counts, share of women trained, modules delivered — with no separate entry required.
• Certifying someone now generates an actual certificate — a designed PDF with their name, the training, the date, and a certificate number — attached to their record and downloadable from the register, not just a number stamped in the database.
• A certificate register lists everyone eligible, filterable by issued, not-yet-issued, or everyone, with a download action on every issued one.
• A reach and impact report aggregates results by month and by project, excluding sessions nobody assessed rather than treating them as zero.

Loans to beneficiaries, from application through to repayment.

• A beneficiary applies for a loan, an officer approves or declines it, and once approved it's disbursed.
• Repayments are recorded as they come in, and the portfolio view updates to reflect every step.
• Every loan and every repayment row opens to its full detail — institution, product, all three amounts, interest, term, risk category — view-only, since every figure on it already moves through its own decision or repayment action.

Factory batches — what came in, what was processed, and how it was transported.

• A batch is logged with its quantity as it comes through the factory.
• A past entry can be corrected afterward if something was recorded wrong, including the production date itself.
• A processing facility opens to its full detail — capacity, machine count, cold storage, product types — and every one of those fields is editable from the same view.

Markets the project sells into, and the distributors serving them.

• A market or distributor is added with a short form — name, location, and the details that identify it.
• Both open to a full detail view and a complete Edit action — type, status, target, contract dates, woman- and youth-owned answers included.

Sales transactions, and the distributors, shops and zones behind them.

• A sale is recorded against a distributor, shop or zone — whichever the signed-in role is responsible for.
• Distributors, shops and zones themselves are managed from the same section.

Youth and employment work records tied to the project.

• A work record is logged directly against the project as employment happens.
• Every record opens to its full detail — employer, income before and after, verification status — with a complete Edit action alongside the existing verify/reject decision.

One executive page for leadership — milestones, feedback and learning at a glance.

• Nothing is entered here — it's a live read of milestones, feedback and learning from everywhere else in the system, laid out for a quick executive view.

Actual results tracked against project targets — and a check against reporting errors before they go out.

• A real figure is reported against each indicator as data comes in from the field.
• The Reconcile view then checks that figure against the underlying records and flags anything that doesn't match — a genuine cross-check, not a display feature.
• An indicator opens to its full definition — baseline, target, data source, frequency — with a View Details dialog and a complete Edit action, both new; before this there was no way to see or correct an indicator's own definition once created.

FRP programme milestones, and the funding claims tied to them.

• A milestone is verified or rejected under Overview — a rejection requires a written reason.
• A disbursement claim is submitted against a milestone under Claims once it's been met, and every claim row opens straight through to its own milestone's full detail.
• A milestone's own fields — title, target, disbursement amount, narrative — and the objective it's filed under can both be corrected with an Edit action, without touching either sign-off status.

Logging, triaging and resolving complaints, suggestions, and safeguarding concerns.

• A case — a complaint, a suggestion, or a safeguarding concern — is raised, then assigned to someone to handle, who can escalate it if it needs a higher decision instead of resolving it themselves.
• It's resolved with a written resolution once addressed. For the categories that require it, someone other than whoever resolved it confirms the resolution before the case can close.
• A case with a reporter's phone number on file can now be replied to directly by SMS, recorded in its history either way — see the Docs section below for what "sent" actually means right now.
• The Communications view shows exactly the real 1:1 replies that have been sent, each one open-able for its full delivery detail — there is deliberately no bulk or broadcast messaging anywhere in the system.
• Safeguarding cases stay visible only to the roles permitted to see them, by design.

Capturing lessons learned during the project, linking each one back to the real record it's about, publishing the ones that clear review, and tracking the follow-up actions — and their measured impact — they produce.

• A lesson is written up against a structured What Happened — what happened, what was expected, and why it matters — instead of one free-text paragraph, plus a recommendation for what should change; the write-up, type, tags and impact rating can all be corrected afterward with an Edit action.
• Its source is searched and linked to the real record it's about — a training session, an activity, a beneficiary or farmer, a sale, a production batch, a work record, a feedback case, or a milestone — with a link back to open that record directly, not just a typed guess at which part of the programme it came from.
• Sent for review, it's published or rejected by someone other than whoever wrote it — a rejection carries a reason and sends it back to draft, and both actions leave a History trail on the learning's own record.
• A published lesson with a file attached — a brief, a case study — appears as a knowledge product automatically; supporting material for the observation itself, like a photo or a data extract, is a separate attachment visible from the moment it's captured rather than only once published.
• Any follow-up action it produces is tracked on a board, moved across status columns as the work happens, and tapping a card opens straight through to the learning it came from.
• Once an action reaches Impact, a second person — not whoever recorded it — verifies the claim, with an optional baseline and current figure attached; the learning's own Impact section shows only what has actually been verified, and who verified it.
• A completed training session hands off straight into this form with a Capture Learning button — the source and project pre-filled, never the session's own test scores or attendance figures, so a training result and a learning's measured impact stay two separate facts.
• Communities of Practice is a real space — join or leave one, post into a threaded discussion, and see who else is a member — for staff to work through problems together outside any one learning record.

Where the real registers and exports staff need for donors or management are found and downloaded.

• A report is found by searching or filtering the catalogue by category, then opened and downloaded as CSV or Excel — the file that comes out is a real export, not a mockup.

Every file that's actually been uploaded as proof — consent forms, signatures, photos, certificates — in one searchable place.

• Files are filtered by which kind of record they belong to, then scanned in a table — filename, what it's attached to, its purpose, size, and date.
• Nothing is uploaded from this page directly; files are attached from inside the beneficiary and farmer forms, a farmer's contract, or a training certificate itself.

Personal account security — password, two-factor authentication, and signed-in devices.

• A password is changed directly from this screen — the same real screen a staff member with a temporary password is required to use before doing anything else.
• Two-factor authentication is turned on by scanning a code and confirming it with a 6-digit number.
• A device can be revoked individually, or every device can be signed out at once.

Creating staff accounts, assigning roles, and deactivating people who leave.

• A staff account is created with a form, then edited, deactivated, or has its password reset from the same row later on.
• Every account is assigned at least one role, which decides what they can see and do.

Defining exactly what each role is allowed to see and do across the whole system.

• A role is created with a name, a full permission matrix — what it can see and do, module by module — a landing page, and its own dashboard layout.
• Deleting a role first shows how many people currently hold it.

The org structure staff are grouped under.

• A department is created, edited, or removed the same way as any list — used to group staff by where they sit in the organisation.

An unchangeable record of who did what, and when, across the whole system.

• Every action is filtered by type or by record, then opened to see exactly what changed, before and after — a permanent, unchangeable trail.

Every text message the system sends — verification codes, notices, feedback replies — with a delivery log and a screen to send a one-off message.

• The delivery log shows every message the system has attempted, filterable by whether it arrived.
• A one-off message can be sent — phone number and text — by the roles permitted to do so, once the gateway account behind it is connected.

A learning starts as a draft. Once it's ready for other eyes, move it to In Review — that's the point it lands in the review queue for someone with approval rights.

1. Capture the learning and set its status to In Review when it's ready.
2. A reviewer opens the Review Queue or the learning's own detail page.
3. They either Publish it — now vetted and part of the knowledge base — or Reject it with a reason, sending it back to draft so the author can address it.

A knowledge product — a brief, a case study, a guide — is simply a file attached to a published learning. Attach a file to one still in draft or review and it stays private to that record until the learning itself clears review.

Open a case that has a reporter's phone number on file — the Reply by SMS button appears on cases that aren't anonymous and do have a number recorded. Anonymous cases and ones with no phone given can't show this option, because there is genuinely nowhere to send a reply.

1. Write the message and send it.
2. It's recorded immediately in the case's history as something the reporter was told, regardless of whether the SMS itself gets through.
3. The confirmation banner reports what actually happened — sent, queued, or not sent — rather than assuming success.

An activity moves through four states: planned → approved → in progress → completed. Each move is checked — trying to jump straight from planned to in progress, or to complete something never approved, is refused rather than silently allowed.

The certificate register is one filterable list, not two screens guessing which was wanted — issued, not-yet-issued, or everyone. Issuing one now produces an actual document, not just a number.

• A certificate is issued from a session's own assessment sheet, next to the attendance and completion it depends on — the same step now also generates a real, designed PDF (the participant's name, the training, the date, and the certificate number) and attaches it to their record.
• The register gathers them across every session, for the two chores that actually differ: chasing who's eligible and hasn't got theirs, or reprinting one that's already out — and a Download action on any issued certificate produces that same PDF on demand, without needing to open the original session.
• The reach report groups results by month and by project, and leaves out sessions nobody assessed rather than counting them as zero improvement.

Every consequential action — approving an activity, verifying a milestone, publishing a learning, resolving a feedback case — is gated by a specific, named permission rather than a general "manager" flag.

The words that come up most, explained plainly.

Verify / Verification

A second person checks a record someone else submitted and either approves it or sends it back with a reason. Until that happens, the record sits Pending — visible, but not yet treated as confirmed.

Self-approval prevention

A backend rule, not just a UI choice: whoever submitted a record can never be the one who verifies, signs off, or resolves it — even if their role holds both permissions. Applies to Beneficiaries, Farmers, Milestones, Employment, Learning and Feedback cases alike.

Escalate / Escalation

Handing a feedback case up to someone with more authority because it shouldn't be decided at the current level. An escalated case returns to Investigating once it's handed back down — never straight to resolved — because the work still has to be done, just by someone else.

Resolution

The written record of what was actually done to address a case — proposed first, then confirmed as final. Kept as two separate steps so "I did the work" and "this is officially settled" aren't the same click.

Disbursement

Two different flows share this word. On a Milestone, it's the donor releasing programme funds once a target is verified. On a Loan, it's a partner bank paying money into a beneficiary's hands after their application is approved — tracked as its own separate step, because an approved loan that never actually pays out is exactly the kind of gap this system is built to catch.

Milestone

A target for one reporting period that a disbursement claim depends on — the one figure a funder acts on directly. Filed under an Objective, and reports against one or more Indicators.

Indicator

The definition of what's being measured — the "what" and "how," not the target. A Milestone points at the Indicator(s) it's proving progress on; the Indicator itself doesn't carry a deadline or a funding claim.

Objective

One of a Project's real aims — e.g. "Increase smallholder incomes." Milestones are filed under the right Objective so a report can say which aim is on track, not just the project as a whole.

Activity (and how it links to a Milestone)

A planned piece of fieldwork — a training round, a distribution, a visit. It can be tagged to the Milestone its work counts toward; the Indicator link is never duplicated on the Activity itself, it's inherited through the Milestone.

Two-factor authentication (MFA)

An extra login step — a 6-digit code from an authenticator app — required in addition to a password. Administrative accounts are prompted to enable it; existing sessions aren't locked out for not having it yet.

Role & Permission

A permission is one specific, named thing a person can or can't do — e.g. "verify beneficiaries." A role is a bundle of permissions given a title, like Field Officer or MEAL Specialist. What a signed-in person sees and can click is decided entirely by which permissions their role holds.