gigHood: Insurance That Pays When a Zone Breaks
How an H3-based disruption engine, proof-of-presence telemetry, and graph fraud checks turn gig-worker protection into a programmable system.
- gigHood reimagines insurance as an event system, where a live zone crossing a threshold is enough to trigger a payout.
- The H3 grid is the project’s real unit of logic, because it lets weather, traffic, presence, and policy coverage line up in the same spatial frame.
- The DCI engine replaces manual adjustment with a deterministic rule over live signals, which is what makes the 90-second payout story plausible.
- Fraud defense is not an afterthought here, because proof of presence and graph-based syndicate detection are baked into the payout path.
When a storm becomes a payment event
gigHood is aimed at a very specific problem: when gig work stops being economically viable because the city itself turns hostile. Weather, congestion, air quality, and platform disruption can all crush earnings in minutes. The project’s bet is that a worker should not have to file a claim and wait for a human to agree that the day was bad.
Instead, the system watches a zone in real time and pays when the zone crosses a disruption threshold. That is the core shift. It moves protection from retrospective paperwork to a live operational signal.
In the repo, this is not framed as a niche insurance demo. It reads like a new operating model for income protection, built for Indian quick commerce workers who live inside narrow margins and fast-moving streets.
The zone is the unit of insurance
The conceptual leap in gigHood is spatial. The platform does not start with a person or a claim. It starts with an H3 hexagon, which becomes the smallest meaningful unit of coverage, monitoring, and payout.
That matters because it gives the product a clean abstraction. Weather does not have to map to a city in an ad hoc way. It lands on a grid cell. A rider does not just exist somewhere in Bangalore or Delhi. They exist inside a specific hexagon that can be measured, scored, and insured.
Inside the DCI engine
The heart of the repo is the Disruption Complexity Index, or DCI. It combines five live signals: weather, AQI, traffic, platform status, and social sentiment. The article of record is simple: once the score crosses the disruption threshold, the zone becomes payable.
# Conceptual view of the DCI rule
score = (
weather * 0.45 +
aqi * 0.20 +
traffic * 0.15 +
platform_status * 0.10 +
social_sentiment * 0.10
)
is_disrupted = score >= DISRUPTION_THRESHOLDThat simplicity is the point. A human adjuster can interpret context, but a product that promises near-instant payout needs a deterministic rule. The DCI engine is basically an actuator: if the inputs line up badly enough, the system does not debate the outcome.
This is where the repo feels more like infrastructure than software. The disruption score is not just a dashboard metric. It is the bridge between live conditions and a financial event.
How proof of presence keeps the payout honest
Parametric systems break if the edge is soft. gigHood tries to harden that edge with proof of presence. The backend ingests location pings on a cadence, checks H3 position, and watches for spoofing hints like mock location flags and weak network signals.
That matters because the product pays based on where the worker is, not just where the storm is. If the trust layer is weak, the whole model becomes a magnet for gaming. The repo’s anti-spoofing approach makes the payout path feel operationally serious rather than aspirational.
The subtle design move here is that presence is treated as evidence, but not as a single point of truth. It is one signal among several, which is exactly how a fraud-aware system should behave.
Fraud does not look like fraud in a spreadsheet
The repository’s fraud layer leans on graph thinking, which is the right shape for the problem. A flat table can spot duplicates. A graph can spot relationships: shared device IDs, shared UPI handles, and clusters of claims that move together in suspicious ways.
| Dimension | Claims-based insurance | gigHood parametric zone model |
|---|---|---|
| Trigger | A human reviews a loss after the fact | A zone crosses a disruption threshold |
| Evidence required | Receipts, forms, and back-and-forth review | Live environmental and presence signals |
| Time to payout | Days or weeks | Minutes, with a fast automated path |
| Fraud surface | Document tampering and duplicate claims | Spoofed presence, collusion clusters, shared identities |
| Operational burden | High manual adjudication load | Higher upfront system design, lower per-event handling |
| Best fit | Slow, individualized loss events | Repeated, local, time-sensitive disruption |
That is why the Neo4j layer is more than a nice-to-have. It gives the system a way to ask a different question: not just whether this worker looks valid, but whether this worker looks connected to a pattern that should not exist.
The sandbox is the secret superpower
The most underrated part of the repo is the simulation and admin override path. It lets an operator force a storm, push a high-AQI event into a hex zone, and watch the payout logic run as if the world had changed. That is not a toy feature. It is the equivalent of a fire drill for actuarial logic.
For product teams, this is the aha moment. The platform is not just reactive. It can rehearse failure, verify the decision path, and test payouts before real conditions do the testing for you. That makes the system easier to trust internally, which matters as much as user trust on the outside.
It also reveals the repo’s engineering posture. The goal is not to automate blindly. It is to build a machine that can be inspected, overridden, and simulated.
Built like a system, not a demo
The stack is unusually coherent for an alpha-stage project. FastAPI handles backend logic, Next.js handles the dual-mode frontend, Supabase gives the data layer shape, XGBoost supports risk profiling, Groq and OpenRouter power the AI layer, and Razorpay closes the loop with payouts.
The monorepo structure matters because it keeps the product’s major concerns in one place: geometry, trust, underwriting, payments, and operator tooling. The `.agents` workflow is a quieter clue. It suggests the project was designed to be maintained with AI assistance, but with domain-specific instructions instead of generic prompt flailing.
That is a meaningful detail. A repo like this does not stay healthy because of raw ambition. It stays healthy because the maintainers made it legible enough for both humans and agents to keep moving without breaking the contract between modules.
What gigHood actually proves
gigHood is not just a more automated insurance product. It is evidence that protection can behave like infrastructure when the system knows how to detect an event, trust a location, and move money without waiting for paperwork.
The deeper implication is that the hardest part of programmable insurance is not pricing. It is event detection, spatial trust, and payout orchestration. gigHood treats those as first-class engineering problems, which is why the repo feels more interesting than a standard fintech prototype.