← All Products/In Active DevelopmentSimulated Backends

One record for every citizen,
shared with consent — not copied.

Setu is a consent-based interoperability gateway designed to connect siloed digital platforms behind a single citizen login, eliminating the repetitive cycle of manual uploads and re-verification.

Origins & HeritageProblem Statement SIH 26129

Setu originated as a project for the Smart India Hackathon addressing "System Integration and Interoperability Among Government Digital Platforms". Prince Naruka is continuing its architectural and engineering development under Naruka AI Labs as an independent product research effort. It is not an official government service and is not affiliated with any public department.

GATEWAY INTERACTION TOPOLOGYSynthetic Test Environment
CITIZENConsent LoginSETUINTEROP GATEWAYRelay & Token AuditMOCK TAX RECORDSSynthetic PAN RefsMOCK IDENTITY REG.Synthetic NIR TokensMOCK LICENCE PORTALSynthetic Verification
THE PROBLEM

Fragmented Departmental Silos

In modern administrative workflows, citizens interact with dozens of independent departmental portals. Each agency operates its own database, verification team, and identity storage.

  • Repetitive uploads: Citizens must download tax, identity, or registration proofs from one portal and re-upload them to another.
  • Security risks: PDF copies are stored across multiple third-party servers, increasing the risk of data leaks and outdated documentation.
  • Verification delays: Every department independently checks authenticity, causing redundant queues and weeks of friction.
THE SOLUTION

Consent-Driven Gateway Relay

Setu replaces redundant document copying with an audited, tokenized gateway relay. Verified records are retrieved directly from the issuing authority only when explicit citizen consent is granted.

  • One citizen login: A single entry point allows the citizen to inspect which departments have verified their documents.
  • Direct department-to-department verification: The gateway requests data over authenticated HTTP contracts, logging every relay.
  • Zero duplicate file storage: Data is relayed on demand rather than permanently duplicated across multiple departmental silos.
Technical Deep Dive

Verified Architecture & Engineering

The Setu codebase is structured around a central orchestration layer, isolated mock departmental microservices, and a grounded conversational assistant.

1. Gateway Orchestration Layer

A Node.js Express service backed by PostgreSQL that manages citizen authentication, session tokens, and department dispatching.

Node.js ExpressPostgreSQLTokenized RelaysAudit Trail
  • Individual HTTP contracts per department client.
  • Graceful degradation: if a department service is unreachable, an explicit error is returned without hanging other lookups.
  • Transaction logs record timestamp, status, and department response.

2. Simulated Department Backends

Three standalone mock microservices running in isolated environments to test real outbound HTTP integration without contacting government servers.

FastAPI (Python)SQLiteSynthetic IdentifiersHeader Auth (X-Gateway-Key)
  • Mock Tax Records: Accepts synthetic identifiers (e.g., SYNPAN-000123) and rejects real PAN formats.
  • Mock Identity Registry: Simulates identity verification lookups with test payloads.
  • Mock Driving Licence Portal: Validates simulated registration records.

3. Grounded Service Assistant

A server-side AI proxy service implementing POST /api/v1/chat to assist visitors with understanding public service procedures.

Gemini API IntegrationServer-side Key IsolationGrounded System PromptsTyped Error Handling
  • API keys are secured exclusively on the gateway server — never exposed in browser bundles.
  • Strict system prompts guard against hallucinating nonexistent public welfare policies.
  • Handles upstream 429 rate limits, validation errors, and network timeouts safely.
Current Stage: Prototype Refinement

Current Development Status

Setu is currently undergoing refactoring into a modular architecture. Core gateway dispatch logic, schema migration tests, and mock client contracts are functional locally. Future exploratory work is planned around formalizing the consent token lifecycle and investigating verifiable audit logging.