Verification: Satellite-Stamped Proof for Subsidies, Takaful, and NADMA

Turn every logged field operation into tamper-evident, satellite-stamped proof formatted for subsidy applications, crop-takaful claims, and NADMA flood-relief submissions. No site visit required.

Verification turns activity on the platform into evidence agencies accept. Every logged field operation - a spray, a scout, a VRA application, a harvest, a flood event - is cross-checked against the satellite record for that parcel and date, then issued as a tamper-evident verification line. Agencies release subsidies faster and settle takaful or disaster claims with evidence instead of paperwork and field audits.

Verification is the presentation layer. The mechanics of the cross-check, hashing, and evidence bundle are documented in Verification Model.

Why this matters

Today, most agri-payments in Malaysia require a physical site visit. That means weeks or months of delay, uneven coverage across smallholders, and disputes that come down to a photograph and a signature. Verification replaces that with:

• A satellite record that captured the parcel on or near the operation date, independent of the farmer.
• A tamper-evident hash over the event, the imagery, and the surrounding context.
• A formatted bundle an assessor can read in minutes without leaving their desk.

The farmer submits. The agency approves. The record is auditable years later.

What can be verified

A verification is always tied to an event already recorded on the platform. Verification cannot invent activity; it can only stamp what was logged.

Event source	Example	Typical use
Field Scouting	Scout confirmed blast lesions on A2, 3 of 8 tillers, 12 Jun	Takaful pest-loss claim; disease-outbreak reporting.
VRA Maps	Nitrogen VRA applied to A2 on 15 Jun, 4.2 ha coverage	Fertilizer-subsidy disbursement; audit trail.
Field Alerts	Flood alert on A2 from Sentinel-1 backscatter, 3-5 Jun	NADMA flood-relief submission.
Crop Health snapshot	End-of-season NDVI + yield estimate on A2	Yield-shortfall takaful claim.
Manual field log	Harvest completed on A2, 18 Sep	Harvest declaration for subsidy closure.

Verification does not create evidence. It certifies that what you logged is consistent with the independent satellite record. If an operation was not logged on the platform (or was logged much later than it happened), it cannot be verified against the pass captured on that date.

The verification line

Every verified event produces a short, human-readable line plus a machine-readable payload. Agencies see the line; auditors can request the payload.

VRF-2026-06-15-A2-VRA-NITROGEN  ·  Field A2 (Kedah, 4.2 ha)  ·  Nitrogen VRA applied 15 Jun 2026, 09:14 MYT  ·  Confirmed against Sentinel-2 pass 16 Jun 2026 (NDRE +0.04 vs pre-application)  ·  Hash sha256:9f2a…c81b  ·  Verified 17 Jun 2026

The line always contains:

• Verification ID with a stable prefix (VRF-YYYY-MM-DD-<field>-<event>)
• Parcel identity (field, region, area)
• Event and timestamp as logged
• Cross-check that passed (imagery, date, delta metric)
• Tamper-evident hash over the full evidence bundle
• Verification timestamp

Submission formats

Agencies do not all want the same thing. The platform ships three preset bundles.

Subsidy application

Formatted PDF + machine-readable JSON. Includes parcel identity, operation log, satellite cross-check summary, and hash. Layout matches common MOA subsidy templates.

Crop takaful claim

Formatted PDF + JSON with an explicit loss narrative (event, yield-at-risk %, estimated loss in tonnes and MYR). Includes pre-event and post-event imagery thumbnails.

NADMA flood relief

Formatted PDF + GeoJSON of the flood footprint. Includes Sentinel-1 backscatter evidence, water-extent polygon, and the affected area calculation.

All three formats share the same underlying evidence bundle. The presentation layer differs by agency. See Verification Model for the exact field lists.

Creating a verification

1. Open the source event

   From Activity & Alerts, open the completed event you want to verify - a scout report, a VRA application, a flood alert, or a season-end yield snapshot.

2. Click Verify

   Every event that is eligible for verification carries a Verify action. The platform pulls the surrounding satellite passes, runs the cross-check, and shows the result.

3. Review the cross-check

   You will see:

   • The event as logged (date, coordinates, actor, quantities)
   • The satellite pass(es) used for the cross-check (source, date, cloud cover, indices measured)
   • The delta metric that confirms the operation (e.g., NDRE +0.04 after N application; water-extent polygon after flood alert)
   • Any anomalies (missing imagery, cloud gap, unexpected delta) called out explicitly

   Cross-checks either pass, pass with note, or fail. Failed checks cannot be submitted; the platform explains why and suggests what to do (re-scout, wait for the next pass, or dispute with a manual field record).

4. Choose the submission format

   Pick Subsidy, Takaful, or NADMA. The platform assembles the bundle and displays the verification line for final review.

5. Submit

   Submit directly to the agency (for integrated agencies) or download the bundle to attach to an external portal. Submission emits a verification.submitted event into the feed with a receipt.

Verify events as soon as they happen, not at the end of the season. A verification requested weeks later may fall outside the imagery window that best confirms it, and the cross-check will be weaker.

What agencies see

Agencies with integrated access see a queue of incoming verifications. Each row shows:

• Verification line
• Parcel identity + smallholder / estate identity
• Cross-check strength (strong / moderate / weak, with the driver)
• Attached evidence bundle
• Assessor actions: Approve, Request more info, Reject with reason

Approval triggers the agency’s own disbursement or claims workflow. The verification hash is stored on the agency side for later audit.

Handling disputes

Some operations cannot be cleanly cross-checked. Common cases:

Situation	What the platform does	What the submitter can do
Cloud cover blocks the satellite pass	Cross-check flagged weak, with imagery gap called out	Attach ground photos with GPS + timestamp; re-verify on the next clear pass
Operation logged days late	Cross-check compares against the wrong pass window	Log operations same-day whenever possible; late logs are marked in the bundle
Satellite record contradicts the log	Cross-check fails	Review with agronomist; a scout task is auto-suggested
Sensor or feed disruption	Verification is held until the feed recovers	The event stays in the queue; no submission is lost

Disputes never delete the underlying event or verification attempt. The audit trail is preserved.

Bulk verification

Estate managers can verify many events at once. Under Verifications → Bulk, filter by field, event type, date range, or claim type, then submit the whole set as one bundle. This is the recommended path for:

• Season-end subsidy closure across an estate
• Region-wide flood-relief submissions after a NADMA-declared event
• Cooperative-level takaful renewals

Each event still carries its own verification line and hash inside the bundle; the bulk wrapper just handles the transmission.

Bundle cadence by cycle model

The natural boundary for a verification bundle depends on the crop’s cycle_model. See Crop Cycle Models for the full family definitions.

Cycle model	Bundle boundary	Typical trigger
Cyclical (rice, corn, groundnut)	One Season = one bundle	Harvest complete; subsidy or takaful window opens. Bundle spans planting to harvest.
Perennial (oil palm, rubber, coconut)	One month or one quarter = one bundle	Estate book-close. Bundle covers all FFB tally sheets, tapping logs, and applied maps within the period.
Rolling continuous (pineapple, banana)	One Planting Batch = one bundle	Batch harvest complete. Each Batch is its own claim unit, independent of other batches on the same Field.

The platform picks the default cadence from cycle_model when the bundle is created; estate admins can override under Verifications > Settings > Bundle Cadence. Overriding a cyclical crop to monthly (or a perennial to per-season) is supported but flagged with a warning because it can misalign with the receiving agency’s expected schedule.

Guardrails

This module follows the shared guardrails template. The agent and every non-agent write path must respect these rules.

Category	Rule
Input validation	Bundle requires: field_id or estate_id, cycle_model, bundle boundary (season, month, batch), and at least one source event (scout report, as-applied map, activity entry). Every source event must carry an ISO timestamp, GPS coordinates within the field, and a hash matching the Verification Model schema. The advisor pre-fills the bundle draft from qualifying events; the user reviews rather than authors.
Preconditions	Cross-check requires a satellite pass within the tolerance window declared for the crop’s cycle_model. Bundle cannot be assembled before the cycle boundary event (harvest, book-close, batch complete). Field geometry must be locked for the bundle period (no unlogged edits).
Refusals	Cross-check refuses to run on intervals shorter than 7 days, on insufficient cloud-free imagery, or on unlocked geometry. Bundle refuses assembly if any source event fails hash validation. Agent cannot override “insufficient data” verdicts; only an authorized reviewer can, with a written reason.
Confirmations	Override of an “insufficient data” verdict (safety-critical). Export of a bundle to a receiving agency (leaves the platform). Deletion of a bundle with agency-side receipts (irreversible on the agency side). Cadence override that misaligns with the agency’s expected schedule. Bundle assembly and pre-export edits commit optimistically with undo.
Soft warnings	Cross-check verdict close to the tolerance boundary. Cadence override that stays within the agency’s usual range but differs from the crop’s default. Bundle assembled with only one source event when multiple are typically available.
Rate and scope limits	Agency-facing exports capped per org tier because of external cost. Manual cross-check re-runs capped per bundle per 24 hours to control satellite tasking cost. No hard cap on bundle drafts or in-platform reviews.
Audit	Every bundle records actor, source-event hashes, satellite pass IDs, cross-check verdict, reviewer identity for any override (with reason), export destination, and receipt IDs from the receiving agency. Bundle records are append-only after export.
Escalation	Cross-check fail escalates to agronomy review before any override is offered. Two consecutive failed bundles on the same field escalate to the estate manager. Any override of an “insufficient data” verdict is copied to the org admin.

Related

• Verification Model - the cross-check math, hashing, and bundle schema.
• Field Scouting - completed scout sessions are one of the strongest verification sources.
• VRA Maps - as-applied uploads become verifiable operations.
• Activity & Alerts - the source feed for every verifiable event.
• Activity Log - export a full-season Gantt view for agency audit trails.
• Estate Group - set default preset bundles once per estate so field-level exports pick the right format automatically.
• Crop Cycle Models - the source of truth for bundle cadence per crop.