> ## Documentation Index
> Fetch the complete documentation index at: https://badixth-dc85e378.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# 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](/concepts/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](/guides/field-scouting) | Scout confirmed blast lesions on A2, 3 of 8 tillers, 12 Jun | Takaful pest-loss claim; disease-outbreak reporting. |
| [VRA Maps](/guides/prescription-maps) | Nitrogen VRA applied to A2 on 15 Jun, 4.2 ha coverage | Fertilizer-subsidy disbursement; audit trail. |
| [Field Alerts](/guides/alerts-notifications) | 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--`)
* **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.
Formatted PDF + machine-readable JSON. Includes parcel identity, operation log, satellite cross-check summary, and hash. Layout matches common MOA subsidy templates.
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.
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](/concepts/verification-model#submission-formats) for the exact field lists.
## Creating a verification
From [Activity & Alerts](/guides/activity-and-alerts), open the completed event you want to verify - a scout report, a VRA application, a flood alert, or a season-end yield snapshot.
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.
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).
Pick Subsidy, Takaful, or NADMA. The platform assembles the bundle and displays the verification line for final review.
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](/concepts/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](/snippets/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](/concepts/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](/concepts/verification-model) - the cross-check math, hashing, and bundle schema.
* [Field Scouting](/guides/field-scouting) - completed scout sessions are one of the strongest verification sources.
* [VRA Maps](/guides/prescription-maps) - as-applied uploads become verifiable operations.
* [Activity & Alerts](/guides/activity-and-alerts) - the source feed for every verifiable event.
* [Activity Log](/guides/activity-log) - export a full-season Gantt view for agency audit trails.
* [Estate Group](/guides/estate-group) - set default preset bundles once per estate so field-level exports pick the right format automatically.
* [Crop Cycle Models](/concepts/crop-cycle-models) - the source of truth for bundle cadence per crop.