CivicOps AI

An AI operations copilot for volunteer organisations, student societies, and non-profit teams.

Comment

Inspiration

I am an actuarial science student and an active volunteer committee member in Malaysia. Through organising youth programmes, training courses, and inter-school activities, I repeatedly encountered the same operational problem: small volunteer teams are expected to deliver complex events without dedicated project-management staff.

Important information is often scattered across spreadsheets, chat messages, meeting notes, and individual follow-ups. Tasks may have owners and deadlines, but teams still struggle to see which prerequisite is blocking other work, where risks are increasing, or which decisions require immediate attention.

CivicOps AI was inspired by a real primary-school foot drill and first-aid knowledge competition that I am helping to organise. I wanted to build a practical operations copilot that could turn a basic event brief into an accountable working plan and continue supporting the committee as the situation changes.

What it does

CivicOps AI converts an event brief into a structured, editable operations plan.

The user provides information such as:

  • Organisation type
  • Event objective, date, and venue
  • Expected participants
  • Available budget
  • Committee size
  • Constraints such as safeguarding, meals, judging, transport flow, and wet-weather planning

GPT-5.6 Sol then generates a schema-validated plan containing:

  • A recommended committee structure
  • Operational tasks with clear owners
  • Deadlines, priorities, and risk levels
  • Direct task dependencies
  • A risk register and mitigation actions
  • Recommended next actions

The generated plan becomes an editable operations dashboard. Committee members can update task owners, deadlines, statuses, risks, priorities, and dependencies directly.

CivicOps AI can then review the latest edited dashboard rather than the original generated plan. The progress review identifies:

  • The most urgent actions
  • Active blocked dependency chains
  • Increasing operational risks
  • Ownership gaps
  • Downstream effects of delayed prerequisites
  • A suggested agenda for the next committee meeting

The plan can also be exported as CSV and JSON for further use.

How I built it

The application was built in Python with Streamlit.

I used the OpenAI Responses API with GPT-5.6 Sol for two main workflows:

  1. Generating the initial operations plan from the event brief
  2. Reviewing the committee’s latest edited task state

The AI outputs are validated with structured Pydantic models. This ensures that committee roles, tasks, risks, dependencies, and progress-review sections follow predictable schemas before they are displayed.

The application also includes a deterministic local workflow. If a live API request fails, the dashboard remains usable and provides a validated fallback plan or review instead of displaying a broken page.

Additional reliability measures include:

  • Sanitised cloud diagnostics
  • Finite connection and read timeouts
  • Controlled retry handling for API timeouts
  • Safe user-facing error messages
  • Protection against exposing credentials or tracebacks
  • Automated tests covering core logic, schema handling, cloud diagnostics, and timeout behaviour

The final implementation passed 39 automated tests.

How I used Codex

Codex was my primary development partner throughout the project.

I used it to:

  • Translate the product idea into an MVP architecture
  • Scaffold the Streamlit interface and application workflow
  • Design the Pydantic schemas
  • Integrate the OpenAI Responses API
  • Build the task dependency and urgency-scoring logic
  • Generate and improve automated tests
  • Diagnose oversized structured outputs
  • Harden the progress-review workflow
  • Investigate Streamlit Community Cloud failures
  • Add sanitised production diagnostics
  • Replace hidden retries with controlled timeout recovery
  • Prepare secure deployment copies without API keys or generated artefacts

Codex was especially valuable when the locally working application behaved differently after cloud deployment. It helped trace the problem to an API timeout, inspect the existing timeout configuration, reduce request latency, and implement a safer retry strategy without changing the product scope.

Challenges I ran into

Producing useful structured plans

The first challenge was preventing the model from producing a generic event checklist. The prompts and schemas had to make the output operationally specific while keeping it bounded and editable.

I limited the number of roles, tasks, risks, and next actions, required direct dependencies rather than large repeated dependency lists, and added concise field-length constraints.

Reviewing the current state instead of the original plan

The progress review needed to analyse the committee’s latest edits. It could not simply regenerate the original plan. The application therefore reconstructs the current task state before requesting a review.

Dependency analysis

A blocked task should not automatically mean every downstream activity is completely impossible. CivicOps AI distinguishes work that must wait from useful preparation that can continue while a blocker is resolved.

Cloud reliability

The application worked locally but initially experienced timeouts on Streamlit Community Cloud. I added secure diagnostic categories, increased the bounded read window, removed multiple hidden retries, added one controlled timeout retry, reduced reasoning effort for latency-sensitive requests, and tightened output limits.

Security

The OpenAI API key is stored only through environment variables or Streamlit Secrets. It is excluded from Git, never shown by the application, and never included in diagnostic logs.

Accomplishments that I am proud of

I am proud that CivicOps AI is grounded in a real operational problem rather than a hypothetical use case.

The project successfully combines:

  • Live GPT-5.6 Sol planning
  • Editable human-controlled task data
  • Structured output validation
  • Dependency and urgency analysis
  • Progress reviews based on current information
  • Safe fallback behaviour
  • A public cloud deployment
  • Automated reliability tests

I am also proud that the product remains useful when the AI service is temporarily unavailable. The system does not treat the model as the entire application; it combines AI reasoning with deterministic operational logic.

What I learned

This project taught me that building a reliable AI application requires much more than sending a prompt and displaying the response.

I learned how to:

  • Design bounded structured outputs
  • Validate model responses
  • Separate AI reasoning from deterministic business logic
  • Trace task dependencies
  • Build safe fallback behaviour
  • Diagnose differences between local and cloud environments
  • Handle API failures without exposing sensitive information
  • Use Codex as an iterative engineering partner rather than only as a code generator

Most importantly, I learned that AI is most useful when it strengthens human accountability instead of replacing human decision-making.

What's next for CivicOps AI

The next version of CivicOps AI could include:

  • Multi-user committee collaboration
  • Authentication and role-based permissions
  • Persistent project storage
  • Automated reminders and status check-ins
  • Calendar and messaging integrations
  • Comparison of planned versus actual expenditure
  • Reusable templates for different event types
  • Multilingual interfaces for volunteer organisations
  • Historical analytics across multiple projects

My long-term goal is to make professional operational discipline accessible to volunteer teams and student organisations that do not have dedicated project-management resources.

Built With

  • codex
  • github
  • gpt-5.6sol
  • openairesponsesapi
  • pytest
  • python
  • streamlit
  • streamlitcommunitycloud
Share this project:

Updates