Mission Context

The system behind how the U.S. manages its water

The Corps Water Management System (CWMS) is the U.S. Army Corps of Engineers' authoritative platform for managing the nation's reservoirs, dams, locks, and river systems. It sits at the center of how USACE's Hydrologic Engineering Center (HEC) coordinates flood response, navigation, hydropower, and water supply operations.

CWMS data flows into applications, district workflows, analyst tooling, and partner systems at NOAA and USGS. Every river-stage reading, reservoir-storage record, and forecast value is consumed by people making decisions that affect public safety, infrastructure, and billions of dollars of downstream activity.

The program needed finer-grained access control so that different users, roles, and systems could see exactly the records they were entitled to. The application was live, in production, and could not be disrupted while the change was introduced.

CWMS at a Glance
Authoritative source for
U.S. Army Corps of Engineers water resources data
Managed by
USACE Hydrologic Engineering Center (HEC)
Consumed by
USACE districts, NOAA, USGS, partner systems, and analyst tooling
Operational footprint
Hundreds of reservoirs, locks, and water control structures
Tolerance for downtime
None. Decisions ride on it 24/7, especially during flood events
The Problem

A live federal system whose access model could no longer keep up with the data it managed

CWMS has been operationally critical for years, which is exactly why its access controls had calcified around the technology choices of an earlier era. Three pressures converged.

01

CWMS data sprawl

CWMS is the authoritative source for U.S. Army Corps water resources data, consumed across districts, partner agencies, and downstream applications. Every record has different sensitivity, different ownership, and different audiences. The access model had to keep up.

02

Oracle VPD reliance

Access was enforced almost entirely through Oracle Virtual Private Database (VPD) policies. Those policies were coupled to the schema, tied to a specific database vendor, and difficult to evolve without touching the live production database. Every authorization change was a database change.

03

A two-role baseline that could not keep up

The role model in place gave exactly two privileges at the office (district) level: Modifier and Administrator. That was nowhere near enough to express the way USACE actually operates. Dam operators work within specific shift hours. Water managers need overrides on embargoed data during emergencies. Automated collectors should only append, never modify. External cooperators are limited to specific parameters. Partner agencies carry legal hold obligations on their own data.

Non-Negotiables

Two constraints we set before writing any code

These weren't aspirations. They were success criteria. Anything that broke either of them broke the engagement.

Operational Continuity

Don't break the legacy system

CWMS was live, in production, with established integrations and workflows. Districts, partner agencies, and analyst tooling depended on it around the clock. Any solution that required pausing the system, rewriting application logic, or coordinating a multi-district cutover was off the table.

Performance Posture

Don't add measurable latency

Authorization runs on every request. A new access control layer that pushed query times into the warning range during flood response surge traffic would be worse than the gaps it closed. The new model had to disappear into the request path rather than show up in it.

The Approach

Understand first, model second, validate against reality before touching production

The risk of a project like this is rarely the technology. It's mismatching the new access model to the way districts actually use their data. We sequenced the work to remove that risk before code shipped.

Step 1

Understand the users and the roles

Cataloged how access decisions were actually being made at the API layer, at the database layer, and inside the application. Mapped the real relationships between USACE districts, water managers, dam operators, public users, automated systems, and the data each one legitimately needed.

  • API authentication and authorization mechanisms
  • Oracle VPD policy logic and enforcement points
  • District data ownership and embargo conventions
  • Partner agency consumption patterns (NOAA, USGS)
Step 2

Model the real personas, not just the legacy roles

Interviews with HEC staff, district users, and program office stakeholders surfaced thirteen distinct personas, well beyond the original two-role baseline. The model expressed each one declaratively, with attributes such as office, data classification, embargo window, and source type layered over role to capture how districts actually own their records.

  • Core personas from the PWS: Public, Dam Operator, Water Manager, Data Manager, Auto Collection, Auto Processing, External Cooperator
  • Refined personas from stakeholder interviews: Facilities Staff, Authorization Admin, Data Steward (QA), Diagnostics Engineer, Partner Data Controller, Water Quality Manager
  • Attributes layered over role: office, classification, embargo window, source type, parameter scope
  • Reviewable by the program office without reading SQL
Step 3

Validate against the existing VPD

Before swapping anything, we ran the new policy logic in parallel against the existing Oracle VPD enforcement. Same requests, same data, same users, two enforcement paths in lockstep. If the new model produced a different answer than VPD, we resolved the gap in the model rather than in production.

  • Dual policy validation against the live VPD enforcement
  • Staging environment for behavior comparison testing
  • No production cutover until both paths returned identical decisions
  • Edge case handling for overlapping roles and dynamic user contexts
The Solution

A transparent authorization layer, sitting in front of the system that was already working

Instead of rewriting CWMS's access logic in place, Solid Logix introduced authorization as a policy layer in front of the existing data API, powered by Open Policy Agent (OPA). Every request still hits the application. Every record still lives in the same database. What changed is that the access decision now happens in a centralized, auditable policy layer, written in Rego, version controlled in Git, and passed into the data API through an x-cwms-auth-context header.

Application code stayed the same. Oracle VPD policies stayed in place as a defense in depth backstop. Districts saw zero workflow change. The new layer handled the persona and attribute decisions the program office actually needed, including embargo windows, shift hour validation, append-only enforcement, and parameter whitelisting, without coupling any of them to the schema.

How a request flows
CWMS Application & APIs
Unchanged. Same code, same endpoints, same workflows.
Authorization Layer (OPA)
Open Policy Agent. Rego policies in Git. Persona and attribute decisions. Auditable. Externalized.
Oracle Database & VPD
In place. Defense in depth. Production of record.
Application + database are untouched. The new enforcement point lives between them, governed by an external policy layer the program office controls.
Zero-Disruption Delivery

The legacy system kept running. The access model got better.

Oracle VPD stayed in place as defense in depth. Application code stayed the same. Districts noticed nothing.

Before

Access policies embedded in Oracle VPD. Tightly coupled to the schema. Coarse role grants that didn't match the way districts owned their data. Every policy change was a database change.

After

Persona policies as code in OPA. Rego policies in Git with code review workflow. VPD still enforcing as defense in depth. Application code unchanged. Shadow mode validation against the live VPD before any cutover. Decision logs structured for NIST SP 800-171 AC, AU, IA, and SC families.

Results

Delivered as scoped, rated accordingly

The engagement closed with strong recorded performance across every CPARS dimension and a stronger authorization foundation for CWMS data, without any disruption to the system already in use.

Exceptional
CPARS rating in primary dimensions
Very Good
CPARS rating across remaining dimensions
Ahead
Delivered ahead of the agreed schedule
Zero
Disruption to the legacy system in active use
Beyond the Scope of Work

The team contributed additional capability beyond the contracted scope, including documentation, integration patterns, and design artifacts that strengthened the foundation for future enhancements and reduced downstream risk to the program office.

What This Demonstrates

Evolving mission systems without disrupting active operations

The CWMS engagement is the operational precedent for how we approach federal modernization work generally: clear analysis of dependencies, layered architecture that respects what already exists, incremental rollout, and direct program office coordination at every step.

Dependency and Data Flow Analysis

Mapped how access decisions were already being enforced and where new authorization needed to live before any code changed.

Layered Architecture

Separated authorization from application logic so it could be introduced without breaking existing workflows or coupling the policy model to the database schema.

Incremental Rollout

Validated changes in controlled increments alongside ongoing operations, with rollback paths preserved at every step.

Program Office Coordination

Worked directly with the USACE program office to align on priorities, review milestones, and integrate changes against the established change process.

The Pattern, Productized

The CWMS approach is now packaged as our Dynamic Access Governance Framework

Wrapping a legacy system with a policy driven authorization layer, without modifying the application, is now a turnkey capability we deliver across federal programs as DAGF. CWMS is the real-world engagement that proved it works.

Have a mission system you can't take offline?

We work inside federal environments where availability isn't optional. Let's talk about what your modernization looks like without the cutover risk.

Start the Conversation