Product management
AuraScore 83/100

Municipal Public Works Service Request Routing Specification

Define functional specs for automated civic service ticket intake, geolocated dispatch, and public transparency feeds.

Use this template to build specifications for local government citizen request management platforms (311 systems). It bridges public-facing issue submission with departmental work orders and open data reporting obligations.

Template

Role: Smart City Product Strategist and Municipal Systems Solutions Architect.

Context

  • Participating departments: {{municipal_department_scope}}
  • Incident taxonomy: {{incident_category_taxonomy}}
  • Spatial logic: {{gis_routing_rules}}
  • Performance baselines: {{sla_escalation_thresholds}}
  • Transparency mandates: {{open_data_disclosure_rules}}
  • Communication pathways: {{resident_notification_channels}}

Task

Author an end-to-end product functional specification for an automated municipal incident triage, spatial dispatching, and public-facing transparency module.

Method

  1. Establish the validation rules for citizen reports based on {{incident_category_taxonomy}}.
  2. Translate {{gis_routing_rules}} into spatial lookup and departmental dispatch logic.
  3. Define automated routing matrices directing tickets across {{municipal_department_scope}}.
  4. Design the lifecycle state machine including automated reminders based on {{sla_escalation_thresholds}}.
  5. Specify outbound milestone messaging triggers across {{resident_notification_channels}}.
  6. Detail automated redaction pipelines filtering PII before publishing to {{open_data_disclosure_rules}}.
  7. Construct duplicate report detection algorithms utilizing reverse-geocoding and proximity thresholds.

Constraints

  • MUST automatically redact citizen personal identifying information prior to syndication to {{open_data_disclosure_rules}}.
  • MUST NOT route tickets without validated spatial coordinates or confirmed street addresses.
  • SLA clocks must pause strictly during approved external dependency states.
  • All status transitions must generate immutable, auditable log entries.

Output format

  1. System Context & Departmental Taxonomy (Scope, boundaries, classifications)
  2. Intake & Geocoding Logic (Coordinate validation, duplicate detection specs)
  3. Triage & Departmental Dispatch Engine (Table: Taxonomy, Routing Rule, {{sla_escalation_thresholds}} Matrix)
  4. Resident Engagement Lifecycle (State diagram & copy triggers for {{resident_notification_channels}})
  5. Public Data Syndication Schema (JSON schema matching {{open_data_disclosure_rules}})

Self-review

  • Confirm duplicate detection logic handles multiple reports for the same incident at one location.
  • Verify all escalation pathways enforce {{sla_escalation_thresholds}} across all {{municipal_department_scope}}.
  • Check that PII filtering thoroughly satisfies {{open_data_disclosure_rules}}.
AuraScore breakdown
83/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency7/10 · Adequate

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

business-strategy
business-product
public-sector-nonprofit
smart-city
local-government
workflow-engine