The city wants domain product teams to move fast without each reinventing pipelines, identity, and platform glue. Which team-topology pattern supports that?

When the city wants domain product teams to move fast without reinventing pipelines, identity, and platform glue, a platform team should provide paved roads while domain teams build products on those shared capabilities. Opinionated reusable services—identity, ingestion templates, observability, environments, and security baselines—reduce duplicated toil and inconsistency without recentralizing all business logic into one team that becomes a bottleneck for every civic product. Making every domain build its own platform from scratch fails by wasting scarce capacity and fragmenting standards residents experience as broken journeys. Having a single central team own all domain products fails by forbidding domain ownership and creating queues that slow service delivery. Eliminating platform standards so each squad chooses incompatible stacks freely fails by maximizing integration friction and operational risk. Exam caveat: paved roads must be usable, funded, and measured; a platform that is merely a mandate without enabling self-service fails both speed and consistency goals. Operational check: publish platform capabilities and contracts, measure adoption versus shadow stacks, gather domain feedback on friction, prioritize road improvements that remove the top repeated toil items, and require an exception path with compensating controls for justified deviations.