DEV Community: Mohammad Tejabwala

NeoNomad🛳️ - Cross-border tax residency & PE Risk Arbiter

Mohammad Tejabwala — Mon, 05 Oct 2026 06:57:24 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

Introduction

All hands on deck! Welcome to the NeoNomad!

This is my second time participating in a hackathon (and also my second post :D), and I am still shocked that I made it in my first try. After winning the prize, the one thing that hit me was getting the prize amount in my resident country. I had to fill out a W-8BEN to avoid double taxation, read the laws in my host country, and had to handle filing for the tax on the "income" generated. So, overall, a big headache. Which leads me to this: NeoNomad (Neo referring to Captain Nemo and Nomad meaning travelling from place to place), Cross-Border Tax Residency & PE Risk Arbiter.

Now, those are some heavy words; let us understand them in simpler terms:

The Persona: Meet Rohan

Imagine a software engineer named Rohan:

Home Base: Rohan is an Indian citizen and tax resident living in India.
The Employer: He works remotely as a Principal Solutions Architect for a high-growth tech company based in Germany.
The Plan: He decides to do a winter detox and work remotely from a beach apartment in Valencia, Spain, for 128 days (straddling October through February).

To Rohan, the setup seems straightforward:

"I'm only staying four months, well below the famous 183-day limit. I'm paying my regular taxes in India, and my employer is a German company with no presence in Spain. Why would this cause any tax issues?"

However, behind that simple intuition lies a hidden cross-border trap where three jurisdictions and their tax laws collide simultaneously.

In reality, three distinct legal frameworks collide simultaneously:

Spain's Unilateral Domestic Tax Law (LIRPF & IRNR):
- Under domestic Spanish personal income tax (Ley 35/2006 LIRPF Art. 9.1(a)), tax residency requires strictly more than 183 days within a single calendar year. Because Rohan's 128-day stay straddles two tax years (78 days in 2026, 50 days in 2027), he does not trigger statutory domestic tax residency.
- However, under Spain's Non-Resident Income Tax Act (IRNR Art. 13.1(c)), Spain asserts strict territoriality: any labor physically conducted on Spanish soil is deemed Spanish-source income, taxable immediately from Day 1 at a 24% non-resident rate, regardless of where the employer is incorporated.
International Treaty Supremacy (India–Spain DTAA Article 15):
- Rohan is an Indian tax resident, so his personal income tax relief is governed by the India–Spain Double Taxation Avoidance Agreement.
- Under Article 15(2), host-country taxation is displaced if:
  - The individual is present for <= 183 days in a rolling 12-month period,
  - The employer is not resident in Spain (the German company satisfies this), and
  - The remuneration is not borne by a Spanish permanent establishment.
- Under Article 96 of the Spanish Constitution, ratified international treaties supersede domestic legislation, legally nullifying Spain's domestic Day-1 IRNR claim.
Corporate Permanent Establishment Exposure (Germany–Spain DTAA Article 5):
- Even though Rohan's personal income is shielded by the India–Spain treaty, his employer's corporate exposure is governed by an entirely different instrument: the Germany–Spain DTAA.
- Because Rohan scopes custom architectures and negotiates commercial Statement of Work (SOW) terms on the ground with European automotive accounts, the German company faces a high risk of triggering a Dependent Agent Permanent Establishment (DAPE) under Article 5(5). Digital DocuSign execution back in Germany does not eliminate this liability under modern OECD rules.

This brings us to the Sanity MCP context and Knowledge bases:

What I built:

Sanity is basically a smart data store, I would say, with relationships clearly defined between entities without any conflicts or duplication.

An agent is only as good as the knowledge it can find

So, what I built was the initial schema containing the jurisdication: containing information about the independent country and the bilateral treaties between these independent countries.

Providing the schema outline here:

Example 1: India–Spain DTAA (treaty-in-es)

JSON

{
  "_id": "treaty-in-es",
  "_type": "bilateralTreaty",
  "title": "Convention Between the Republic of India and the Kingdom of Spain for the Avoidance of Double Taxation",
  "signatoryA": {
    "_type": "reference",
    "_ref": "jurisdiction-in"
  },
  "signatoryB": {
    "_type": "reference",
    "_ref": "jurisdiction-es"
  },
  "article15Terms": {
    "exemptionDayLimit": 183,
    "countingPeriod": "rolling_12_months",
    "conditions": [
      "Recipient is present in the host state for <= 183 days in any 12-month period commencing or ending in the fiscal year concerned",
      "Remuneration is paid by, or on behalf of, an employer who is not a resident of the host state",
      "Remuneration is not borne by a permanent establishment or fixed base which the employer has in the host state"
    ]
  },
  "legalHierarchyStatus": "supersedes_domestic",
  "sourceTreatyUrl": "https://www.incometaxindia.gov.in/DTAA/Spain.pdf"
}

Example 2: Indian jurisdiction

JSON

{
  "_id": "jurisdiction-in",
  "_type": "jurisdiction",
  "name": "India",
  "code": "IN",
  "taxYearCycle": "fiscal_year_apr_mar",
  "domesticResidencyRule": {
    "statutoryAct": "Income-tax Act, Section 6(1) (Residential Status) & Section 5/9 (Scope of Total Income)",
    "daysLimit": 182,
    "comparisonOperator": "greater_than_or_equal",
    "windowType": "fiscal_year",
    "territorialSourceRule": "An individual is a tax resident if present in India for >= 182 days during the financial year (1 April to 31 March), or >= 60 days if present for >= 365 days across the preceding 4 financial years. Residents and Ordinarily Residents (ROR) are subject to tax on worldwide income, while non-residents are taxed exclusively on income accrued, arising, or received in India under Section 5 and Section 9."
  }
}

Sanity supports initial context out of the box, so when we built a database, it can use the GROQ mode to query the data at request time. But, this does not solve the fundamental problem with the RAG model that we just discussed, we need to ensure that there are no conflicts involved with the data that we are seeding and if there are, we need to specify which takes priority.

So, it was decided to move with Knowledge Bases which can process the data that we ingested first. It serves an index built from the data source that we provided, flags the conflicts found when builting that index, and with human-intervention it can be resolved, before the query stage even begins. This is especially usefull against law documents which can be often found conflicting. For example, here in our schema, we introduced a field in the bilateral treaty: legalHierarchyStatus which can indicate whether the treaty overrides domestic laws or it is subject to domestic GAAR (General Anti-Avoidance Rule) override

How I Used Sanity:

This would be a technical section, making some repeat over the intuition behind the earlier section, but please bear with me:

How I Used Sanity

1. Modeling Structured Legal Relationships in the Content Lake

Instead of treating legal tax codes and treaties as unstructured markdown chunks or raw PDFs, I modeled them in the Sanity Content Lake using two custom schema types:

jurisdiction: Stores domestic tax rules, residency day-count thresholds (daysLimit), statutory comparison operators (greater_than), and tax year cycle boundaries (such as Spain's calendar year vs. India's fiscal year).
bilateralTreaty: Models international tax treaties as directed graph relationships between two signatory jurisdictions (signatoryA and signatoryB), specifying Article 15 exemption conditions, counting windows (e.g., rolling 12-month periods), and statutory hierarchy status (supersedes_domestic).

2. Pointing Sanity Context to Build the Knowledge Base

To compile the Knowledge Base, I pointed Sanity Context directly at the Content Lake dataset via a GROQ-scoped source.

During the compilation build:

Topic Synthesis & Entry Compilation: Sanity Context transformed the discrete relational documents into synthesized topic entries (such as residency/domestic_rules, dtaa/article_15, dtaa/treaty_inventory, and pe_risk).
Issue Detection & Standing Instructions: When compiling conflicting legal sources—specifically Spain's domestic territorial rule claiming Day-1 tax rights under IRNR Art. 13.1(c) versus bilateral treaty exemptions—Sanity Context surfaced a critical conflict in the Issues tab. I resolved this issue with a standing instruction: international bilateral treaties (DTAAs) supersede domestic statutory territorial taxes under Article 96 of the Spanish Constitution. This decision survived compiler rebuilds and permanently aligned all synthesized entries.

3. Exposing Tools via Sanity Context MCP

I configured a hosted Model Context Protocol (MCP) server endpoint in Sanity Manage operating in Knowledge Base mode, providing the AI agent in the Antigravity IDE with access to core retrieval tools:

initial_context: Called at the beginning of the arbitration session to inspect the Knowledge Base ID (kbMH6TgNzIIz) and discover the topic outline with its [core] path tags.
knowledge_base_search: Used to perform keyword-based exploration across compiled paths when mapping cross-border treaty provisions.
knowledge_base_read: Used to batch-read authoritative, fully cited entry paths (such as residency/domestic_rules, dtaa/article_15, and pe_risk) in a single network round-trip.

4. What the Agent Did With the Retrieved Content

When presented with the triangular case (an Indian resident employed by a German GmbH working remotely in Spain), the agent executed deterministic multi-jurisdiction arbitration:

Evaluated Domestic Residency: Read residency/domestic_rules to calculate that the employee's 128-day stay split across two calendar years (78 days in 2026, 50 days in 2027) did not breach Spain's $>183$-day statutory residency threshold under LIRPF Art. 9.1(a).
Resolved Treaty Supremacy: Read dtaa/article_15 and applied the standing instruction to override Spain's domestic Day-1 IRNR 24% withholding rule, granting a 100% personal income tax exemption under the India–Spain DTAA.
Attributed Corporate PE Risk: Rather than conflating the employee's personal tax status with corporate enterprise exposure, the agent traversed to pe_risk and evaluated the German employer under the Germany–Spain DTAA (Article 5). Because the employee engaged in on-the-ground commercial Statement of Work negotiations, the agent flagged a High Dependent Agent Permanent Establishment (DAPE) risk for the German GmbH.

Demo

Check out the demo at YouTube

Code

Check out the project on GitHub.

Sanity Project Details

Sanity Project ID: 1vdo75k2
Dataset: production (Public)
Public Content Lake Query URL: [https://1vdo75k2.api.sanity.io/v2026-09-18/data/query/production?query=*[_type%20in%20[%22jurisdiction%22,%20%22bilateralTreaty%22]]]

Thanks,
MT

SqlGo🌱 - Save CO2 by optimizing queries and removing redundant storage

Mohammad Tejabwala — Mon, 20 Apr 2026 04:59:29 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

The challenge was to built something that could celebrate our planet. And what better way to celebrate then try to save it!

Introducing SqlGo, an SQL auditor which connects to your SnowFlake account, finds the historic executions of your query and with the help of Gemini, provides useful suggestions to optimize your query, in turn reducing the computation power needed to run them, which in turn would reduce the CO2 emissions and water maintenance needed for these datacentres to run

It also finds "zombie" — unused or stale tables within your schema that have not been accessed over time, and haven't been used, saving the redundant storage space.

Key features:

Feature	Description
Secure Authentication	Connects to Snowflake using credentials from a JSON file, stored only in the user's session for enhanced security.
Sustainability Dashboard	A central, interactive dashboard displaying key metrics like annual CO2 saved, zombie tables found
High-Compute Query Auditing	Automatically identifies and lists the most resource-intensive queries from the past week for on-demand analysis.
Zombie Table Detection	Scans the database for tables that haven't been altered in over 30 days, helping to eliminate storage waste.
AI-Powered Optimization	Integrates with Google Gemini to provide expert suggestions for rewriting inefficient queries to be more "Green".
Gamified Savings	Features a rewarding animation and updates dashboard metrics when a user "Accepts" an optimization, encouraging eco-friendly practices.
Modern UI/UX	A fully responsive, dark-themed interface with animated loaders, sortable tables, and a clean design for an intuitive user experience.

Demo

Code

Mohammadtej / earthday-hackathon

earthday-hackathon

🚀 SqlGo – Key Features

SqlGo is designed to optimize database performance while promoting sustainability through intelligent insights and a modern user experience.

🔑 Features

Secure Authentication: Connects to Snowflake using credentials from a JSON file, stored only within the user's session to ensure enhanced security.
📊 Sustainability Dashboard: A centralized, interactive dashboard showcasing key metrics such as annual CO₂ savings, zombie tables identified, and compute efficiency.
⚡ High-Compute Query Auditing: Automatically detects and lists the most resource-intensive queries from the past week, enabling targeted performance improvements.
🧟 Zombie Table Detection: Identifies tables that have not been modified in over 30 days, helping reduce unnecessary storage usage.
🤖 AI-Powered Optimization: Integrates with Google Gemini to suggest optimized, more efficient ("greener") versions of SQL queries.
🎮 Gamified Savings: Encourages eco-friendly actions with interactive feedback—users receive visual rewards and updated metrics when they accept optimization…

View on GitHub

How I Built It

Tech stack used:

Framework: Django (Python)
Database Integration: Snowflake Connector for Python
AI Engine: Google Gemini API (gemini-2.5-flash)

Design decisions:

Ease of Use: It was decided to include the table statistics as well into the schema, so that the end user may get an overview of the data and the storage space used. Based on that and the usage, indexes may be created to further optimize key tables.
Query Traceability & Analysis: Sql ids were included in the report for the queries that are taking a significant time so that the end user may leverage other tools based on the underlying database to analyse the SQL based on the id.
Efficient Token Utilization: Rather than collecting all the SQLs taking significant time and passing it to the Gemini layer, it was better to leave it to the end user to select which SQL to chose, in turn reducing the tokens wasted in analysing all the queries.
Privacy-First Stateless Architecture: Taking the input via a JSON object for the database credentials, and only storing them in the session, so that confidential user data may not be misused.

Prize Categories

Best use of Google Gemini: Used the Gemini API as the main engine of the system to provide analysis based on the data gathered from Snowflake. Also, this application was developed by using Gemini Code Assist and chat. (Chat works better in remembering the overall context I feel)
Best use of Snowflake: Used a pre-existing high-data schema in Snowflake and executed some of the compute intense queries resembling real-life examples, not just poor code! Futhermore, the Snowflake agent Cortex code helped a lot in understanding the schema, and debugging some of the prompt queries used in this application. It even helped in establishing the connection from python to snowflake :)

Future Improvements

Instead of a JSON based input, we could provide an option to directly connect with a Snowflake account to get continuous monitoring and audit

Fun Fact: The entire frontend of the application was done using Gemini Code Assist