Skip to main content

Cluster Boundary Framework

1. Purpose​

Define the legal & operational boundary for an OX Cluster (taluk-level) and provide the exact steps, rules, and data artifacts required to create, validate, publish, and audit that boundary.

2. Core principle​

One Taluk = One Cluster. Use government taluk polygons/records as the authoritative boundary for the Cluster. All assets, people and franchises are assigned to the Cluster by that taluk identity.

3. Boundary rules​

  1. Source of truth: Official government taluk polygon (GIS/GeoJSON) and taluk code.
  2. Cluster containment: OX Park, Nodes, Booking Centers and Outposts must be located inside the taluk polygon. Park should be near but outside the taluk HQ urban core where possible.
  3. Operational radii are subordinate: Park coverage radius (20–25 km) and Node radii (10–15 km) are purely operational and must be clipped to the taluk polygon — they must not legally extend the Cluster beyond the taluk.
  4. No overlapping clusters: Adjacent taluks are separate clusters. No land, farmer primary record, or Sub-franchisee can have two primary cluster IDs.
  5. Cross-taluk access: Allowed only as a secondary (operational) access; revenue and primary records remain with the official taluk (home cluster). See Conflict Handling.

4. Required data artifacts (must be uploaded to Platform)​

  • taluk_polygon.geojson (authoritative polygon file) — source + checksum.
  • taluk_metadata.csv with: TalukCode, TalukName, District, State, SourceDocumentRef.
  • cluster-boundary-record.json (see template below).
  • park_point.geojson (Park GPS & land-doc ref).
  • node_points.geojson (Node GPS list).
  • village_list.csv (official villages with village codes mapped to taluk). All artifacts must reference the original government source document.

5. Cluster boundary creation workflow​

  1. Obtain official taluk polygon (PDF map + GIS if available) from Revenue Dept. — owner: Master Legal.
  2. Convert to GeoJSON and sanitize topology (no self-intersections). — owner: Platform Ops.
  3. Assign TalukCode & generate ClusterID. — owner: Platform Ops.
  4. Choose OX Park site (GPS) and validate: park_point must be inside taluk_polygon. If not, select alternate. — owner: Master.
  5. Plan Nodes/BookingCenters ensuring their points fall inside taluk_polygon.
  6. Compute operational buffers (Park radius 20–25km, Node radius 10–15km) and clip them to taluk_polygon. Store clipped geometry. — owner: Platform Ops.
  7. Publish cluster-boundary-record (see template) and submit to Franchisor for approval. — owner: Master + Platform Ops.
  8. Sign-off & publish (Franchisor signature + date). After sign-off, boundary is immutable except via formal change-control process.

6. Conflict handling (border cases)​

  • Farmer/machine has official home taluk A but is physically closer to Park in taluk B:

    • Primary cluster = taluk A (based on official village/taluk code).
    • Operational access to taluk B allowed (booking) but revenue / settlement credited to taluk A.

  • Park radius overlap beyond taluk border: Clip coverage to taluk polygon. Do not reassign adjacent taluk areas to this Cluster.

  • Disputed taluk polygon or updated revenue maps: Use the most recent government document. If discrepancy remains, notify District Revenue Office and mark cluster state as UNDER_DISPUTE until resolved.

7. Minimal Cluster boundary JSON template​

{
  "cluster_id": "OX-TLK-<TalukCode>",
  "taluk_code": "<TalukCode>",
  "taluk_name": "<TalukName>",
  "district": "<District>",
  "state": "<State>",
  "taluk_polygon_ref": "taluk_polygon.geojson",
  "taluk_polygon_checksum": "<sha256>",
  "park": {
    "park_id": "PARK-<TalukCode>",
    "gps": ["lat", "lon"],
    "land_doc_ref": "park_land_doc.pdf",
    "inside_taluk": true
  },
  "nodes_ref": "node_points.geojson",
  "booking_centers_ref": "booking_centers.csv",
  "village_list_ref": "village_list.csv",
  "boundary_status": "PENDING_APPROVAL", 
  "created_by": "<user>",
  "created_at": "<ISO8601>",
  "approved_by": null,
  "approved_at": null
}

Populate and store this file in the cluster folder.

8. Minimal GIS operations (what Platform must do)​

  • Validate park_point is within taluk_polygon (point-in-polygon).
  • Clip park coverage circle (20–25 km) to taluk polygon using geometry intersection and store result.
  • Run distance checks: every Node and BookingCenter must have distance_to_nearest_village <= 7 km (or document reason).
  • Maintain checksum and source doc link for the taluk polygon.

9. Approval & change control​

  • Approval: Franchisor signs cluster-boundary-record after review. Record approver name, role, date.
  • Changes: Any change to taluk polygon must go through: Evidence → Legal review → Franchisor approval → Platform update. Keep previous versions archived and tag effective_date.
  • Immutability: Once approved and in production, boundary edits are only allowed via formal change-control; all historical settlements/reference remain tied to the original effective_date unless a migration plan is approved.

10. Audit & verification cadence​

  • Initial verification: Before launch (Step 1–7 above).
  • Annual audit: Verify polygon still matches latest government records. Reconcile village list. — owner: Franchisor + Master.
  • Trigger audit: On receiving any government-level taluk changes or certified mapping updates.

11. Checklist for Each New Cluster​

  1. Acquire an official taluk boundary map & codes.
  2. Finalize OX Park location (GPS, land docs).
  3. Plan Nodes (10–15 km intervals).
  4. Map Booking Centers to village clusters.
  5. Mark potential Outpost zones.
  6. Tag lands, users, machinery, and Subs to cluster.
  7. Upload map + docs into OX Platform.
  8. Submit for OX Franchisor approval.