The whole job, on a mid-range Android, with no signal
Six lifecycle visits to one plot, captured by a technician covering 150 to 200 farmers across villages with no connectivity and no external GPS. This is that app, running: the walk is simulated unless your browser supplies a real position, the area and its error band are computed from the fixes on screen, and a saved capture is stored on the device and survives a reload.
The six visits are not a burden imposed on the technician. They are the error-reduction mechanism: six independent observations of one boundary, plus the edges it shares with neighbours in the same club, reconcile to something far tighter than any single walk can be.
Today
Before you leave
Clubs
Day order is derived from open stage slots, not from a calendar. The season is closed and the settlement window is open, so a plot missing a stage is a plot that cannot be settled.
Top-level screen
Screen 1 · Daily plan
Everything needed today is on the handset before leaving, measured in bytes. Day order comes from open stage slots, not a calendar.
Who is holding the phone
Switching technician switches handset. Every tolerance, expected error and acceptance band on the capture screens is recomputed from that handset, so the dual-frequency case is made by using it rather than by claiming it. Srikanth B. is on Mid Android (2021 class), L1.
Conditions
Models field connectivity. The browser itself stays online, and no screen claims otherwise.
Blocks or qualifies a capture on the start and walk screens.
Every screen
What is real in here
- The walkSimulated by the engine: a fix every 2.5 m along the true boundary, with a GNSS error that drifts rather than jitters, at the accuracy this handset gets under this stage's canopy in this village. Seeded, so the same plot walks the same way every time.
- Every numberArea is the shoelace area of the recorded fixes. The band is the engine closed-form area variance on those same points. Tolerances, value at risk and marginal gain are engine calls, not constants in the copy.
- The queueA real on-device queue with gap-free sequence numbers. Captures survive a reload; the session counter on the queue screen is the proof.
- The syncA real request to the server, which checks ordering, duplicates, conflicts and mocked positions against a reference club and stores nothing. Whatever it answers is shown as it came back.
- The conflictFound by the queue's own local detector with no connectivity: two unsynced captures on one plot and stage from two technicians. The second walk is a second real simulation, so the areas differ by physics.
- Real GNSSOptional and clearly labelled. If this browser gives a position, the capture uses it and every screen says so, including the record written to the queue.
SYNTHETIC DATA. Every company, village, club, farmer, plot boundary, capture, contract, rate and settlement in this file is fabricated to demonstrate the product. No real person, holding or agreement is represented. District and state names are real Indian administrative names used only to anchor the belt; village centroids are approximate synthetic points inside it and do not correspond to any actual settlement.
Every GNSS fix in this app is simulated unless the screen says otherwise, and a simulated capture is labelled as simulated everywhere it goes, including in the record it queues for upload. If your browser grants a real position, the capture uses it and is labelled as a device fix from the walk screen through to the stored record.