Share

Cornerstone position paper

UI modernization cannot keep depending on large, all-or-nothing replacement projects. A governed modular model gives states a practical way to improve capabilities incrementally while preserving public control, competition, and accountability.

Unemployment insurance modernization is often discussed as a technology problem. States need newer systems, better portals, stronger identity tools, faster payment workflows, modern infrastructure, and improved reporting. Those needs are real. But the deeper problem is structural: the way UI technology is usually bought, governed, integrated, and changed makes durable modernization unusually difficult.

For decades, many states have faced a narrow set of choices. They can maintain legacy systems longer than they want. They can customize around those systems until complexity becomes hard to manage. Or they can attempt a large replacement project that concentrates cost, schedule risk, operational risk, and vendor dependence into one procurement.

That model does not fit the reality of unemployment insurance. UI is a federal-state program with state-specific law, policy, staffing models, employer processes, claimant populations, appeals structures, tax requirements, fraud controls, reporting obligations, and political accountability. A single monolithic product cannot erase that variation. A one-time replacement cannot keep pace with future policy changes, economic shocks, fraud patterns, claimant expectations, accessibility needs, and federal direction.

Modernization should be treated as an ongoing capability, not a rare capital event.

The emerging Open UI conversation points in that direction. The most important idea is not simply that software should be open source or that systems should expose APIs. The stronger idea is that UI technology can be organized around governed, interchangeable capabilities. If the boundaries between capabilities are defined, versioned, tested, and stewarded, then states can improve one part of the system without being forced to replace everything else.

That is the case for governed modular UI modernization.

Modularity by itself is not enough. A system can be broken into many parts and still be locked down, fragile, or vendor-controlled. If every interface is private, every integration is custom, and every acceptance test depends on one implementation partner, the state has not gained much practical freedom. It may simply have a more complicated monolith.

Governed modularity requires more discipline. It asks several public-sector questions:

  • What capabilities should be separable?
  • What information must each capability provide, consume, and preserve?
  • How are interface expectations documented?
  • How are versions changed over time?
  • How does a provider demonstrate compatibility?
  • How does a state validate readiness before production use?
  • How does the model preserve state law, policy, security, privacy, and procurement authority?

The answers to those questions are governance decisions as much as technical decisions.

A governed modular model creates a public baseline without requiring one public system. Multiple vendors, states, open-source projects, and managed-service providers can implement a capability if they satisfy the same expectations. A state can select what fits its policy and operational environment. A federal or neutral steward can help define reusable standards and evidence expectations without dictating every implementation detail.

This changes the modernization market. Smaller providers can compete on strong individual capabilities. States can reuse assets developed elsewhere. Open-source work can become more than a code repository if it is paired with documentation, conformance, deployment guidance, and stewardship. Larger vendors can still provide broad systems, but they must compete on modular fit, interoperability, and evidence rather than lock-in.

Governed modularity also changes risk. Instead of waiting for a complete replacement, a state can select a priority capability and adopt it incrementally. Claim status, document management, correspondence, identity workflow, employer response, appeals support, integrity analytics, reporting, and staff tasking are all examples of capabilities that may be candidates for bounded modernization.

The point is not to make every state adopt the same sequence. The point is to give states a practical way to move.

Conformance is central to this model. Compatibility should not be a claim made in a sales presentation. It should be supported by evidence: tests, interface behavior, audit records, accessibility review, security documentation, performance expectations, and operational playbooks. Conformance lets agencies compare options more objectively and reduces the amount of custom review that must be repeated for every procurement.

Procurement must change with the architecture. If a state buys a "module" but the contract, implementation, data model, or acceptance process prevents future replacement, the procurement is not truly modular. Modular procurement should preserve future options. It should ask whether a capability can be adopted, tested, operated, and replaced without surrendering control of the broader environment.

Governed modular modernization also supports stronger public accountability. A state should be able to explain how a capability handles sensitive data, what logs are preserved, how errors are managed, how decisions are audited, how users are supported, and how performance is measured. Modularity should improve transparency, not obscure responsibility.

This approach is especially important because UI modernization has multiple goals that cannot be separated cleanly. Fraud prevention, equitable access, timely payment, customer experience, staff workload, appeals quality, employer participation, and federal reporting all depend on shared foundations. A narrowly optimized point solution can create new problems if it does not fit the larger operating model.

The opportunity now is to turn Open UI from a concept into an adoption path. States do not need abstract modernization language. They need readiness assessment, capability boundaries, procurement guidance, conformance evidence, governance models, and implementation support.

Solid State's view is that modernization should preserve state authority while making change easier. The state should retain control of policy, program judgment, procurement decisions, security posture, and operational accountability. The market should provide better options, stronger competition, and reusable capabilities. Public stewards should help define the common expectations that make reuse practical.

That is the promise of governed modular UI modernization: not one system, not one vendor, and not one irreversible project, but a durable operating model for continuous improvement.

Explore how Solid State helps agencies move from Open UI concepts to governed modular adoption.

By Published On: June 24, 2026Categories: Insights

Share This Article