The old site let people filter promises by category (Health, Roads, Housing, and so on). The new site only lets them filter by status. So someone who wants to see, for example, just the health promises has no way to do it and has to scan the whole list.
That is a discovery problem. As the number of tracked promises grows, a status only filter is not enough to find what you care about. Restoring category filtering fixes that.
Part A: filter UI on the Promises page
What: The old site Promises page had Filter By Status and Filter By Category. The new site has Status only.
Expected: Add a Category filter “Drop-down” beside the existing Status filter, matching the old site. Selecting a category filters the promises list. Works with the existing sort options.
Depends on: Reads whatever category values exist on promises. Can ship with current data and light up fully once Part B populates categories.
Part B: AI category assignment on extraction
What: Promises need a category so the filter has something to filter by. Assign it by AI when a promise is extracted into Payload.
Expected: On extraction, the AI assigns each promise one primary category from the fixed list below. The field is editable in Payload so editors can correct it.
Proposed taxonomy
- Health
- Education
- Roads and Transport
- Housing and Urban Development
- Water
- Waste and Sanitation
- Energy and Electricity
- Agriculture and Food
- Economy
- Job Creation
- Empowerment
- Technology
- Security and Policing
- Governance
- Sports
- Environment and Climate
- Social Welfare
- Religion
- Others (fallback)
Classification rules:
- Pick exactly one primary category. Never leave it blank.
- Use Others only when nothing fits with reasonable confidence. Route low-confidence matches to Others rather than guessing.
- The field is editable in Payload so editors can correct it; the AI sets a default; the editor has final say in Payload.
The old site let people filter promises by category (Health, Roads, Housing, and so on). The new site only lets them filter by status. So someone who wants to see, for example, just the health promises has no way to do it and has to scan the whole list.
That is a discovery problem. As the number of tracked promises grows, a status only filter is not enough to find what you care about. Restoring category filtering fixes that.
Part A: filter UI on the Promises page
What: The old site Promises page had Filter By Status and Filter By Category. The new site has Status only.
Expected: Add a Category filter “Drop-down” beside the existing Status filter, matching the old site. Selecting a category filters the promises list. Works with the existing sort options.
Depends on: Reads whatever category values exist on promises. Can ship with current data and light up fully once Part B populates categories.
Part B: AI category assignment on extraction
What: Promises need a category so the filter has something to filter by. Assign it by AI when a promise is extracted into Payload.
Expected: On extraction, the AI assigns each promise one primary category from the fixed list below. The field is editable in Payload so editors can correct it.
Proposed taxonomy
Classification rules: