Skip to content

Example Everything on this site is sample data — one of the configurations this template ships with, built from the same repository.

Example: AI use case catalog
Civic AI Community of Practice AI Use Case Catalog
Contribute

Submit a use case

Share an AI use case, tool or project with the community. Submissions open a GitHub issue for the maintainers to review; nothing is published until it is approved.

Nothing is sent from this page. Your answers stay in this browser until you press a button. You'll need a free GitHub account — or use Email it instead.

  1. 1. Answer the questions below.
  2. 2. Check your answers, then send them to GitHub.
  3. 3. Press Submit new issue on GitHub — that is what actually submits it.

Before you start, the governance page has the five things reviewers check and the rules on privacy and licensing — you keep ownership of anything you share.

About

0 of 8 sections complete

Section 1 of 8

About

What it is, who built it, and what it changed.

Specific enough that someone scanning a list of names knows what it is.

What are you sharing?

Pick the closest match.

Which of the four categories fits best?

Broad, HHS-adapted use-case categories. Area of work (below) is the finer cut.

Which areas of work does it apply to?

Select all that fit — these are business functions as much as health programs.

How far along is it?

Pick the stage that matches real use, not the plan.

Shown on the catalog card. Plain language, no jargon.

A number if you have one.

The city, county, agency or health department that built or runs it.

Section 2 of 8

How it's built

The AI involved and where it runs.

Is the AI in the product, or was AI used to build it?

What kinds of AI does it use? (optional)

Select all that apply.

Name the models, platforms or libraries that matter. One per line, or separated by commas.

Where does it run? (optional)

Select all that apply.

Leave it blank if your own team built it.

Section 3 of 8

Reuse

What it would take for another team to use this.

Who is the least technical person who could get this running?

Judge it by setting the thing up, not by using it afterwards.

What would another team need before they could use this? (optional)

Select all that apply.

GitHub, GitLab, Azure DevOps or any public repository.

A report, a blog post or a vendor case study all count.

Anything else worth linking? (optional)

Shared drives, SharePoint, model cards, container images, vendor pages.

Up to eight PNG, JPEG, GIF or WebP images of the tool in use (15 MB total). Make sure no personal or protected information is visible.

You can drag image files straight into the GitHub issue on the next screen. If your images are already online, paste their addresses here instead — one per line, optionally followed by | alt text. PNG, JPEG, GIF and WebP images are copied into the repository; anything else is left as a link for a maintainer.

Slide deck or one-pager

Attach the slide deck here. A thumbnail is generated from its first page.

Files can't be attached from this page. Drag deck.pdf into the GitHub issue on the next screen and a maintainer will add it to your entry.

Section 4 of 8

Sharing & licensing

How another jurisdiction may use it, and how portable it is.

Under what license is it shared?

The community default is a permissive open license (MIT, Apache 2.0, CC BY). Submitting does not transfer ownership — your organization keeps authorship.

Government-to-government only, agreement required, contact us — whatever applies. Leave blank for open-licensed resources.

Could it be adapted outside its original vendor ecosystem?

Microsoft-built but portable to AWS is 'partially'.

Which pieces are vendor-specific, and what a team on a different stack would need to swap.

Name the source by its slug — the last part of its URL. The entry you name will say it was adopted by yours. One per line, or separated by commas.

Section 5 of 8

What it took

Money, contracting and approvals — the part a budget or governance conversation needs.

Roughly what did it cost to get it running the first time? (optional)

One-time cost: contracts, build, implementation. A band is fine — nobody expects an exact figure.

What does a normal year cost to run? (optional)

Licences, hosting and usage charges only — staff time belongs in the write-up.

How was this paid for or contracted? (optional)

Select all that apply. This is the question peers ask most and the one that is hardest to find out.

Which internal reviews or approvals did it need? (optional)

Select all that apply. Saying 'not yet reviewed' is more useful to a peer than leaving it blank.

Optional but strongly encouraged. Which populations the output reaches, what you checked for uneven performance, and what you would watch.

Section 6 of 8

Data & access

What data it touches and who sees the output.

The community's baseline for anything published here. Reviewers spot-check; if the answer is no, redact before submitting.

What kind of data does it touch?

Select all that apply. This helps others judge governance and approval effort.

Describe the sources — do not paste sensitive data. One per line, or separated by commas.

Who sees the output?

Pick the widest group that sees anything it produces.

Data-use agreements, retention rules, de-identification steps — the caveats that travel with the resource.

Section 7 of 8

Contact

Someone others can reach out to.

Someone happy to answer questions from another team.

So a peer knows who they are writing to.

Used once a year: when this entry is due to be re-confirmed the reminder mentions you, so the request reaches the person who wrote it. Leave it blank and the reminder goes to the maintainers alone.

Section 8 of 8

The story

Problem, approach, what it took, results and lessons.

Markdown is supported. Suggested headings: Problem, Approach, What it took (data, staffing, cost), Results, Lessons learned, How to reuse.