Volume III — Implementation · The People's Model — Manifesto v2026

Chapter 22 — One State. One App. Total Access.

The architecture defined in Vol I Ch 2 makes JANATA explicit as one of four citizen-facing front doors into the state’s digital system: JANATA for…

Read this chapter in the interactive reader, or download the full 601-page manifesto (PDF).

The People’s Model

Manifesto v2026

Volume III — Implementation Handbook

Chapter 22

One State. One App. Total Access.

Citizen experience is policy. If it is not easy, it does not exist.

Where this chapter sits

Chapter 22 is the citizen-side surface of the operating spine. Vol I Ch 2 describes the spine — four front doors, six publishing surfaces, KSSL, and the five named functional subsystems; Chapter 22 describes what the resident actually sees and uses — the People’s App (JANATA) and the assisted-access network that backs it for residents without smartphones. The link to Vol I Ch 2 is stated crisply here, and the offline / low-connectivity design constraints are written in explicitly.

Architecture clarification — JANATA is one of four front doors

The architecture defined in Vol I Ch 2 makes JANATA explicit as one of four citizen-facing front doors into the state’s digital system: JANATA for residents, the Officer Console for state employees, the Business Portal for enterprises and traders, and the Civil Society Interface for journalists, researchers, and audit bodies. All four front doors talk to the same backend through the Karnataka State Service Log (KSSL) — meaning every interaction generated by JANATA is anchored to the same cryptographically verifiable floor that anchors every other state digital interaction.

JANATA scope and capabilities under the new architecture

JANATA is the citizen’s primary surface. It carries: the citizen’s case files across departments (read-only and write actions where the citizen has standing); the citizen’s view into their own Citizen Data Trust holdings; the citizen’s consent tokens via the Citizen Consent Ledger; grievance filing and tracking; payment and benefit status; calendar of upcoming service interactions (booked slots, license renewal windows, payment due dates); language-localised access in Kannada and the other major languages used in Karnataka; accessibility features for blind, deaf, and low-literacy users; voice-first paths for users without smartphone literacy.

Every transaction completed through JANATA returns a signed receipt stored in the citizen’s record — verifiable against the published anchor at any time, exportable, and usable as proof in any grievance or appeal. Receipts are offline-capable: SMS and voice fallbacks carry the same verifiable reference for residents without smartphones, and assisted-access counters print them.

Integration with sector flows — Agriculture booking example

The JANATA Agriculture integration (Vol II Ch 10) — predictive food demand sharing, farmer booking against demand windows, soil-test results, insurance claim status, state awards (Innovation / Quality / Yield Excellence) — runs through JANATA’s standard front-door pattern. The booking transaction passes through KSSL and is anchored. The farmer’s data is held in Citizen Data Trust under the farmer’s own consent tokens. Awards are published on the Karnataka Open Data Portal. Sector-specific operational state lives in the Department of Agriculture’s operational systems, which talk to the same KSSL.

JANATA does not become a catch-all

JANATA is the citizen’s front door. It is not the Open Ledger (which is a publishing surface for financial flows). It is not the AI-Use Register (which is a publishing surface for AI use). It is not the Citizen Data Trust (which is a storage layer). It is not KSSL (which is the mediation and logging layer). JANATA reads from and writes to these other components through standard interfaces, anchored to KSSL. Keeping these layers separate is what allows independent civil-society audit of each component on its own terms.

Officer Console, Business Portal, Civil Society Interface

The other three front doors carry parallel structure: the Officer Console is the state employee’s surface for the same case files and service registry, with role-based access governed by the Citizen Consent Ledger and audit through KSSL. The Business Portal is the enterprise / trader surface — tax filings, license applications, procurement responses, e-invoicing — also anchored through KSSL. The Civil Society Interface is the surface for journalists, researchers, and audit bodies to query the publishing surfaces under defined access patterns, with their own queries logged through KSSL for transparency about who is auditing what.

22.0 App architecture: People’s App vs Party App — the infrastructure-level Oath Boundary

Karnataka under The People’s Model operates two distinct apps, separated by binding architectural rule. The separation is the infrastructure-level expression of The Oath Boundary (Party Operating Principles addendum, P.6). Confusing the two — or letting one host the other’s functions — would silently undo the structural separation that the rest of this manifesto is built to preserve.

The People’s App (JANATA) — government infrastructure. Citizen-government interface. Hosts: service applications (income certificate, ration card, Bengaluru city corporation property tax, all 100+ Karnataka services on charter), case file tracking with L0→L4 escalation visualisation, Open Ledger view, service status dashboard, grievance filing, Service Charter views, public-interest civic data (Manifesto Delivery Dashboard, recall window countdown per representative — informational only). Party builds a prototype in the current cycle to demonstrate. When in government, the government builds the production version on government infrastructure. The party then retires its prototype. The People’s App never hosts party functions — no party membership signup, no party donations, no vote-back ballots, no party-internal voting.

The Party App — party infrastructure. Party-side functions only. Hosts: party membership signup, monthly dues collection (capped per-person), volunteer signup, candidate development pipeline view, the Candidate Accountability Agreement workflow, vote-back petition signing, vote-back ballot, party publications, party financial accounts published Open-Ledger-style, donation portal, internal party member voting. Party owns this forever. Status: to be built. Build sequence: cycle 2026-2027, so the Candidate Accountability Agreement clause Sec. C is operationally backed by a system that exists before it is first needed.

The two apps must not share codebase, must not share servers, must not share authentication backends, must not present a single sign-on across the boundary. A citizen who is also a party member operates two separate identities — their citizen identity on the People’s App and their party-member identity on the Party App. Whether to be a party member is the citizen’s choice; whether to use the People’s App is also their choice (physical / assisted-centre fallback is always available). Linking the two would mean party membership becomes traceable through government infrastructure — which would violate Vol I Ch 6 (Citizen Data Trust) and the founding principle from Vol 0c MethodNote (’The founding principle’).

Physical-side equivalents. Every function on both apps has a physical equivalent. People’s App functions are available at Public Service Centres (Vol I Ch 2 — Service Registry subsystem). Party App functions — including the vote-back ballot — are available at physical booths set up by the party at locations published in advance. Density of physical booths is an operational decision by the relevant party body based on constituency size, petition volume, and budget; not committed in advance by this manifesto.

22.0a JANATA Role-Based Unified Surface — every citizen sees the part of government that’s about them

JANATA is not one app with one view for everyone. It is a single login that adapts to the roles a citizen actually holds. A farmer opens JANATA and sees their land record, soil-test history, crop calendar, MSP entitlements, tractor-loan status, and nearest mandi price. A student opens JANATA and sees their attendance record, exam timetable, scholarship status, and their school’s transparency dashboard. A patient opens JANATA and sees their hospital visits, prescription history, next vaccination due, and the staff roster at their nearest PHC. Every citizen holds multiple roles — farmer-and-parent, patient-and-pensioner, student-and-jobseeker — and JANATA stacks role-cards for all of them on one home screen.

Multi-role detection. A single citizen typically holds three to seven government-recognised roles at any time. JANATA detects roles from the operating spine (Vol I Ch 2) — land records mark you as a landholder, school enrolment marks you as a parent, hospital visits mark you as a patient, ration-card status marks you as a beneficiary — and lets you confirm or decline each role-card. Adding or removing roles is one tap. Roles update automatically as life changes: a 12th-grade student becomes a college applicant, then a job-seeker, then an employee, then a parent, then a senior citizen.

Track and act in every role. Each role-card surfaces three things: what the government already knows about you in that role (your records), what you can do in that role right now (apply, file, submit, register, complain), and what the process is (a plain-language explainer for every step). Action capability is not gated behind separate sector portals — every published Service Charter is reachable through the role-card it belongs to. The 25-service launch set covers the most common actions across roles; subsequent phases extend to every Service Charter on the spine.

Process knowledge as first-class content. Every role-card includes a ’How this works’ tab — what the rule is, what evidence is required, who handles it, how long it takes, what the escalation ladder looks like (L0–L4 per Vol I Sec. 3.3), and what the appeal path is. Process knowledge is not buried in a separate help section; it lives inside the role context, where it’s needed.

Phase 1 anchor roles, then full sector coverage. Three sector role-families anchor the v1 launch because they cover the highest-volume citizen interactions: Education (Student / Parent / Teacher), Health (Patient / Caregiver / Health-worker), Agriculture (Farmer / Farm-worker / Self-Help-Group member). Other sectors — Cities (Resident / Property-owner / Commuter), Justice (Complainant / Witness / Accused), Welfare & Pensions (Beneficiary / Pensioner), Jobs (Job-seeker / Apprentice / Employer), Environment (Resident / Reporter), Inclusion (SC/ST/OBC entitlement-holder, PwD, women-headed-household) — extend the same pattern in published phases. The architecture is sector-agnostic from day one; only the role library expands.

22.1 Problem Snapshot

When services are scattered across portals and offices, residents lose time, dignity, and money — and corruption thrives in the gaps. No resident should need contacts, bribes, or repeated visits to get what the law already promises them. If access is not simple, the service effectively does not exist.

If access is not simple, the service effectively does not exist.

22.2 People’s Model Blueprint

Karnataka delivers a single citizen-facing platform — the People’s App (JANATA) — that unifies services, documents, payments, grievances, and public dashboards on the operating spine. Every request is a trackable task with an SLA, an evidence trail, and accountability at the right level (ward, taluk, district, state).

Design commitments

22.3 How it Works

Service phases

The App rolls out in published phases. The first phase covers the top 25 high-volume services and the top 25 grievance categories. Each subsequent phase adds services in priority order. Every service that launches on the App has a published Service Charter (Vol I Sec. 3.3) and is bound to the Standard Escalation Ladder (Vol I Sec. 3.3).

Service mechanics

Each service has a standard form, eligibility rules, a clear timeline, and named evidence requirements. The back-end workflow routes tasks to the right officer, auto-escalates breaches, and publishes performance metrics. Personal data is protected through consent and access-logging (Vol I Ch 6).

Assisted access in practice

Every Gram Panchayat hosts a Panchayat Service Centre with a trained operator. Every ward in a tier-1 or tier-2 city hosts a ward-level assisted-access kiosk. Operators are accountable through the same workflow engine — operator actions create an audit trail just like any officer action. The assisted layer is funded as a permanent capability, not as a digital-bridging interim.

Offline-and-low-connectivity design

The App caches forms and case status locally. A resident in a low-network area can complete a form, queue it, and sync when network returns. Status updates from government back to the resident also queue and sync, so a resident with intermittent connectivity is not penalised on the SLA clock. Kiosk operators have a similar offline-tolerant version of the same workflow.

22.4 Safeguards

Architectural anti-capture safeguards. Every JANATA transaction returns a signed receipt anchored through KSSL — citizens can independently verify their own record. The four-front-doors design (JANATA + Officer Console + Business Portal + Civil Society Interface) is open-source with reproducible builds and hardware-attested signed releases — civil-society can run their own builds and verifier nodes. The Citizen Consent Ledger governs every personal-data flow; CSOC monitors the front-door stacks with compel-patching authority. KSSL degraded-mode guarantees that JANATA continues to serve citizens even if the anchoring layer is temporarily down — no resident denied service because logging is unavailable.

22.5 Implementation Roadmap (Narrative)

Foundations (0–100 days, Year 1)

Build-out (Years 2–5)

Consolidation (Years 5–10)

Learner role-card and KPB integration. Per Vol II Ch 7 Sec. 7.4.4, every JANATA citizen has a Learner role-card — automatic, not opt-in — that surfaces personalised Karnataka Public Broadcaster (KPB) content recommendations, the local Learning State events calendar, optional self-tracked learning progress, and skill-credential records for state-recognised programmes. The Learner role-card is one of the v1 launch roles per Sec. 22.0a. KPB content is also distributed natively on JANATA so any citizen can watch educational programmes through the app, with closed-captions in Kannada and English at minimum.

22.6 Finance & Accountability

JANATA — the citizen-facing People’s App — is the single largest digital-delivery investment in the manifesto. Total capital outlay across the first five years is projected at ₹2,800–3,400 crore, of which roughly 35 percent funds platform engineering and the role-card surface library, 25 percent funds the integration library against KSSL and the operating spine, 15 percent funds the Assisted-Access Centre Network kiosk infrastructure (the JANATA presence inside Vol II Ch 16 Centres), 15 percent funds the offline-mode caching and resilience layer for low-connectivity Karnataka, and the remaining 10 percent funds the in-app language and accessibility surfaces. The Year 5 annual operating cost is projected at ₹500–650 crore inclusive of maintenance, content updates, security operations, and the development cadre.

The structural fiscal case is compounding. Every citizen interaction that moves from a taluk-office visit to a JANATA self-service or assisted-access submission saves the resident an average of half a day’s wage and the state an average of one hour of officer time per interaction. At a steady-state interaction volume of roughly 240 crore interactions per year by Year 5, the avoided-cost economy across citizen time and officer time is in the range of ₹45,000–55,000 crore per year — many multiples of the platform’s own operating cost. The platform pays for itself within the first eighteen months of statewide steady-state.

22.7 KPIs & Public Dashboards

Six headline KPIs for the One-State-One-App architecture, each measurable from JANATA platform telemetry, the Assisted-Access Centre Network operations records, and the Karnataka State Service Log anchoring pipeline. Each KPI’s definition, unit, source dataset, and audit frequency is published in Vol III Appendix A.

JANATA service-completion rate (% of services started that complete within published Service Charter SLA) — baseline: (new); Year 3 ≥85%; Year 5 ≥95%. Assisted-Access Centre walk-in coverage (% of Karnataka residents within 5 km of an active Centre) — baseline: variable; Year 3 ≥90%; Year 5 100%. JANATA offline-mode service availability (% of priority-service categories functional in cached offline mode) — baseline: 0; Year 3 ≥60%; Year 5 ≥90%. Language coverage on JANATA (% of services available in all four major regional languages of Karnataka) — baseline: variable; Year 3 ≥80%; Year 5 100%. Citizen receipt verifiability rate (% of JANATA transactions returning a KSSL-anchor inclusion proof) — baseline: 0; Year 1 100%; Year 5 sustained 100%. Manifesto Delivery Dashboard interaction rate (median citizen-initiated checks on manifesto commitments per quarter) — baseline: (new); Year 5 published baseline + trajectory.

22.8 Governance, Audit, and Cryptographic Floor

Every transaction JANATA mediates — service application, Centre walk-in record, role-card data access, consent token issuance, citizen receipt — is anchored on the Karnataka State Service Log (KSSL). The platform’s architectural commitment is recursive: the surface that citizens use to verify state actions has its own actions verified at the same standard. Citizen receipts carry inclusion proofs against the published KSSL anchor; a resident can verify on their own device, or through any independent verifier, that their interaction is in the record and untampered.

The Civil-society Independent Audit Board runs annual audits on three programmes under this chapter: (1) JANATA platform service-completion rate against published Service Charters, (2) Assisted-Access Centre operational quality and language coverage, and (3) Citizen receipt verifiability and anchor publication cadence. The platform code is open-source under the Karnataka State Digital Infrastructure Act; civil-society organisations, academic researchers, and citizen-science groups can independently inspect, audit, fork, and reproduce the deployment. Audit Board funding is ring-fenced from departmental control; findings publish independently of executive review.

The Karnataka Citizen Data Trust governs every role-card data flow, every consent token issuance, and every Assisted-Access Centre walk-in record. Consent is purpose-bound, time-bound, and revocable through the in-app consent surface or at any Centre. The Cybersecurity Operations Centre (CSOC) monitors the JANATA platform infrastructure with compel-patching authority and operates the bug-bounty programme that hardens the platform continuously. Verifier-node operators (Vol I Ch 2) can independently re-derive KSSL anchors for JANATA transactions, audit dataset publication on the Karnataka Open Data Portal, and verify citizen receipts at scale, giving press, journalists, civil-society organisations, and citizen-science groups the structural ability to detect retroactive platform-level tampering or selective non-publication.

22.9 Citations & Further Reading

← Chapter 21 — Constitutional Literacy & Civic Participation · Chapter 23 — Conclusion: A Government That Delivers →

This is a chapter of The People's Model manifesto for Karnataka — published in full for public review. Every claim may be challenged: write to [email protected].