Low-Code and Government

DIALOG is a product developed at the Centre for Smart Governance (CSG), Government of Karnataka. Digital Infra for Accessible Open Governance, if you want the full acronym unpacked. Form.io, Camunda, real deployments at ISRO and HRMS. The platform underneath is holding up. The AI layer on top, the bit I've been contributing to, is where things get interesting. Or where the skepticism kicks in. This post is about that.

The stack: Form.io, Camunda, and my corner of it

At the core, DIALOG rests on two big blocks: Form.io for building and rendering forms, and Apache Camunda for orchestrating workflows. Form.io gives you a drag-and-drop builder, JSON schemas, conditional logic, validations, file uploads. Camunda gives you BPMN diagrams, user tasks, service tasks, gateways, timers. The usual workflow engine machinery.

Form.io and Camunda are both mature, well documented tools. Form.io gives you a flexible schema model, conditional logic, and a decent component library out of the box. Camunda is enterprise grade: BPMN diagrams, process variables, user tasks, service tasks. There's a learning curve, but once your team knows the stack, you can ship new forms and workflows without rewriting everything from scratch. That's the real value of DIALOG: consistent patterns, reusable building blocks, faster iteration.

The bit I touch is above that: the AI layer. Natural language to Form.io schema generation, prompt based edits, some assistance around form structure. Think "build me an onboarding form for MSME loan applications" and the system spits out a JSON skeleton you can refine. Architecturally it shares DNA with what I wrote about in Queue the Context. On slides it looks very slick. In practice, it sits in that awkward space between "genuinely helpful sometimes" and "a slightly overqualified autocomplete that still needs close supervision."

ISRO inventory: a good fit

One of the stronger deployments is at ISRO, for inventory management. The process topology is straightforward: request to storekeeper or section head validation, conditional escalation via exclusive gateway on threshold, then procurement or issue. The BPMN maps cleanly: user tasks for human approvals, service tasks for system calls like stock lookup, parallel gateways where multiple sign offs are required. Camunda's process variable model handles the data flow. Form submission payloads get serialised into the process context, so downstream tasks receive the right payload without extra glue.

example: A scientist at an ISRO centre requisitions 5 units of a specific electronic component for a payload integration test. She fills the Form.io form: item code from a dropdown synced with the master catalog, quantity, justification text, budget head, and attaches a project sanction letter. On submit, a Camunda process instance is created. The storekeeper sees the task, checks physical stock via a service task that hits the inventory DB. If stock is insufficient, the process routes to the section head for "procure vs. wait" decision. If the requisition value crosses a threshold, say ₹2 lakh, an exclusive gateway routes it to the centre director for approval. Once approved, the storekeeper issues the items and marks the task complete. The entire trail, who approved what and when, lives in Camunda's execution history.

Form.io schemas capture the domain: item codes, quantities, justification text, budget heads, supporting documents. The integration layer maps Form.io submission JSON to Camunda variables; the schema is flexible enough that adding new inventory categories or adjusting approval thresholds is a schema + BPMN change, not a code change. The deployment is Camunda's standard deployment model: process definition versioning, redeploy. The fit is strong because the process is well-structured and the data model is bounded.

HRMS portals: one platform, many tenants

Another major use case is HRMS: leave, transfers, promotions, service verification, retirement flows. The architecture is multi-tenant: each org gets its own process definition IDs and form schema namespaces, but they share the same Form.io/Camunda runtime. Process variants are implemented as separate BPMN deployments rather than a single uber process with conditional branching. Cleaner separation of concerns, easier to reason about per org behaviour.

example: A clerk in the Revenue Department applies for 12 days of earned leave. The form prefills his name, designation, and leave balance from the employee master via API. He selects leave type, earned, dates, reason, and uploads a supporting document like a wedding invitation. Because this org's rule says "leave over 10 days needs director sign off," the workflow routes: reporting officer → department head → director. Each approver sees the same form with the submitted data; they add remarks and approve or reject. On final approval, a service task pushes the leave record to the attendance system. A different department, say Education, might have a different rule: "leave over 5 days needs director, and during exam season add an extra level." That's a separate process definition, same Form.io runtime, different BPMN.

Government HR rules vary: approval levels, festival period logic, attendance and payroll integrations. The platform accommodates this via process variants per org, all built on a small set of shared workflow archetypes like single approval, multi level approval, parallel review. Form.io handles the form complexity: conditional visibility, medical leave fields only when leave type is medical, pre filling from master data via API, validation rules expressed in the schema. New orgs are onboarded by configuring a new process definition + form schema, not by writing application code. Typical onboarding is in the order of weeks, not months.

The need: why a platform makes sense

Government processes are structurally similar: receive input → validate → route → approve → record. The variation is in the schema (what fields), the routing rules (who approves what), and the integrations (legacy systems, NIC, state data centres). Example: A citizen grievance (pothole complaint) and an NOC for a building plan are different domains, but both follow the same pattern: form submission → routing to the right desk → approval/rejection → record in a backend. A grievance might route to ward engineer → municipal commissioner if unresolved in X days. An NOC might route to town planning → fire safety → final clearance. Same platform, different schemas and BPMN. Building a bespoke application per process yields a fragmented ecosystem: N codebases, N deployment pipelines, N vendor handovers. DIALOG centralises the form layer (Form.io) and the workflow layer (Camunda) under a single deployment model. Authentication, logging, and audit are configured once at the platform level.

The delivery model is composition over custom development. Form schemas and BPMN definitions are deployable artifacts; changes are versioned and deployed like any other config. Government procurement cycles are long; requirements drift. A platform lets you iterate: schema change, process redeploy, pilot, all without a full SDLC. CSG is building internal capacity: documented workflow archetypes, reusable form templates, training on the stack. The platform approach reduces the marginal cost of adding new processes.

The AI layer: my reservations

On to the AI piece, the bit I actually work on. The idea is straightforward: use AI to generate or edit forms from natural language, draft workflow skeletons, suggest structures. In a demo it looks great: you describe a process, the model spits out a Form.io schema or a BPMN sketch, you refine it, done.

My first reservation is ROI and opportunity cost. The compute we're burning through, LLM calls for schema generation, workflow drafting, validation passes, is nontrivial. GPU time, token counts, API costs. For what? A form that a developer or a semi technical person could build in an hour using Form.io's drag and drop builder and a few templates. The ROI doesn't stack up. The same resources could be used to build something else with higher impact: better observability, integrations with legacy systems, tooling that actually reduces operational load. We're choosing to spend compute on form generation when there are other problems that would benefit more from that investment.

My second reservation is what I've seen when pitching to departments. They're skeptical. And they have a point. The pitch is often: "Give a non-technical person DIALOG with AI, and they can build forms without writing code." The reality is that departments would rather hire a dev or a less technical person who knows Form.io and can design forms properly, someone who understands the schema, the validations, the GR rules, than hand a completely non technical person an AI powered form builder and hope for the best. It's the monkey with a gun problem. You're giving a powerful, unpredictable tool to someone who shouldn't be the one pulling the trigger. The departments get it. They'd rather have a trained person who produces correct, auditable output than rely on an AI layer whose value is hard to quantify. The AI pitch doesn't land because the alternative, hire someone, use templates, iterate, is more predictable and often cheaper when you factor in the compute and the review overhead.

There's more in the pipeline: STT, speech to text for form filling and multi lingual form generation. On multi lingual, I have fewer reservations. The use case is clear: generate form labels, help text, and validation messages in Kannada, Hindi, or other regional languages from a single source schema. The output is bounded. You're translating or localising, not inventing structure. The value is obvious: accessibility, compliance with language policy, reaching citizens who aren't comfortable in English. The risk surface is smaller. I can see that being genuinely useful.

On STT pipelines, I'm more skeptical. The idea is to let users speak into a form field and have speech transcribed into text. Useful for low literacy users or field workers on mobile. The reservations: accuracy in Indian languages and accents, noise in real world environments like offices, kiosks, outdoor, and critically, what happens when the transcription is wrong. If a user says "Mysore" and the STT outputs "Mysuru" or "Mahesh" or something garbled, that wrong value gets submitted. In a government form, that's a data integrity problem. You need a review step, but then you've added friction. Plus STT is compute heavy: real time transcription, possibly with a language model for correction. The same ROI question: does the value justify the infra? And who validates the output? I'm not convinced the STT integration is ready for production use cases where accuracy and auditability matter. It might work for internal drafts or low stakes fields; I'd be cautious about citizen facing forms.

I'd be blunt: the AI layer is not high value right now. If it vanished tomorrow, DIALOG would still work. The platform's core, Form.io, Camunda, the deployments at ISRO and HRMS, would be unaffected. The AI is frosting, and the compute we're spending on it doesn't justify the frosting. Multi lingual might change that calculus; STT, in its current form, adds more risk than value. I'm cautious about overselling it. Building it has taught me a lot, but I wouldn't point to it as a reason to adopt DIALOG. Departments seem to agree.

Is low-code in govtech viable?

Platform layer: evidence supports viability

Market and analyst view. Gartner argues that more than 80% of government digital implementations not built on a technology platform will fail to meet objectives; low-code and digital platforms are framed as critical for transformation [1]. The LCAP market is forecast to reach $16.5B by 2027 with 16.3% CAGR [2].

Benchmarks. The OECD Digital Government Index benchmarks six dimensions, including "government as a platform." South Korea leads at 0.95; the OECD average improved 14% from 2023 to 2025 [3].

Case evidence.

• Norway, Altinn 3: Gartner cites it among five leading digital government platforms; serves over 90% of the population and nearly 100% of businesses [4].
• Estonia, X-Road: Operational since 2001; underpins 3,000+ e-services; adopted in 20+ countries [5].
• Ukraine, Diia and Liquio: Service development reduced from 6–12 months to 6 weeks [6].
• Singapore, GovTech SGTS: 40+ agencies launched 200+ systems; MyInfo went live in 4 months [7].

Implication. Form and workflow platforms work when processes are well bounded and teams have platform literacy. DIALOG fits that profile. Form.io and Camunda have community editions and open source roots; CSG runs on community plus in-house expertise. The constraint is capacity: whether you have people who can read the docs, debug the stack, and extend when needed.

References. [1] Gartner via Appian (2018). [2] Gartner LCAP Risk and Opportunity Index. [3] OECD Government at a Glance 2025. [4] Altinn 3. [5] Estonia X-Road. [6] GovInsider / Ukraine Diia. [7] Singapore GovTech SGTS.

The verdict (for now)

DIALOG as a platform has delivered. The Form.io + Camunda stack works. ISRO, HRMS, and other deployments are real, in production, and providing value. The team has done solid work: templates, conventions, observability. I don't have major platform level regrets. The improvements I'd suggest are incremental: more documented workflow archetypes, clearer ownership when processes stall. If you're evaluating low code for govtech, the platform itself is worth taking seriously.

The AI layer is a different story. I've contributed to it, and I'm skeptical. It works. The output is usually correct; we're not hallucinating. The reservation is ROI and opportunity cost. The same resources could build something else that moves the needle more: better integrations, more robust observability, tooling that reduces the ops burden. I wouldn't recommend it as a selling point for DIALOG right now. The platform stands on its own. The AI layer is still an experiment, one I'm not confident justifies the resource allocation. I'll keep working on it, but I'd rather undersell it than oversell it.