How it works

How Nagarik Niti fits together.

Five views of the same platform: a bill's journey and what gets recorded along the way, how a bill's version history accumulates, the technical architecture underneath, a picture of who talks to whom, and how a bill summary actually gets drafted.

A bill's journey, and what gets recorded

As a bill moves from introduction through committee, passage, and gazetting, Nagarik Niti layers on accessible, validator-checked AI summaries and a way for citizens and stakeholders to read, respond, and submit input at each stage. Every step leaves a record: the bill text version, the summary and its history, timestamped citizen submissions, and linked stakeholder input, so nothing is silently overwritten.

Timeline diagram from T1 to T2: a bill's Life Cycle (Introduce, Committee, Passed, Gazetted) feeds into Nagarik Niti's Accessible Validated AI Summaries (Plain-language summary evolving into Final summary + full version history) and then Citizens Inputs & Participation (Read Summary, Submit Input, Citizen Report, plus CSO/Stakeholder recommendations shown as linked and attributed, not hosted). A parallel Nagarik Niti Records column shows what's kept at each stage: version of the bill's text, summary published with history, citizen submissions timestamped, and stakeholder inputs linked.

Technical architecture

Citizens reach a frontend component (bill tracking & search, policy summaries, structured input, citizen reports) over the internet, backed by a backend component holding the database and the engines behind each module (Policy Tracker, Summary Engine, Legal Reference Mapping, Structured Input Aggregation, Roles Management, the AI provider interface, and the validator/editorial and manual-checker consoles staff and validators use). An ingestion component pulls bill text, status, and notices from federal government sources on a schedule.

Architecture diagram: Citizens, CSOs and Journalists, and Staff/Validators, reach the Nagarik Niti Frontend Component (Bill Tracking & Search, Policy Summaries, Structured Input Form, Citizen Reports) over the internet. It sits above a Backend Component containing the Database, Policy Tracker Engine, Summary Engine, Legal Reference Mapping, Manual Checker Console, Structured Input Aggregation, Roles Management, AI Provider Interface, and Validator & Editorial Console. An Ingestion Component (auto/manual + scheduled check) pulls from Federal Gov Sources (registries, Gazette, MoLJPA).

Who talks to whom

Civic actors (citizens, advocates, journalists) read from and submit to Nagarik Niti, which is bilingual, AI-assisted, and both verified and versioned. On the other side, federal government sources (the House of Representatives and National Assembly registries, the Nepal Gazette, and the MoLJPA comment portal) are tracked on a schedule for bill text and status. Citizen report data flows to committees and ministries, the recipients responsible for acting on it. Provincial and local government sources aren't connected yet.

Diagram showing Civic Actors (Citizens, Advocates, Journalists) reading from and submitting to Nagarik Niti (bilingual, AI-assisted, verified and versioned), which does scheduled tracking of bill text and status from Federal Gov. Sources (HR Parliamentary Registry, National Assembly Registry, Nepal Gazette, MoLJPA Comment Portal), and sends citizen report data to Recipients (Committees, Ministries). Provincial and Local Governments are shown as future, not yet connected.

How a bill summary gets drafted

A closer look at the Summary Engine's AI-assisted route: the raw source document is cleaned and chunked, built into a prompt alongside any previous draft, sent to the AI model, then validated before it's stored as a draft awaiting human sign-off. This is an early design sketch of the pipeline, not a finished implementation.

Pipeline diagram: Source Document (raw) flows through Text Extraction and Cleaning, Structure-Aware Chunking, and Prompt Construction (optionally including the previous Summary Draft), into a single LLM API Call. The raw JSON response is Schema-Validated and Parsed, retried once on failure or flagged for manual authoring if still invalid, then Stored as a Summary Draft tagged with route, model, and timestamp.

How a bill's history accumulates

A bill isn't static text. It moves along a single trunk: drafted and introduced, reviewed by committee, passed by the house it originated in, then passed by the second house, and finally gazetted into law, with each stage kept permanently rather than overwritten. If the second house sends it back with amendments, it loops back to committee for another round rather than skipping straight to a vote. Floor arguments, the debate and individual proposals raised during a vote, aren't part of this model yet. They're flagged here as an open question, not wired into the record.

State diagram showing Nepal's Laws as they stand today: Bill Introduced (drafted to registered) leads to Committee review, then Passing originating house, then Passed second house, then Gazetted (Act record created), after which Nepal's Law is now updated. An arrow labeled 'if returned with amendments' loops from Passed second house back to Committee review. A separate, disconnected Floor Arguments box is shown with no connections, flagging it as not yet modeled.

What's live today: every version of a bill's text is kept on the record as it moves through introduced, committee, passing the originating house, passing the second house, and gazetted, including the loop back to committee if the second house returns it with amendments. What's not built yet: tracking floor arguments and individual MP proposals as part of that record.