Volume I — Core Architecture · The People's Model — Manifesto v2026

Chapter 3 — The 24/7 Governance Engine: Mission Control, Workflows, and Reliable Delivery

The Karnataka state machinery is structurally reactive. Potholes are filled after road accidents. Hospitals respond after outbreaks spread. Water…

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 3

The 24/7 Governance Engine: Mission Control, Workflows, and Reliable Delivery

Where this chapter sits

Chapter 1 stated the problem and the five non-negotiable commitments. Chapter 2 described the operating spine — four citizen-facing front doors, six purpose-built publishing surfaces, the Karnataka State Service Log (KSSL), and the five named functional subsystems that sit inside them. This chapter is the runtime that makes the spine work — the rooms it runs from, the workflows it executes, the SLAs it enforces, and the escalation pathway that fires automatically when a deadline slips. We also introduce two artefacts that recur in every chapter of the manifesto from this point on: the Service Charter format, and the Standard Escalation Ladder.

3.1 Problem Snapshot

The Karnataka state machinery is structurally reactive. Potholes are filled after road accidents. Hospitals respond after outbreaks spread. Water shortages are addressed after borewells fail. Procurement frauds are detected after the money has left the treasury. Project delays are reported after the year-end audit, by which time the contractor is already paid and the asset is already late.

This reactive posture is not a question of individual officer competence. It is a function of how the working day is organised. Departments have no shared view of what is going wrong right now. There is no continuous sensing layer over the state’s services, no single room where incidents are tracked across departments, no automatic escalation when an SLA is breached. By the time a problem reaches a decision-maker, it has already become a failure.

A modern state needs a continuous governance engine — sense, decide, act, verify, learn — running every hour of every day, not only at budget time and not only when a crisis breaks. Karnataka does not have one today. The People’s Model builds one.

Reliability is not a posture. It is a runtime.

3.2 People’s Model Blueprint

The 24/7 Governance Engine has four parts. They share data and identifiers through the operating spine (Chapter 2), and they run continuously rather than on a budget-cycle clock.

Part 1 — Mission Control Rooms

A State Mission Control Room sits in the Chief Secretary’s office. A District Mission Control Room sits in each district headquarters. Both run live dashboards for the outcomes that matter most: SLA compliance across the top services, public-works project status, health and safety alerts, financial flows on the Open Ledger, and security incidents on the spine. The rooms are not viewing galleries — they are decision rooms. The State Room convenes a daily 15-minute standup of department heads on red items; District Rooms convene the same standup at district level.

The runtime inherits KSSL’s availability rule: if the anchoring layer is unavailable, Mission Control and the workflow engine continue on locally signed queues that synchronise and anchor on recovery, and every such window is itself logged and published. A citizen is never denied service because the spine’s logging layer is down.

Part 2 — Workflow-driven Operations

Every service, complaint, inspection, project milestone and grievance is a ticket in the workflow engine that sits on top of the operating spine. Each ticket has an owner role, an SLA clock, the supporting evidence, and a Standard Escalation Ladder (see Sec. 3.3). Officers do not manage files; they work tickets, and the system makes the queue visible so the most SLA-risky tickets surface first.

Part 3 — Evidence-based Payments

Project and supplier payments are released only on milestone evidence: geo-tagged photographs, signed measurement books, third-party verification where applicable. No advance against unmet milestones except in pre-disclosed categories with a cap. Payment release is itself a ticket — the disbursing officer’s decision generates an Open Ledger entry that any resident, journalist, or auditor can inspect within the publication window.

Part 4 — Continuous Improvement

Teams are measured on outcomes — SLA adherence, audit-sample decision quality, citizen rating — not on file movement. When a failure repeats, the workflow itself is redesigned: the Service Registry entry is amended (with a public effective-from date), the escalation thresholds are revisited, and the change is recorded as a post-incident learning. The engine learns; it does not blame.

Universal access numbers

Two standard numbers are operative across the state, integrated with the spine and the workflow engine:

Examples of 111-routed service categories: legal aid and non-emergency police complaints; education support — admissions guidance, scholarship enquiries, school issues; health navigation — referrals, medicine-availability grievances; pensions and welfare — eligibility checks, enrolment, status; land and local services — mutation guidance, encroachment complaints, civic issues such as potholes and streetlights.

Architecture integration — Mission Control, workflows, and the cryptographic floor

The 24/7 Governance Engine sits on top of the operating spine described in Chapter 2. Three structural updates from the operating architecture carry through this chapter: Mission Control Rooms read directly from the Karnataka State Service Log (KSSL); workflow tickets and decisions are anchored through KSSL; evidence-based payments are signed and anchored before they are executed.

Mission Control reads from KSSL

The State Mission Control Room and District Mission Control Rooms surface their dashboards from a single source: KSSL. Every workflow ticket, every grievance, every payment instruction, every AI decision, every sensor reading is anchored through KSSL into a publicly verifiable append-only structure. Mission Control sees the live stream; oversight bodies see the same stream through the Civil Society Interface; the resident sees their own slice through JANATA. Three views, one cryptographically anchored ground truth. Alerts from the Karnataka Cyber Security Operations Centre (CSOC, Vol II Ch 15) and revocations from the Citizen Consent Ledger (Vol I Ch 6) feed the same dashboards — a Mission Control Room sees, in real time, when an officer’s access is revoked or a system is isolated for non-compliance.

Workflow tickets are KSSL entries

Every ticket in the workflow engine — service request, complaint, inspection, project milestone, grievance — generates a log entry through KSSL: actor, time, action, data fields accessed, reason. The ticket’s full lifecycle (creation, hand-off, decision, closure, appeal) is reconstructible from KSSL entries alone. This means a misbehaving officer cannot quietly delete or backdate a ticket; the cryptographic anchoring makes tampering mathematically detectable. It also means the resident’s right to know about every action against their case file (Vol I Ch 6) is mechanically enforced — the audit query runs against KSSL, not against the operating department’s database.

Evidence-based payments are anchored before execution

Under this architecture, no payment instruction leaves the state without being signed by a defined quorum and anchored through KSSL. For payments above defined thresholds, threshold cryptography requires a multi-key quorum rather than a single administrator’s signature (Vol II Ch 15). The payment instruction, the evidence it cites, the approver identities, and the timestamp are all anchored. The Open Ledger then publishes the financial event in its monthly cycle, anchored to the same KSSL log. The result is a payment chain where every link is cryptographically provable to any independent observer.

AI assistance under the AI-Use Register

Where AI assists Mission Control or workflow decisions, the AI’s role is registered on the AI-Use Register (Vol I Ch 6). Every AI-assisted decision generates a KSSL entry recording the model used, the inputs, the recommendation, and whether the human decision-maker followed or overrode it. This is the operational backbone of the AI-Use Register — without KSSL anchoring, the Register would be a declaration; with it, the Register is verifiable.

Sector operational systems remain the operating record

Mission Control and the workflow engine do not replace sector operational systems — they sit above them. The health system’s UMRS (Vol II Ch 8), the city system’s traffic and infrastructure layer (Vol II Ch 9), the agriculture system’s KAIA (Vol II Ch 10), the education system’s Learning State (Vol II Ch 7) all remain the operating record for their domain. KSSL is the inter-system layer — every call from Mission Control into a sector system, every call between sector systems, every read by JANATA into a citizen’s case file across systems goes through KSSL and is anchored.

3.3 How it Works (Operational Flow)

The Service Charter — the format

Every service the state delivers has a Service Charter published in the Service Registry. The charter is the binding promise the state makes to a resident about that service. The format is identical across all services so a resident can read any charter and know what to expect.

The Standard Escalation Ladder

Every SLA breach triggers escalation automatically — not on the resident’s request. The Ladder is identical across services so officers and residents both understand it without learning a new pattern.

L0 through L3 are case-level escalations; L4 is a structural escalation that fires when the engine detects a pattern across cases — a particular taluk where a particular service consistently slips, an officer whose adverse-decision rate is statistically anomalous, a contractor whose milestone disputes cluster. The thresholds for L4 are published in Vol III Appendix A.

The daily operational rhythm

The project cycle

Public projects move on a six-step cycle, with each step a workflow stage: Plan → Budget → Tender → Execute → Inspect → Pay → Maintain. Maintenance is a first-class step, not an afterthought; every asset created in Execute is registered into a maintenance schedule before Pay can complete. Failure of the Maintain step is itself a workflow ticket.

Grievance integration

Resident complaints filed through 111, the People’s App, or assisted service centres feed directly into operational queues against the underlying case file. Repeated complaints on the same service category in the same area auto-trigger an L4 structural audit; the audit and its remedies are published.

3.4 Finance & Accountability

A 24/7 governance engine costs money to run. It pays for itself by preventing more expensive failures and by reducing the cost of every transaction it touches.

Cost categories

Return on investment

Budgeting rules

3.5 KPIs & Public Dashboards

Six headline KPIs for the engine. Each is measurable directly from the workflow engine itself; the engine is the instrument by which it is measured.

3.6 Implementation Roadmap

Foundations — 0 to 100 days

Mission Control reads its live ground-truth from the Karnataka State Service Log (KSSL) — every workflow ticket, payment instruction, AI decision is anchored to a publicly verifiable structure from the pilot stage.

Officer Console launched as one of the four front doors — every officer login generates a KSSL entry; performance dashboards trace back to anchored evidence, not officer self-reports.

Foundations — Year 1

AI-assisted decision support inside Mission Control registered on the AI-Use Register; every recommendation generates a KSSL entry capturing whether the officer followed or overrode it.

Threshold cryptography enforced for any operation that touches more than 1 lakh case files at once — bulk reassignments and mass closures require multi-signer quorum.

Build-out — Years 2 to 5

Every payment instruction issued through evidence-based release is signed by the threshold-cryptography quorum and anchored on KSSL before execution — no payment leaves the state without a cryptographically provable trail.

AI assistance across the workflow engine fully audited annually by the Civil-society Independent Audit Board.

Consolidation — Years 5 to 10

3.7 Anti-capture Safeguards

The eight named safeguards from Chapter 1 apply to the engine. Three of them have specific engine-level rules; three additional engine-specific safeguards apply because of the kinds of decisions the engine concentrates.

Engine-level rules for the Chapter 1 safeguards

Engine-specific safeguards

Every exception to any of the above is itself a workflow event with a written reason that the resident, the auditor, and the oversight body can inspect.

Cryptographic anti-capture floor. Every Mission Control event, every workflow decision, every payment release is anchored through KSSL into a publicly verifiable append-only structure — a successor administration cannot quietly delete the record of a slow-walked grievance or a back-dated payment authorisation. Independent verifier nodes operated by civil-society organisations re-check the anchors and would notice tampering immediately.

Vendor capture in the engine itself. The Karnataka Cyber Security Operations Centre (CSOC, statutory) holds compel-patching authority across the engine’s stack; vendor diversity is mandatory for the critical components; open-source mandate keeps the engine inspectable. No single vendor can lock the state into a black box.

Quorum-protected sensitive operations. Bulk case-file actions, AI model retraining for assistance, mass closures or escalations all require a threshold-cryptography quorum — no single officer, however senior, can act alone on operations that affect tens of thousands of residents.

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

Charter field — What it states

Name — Plain-language name of the service.

Owning department & officer role — Which department delivers it; which officer role decides.

Eligibility — Who can apply. Conditions, exclusions, supporting documents required.

Documents — The exact list, with the format and source of each.

Fees — The exact statutory fee. Zero is also a fee.

Timeline (SLA) — Number of working days from a complete submission to the decision.

Decision authority & evidence — Who decides, on what evidence, with what reasons.

Escalation pathway — The Standard Escalation Ladder (see below) bound to specific role-holders.

Grievance route — How to challenge an adverse decision, on what timeline, with what statutory remedy.

Effective from / version — Version stamp. Changes require a published amendment.

Level — Trigger — Recipient and required response

L0 — SLA half elapsed — Owning officer receives a prompt and a single-click status update form.

L1 — SLA elapsed — Owning officer’s supervisor is notified; case appears on the supervisor’s queue with an L1 deadline equal to 25% of original SLA.

L2 — L1 deadline elapsed — District Service Officer for the relevant department; appears on District Mission Control dashboard.

L3 — L2 deadline elapsed — State Mission Control; appears on the Chief Secretary’s daily standup list; root-cause review required within 7 days.

L4 — Pattern (≥X cases in Y days) — Triggers a structural audit by the Procurement Audit Cell or relevant oversight body; audit and remedies are published.

← Chapter 2 — The People’s Model Operating System: Identity, Services, Case Files, Four Front Doors, Six Publishing Surfaces, and the Karnataka State Service Log · Chapter 4 — Public Finance with 100% Accountability: Outcome Budgeting, Open Ledger, Open Contracting, and Cryptographically Anchored Auditability →

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