# From Prompts to Production: Building Civic-Tech AI Workflows with RICE + CRAFT

> Source: <https://dev.to/pavithranp12/from-prompts-to-production-building-civic-tech-ai-workflows-with-rice-craft-385f>
> Published: 2026-09-03 20:11:53+00:00

I recently completed the **Vibe Coding Workshop — Civic Tech Edition**, working through four practical use cases designed around real municipal workflows.

The goal wasn't simply to “make an AI app.” The workshop focused on turning vague prompts into **structured, testable, reliable workflows** using RICE, CRAFT, explicit enforcement rules, and Git-based iteration.

The first challenge was a **municipal complaint classifier**.

The input contained citizen complaints that needed to be classified into an exact municipal taxonomy such as:

Each complaint also needed a priority:

**Urgent / Standard / Low**

The initial naive prompt was simply:

“Classify this citizen complaint by category and priority.”

The problem became obvious quickly: a simple prompt can classify the topic, but it doesn't necessarily enforce **severity detection, evidence, or consistent taxonomy**.

For example, a complaint mentioning an **injury, child, school, hospital, ambulance, hazard, fall, or collapse** needed to be treated as urgent.

I converted the requirements into explicit agent instructions and skills:

`NEEDS_REVIEW`

for ambiguous casesThe final classifier was tested against the supplied Pune dataset and produced the expected `results_pune.csv`

.

**Key lesson:**

A good prompt doesn't just tell an AI *what* to do. It defines **what counts as correct**.

The second use case was an **HR leave-policy summarizer**.

At first glance, this sounds straightforward:

“Summarize the policy document.”

But policy documents contain details that cannot safely be summarized away.

The document included requirements such as:

The major failure modes were:

**Clause omission · Scope bleed · Obligation softening**

The workflow was redesigned to explicitly preserve:

I also added validation so the generated summary could be checked for required policy details rather than simply trusting the output.

The final workflow generated `summary_hr_leave.txt`

and passed the policy-summary validation.

**Key lesson:**

For policy workflows, “approximately correct” is often **incorrect**. Important conditions and exceptions have to survive the transformation.

The third challenge involved **municipal budget analysis**.

The dataset contained:

The task was to calculate growth for a **specific ward and category**, for example:

Ward 1 – Kasba → Roads & Pothole Repair

The main failure modes were:

**Wrong aggregation level · Silent null handling · Formula assumption**

This was important because an apparently reasonable calculation can become completely misleading if data from different wards or categories is accidentally combined.

The implementation enforced:

The output correctly produced values such as:

**Scope is part of correctness.**

A mathematically correct formula applied to the wrong aggregation level is still a wrong answer.

The final use case brought everything together.

The task was to build an interactive policy Q&A system using three separate documents:

The challenge wasn't just answering questions. It was preventing the model from **combining information from different documents to create a permission that no document actually grants**.

For example:

“Can I use my personal phone to access work files when working from home?”

The HR document may discuss remote work, while the IT policy specifically limits personal-device access.

The agent therefore needed to maintain **source boundaries**.

The final workflow required:

For unsupported questions, the required response was:

“This question is not covered in the available policy documents…”

The test cases successfully demonstrated:

The most important part of a document Q&A system isn't just retrieval.

It's **knowing when not to answer**.

Across all four use cases, the biggest shift was moving from:

**“Give the AI a prompt and see what happens.”**

to:

**“Define the task, failure modes, enforcement rules, skills, validation, and test cases before trusting the output.”**

The workflow I followed was essentially:

**Naive Prompt → Identify Failure → RICE Prompt → agents.md → skills.md → Code → Test → Analyze → Fix → Commit**

Git also became part of the development process rather than just version control. Each UC was developed and committed separately, creating a traceable history of **what failed, why it failed, and what changed**.

The four use cases reinforced a simple principle:

Reliable AI isn't just about generating better answers. It's about designing systems that make incorrect answers harder to produce.