Chapter 2 — The People’s Model Operating System: Identity, Services, Case Files, Four Front Doors, Six Publishing Surfaces, and the Karnataka State Service Log

A resident of Karnataka is recognised by the state in fragments. There is one ID for the ration card, another for the property record, another for the…

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

---

The People’s Model

Manifesto v2026

Volume I — Core Architecture

Chapter 2

The People’s Model Operating System: Identity, Services, Case Files, Four Front Doors, Six Publishing Surfaces, and the Karnataka State Service Log

Where this chapter sits

Chapter 1 stated the problem and named the five non-negotiable commitments. This chapter is the detail of the first of those commitments: a single state operating spine. We describe the spine’s three architectural layers — the four citizen-facing front doors, the six purpose-built publishing surfaces, and the Karnataka State Service Log (KSSL) that ties them together — together with the five named functional subsystems (Identity & Consent, Service Registry, Citizen Case File, Open Ledger & Payments, the Grievance engine) that carry the day-to-day work. Chapters 3 (Mission Control runtime), 4 (Open Ledger and outcome budgeting in depth), and 6 (digital rights and the six statutory institutions) each take a piece of this spine and build it out further; this chapter establishes the shared vocabulary they all draw on.

2.1 Problem Snapshot

A resident of Karnataka is recognised by the state in fragments. There is one ID for the ration card, another for the property record, another for the driving licence, another for school admission, another for an OBC certificate, another for the Bengaluru city corporation property tax bill, another for the BESCOM electricity connection, another for the gas subsidy. Each system stores a separate name, a separate address, a separate date of birth. None of them knows what the other knows.

This fragmentation produces three harms, day after day:

• Residents spend their time proving they exist. Every new service requires the same identity proofs, the same address proofs, the same income certificates — re-collected, re-attested, re-uploaded.
• Officers spend their time verifying what should already be known. The energy of a competent officer goes into checking documents instead of making decisions.
• Corruption thrives in the gaps between systems. Wherever an officer holds a manual discretion to confirm or deny an identity, an income, or an entitlement, the cost of that discretion gets paid by the resident.

Even well-intentioned schemes fail because the state cannot see the whole picture. A child’s learning trajectory, a family’s health risk, a farmer’s crop loss, the delay status of a public project — none of these is visible end-to-end inside government, because no two systems share a common identifier, a common service definition, or a common ledger.

The state cannot be accountable for outcomes it cannot see. Before we ask government to deliver, we have to give government a way to know.

2.2 People’s Model Blueprint

The operating spine has three architectural layers. Four front doors are the interaction layer — one per audience, each open-source. Six publishing surfaces are the data layer — each purpose-built for one data class, governed by its sector authority. The Karnataka State Service Log (KSSL) is the integration layer — every inter-system call passes through it, every interaction is logged, every batch is cryptographically anchored. Five named functional subsystems sit inside these layers and carry the work residents and officers actually interact with: the Identity & Consent layer, the Service Registry, the Citizen Case File, Open Ledger & Payments, and the Grievance & Ombuds engine. None of these replaces existing department systems overnight; each connects to them through open APIs and a shared data standard, then absorbs their function over time.

The four front doors

Every state interaction reaches the citizen through one of four front doors, each tailored to its audience. JANATA is the citizen-facing app + web — residents’ single surface for every state interaction (services, applications, complaints, records, payments, notifications, consent management). Officer Console is the internal web surface for government officers — workflow, case files, escalations, performance dashboards. Business Portal is for companies and suppliers — tender filing, compliance reports, tax filing, scheme participation. Civil Society Interface is open APIs and bulk-download for journalists, researchers, and civil-society auditors — including independent verifier mode. All four front doors are open-source; anyone can audit the client code and civil-society organisations can run their own builds. The state ships official builds with hardware-attested signed releases.

The six publishing surfaces

Behind the front doors, state data is split into six purpose-built publishing surfaces, each governed by its sector authority with its own data model, access controls, and scaling characteristics. (1) Open Ledger — financial and contractual transparency: contracts, payments, milestone evidence, outcome-budget tagging, procurement under open contracting standards. The financial spine, public by default. (2) AI-Use Register — governance record of every state-operated AI system, public by default, immutable versioning. (3) Karnataka Open Data Portal — datasets and time-series: food-demand forecasts, environmental sensor streams, transit data, soil-test aggregates, geospatial visualisations. Public, with bulk download and API access. (4) Citizen Data Trust — personal records and per-citizen access logs (UMRS records, scheme entitlements, claims). Citizen-private by default; aggregates feed Open Ledger. (5) Karnataka Digital Twin raw store — geospatial point clouds, building footprints, utility geometries. Closed by default; access through the KDT Authority. (6) Sector operational systems — operational data per department. Operational; summaries flow to Open Ledger. De-identified historical content derived from citizen records is not a separate surface: it publishes through the Karnataka Open Data Portal under the published statistical-disclosure standard, with the Citizen Data Trust as its consent source.

Karnataka State Service Log (KSSL)

KSSL is the integrated state-coordination system that ties the front doors and the publishing surfaces together. It performs three functions in one architecture. Mediation — every inter-system data request between state services flows through KSSL with sender + receiver authenticated and citizen consent token attached for any personal-data flow; no system talks directly to another except via KSSL. Logging — every interaction is recorded in an append-only ledger with sender, receiver, citizen consent token, timestamp, purpose. Cryptographic anchoring — log entries are batched into a publicly verifiable append-only structure; periodic anchors are published using open-standard public-verification protocols, so any party can independently verify any record’s inclusion and ordering without trusting the state’s word. Successor governments cannot quietly rewrite history; tampering is mathematically detectable. KSSL is a statutory body governed by an independent board with civil-society + technical members; signing keys held in Hardware Security Modules; threshold cryptography ensures no single officer can sign sensitive operations alone.

The named functional subsystems

Across these three layers, five named subsystems carry the day-to-day work residents and officers interact with. Each sits inside specific surfaces and institutions — they are not a separate architectural layer.

Identity & Consent — a unified resident profile that interoperates with existing national IDs (Aadhaar, PAN, DigiLocker) and offers assisted, offline, and biometric-exception pathways. The state recognises the resident, verifies once, and reuses the verification across services — only with the resident’s consent, logged transaction by transaction through the Citizen Consent Ledger (Vol I Ch 6). The operating principle is minimum data, maximum service: a department gets only the fields it needs for the service in front of it, never the resident’s full profile by default. The Identity subsystem authenticates against KSSL; consent management lives in the Citizen Consent Ledger; personal identity records live in the Citizen Data Trust (Vol I Ch 6).

Service Registry — every government service is defined once in a canonical book: name, owning department, eligibility, required documents, fees, timeline, decision authority, escalation path, grievance route. A change to any of these requires a published amendment with effective-from date. The Service Registry is the source of truth that the citizen-facing JANATA front door, the assisted service centre, the Officer Console, and the workflow all read from — a resident cannot be told two different things about the same service by two different counters. Operationally the Registry lives in the sector operational systems publishing surface.

Citizen Case File — every service request, complaint, inspection, and benefit a resident interacts with attaches to a single case file, indexed by the resident’s Identity ID with consent. Where a life-event chain exists — birth registration → school enrolment → scholarship → skills programme → job-portal registration — the case file connects the chain so the state can act on it as a chain rather than as eight unrelated transactions. A resident sees their own case file in full through JANATA; a department sees only the cases relevant to its services through the Officer Console; access goes through KSSL with a Citizen Consent Ledger token; the records themselves live in the Citizen Data Trust.

Open Ledger & Payments — every rupee the state spends is tagged to a programme, a beneficiary or a project, and a measurable milestone. Payments are released against milestone evidence — geo-tagged photographs, signed inspection reports, third-party verification — and every release is published on the Open Ledger publishing surface in OCDS form within a defined publication window, anchored through KSSL so any party can independently verify the entry. This is the financial spine specifically; time-series outcome data lives on the Karnataka Open Data Portal, personal payment records under the Citizen Data Trust. Chapter 4 builds Open Ledger and outcome budgeting out in depth.

Grievance & Ombuds engine — grievances are tracked work items with owners, deadlines, escalation ladders, and statutory backing through the Grievance Justice Authority (Vol I Ch 6). Every grievance has a parallel workflow attached to the underlying Citizen Case File, so the resolution updates the case rather than living in a separate complaint silo. Operationally the engine lives in the sector operational systems publishing surface; statutory authority rests with the Grievance Justice Authority; case files of grievances sit in the Citizen Data Trust under the Citizen Consent Ledger.

Where the architecture is detailed in full

Vol I Ch 4 (KSSL cryptographic-anchoring rules), Vol I Ch 6 (Citizen Consent Ledger and oversight), Vol II Ch 15 (cybersecurity baseline + CSOC + post-quantum by default), Vol III Ch 22 (JANATA spec).

The dependency map

The three layers are not equally independent. The Identity & Consent subsystem and the Service Registry are foundational — without canonical resident identity and canonical service definitions, no front door has anything meaningful to show. The publishing surfaces depend on KSSL being live to anchor entries authentically. The Citizen Case File depends on Identity (to bind records to a resident) and on the Service Registry (so each case has a defined service to attach to). Open Ledger & Payments depends on the Service Registry (to tag entries to a programme), on Identity (to bind disbursements to a beneficiary), and on KSSL (to anchor financial entries). The Grievance engine depends on the Citizen Case File (so grievances attach to the underlying transaction). A reform programme that tries to publish Open Ledger entries before the Service Registry exists will fail — there is no canonical service definition for the ledger to tag against.

Chapter 3 is the runtime that makes these subsystems work together — Mission Control, the workflow engine, the SLA tracker, all reading from KSSL. Chapter 4 builds Open Ledger out in depth, including the financial-spine scope and the cryptographic anchoring rules. Chapter 6 builds the rights and institutions around personal data — the Citizen Data Trust, the AI-Use Register, the Grievance Justice Authority, the Citizen Consent Ledger, the Civil-society Independent Audit Board, and the Karnataka Cyber Security Operations Centre — and owns the operating rule that binds every system the state runs or contracts.

2.3 How it Works (Operational Flow)

The resident journey

A resident opens the People’s App or walks into any assisted-access point — a Gram Panchayat Service Centre, an urban ward kiosk, the existing taluk office, or — by the build-out phase (Vol I Ch 1 Sec. 1.6, Year 5) — a village digital centre within walking distance of every household. Sign-in uses the Identity layer with the resident’s choice of pathway — Aadhaar OTP, DigiLocker, biometric, or assisted verification by a trained operator for residents without smartphones. The Service Registry lists the available services in the resident’s language, with each service’s charter visible up front: what it gives, who is eligible, what it costs, how long it takes, who decides, what to do if it slips. The resident selects a service. Eligibility is auto-checked against fields the Identity layer is already authorised to share. The application generates a case-file entry. From that point the resident tracks the case from the same screen, end to end.

The officer workflow

The officer logs in and sees a task queue — not paper files. Each task carries the case file, the service definition from the Registry, the SLA clock, the supporting evidence, and a structured decision form. Verifications use machine-readable records — geo-tagged photographs, authenticated documents, third-party data feeds — not the “bring another letter” loop. Sensitive actions, such as changing the beneficiary bank account on a welfare disbursement, require multi-factor authentication and supervisor approval. The officer’s output is a decision with a written reason; the audit trail is created automatically.

The audit trail

Every action against a case file generates a log entry: actor, time, action, data fields accessed, reason. Log entries flow through the Karnataka State Service Log (KSSL, Sec. 2.2), which mediates every inter-system interaction, records it in an append-only ledger, and anchors batches into a publicly verifiable structure. Logs are immutable, queryable by the resident for their own case file through the Citizen Data Trust, and queryable by oversight bodies (Lokayukta, CAG, Grievance Justice Authority) under defined rules. The cryptographic anchoring means tampering with a log entry is mathematically detectable, even by a successor administration.

Four further properties complete the KSSL guarantee. Every completed transaction returns a signed receipt to the citizen — verifiable against the published anchor, so any resident can confirm that their own record exists and is untampered. Every periodic anchor is co-signed by independent witnesses — the State Audit Office, the Civil-society Independent Audit Board, accredited universities and civil-society verifier nodes — and the anchor hash is published in the Karnataka Gazette and the press, so the log cannot show different versions to different audiences and is verifiable without internet access. And if KSSL itself is ever unavailable, citizen services continue on locally signed queues that anchor on recovery — no resident is denied service because the logging layer is down. Signing keys rotate on a published schedule, with a pre-published compromise-recovery protocol.

Interoperability with existing systems

Karnataka already runs dozens of citizen-facing portals: Sakala, Seva Sindhu, Bhoomi, Kaveri, the Bengaluru civic and BESCOM portals, departmental ERP installations. The Model does not throw any of them away on day one. Each is connected to the spine through three building blocks: an Identity-layer adaptor, a Service Registry mapping, and an Open Ledger publisher. Existing portals continue to function during the migration, but every transaction on them creates a case-file entry and a ledger tag on the spine. Migration completes when the spine becomes the source of truth and the legacy portal becomes a thin client over it.

2.4 Finance & Accountability

The operating spine is a one-time capital build that produces recurring savings. The Model is explicit about both sides of the ledger and publishes both.

Cost categories

• Core platform — Identity adaptor, Service Registry, Case File, Open Ledger publisher, Grievance engine, Karnataka State Service Log (KSSL — cryptographic-anchoring layer, Hardware Security Module fleet, threshold-signing infrastructure), Karnataka Open Data Portal, AI-Use Register, Citizen Data Trust gateway, plus the cybersecurity and SRE function that runs them.
• Integration — adaptors into existing department systems and the legacy citizen portals, in priority order from the top 100 services down.
• Assisted access — service centres, call support, language-friendly help for residents without smartphones; the assisted layer is permanent, not transitional.
• Training and change management — the Project Delivery Cadre (Chapter 5) trains officers on the workflow; the resident-facing communications layer is funded separately under Vol II Ch 17 (Media).

Return on investment

The spine pays back through four channels, each measurable from data the Model itself publishes:

• Reduced duplication and rework. Officers stop re-verifying what the spine already knows; residents stop re-submitting documents already in their case file.
• Faster procurement and payments. Milestone-paid disbursement on the Open Ledger removes the “delay rent” that contractors and middlemen extract from slow approval chains.
• Reduced fraud. Data-linked verification — ledger entries reconciled against beneficiary records — closes the gaps that ghost-beneficiary fraud and inflated milestone claims exploit.
• Better targeting. The case file makes inclusion and exclusion errors visible at the resident level, so corrective programmes can act on real cases rather than on aggregate guesses.

The spine is funded as a capital programme over Foundations and Build-out, with operating costs absorbed into department budgets as services migrate. The full cost breakdown and the ROI model are published in Vol III Appendix D (Open Ledger Data Dictionary) and on the Open Ledger itself, so any resident, journalist, or auditor can check the numbers against actual spend.

2.5 KPIs & Public Dashboards

Six headline KPIs for the operating spine. Each is measurable from the spine’s own data — the spine is the instrument by which it is measured. Baselines reflect Karnataka 2025–26 where data exists; many of these KPIs do not have a state baseline today, which is itself the diagnosis.

• Service-charter SLA adherence on top 100 services — baseline: Sakala 2025–26 high breach; Year 1 dashboard live; Year 3 ≥80%; Year 5 ≥95%; Year 10 ≥99%.
• Open Ledger publication coverage (% of state contracts and payments above KTPP threshold published within window) — baseline: low / sample-based; Year 1 pilot live; Year 3 ≥50% of state spend; Year 5 100% statewide.
• KSSL anchoring coverage (% of inter-system calls between state services routed through KSSL and anchored) — baseline: 0%; Year 1 pilot anchoring live; Year 3 ≥50% of state systems; Year 5 ≥85%; Year 7 ≥99%.
• Citizen Consent Ledger coverage (% of personal-data flows under citizen-issued tokens) — baseline: 0%; Year 1 first personal-data flows live; Year 3 ≥50%; Year 5 ≥85%; Year 7 ≥99%.
• Grievance Justice Authority resolution within statutory SLA — baseline: high pendency; Year 3 median ≤ statutory SLA; Year 5 ≥95% closed within SLA.
• Citizen receipt-verification rate — baseline: 0%; Year 1 100% transactions return signed receipts; Year 5 ≥30% of citizens verified at least one; Year 10 ≥60%.
• Citizen Case File coverage (% of residents with an active case file linking eligibility, services availed, payments, grievances, and consent state) — baseline: 0%; Year 1 pilot districts live; Year 3 ≥70%; Year 5 100%.
• Service Registry currency (% of state services with an authoritative registry entry — owner, SLA, escalation, and evidence requirements current within the last 90 days) — baseline: low; Year 1 top-100 services live; Year 3 ≥90%; Year 5 100%.

Definitions, units, source datasets, and audit frequency are published in Vol III Appendix A. The Citizen Data Trust independently certifies the integrity of the dashboard data on a quarterly basis (Chapter 6).

2.6 Implementation Roadmap

Foundations — 0 to 100 days

• Publish the Service Registry definitions for the top 100 services, with every field — eligibility, documents, fees, timeline, decision authority, grievance route — locked and version-controlled.
• Launch a single sign-in plus case-number system across the spine, even before all back-end department systems are integrated; this gives residents an end-to-end tracker on day one.
• Stand up the Identity layer with Aadhaar / DigiLocker adaptors and assisted-verification pathway; consent logs live from the first transaction.
• Issue the spine’s data-protection design document for public review under the Citizen Data Trust (Chapter 6).

Foundations — Year 1

• Integrate the Open Ledger and Payments component end-to-end for welfare disbursement and capital-works contracts above the KTPP threshold.
• Bring the Grievance & Ombuds engine live across all top-100 services; integrate with Sakala / Seva Sindhu as the migration interim.
• Begin a managed migration of Sakala, Seva Sindhu, Bhoomi, Kaveri, the Bengaluru civic portals, and BESCOM citizen flows onto the spine, in priority order.
• Publish the document vault that lets residents store, share, and revoke documents through the Identity layer with consent.

Build-out — Years 2 to 5

• Migrate all citizen-facing services onto the spine; sunset legacy portals once parity is verified.
• Standardise data across departments to a common set of identifiers and reference codes; publish the Open Ledger Data Dictionary v2.0. Bring the Karnataka State Service Log (KSSL) online for the first cohort of state systems, with periodic cryptographic anchors published. Stand up the Karnataka Open Data Portal as a separate publishing surface for time-series and dataset content, distinct from the financial-spine Open Ledger.
• Build analytics-driven early warnings on the spine — disease outbreak, crop distress, project delay, fraud patterns — and route alerts into Mission Control (Chapter 3).
• Bring district-level assisted access to parity with the App so residents without smartphones experience the same SLAs.

Consolidation — Years 5 to 10

• A mature state OS: continuous improvement, paperwork reduced to defined exceptions, residents’ life events handled end-to-end.
• Citizen Data Trust governance fully binding on every system that connects to the spine.
• Karnataka’s spine published as a reference architecture for other states, under open licence.

2.7 Anti-capture Safeguards

The eight named safeguards from Chapter 1 apply to the spine. Four of them have specific spine-level rules that are worth stating explicitly, and one component (Identity & Consent) carries additional safeguards because of the harm it can do if captured.

Spine-level rules for the Chapter 1 safeguards

• Published workflow — every service’s workflow is the Service Registry entry; deviation requires a published amendment, not an officer’s discretion.
• Open Ledger publication — every spine financial transaction generates a ledger entry within the publication window; missed entries are themselves auditable events. The Karnataka State Service Log (KSSL) anchors every inter-system interaction into a publicly verifiable structure, so the integrity floor extends beyond the financial spine to every data flow across state services. Any party — civil society, journalist, oversight body — can independently verify that a record exists exactly as published and has not been altered.
• Milestone-only payment — the Payments component refuses to release funds without milestone evidence; exceptions are pre-disclosed categories with a cap, never one-off overrides.
• Citizen-rating triggered audit — ratings on a service category in a district are visible on Mission Control; the audit trigger fires automatically, the audit and its remedies are published.

Identity & Consent — additional safeguards

• Privacy by design — minimum data per transaction; field-level consent; consent is revocable; revocation propagates to downstream consumers.
• Independent security audit — the spine is audited annually by a third party named by the Citizen Data Trust, not chosen by the spine’s operators.
• Use-purpose binding — every data-access log entry records the purpose; access for a purpose other than the consented one is a chargeable offence under the Trust’s governance code.
• Breach disclosure — any incident affecting resident data is notified to the Data Protection Board within 72 hours of becoming aware of it, affected residents are informed without delay, and a public summary follows once notification is complete of containment, with the post-incident report published in full within 30 days.

The spine cannot be a tool of surveillance. Every safeguard above exists to make the spine work for residents’ accountability over the state, not the other way around.

2.8 Citations & Further Reading

Full bibliography for this chapter and the wider manifesto is in Vol III Appendix G (Research References).

Cross-references inside this manifesto

• Volume I — Chapter 1: the five non-negotiable commitments; the eight named anti-capture safeguards.
• Volume I — Chapter 3: Mission Control, workflow engine, SLA tracker — the runtime that operates the spine.
• Volume I — Chapter 4: Open Ledger, outcome budgeting, OCDS — Open Ledger & Payments in depth.
• Volume I — Chapter 6: digital rights, Citizen Data Trust, AI-use register, Grievance Justice Authority — the governance frame around the Identity & Consent and Grievance & Ombuds subsystems.
• Volume II — Chapter 15: Cybersecurity, DPI & Citizen Tech — the operational defence of the spine.
• Volume III — Appendix A (KPI Dictionary), Appendix D (Open Ledger Data Dictionary), Appendix H sheets H.022, H.035, H.054, H.070 (cross-cutting case-file references).

Component — Depends on — Provides

1. Identity & Consent — (foundational) — A trusted resident identifier and consent log used by 2, 3, 4, 5.

2. Service Registry — Component 1 for identity-bound entitlements — Canonical service definitions used by 3 (case file), 4 (ledger tags), 5 (grievance routing).

3. Citizen Case File — Components 1 and 2 — A consolidated record per resident; the unit of work for officers and the unit of view for residents.

4. Open Ledger & Payments — Components 1, 2, 3 — Outcome-tagged, milestone-paid spending; data feed for dashboards in every chapter that follows.

5. Grievance & Ombuds Engine — Components 1, 2, 3 — Tracked resolution workflow; parallel pathway with escalation, audit, statutory remedy.

---

← Chapter 1 — Why Government Must Change: From Schemes to Systems · Chapter 3 — The 24/7 Governance Engine: Mission Control, Workflows, and Reliable Delivery →

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].