8.4 Established

Risk-proportionate review of civic tools

A tiered submission-and-review flow (automated scan for all tools, human review for high-risk categories) paired with a mandatory structured disclosure section and a public, auditable statement of the review criteria.

01 Emerging Challenges

The tools and agents a citizen might use to deal with government range from a harmless information lookup to something that files a claim or shapes a decision. Reviewing every one to the same depth is neither affordable nor useful, but reviewing none leaves citizens relying on tools no one has checked.

The challenge is to match the depth of review to what a tool can affect, across a large and constantly changing population of tools.

02 Assurance

Government needs a level of review that scales: a light automated check every tool can pass quickly, deeper human review reserved for the tools that can do real harm, and a way to act after publication when something slips through. The aim is a credible minimum bar, not an exhaustive audit of every tool.

03 Access

Concentrated, opaque review shuts out the small builder who cannot read the rules they are judged against, or appeal a rejection. Keep the path open by publishing the review criteria so anyone can see what is checked, by keeping the lightest tier cheap enough for a solo builder, and by not vesting the gate in a single entity that can exclude without recourse.

04 Response surface
Service design Considered
The response this pattern proposes

A submission pipeline routes informational tools through automated checks and decision-support tools through additional human review, so review burden scales with consequence.

No surface has been built yet; the approach above is the brief for one.

05 Maturity
  1. Established Headline

    As a consumer-app review precedent.

  2. Frontier

    As a tiered-review model for civic technology, which no jurisdiction has built.

06 Precedents

Apple App Store review. Apple combines automated scanning (crashes, private API use, missing assets) with manual human review of app flows, permissions, and usability. In 2025 Apple rejected over 2 million submissions and blocked US$2.2 billion in fraudulent transactions; review averages 1–2 days. The Data Safety section requires developers to disclose data collection, storage, and sharing.

Google Play Protect. Google relies more heavily on automated machine-learning checks, triggering human review for flagged or sensitive categories; its Data Safety section mirrors Apple's disclosure requirements.

Known limitations. Despite review, malware regularly bypasses checks through code obfuscation, delayed execution, and compromised third-party SDKs; in 2025 multiple incidents traced to vulnerable advertising SDKs. App-store review is a minimum-bar filter, not an exhaustive security audit, and enterprises are advised not to treat presence as sufficient assurance.

07 Transferability

The app-store model shows that centralized review at scale is feasible but imperfect. Transferable elements: structured disclosure requirements (the Data Safety section is a nutrition label by another name); tiered review (automated first pass, human review for high-risk categories); post-publication monitoring and takedown. Limitations: review checks behavior against stated policies, not ground-truth accuracy; it concentrates gatekeeping in a single entity; and it is binary rather than graded.

A civic registry should adopt the tiered review model but add domain-specific accuracy checks and make criteria publicly auditable.

08 Where things go wrong

App-store review checks behavior against stated policies, not the ground-truth accuracy of outputs. A binary approved/rejected gate of this kind would not catch a method that produces plausible-looking but incorrect results, which pass any behavioral check.

09 Sources
4 references US