Data Authorization‐W912HQ25P0049

Project Overview

CWMS Data Authorization Project Overview

This page contains meeting notes and other documentation related to progress on a contract to improve data operations and security. While the majority of data in the CWMS database is public by law, some data we store must be private, or at least have release delayed in time by various agreement with those entities that own that data, such as a privately owned dam upstream of a flood control project.

The information is being stored here given a need to have a record of it, and in the interest of transparency. We ask that anyone that isn't USACE staff that work on this project, or the vendor doing the work, refrain from editing this page. If there are points of concern you wish to address please open a discussion about it so it can be addressed.

Key Links and Resources for project

Resource	Link
Project Wiki Home Page (this page)	https://github.com/USACE/cwms-data-api/wiki/Data-Authorization%E2%80%90W912HQ25P0049
Kanban board	https://github.com/orgs/USACE/projects/49/views/1
CDA Wiki	https://github.com/USACE/cwms-data-api/wiki/Data-Authorization%E2%80%90W912HQ25P0049
Bitbucket Repo	https://bitbucket.hecdev.net/projects/CWMS/repos/cwms_database
Data API Repo	https://github.com/USACE/cwms-data-api/
CWMS Python Wrapper Repo	https://github.com/HydrologicEngineeringCenter/cwms-python
CWMS Database Repo	https://github.com/HydrologicEngineeringCenter/cwms-database
CWMS Data Repo	https://github.com/cwbi-dev-infrastructure/cwms-data
USACE Org Policy	https://github.com/USACE/policies?tab=readme-ov-file#user-profiles
Docker Compose for CDA getting started wiki page	https://github.com/USACE/cwms-data-api/wiki/How-to-use-Docker%E2%80%90compose-with-a-windows-Client

Meeting Minutes

Project Kickoff 5/19/25

Core Meeting Metadata

topic	detail
Meeting Title	W912HQ25P0049 CWMS Database Authorization Updates Kickoff
Date/Time	5/19/25, 2pm EST
Meeting Location	Virtual (MS Teams)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Kickoff meeting for CWMS Authorization Improvements contract

Meeting Agenda

Introductions
Verify current source code locations methods of contribution
Scheduling the regularly occurring meetings
General questions

Meeting Invitees and Attendees

Invitee	Present?	Org
Michael Neilson (host)	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	Y	USACE - HEC
Fauwaz Hanbali	Y	USACE - HEC
Jorge Hassan	Y	SolidLogix
Milver Valenzuela	Y	SolidLogix
Todd Boss	Y	SolidLogix
Ryan Cunningham	Y	SolidLogix
Christina Whitehead	Y	SolidLogix
Vairav Laxman	Y	SolidLogix

Meeting Detailed notes

Note: a Powerpoint deck was used to drive the meeting: see here: USACE CWMS Kickoff Meeting Presentation 2025.05.19.pdf

Agenda Item #1: Introduction of the teams

All team members from both sides were introduced, with tiles and job roles described. The project team for both the Government and the Contractor are as follows:

From SolidLogix:

Jorge Hassan - SolidLogix CEO, Executive Sponsor & Solutions Architect.
Milver Valenzuela - SolidLogix COO, Project Director.
Todd Boss - Project and Data Manager.
Ryan Cunningham - Senior Software Engineer.
Christina Whitehead - Business Analyst.
Vairav Laxman - Software Engineer.

From USACE HEC:

Michael Neilson - main technical POC, COR
Charles Graham - district staff member for ACE, community outreach/front-end
Eric Novotny - data team lead for water management section, database development
Fauwaz Hanbali - senior hydraulic engineer During the team introductions, the HEC team described the technical scope: CWMS Data API, time series authorization, cloud migration context, and stakeholder access goals.

Agenda Item #2: Verify current source code locations methods of contribution

The team discussed the current technical makeup of the project, discussed communication, tooling, and other development topics.

CWMS API is hosted publicly on GitHub – Solid Logix will fork it for contribution.
Docker Compose setup with local Oracle database image is available for local dev/testing.
HEC will share a ready database image, schema repo, and setup guides.
HEC to grant GitHub repo access and create DevNet SSO/rocket.chat accounts for Solid Logix team.
Fork-first development model will be followed; internal contributions may be considered later.
Rocket.Chat + Discourse to be used for real-time communication and stakeholder engagement.
Focus is on time series authorization and integration into the existing CWMS Data API.
Local schema includes metadata but not time series data – HEC can provide loading tools.
No CAC required now – if needed later, they'll work to expedite it.
Target architecture is cloud-first; PostgreSQL is preferred long term, but Oracle is current baseline.
Unit/integration tests will be run through GitHub Actions.
HEC is open to sharing real use cases, success criteria, and sample data once accounts are in place.
Mike to provide list of stakeholders for interviews.
HEC emphasized “open, opinionated, and collaborative” community culture.

Agenda Item #3. Scheduling the regularly occurring meetings The team discussed meeting cadence, plus discussed documentation initiatives and talked about other Project Management issues.

Bi-weekly meetings to be scheduled starting Monday, 5/27 @ 11AM EST / 8AM PST
Next Monday is a Federal Holiday: we’ll do a one-off Tuesday 5/28 meeting, then return to every other Monday cadence.
Todd will manage the cadence, project board (GitHub Projects), and wiki structure.
We will use GitHub Projects to do Task tracking
We will use GitHub Wiki for online documentation.
GitHub wiki and Issues will serve as the single source of truth for docs, MFRs, and meeting notes.
Formal MFRs (Memos for Record) will be used when decisions are finalized.
Both sides are on the same page w/r/t transparency and documentation, and we’ll do our best to use the tools and to document as much as possible.

Agenda Item #4: General questions and Next Steps. General Questions as documented in the Kickoff deck; the five major subject areas to cover were:

Source code & Collaboration
Environment & Infrastructure
Authorization Design Input
Stakeholders & Meetings
Additional Considerations.

Questions or blockers? Reach out via email or rocket.chat once available. The USACE team endeavors to be as responsive as possible, given their role as government employees.

All Next Steps are captured as Action Items with assignees.

Action Items

Action item	Assignee
HEC will share a ready database image, schema repo, and setup guides	HEC Team
HEC to grant GitHub repo access	HEC Team
Create DevNet SSO/rocket.chat accounts and Discourse action	HEC Team
Solid Logix to send GitHub usernames and team email list to HEC	Todd Boss
Schedule recurring Monday every two week meetings	Todd Boss
Mike to provide list of stakeholders for interviews.	Mike Neilsen
Solid Logix to try Docker Compose setup and report issues	SolidLogix Dev Team
Define repo structure (sub-project vs separate repo) by end of week	Team

Bi-Weekly Status Meeting 5/27/25

CWMS Database Authorization Bi-Weekly Status Meeting 5/27/25

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 5/27/25
Date/Time	5/27/25 11am EST/8am PST (note; this is off one day from normal cadence due to Federal Holiday on 5/26/25)
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Review Open Action Items for Status and Completion
Review Kanban Board Structure
Discuss Overall plan of attack for Project
Discuss Status of current Deliverables being worked
General Discussion, Questions

Meeting Invitees and Attendees

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	Y	USACE - HEC
Fauwaz Hanbali	Y	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Jorge Hassan	Y	SolidLogix
Milver Valenzuela	Y	SolidLogix
Todd Boss (host)	Y	SolidLogix
Ryan Cunningham	Y	SolidLogix
Christina Whitehead	Y	SolidLogix
Vairav Laxman	Y	SolidLogix
Raul Proenza	N	SolidLogix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date
HEC will share a ready database image, schema repo, and setup guides	HEC Team	Docker image provided in kickoff, complete	Done with 5/19/25 kickoff.
HEC to grant GitHub repo access	HEC Team/Mike	We can clone repo, fork USACE repo. One was private, now granted access to Ryan. Jorge and Vairav still need access. Mike sent emails to get things set up. Anyone should be able to edit wiki on the CDA project. Todd specifically invited by Mike to edit during Meeting; done	Done during 5/27/25 Meeting
Create DevNet SSO/rocket.chat accounts and Discourse action	HEC Team/Mike	Mike has informed internal Admin, not yet done. When done, we’ll get emails to indicate as such.
Solid Logix to send GitHub usernames and team email list to HEC	Todd Boss	Done, sent list of git usernames and emails to USACE team. Jorge to re-send today to add one more developer during meeting	5/20/25, 5/27/25 follow up done.
Schedule recurring Monday every two week meetings	Todd Boss	Done; scheduled one-off 5/27 meeting then every two-weeks cycle	5/20/25
Mike to provide list of stakeholders for interviews.	Mike Neilsen	Mike sending email imminently during meeting	Sent 5/27/25.
Solid Logix to try Docker Compose setup and report issues	Solid Logix team	Ryan: done. We have Docker compose done, now testing	5/23/25
Define repo structure (sub-project vs separate repo) by end of week	Team	Mike suggests starting as a subproject of the data api. Add it as a new directory in the existing repo.	Decision made 5/27/25

Meeting Detailed notes

Highlights:

The meeting centered on establishing the technical environment, onboarding procedures, and outlining collaboration methods.
The technical team confirmed the successful setup of initial development tools, including a containerized local environment and access to foundational schema resources.
Repositories and documentation relevant to the data API project were reviewed.
A Kanban-based tracking model will be used for task management and milestone tracking.
Early priorities include familiarization with the data API and associated UI planning.
Billing practices were aligned to tracked deliverables and development progress.

Key Technical Notes:

The system under development is a data-centric API supporting time series management and related operations.
A pre-configured container image was made publicly available for bootstrapping local development.
Development contributions will be managed within a shared repository, using GitHub Projects for coordination.
A Swagger-based interface is available for exploring API functionality.
Role-based access control (RBAC) and identity features are in progress but not mandatory for initial development.
Versioning is managed at the data layer; endpoint URLs do not include version tokens.
Time series endpoints are the first area of focus, followed by UI mockups aligned with planned access controls.

Action Items Discussion and Disposition

Local environment and schema access confirmed by both teams.
GitHub access permissions under review and being updated.
Access to internal collaboration tools (e.g., chat, wiki) is being provisioned.
Discussion underway on whether additional access to private repositories is needed.
A shared Kanban board is being built to reflect active and upcoming tasks.
A stakeholder list has been distributed via secure channel.
Initial invoice to be drafted based on progress indicators tied to Kanban status.
Project tooling permissions and access to be validated by developers.
Local development is preferred for now; potential cloud environment needs will be reassessed.
Contributors are encouraged to review shared documentation and example notebooks.

Action Items: New from this meeting

Action item	Assignee
Get Kanban fully populated with PWS tasks and subtasks	Todd Boss
Get billing process defined and ready to go	Milver, Todd
Confirm wiki/project edit capabilities just provided	Todd, Milver
Begin setting up Stakeholder interviews	Todd, Christina

Bi-Weekly Status Meeting 6/9/25

CWMS Database Authorization Bi-Weekly Status Meeting 6/9/25

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 6/9/25
Date/Time	6/9/25 11am EST/8am PST
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Review Open Action Items for Status and Completion
Review Kanban Board And Provide Updates on Epics and Tasks
General Discussion, Questions

Discussion to include:

Local setup of API and DB working
We are using Docker to run things locally
We see the skeletal tables in the CWMS schemas
We begun analysis of the API code base and are exploring solutions
Current plan is to focus on RBAC + ABAC approach options; in a spike we need more down time to do research

Meeting Invitees and Attendees

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	Y	USACE - HEC
Fauwaz Hanbali	N	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Jorge Hassan	Y	SolidLogix
Milver Valenzuela	Y	SolidLogix
Todd Boss (host)	Y	SolidLogix
Ryan Cunningham	Y	SolidLogix
Christina Whitehead	Y	SolidLogix
Vairav Laxman	Y	SolidLogix
Raul Proenza	N	SolidLogix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date
Create DevNet SSO/rocket.chat accounts and Discourse action	HEC Team/Mike	Mike has informed internal Admin, not yet done. When done, we’ll get emails to indicate as such. 6/9: Mike Escalating	Open
Confirm wiki edit capabilities	Todd, Milver	Confirmed wiki editing going forward	Closed 5/28/25
Confirm project edit capabilities	Todd, Milver	Project config issues remain, resulting in use of outside Project for now. Mike found issue, functionality restored, closing	Resolved 6/9/25
Get Kanban fully populated with PWS tasks and subtasks	Todd Boss	Kanban setup in SL project, moving forward	Done 6/4/25
Get billing process defined and ready to go	Milver, Todd	Done, first invoice generated	done 6/1/25
Begin setting up Stakeholder interviews	Todd, Christina	Christina created pre-survey and Skeleton, ready to schedule	Open

Meeting Detailed notes

Meeting Summary: Project Stakeholder Sync Participants: USACE Representatives and Solid Logix Team

Highlights Interview Preparation:

Solid Logix team developed a pre-interview survey and a structured interview guide to support upcoming stakeholder engagements. Approval from the agency is pending before scheduling begins.

Stakeholder Engagement Strategy:

One-on-one interviews are preferred to maximize feedback.
USACE will notify internal stakeholders; Solid Logix team will coordinate logistics and scheduling.
An additional stakeholder was identified for inclusion.

Local Development Environment:

Solid Logix team completed local environment setup using containerized deployment.
A key gap identified: lack of seeded data for validating access control configurations.
USACE agreed to provide example data in standard formats to support testing.

Technical Updates:

Recent changes improved how access control is managed in the codebase.
Test data injection via configuration files was recommended for local testing.
Current logging mechanisms do not expose all session context details; enhancements are planned.
Existing role enforcement is simplified, based on office-level permissions.

Security Model Planning:

The team plans to use data from interviews and system analysis to inform design of candidate access models.
Future tasks will include analyzing permissions and building hybrid RBAC/ABAC models.

Project and Repository Coordination:

Issues related to project board alignment and permissions on the version control platform were resolved.
Solid Logix team now has full access to submit and track issues.

Communication Logistics:

Some email delivery issues were reported between the two organizations, potentially due to attachments or server configurations.
Multiple recipients will now be CC’d to ensure communications are received.

Action Items

Resolve Communication Issues:

Solid Logix team to resend key emails and include additional recipients.
USACE team to investigate possible mail server filtering or quarantining.
See open action item for Rocket accounts escalation

Initiate Stakeholder Interviews:

Solid Logix team to send interview requests and begin scheduling.
Survey form will be updated to capture respondent identity for correlation.
Each interview will be scheduled as a one-on-one session (approx. 1 hour).

Seed Test Data:

USACE to prepare and share a limited dataset for local testing of security and access control logic.
Possible use of container-based utilities to automate loading of test data.

Repository and Task Tracking:

Project issues and Kanban tasks will now be tracked under the correct repository.
Access rights have been updated to allow task ownership and triage.

Next Phase Planning:

Solid Logix team to begin dependency and use-case gathering immediately after interviews.
Permission analysis and model design will follow based on insights gathered.

Action Items: New from this meeting

Action item	Assignee
USACE Seed Test Data	USACE Staff/Eric

Bi-Weekly Status Meeting 6/23/25

CWMS Database Authorization Bi-Weekly Status Meeting 6/23/25

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 6/23/25
Date/Time	6/23/25 11am EST/8am PST
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Review Open Action Items for Status and Completion
Review Kanban Board And Provide Updates on Epics and Tasks
General Discussion, Questions

Meeting Invitees and Attendees

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	N-OOO	USACE - HEC
Fauwaz Hanbali	N	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Jorge Hassan	N-conflict	SolidLogix
Milver Valenzuela	Y	SolidLogix
Todd Boss (host)	Y	SolidLogix
Ryan Cunningham	Y	SolidLogix
Christina Whitehead	Y	SolidLogix
Vairav Laxman	Y	SolidLogix
Raul Proenza	N	SolidLogix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date
Create DevNet SSO/rocket.chat accounts and Discourse action	HEC Team/Mike	Mike has informed internal Admin, not yet done. When done, we’ll get emails to indicate as such. 6/9: Mike Escalating. done 6/11, team confirming.	Done 6/11/25
Begin setting up Stakeholder interviews	Todd, Christina	Christina created pre-survey and Skeleton, ready to schedule, email config issue blocker resolved 6/11/25, emails sent and scheduling started	In progress 6/11/25; 1 done, 2 scheduled as of 6/23/25
USACE Seed Test Data	USACE Staff/Eric	Discussed 6/10/25, USACE actively working. goal is something by 6/13/25	Eric delivered 6/17
Resolve Email connectivity issues	Team	Emails not going through, SL diagnosed with USACE IT, discovered email MX/SPF record issue	resolved 6/11/25

Meeting Detailed notes

Summary

The team reviewed progress on test data implementation, stakeholder interviews, logging infrastructure, and auditing controls. Solid Logix provided updates on data loading and container compatibility. USACE participants discussed database auditing design choices, API access limitations, and evolving stakeholder interview strategies. Logging framework gaps and the need for structured telemetry were acknowledged. Invoicing processes were clarified. The meeting was collaborative and forward-looking, with early technical validation supporting downstream access control analysis.

Technical Insights

Test Data Branch & Execution (Solid Logix):
Seed data is being loaded from the feature/data-initialization branch, which builds on develop.
Jupyter Notebooks are present in the branch but have not yet been reviewed.
Execution is being validated through docker compose up against a clean environment.

Docker/Podman Compatibility (Solid Logix):

Docker Compose files are confirmed to run equivalently in Podman Compose.
This ensures interoperability across environments used by different developers (e.g., Docker vs. Podman).

Stack Initialization Quirk (Solid Logix):

The data-api occasionally starts too early in the stack, requiring a manual restart.
While not currently observed in Vairavan's setup, additional testing (e.g., hot reload scenarios) is underway.

DB Schema and VPD Integration (Solid Logix + USACE):

Seed data integration is essential to support upcoming VPD policy testing.
Visibility of role-based restrictions and schema alignment depend on successful test data deployment.

Logging Infrastructure (USACE):

Google Flogger and Tomcat backend are used but do not support structured logging effectively.
A future upgrade to a more robust logging system is under consideration but currently low priority.
Access Control & Embargo Considerations

API Usage Observability (USACE):

Access logs often lack originating IP addresses due to multiple proxy layers.
Some API usage occurs in district-local instances outside central observability.
Prometheus logging is being piloted in dev environments, with plans to capture office-level data context.

Oracle Auditing Policy (USACE):

SELECT auditing is disabled to prevent performance degradation.
Destructive operations (INSERT/UPDATE/DELETE) are typically logged.
Some districts may not have full audit enablement despite policy assumptions.

Data Embargo Enforcement (USACE):

A 10-day embargo is in place for certain operational data (e.g., power plant flows).
Embargoes are policy-driven and enforced through memorandums of understanding, not technical restrictions.
Some district-specific datasets may be withheld for commercial purposes.

Stakeholder Interviews Current Status (Solid Logix):

One interview completed. Two more scheduled.
Survey resends are planned to boost participation.
Persona Mapping & Permission Gap Analysis (Solid Logix):
Interview insights will inform future persona documentation and permission role design.

Participant Suggestions (USACE):

Emphasis placed on including non-technical and power users to balance perspectives.
External heavy API users such as NOAA were recommended for interview outreach.
GitHub commit metadata (e.g., TVA contributors) may help identify further stakeholders.

Action Items: New from this meeting

Action item	Assignee
Mike Would like to see RFC progress	Jorge/SL dev team
Invoicing process changed	Mike & Milver

Bi-Weekly Status Meeting 7/7/25

CWMS Database Authorization Bi-Weekly Status Meeting 7/7/25

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 7/7/25
Date/Time	7/7/25 11am EST/8am PST
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Review Open Action Items for Status and Completion
Review Kanban Board And Provide Updates on Epics and Tasks
General Discussion, Questions

Meeting Invitees and Attendees

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	Y	USACE - HEC
Fauwaz Hanbali	N	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Jorge Hassan	Y	SolidLogix
Milver Valenzuela	Y	SolidLogix
Todd Boss (host)	Y	SolidLogix
Ryan Cunningham	Y	SolidLogix
Christina Whitehead	Y	SolidLogix
Vairav Laxman	Y	SolidLogix
Raul Proenza	N	SolidLogix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date
Mike Would like to see RFC progress	Jorge/SL dev team	Reviewed during 7/7 status meeting	7/7/25
Invoicing process changed	Mike & Milver	Resolved with invoice pmt success	7/1/25

Meeting Detailed notes

Administrative Updates/Action Item resolution:

Invoicing issues have been resolved successfully; the first payment was confirmed received.
Discussed potential updates to the Request for Comment (RFC) process.

Technical Progress:

The database and schema analysis, including Virtual Private Database (VPD), is progressing well with successful installation and initial data analysis.
The team requested clarification on VPD behavior and received guidance regarding office-based data segregation.

Stakeholder Interviews:

Completed five stakeholder interviews covering technical and end-user perspectives, gaining substantial insights.
Plans to follow up with additional stakeholders and begin detailed persona development based on insights gathered.
Highlighted important user workflow differences between GUI-driven users and more technical, database-oriented users.

Proposed Architectural Changes (RFC Discussion):

Proposal to introduce a middleware (authorization service layer) ahead of the existing API to handle authorization and caching, minimizing changes to the current API implementation.
Discussed adopting an in-memory policy engine (Open Policy Agent - OPA) and a transparent proxy pattern.
Emphasized performance considerations, caching mechanisms, and minimal API code modification to facilitate future migrations.
General positive reception by all stakeholders regarding the architectural proposal.

Next Steps:

Prepare and submit the RFC document formally to stakeholders for review and feedback.
Schedule a dedicated technical discussion meeting, tentatively planned for the week of the 21st.
Begin consolidating insights from stakeholder interviews and technical analyses into structured documentation to inform solution designs.

Action Items:

Administrative:

Confirm ongoing success of invoicing processes.

Technical:

Provide guidance on specific users and API behaviors related to VPD for clearer analysis and testing.
Finalize and submit the RFC document outlining the proposed middleware and authorization changes.

Stakeholder Interviews:

Continue scheduling and conducting remaining stakeholder interviews.
Follow up with stakeholders who have not yet responded.

Documentation and Analysis:

Schedule internal sessions to integrate interview insights and technical analyses into formal documentation.
Prepare structured persona definitions and use-case scenarios based on interviews.

Future Technical Discussions:

Arrange detailed RFC and architecture discussion meeting post-RFC submission for stakeholder validation and approval.

Action Items: New from this meeting

Action item	Assignee
Iterate internally on RFC	SolidLogix Team
Set up 1st Dev Meeting to review RFC	Todd Boss
Create ADR from RFC content and discussions	Vaira
Setup internal meeting to combine role findings from interviews and analysis	Todd Boss

Bi-Weekly Status Meeting 7/21/25

CWMS Database Authorization Bi-Weekly Status Meeting 7/21/25

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 7/21/25
Date/Time	7/21/25 11am EST/8am PST
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Review Open Action Items for Status and Completion
Review Kanban Board And Provide Updates on Epics and Tasks
General Discussion, Questions

Meeting Invitees and Attendees

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	Y	USACE - HEC
Fauwaz Hanbali	N	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Jorge Hassan	Y	SolidLogix
Milver Valenzuela	Y	SolidLogix
Todd Boss (host)	Y	SolidLogix
Ryan Cunningham	Y	SolidLogix
Christina Whitehead	Y	SolidLogix
Vairav Laxman	Y	SolidLogix
Raul Proenza	N	SolidLogix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date
Set up 1st Dev Meeting to review RFC	Todd Boss & Team	Open; waiting for SolidLogix internal discussions	--

Meeting Detailed notes

Agenda & Status Updates

Quickly reviewed outstanding action items and current Kanban board progress.
Confirmed that most Phase 1 tasks (interviews, database analysis, code inventory) are on track.

RFC (Authorization Middleware)

The draft RFC has been posted to the project wiki for government review.
Discussion of where the proxy/OPA code should live (separate TypeScript repo vs. existing CDA repo).
Plan to capture deeper design decisions in standalone ADRs once RFC feedback is received.
Government team to review and comment on the high-level architecture and technology choices.

Tech Stack Rationale

Reaffirmed choice of TypeScript + Fastify proxy over Go/Rust based on team expertise, hot-reload velocity, and acceptable performance.
Acknowledged potential for future Rust/Go modules if ultra-low-latency demands arise.

Interview Progress

Completed 8–9 stakeholder interviews spanning Army Corps, NOAA, and cloud-migration teams.
Gathering final “dam operator” persona remains; once secured, interview phase will close.
Consolidation of all findings into a unified use-case and gap-analysis document is underway.

Next Steps & Roadmap

Government to provide RFC comments via wiki PR.
Move RFC content to a dedicated wiki page for easier line-by-line review.
Schedule and conduct the final dam-operator interview.
Finalize interview summary and gap analysis document.
Draft ADRs for proxy pattern, caching strategy, and policy management.
Align on Phase 1 deliverables scope and funding before entering detailed design.

Action Items

Government Team

Review the RFC in the wiki and submit feedback.
Suggest names for the final dam-operator interview.

Contractor Team

Relocate RFC to its own wiki page and open a PR for comments.
Coordinate and conduct the remaining persona interview.
Compile all interview insights into a consolidated summary.
Prepare ADRs covering each core design component.
Confirm Phase 1 scope and update the Kanban board accordingly.

Bi-Weekly Status Meeting 8/4/25

CWMS Database Authorization Bi-Weekly Status Meeting 8/4/25

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 8/4/25
Date/Time	8/4/25 11am EST/8am PST
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Review Open Action Items for Status and Completion
Review Kanban Board And Provide Updates on Epics and Tasks
General Discussion, Questions

Meeting Invitees and Attendees

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	Y	USACE - HEC
Fauwaz Hanbali	N	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Jorge Hassan	N - travel	SolidLogix
Milver Valenzuela	Y	SolidLogix
Todd Boss (host)	Y	SolidLogix
Ryan Cunningham	N - conflict	SolidLogix
Christina Whitehead	Y	SolidLogix
Vairav Laxman	Y	SolidLogix
Raul Proenza	N	SolidLogix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date
Relocate RFC to its own wiki page and open a PR for comments.	Todd Boss & Vaira	done, see PR https://github.com/USACE/cwms-data-api/pull/1213	8/5/25
Review the RFC in the wiki and submit feedback.	Mike and team	Pending release of above PR; blocked	tbd
Set up 1st Dev Meeting to review RFC	Todd Boss & Team	Open; waiting for USACE signoff on RFC mods, which is blocked by the two above action items.	tbd
Suggest names for the final dam-operator interview.	Charles	Emailed 8/5/25 to solicit suggestions	tbd
Compile all interview insights into a consolidated summary.	SLX team	Interview artifacts collected on internal SLX site as we went, findings documented in Use case task to be included in Task 2 deliverable.	7/28/25
Prepare ADRs covering each core design component.	SLX team	On hold until Task 3 commences.	tbd

Meeting Detailed notes

RFC and PR Workflow

RFC will be transitioned into a GitHub Pull Request (PR) to streamline comments and collaboration.
PR creation will unblock at least three related development items.
RFC content currently on a large internal wiki will be moved to a modular PR page.

Interview Findings

Dam operators are highly focused on their own assigned dams.
Cross-dam support only occurs during outages or coverage needs.
Interviews provide useful insights but are not mandatory for deliverables.

Privacy Measures

Names and email addresses will be anonymized in all publicly posted materials.
Emails removed from documents to prevent scraping or misuse.
Uploads to GitHub will follow privacy best practices.

Task Two Deliverable Status

Draft includes:
- Comparative analysis of policy rules vs. RBAC/ABAC.
- Compliance overview and benefit breakdown.
- High-level system design proposal.
Recommendation: Adopt Open Policy Agent (OPA) due to flexibility.
Markdown-based deliverable to be published after internal review.

Wiki and Documentation Cleanup

Existing RFC content to be split from a large internal page into a clean wiki hierarchy.
Modular PR pages will preserve a more usable table of contents structure.

Development Environment Setup

Local development environment configured using Docker and Podman.
Java container supports hot reload during development.
taskfile or justfile under evaluation for automated dev setup workflows.

Implementation Planning

Tasks for Phase 1A and 2 are on track to complete by August 15.
Implementation plan being developed collaboratively.
Task Three items are in backlog, pending initiation.

Language Clarification

Documentation will note "Maintenance and ownership by USACE post-delivery" to avoid misinterpretation of ongoing ownership.
Revised text will align with current contract obligations only.

Deliverable Review Strategy

Draft sections will be submitted early for review, ahead of formal due date.
Iterative writing, review, and final stitching planned over next two weeks.

File Location and Submission

All deliverables and RFC content will be submitted in markdown format.
New folder docs/source/RFC will house RFC materials for version control.

Contract Planning Considerations

Future contracts should allow staggered deliverable submissions before POP end.
Receiving deliverables in logical chunks is strongly preferred over large final drop.
Current contract used single start/end dates due to USACE system constraints.

Action Items: New from this meeting: added to next agenda.

Reach out to Northwest district to identify potential dam operator contact.
Ensure USACE maintenance ownership language in final deliverable.
Create the RFC PR and set up docs/source/RFC directory.
Finalize and iterate on deliverable content.
Discuss early draft section release by August 11.

Bi-Weekly Status Meeting 8/18/25

CWMS Database Authorization Bi-Weekly Status Meeting 8/18/25

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 8/18/25
Date/Time	8/18/25 11am EST/8am PST
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Review Open Action Items for Status and Completion
Review Kanban Board And Provide Updates on Epics and Tasks
```
 Review Phase 2 Deliverable
```
General Discussion, Questions

Meeting Invitees and Attendees

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	Y	USACE - HEC
Fauwaz Hanbali	Y	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Jorge Hassan	Y	SolidLogix
Milver Valenzuela	Y	SolidLogix
Todd Boss (host)	Y	SolidLogix
Ryan Cunningham	N (conflict)	SolidLogix
Christina Whitehead	Y	SolidLogix
Vairav Laxman	Y	SolidLogix
Raul Proenza	Y	SolidLogix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date
Relocate RFC to its own wiki page and open a PR for comments. Create the RFC PR and set up `docs/source/RFC` directory.	Todd Boss & Vaira	done, see PR https://github.com/USACE/cwms-data-api/pull/1213	8/5/25
Review the RFC in the wiki and submit feedback.	Mike and team	Pending release of above PR; unblocked 8/5/25	tbd
Set up 1st Dev Meeting to review RFC	Todd Boss & Team	Open; waiting for USACE signoff on RFC mods, which is blocked by the two above action items.	tbd
Suggest names for the final dam-operator interview. Suggest someone in NW district	Charles	Emailed 8/5/25 to solicit suggestions, had email conversation about topic to conclude not necessary.	8/6/25
Compile all interview insights into a consolidated summary.	SLX team	Interview artifacts collected on internal SLX site as we went, findings documented in Use case task to be included in Task 2 deliverable.	7/28/25
Prepare ADRs covering each core design component.	SLX team	On hold until Task 3 commences.	tbd
Ensure USACE maintenance ownership language in final deliverable.	SLX team	removed language from RFC and from deliverable	8/5/25 done.
Finalize and iterate on deliverable content.	SLX Team	This is our primary goal in the next 2 weeksj; delivered content 8/13/25	8/13/25
Discuss early draft section release by August 11.	SLX Team	As we finalize review on sections we will release. Released all 9 sections 8/13/25	8/13/25

Meeting Detailed notes

Highlights (what actually got decided or clarified)

Schedule a dev meeting and close the RFC loop. Team agreed to set up a dev meeting this week to drive a final decision and then close the RFC; an ADR will follow (phase 3).
Phase 2 deliverable is in; Kanban shows Task 2 work done. Authorization plan report is the only item in review; remaining items are placeholders for contract mgmt and biweekly meetings.
Direction call: Option 1 (OPA) and Option A (CLI) selected. USACE explicitly favored Option 1 due to no DB changes, better fit with other services, lower effort (~60% less), and faster performance; group aligned on Option A (CLI) and lowering web UI priority. Transparent proxy + Java helper approach affirmed; VPD becomes optional later. Proxy injects an x-cwms-auth-context header consumed by a Java helper; this enables gradual migration and keeps existing APIs stable.
Rego debugging approach: use OPA eval/explain + structured logs; unit tests. Emphasis on decision logs and native OPA tooling for troubleshooting.
Docs hygiene: remove full last names from deliverables. Captured as an action in the meeting.
Public timeseries question is a real, near-term use case. Districts need an easy way to mark and update what is public, potentially with per-series embargo windows; team discussed CLI policy updates, PR-driven persistence, and possibly automating from an existing DMZ include list (currently on S3). Biweekly meeting time shift. Agreement to move the meeting 30 minutes earlier (10:30 ET / 7:30 PT).

Gaps and watch-outs

Who can set 'public' and how granular is the rule. You still need the exact governance model (district admins only? central overrides?) and whether 'public' is a series-level flag with time windows or record-level classification. Today it is discussed, not finalized.
Non-technical pathway for districts. Team floated keeping the legacy DMZ include list and auto-generating policies from it to avoid forcing PRs for every change. That path needs a concrete design.
Decision logging scope. Strong leaning toward structured JSON logs; whether to persist an audit table now vs later is still a scope choice tied to RMF evidence. Meeting favored logs-first.
GUI deprioritized, but some minimal visual test harness may still help. Reviewers noted a lightweight visual test (Rego playground-like) could be useful later, but not blocking.

Action items (owner → action → when)

Solid Logix → Schedule dev meeting to finalize RFC decision and outline ADR topics; send invite this week.
Solid Logix → Draft ADR for core design components (phase 3) once the dev decision is captured.
Solid Logix → Sanitize deliverables by removing full last names and re-upload.
USACE (Eric) → Document current 'public list' process (DMZ include list/S3 path, update cadence, ownership); share with Solid Logix.
Solid Logix → Propose automation: ingest DMZ include list and generate/patch OPA policies (with CI job + PR backstop). Include rollback story.
Solid Logix → Provide Option A CLI sketches: o grant public read to a series, o set per-series embargo window, o list/rollback changes; wire to Git policy repo + OPA bundle deploy.
Solid Logix → Confirm logging plan: location, schema, and routing of JSON decision logs to CloudWatch/Splunk; include 'why denied' trace hooks for Rego.
USACE + Solid Logix → Move the biweekly meeting 30 minutes earlier (10:30 ET / 7:30 PT); update the standing invite.
Solid Logix → Publish Kanban refresh for the next phase: epics/tasks cadence, visibility of RFC closure, and ADR workstream.

Bi-Weekly Status Meeting/Phase 3 Development Meeting 9/2/25

CWMS Database Authorization Bi-Weekly Status Meeting/Phase 3 Development Meeting 9/2/25

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting/Phase 3 Development Meeting 9/2/25
Date/Time	9/2/25 10:30am EST/7:30am PST
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Review Open Action Items for Status and Completion
Review Kanban Board And Provide Updates on Epics and Tasks
Discuss Outstanding questions related to Phase 2 Deliverable
Discuss Phase 3 Plan of Action
Discuss ADRs and RFC
General Discussion, Questions

Meeting Invitees and Attendees

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	Y	USACE - HEC
Fauwaz Hanbali	N	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Jorge Hassan	Y	SolidLogix
Milver Valenzuela	N-ooo	SolidLogix
Todd Boss (host)	Y	SolidLogix
Ryan Cunningham	Y	SolidLogix
Christina Whitehead	Y	SolidLogix
Vairav Laxman	Y	SolidLogix
Raul Proenza	N	SolidLogix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date
Review the RFC in the wiki and submit feedback.	Mike and team	RFC posted, waiting for feedback	tbd
Set up 1st Dev Meeting to review RFC	Todd Boss & Team	Open; waiting for USACE signoff on RFC mods, which is blocked by the two above action items.	tbd
Prepare ADRs covering each core design component.	SLX team	On hold until Task 3 commences.	tbd
Convert all names to First Name Last Initial in public facing deliverables	Vaira	tbd	tbd
Change regular bi-weekly meeting to be 10:30am	Todd	this avoids conflicts for several key staff	done for 9/2/25 going forward

Key Discussion Points

Action Items from Last Meeting

RFC review: Modifications were posted, PR opened, not yet merged but no additional comments. Resolution: merge is pending and will close related items.
ADRs: Task 3 deliverable, in early progress. Vairav starting work.
Name cleanup: Converting full names to initials flagged as a quick fix, to be handled immediately.
Meeting schedule: Regular time shifted to 10:30 AM Eastern to avoid conflicts.

Project Phase Status

Phase 2 deliverable: Still in review until sign-off, only open issue is name formatting.
Phase 3: Officially started; requires 12 biweekly dev meetings over ~6 months (due Feb).
Features now replacing high-level epics on Kanban. Each feature (3A, 3B, etc.) maps to multiple deliverables.

Task 3 Progress

Feature 3A (Foundation & Architecture) has 10–12 tasks, some already in progress (e.g., monorepo structure, ADRs).
Eric’s email raised important questions; response being carefully drafted as a working doc to avoid over-committing in contract language.
Solid Logix team already held internal planning sessions, producing detailed task lists (not yet all transcribed to Kanban).

Process & Collaboration

Emphasis on using small/draft PRs early to surface issues and course-correct.
Agreement that incremental delivery worked well in Phase 2 (chapters submitted early).
Contractors encouraged to participate in CDA endpoints/documentation meeting even if not directly in contract scope, for shared understanding.

Logistics

Next biweekly in two weeks.
Some leaders (Mike) will be OOO next week; others (Eric, Charles) will handle decisions in his absence.

Action Items (put into next meeting agenda)

Merge RFC PR (Mike/Charles) to formally close two open items.
ADRs – @Vairav Laxman to draft and begin circulating for review.
Name cleanup (convert full names to initials) to be completed promptly. @Todd Boss who is handling this?
Eric’s Questions – Solid Logix to deliver structured written response document.
Update Kanban – Ensure new features/tasks for Phase 3 are fully transcribed.
CDA endpoints meeting – Confirm attendees (Todd, others welcome).
Maintain cadence – Biweekly dev meetings through February, focus on incremental PRs.

Bi-Weekly Status/Phase 3 Development Meeting 9/15/25

CWMS Database Authorization Bi-Weekly Status/Phase 3 Development Meeting 9/15/25

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 9/15/25
Date/Time	9/15/25 10:30am EST/7:30am PST
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Review Open Action Items for Status and Completion
Review Kanban Board And Provide Updates on Epics and Tasks
Review of CDA API call, impact on project (Jorge)
General Discussion, Questions

Meeting Invitees and Attendees (Note: not all invitees are expected to be regular attendees)

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	Y	USACE - HEC
Fauwaz Hanbali	N	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Jorge Hassan	Y	SolidLogix
Milver Valenzuela	Y	SolidLogix
Todd Boss (host)	Y	SolidLogix
Ryan Cunningham	N - ooo	SolidLogix
Christina Whitehead	Y	SolidLogix
Vairav Laxman	N - ooo	SolidLogix
Raul Proenza	N	SolidLogix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date
Merge RFC PR	Mike/Charles	Formally close two open items.	tbd
Set up 1st Dev Meeting to review RFC	Todd Boss & Team	Open; waiting for USACE signoff on RFC mods, which is blocked by the RFC merge	tbd
Convert all names to First Name Last Initial in public facing deliverables	SLX Team	done; RFC updated to obfuscate names	9/8/25
Include Architectural response to Eric N's Questions	SolidLogix	Solid Logix to deliver structured written response document	tbd
Prepare ADRs covering each core design component.	SLX team	ADR development underway, not a blocker for progress	tbd

Meeting Detailed notes

RFC and ADR Status

The team confirmed the initial design RFC pull request is effectively resolved and agreed it no longer blocks development.
A follow-up Architectural Decision Record (ADR) will capture any remaining architectural clarifications as the project moves forward.

Documentation Strategy

Significant design feedback will be captured in reStructuredText (RST) or markdown so it can be merged into the main documentation.
Less critical notes can remain in GitHub discussions or PR comments, with a final documentation pass planned before project completion.
The team also discussed ensuring that any change that materially affects the architecture is recorded in RST to provide a permanent reference for future maintainers.

Fastify Proxy Role

The Node.js Fastify service is acting as a lightweight authorization proxy in front of the CWMS Data API.
It validates JWTs, injects an x-cwms-auth-context header, and forwards traffic to the backend, making it a key trust point for the system.

JWT vs. mTLS Security Discussion

The group debated whether relying solely on JWT verification is sufficient or whether mutual TLS (mTLS) should be added for defense-in-depth.
Traefik (the reverse proxy in the stack) likely supports mTLS, but this requires internal PKI planning and is not a current contractual requirement.

Early OPA Development Plan

Developers will open a work-in-progress pull request with initial OPA integration before the next meeting, merging incremental progress to avoid a massive single PR.
A semi–test-driven approach will be used, starting with a Postman collection for API-level integration tests while evaluating Java-based test frameworks (Rest-Assured) for reuse.

Incremental Development Mindset

The team reaffirmed a strategy of small, frequent pull requests to reduce review risk and speed feedback as OPA features roll out.

Testing Philosophy

They endorsed a "test-guided" development style—lighter than strict test-driven development—using Postman integration tests first, while exploring whether existing Java Rest-Assured tests can be reused for automated regression coverage.

API Walkthrough Series

The ongoing API walkthrough meetings will continue, with summaries being captured for inclusion in RST documentation.
These notes may eventually be made accessible to trusted external stakeholders once a hosting location is finalized, providing a baseline for public technical documentation.

Environment & Deployment

The team discussed container placement relative to the Traefik proxy and tentatively favored placing the new container in front for simplicity and easier mTLS integration.
Mutual TLS (mTLS) is not a contractual requirement but will be investigated as an added trust mechanism.

Collaboration & Access

Meeting notes and API documentation will be shared internally, and a suitable public or semi-public repository (outside restricted SharePoint) will be identified to enable contractor access.

Gaps and Future Risk items

Documentation Hosting – Final decision on where to host and merge architectural notes (GitHub repo, RST site, or alternative) is still pending.
Testing Integration – Alignment is needed on whether to keep Postman tests separate or integrate with the existing Java Rest-Assured test framework.
mTLS Feasibility – While desirable, enabling mTLS depends on internal PKI readiness and requires further investigation.

Action Items (these are transcribed into Action Item section of next meeting for immediate discussion)

Solid Logix team → Open a work-in-progress pull request for initial OPA integration and merge incremental progress before the next dev meeting.
Solid Logix team → Draft an ADR capturing architectural decisions and feedback once RFC closure is confirmed in the next phase.
Solid Logix + USACE leads → Decide on final documentation hosting (GitHub RST site, OneNote alternative, or other) and provide external access during the upcoming sprint.
Solid Logix team → Build an initial Postman collection for API integration testing and evaluate reuse of Java Rest-Assured tests in the next sprint.
Solid Logix team → Confirm container placement relative to Traefik and document the decision in the next sprint.
Solid Logix team → Investigate feasibility of enabling mTLS within the current proxy setup and report findings in the next sprint.
Solid Logix team → Continue API walkthrough documentation and share baseline notes in the agreed repository on an ongoing basis.

Bi-Weekly Status/Phase 3 Development Meeting 9/29/25

CWMS Database Authorization Bi-Weekly Status/Phase 3 Development Meeting 9/29/25

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 9/29/25
Date/Time	9/29/25 10:30am EST/7:30am PST
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Review Open Action Items for Status and Completion: note change in Action Item Tracking to just administrative/non-delivery items.
Review Kanban Board And Provide Updates on Epics and Tasks
Demo of Authorization Middleware/Transparent Proxy component functionality
Discussion of Deliverable work for coming two weeks
General Discussion, Questions

Meeting Invitees and Attendees (Note: not all invitees are expected to be regular attendees)

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	Y	USACE - HEC
Fauwaz Hanbali	N	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Jorge Hassan	Y	SolidLogix
Milver Valenzuela	Y	SolidLogix
Todd Boss (host)	Y	SolidLogix
Ryan Cunningham	Y	SolidLogix
Christina Whitehead	Y	SolidLogix
Vairav Laxman	Y	SolidLogix
Raul Proenza	N	SolidLogix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date
Open a work-in-progress pull request	SolidLogix	for initial OPA integration and merge incremental progress	Moot with dedicated Repo, closed
Decide on final documentation hosting	SolidLogix and USACE Leads	GitHub RST site, OneNote alternative, or other, then provide external access	Decided to use GitHub RST; closed

Meeting Detailed notes

Transparent Proxy and Monorepo Demo

The team demonstrated a working Fastify-based transparent proxy inside an NX monorepo, running alongside OPA, Keycloak, Redis, and the CWMS Data API in a Podman container stack.

Structured Logging and Testing

Structured JSON logging (Pino) is enabled, and Postman collections are in place for health checks, proxy calls, and OPA policy evaluation.

Dynamic Time Series Approach

Mike raised the need to keep the existing DMZ include list workflow. Vairav confirmed the plan to pull time series IDs from the CWMS database, cache them in Redis, and push updates dynamically to OPA via a lightweight service and optional event bridge.

Next Steps

Move the codebase to the USACE GitHub repo
clean up the proxy service
add basic Rego rules
integrate Redis caching with OPA.

Infrastructure Choices

Redis is currently used for caching but may be swapped for Valkey if licensing or performance needs dictate.
OpenTelemetry will be used for metrics, and Traefik placement for the proxy remains a design decision.

Gaps and Watch-Outs

Policy Management Complexity: Even with Redis as a data store, dynamic updates must be carefully designed to avoid policy bloat and ensure OPA data documents remain manageable.
UI vs CLI Scope: Discussion revealed uncertainty about how much end-user role management (creating roles, assigning users) will require a UI versus CLI tools.
Network Exposure: The CWMS private subnet needs clear documentation for exposing required ports (e.g., 701, 8181) to support development and testing.
Postman Limitations: The free Postman version limits team collaboration and may require exporting or alternative tools.

Action Items

Administrative

GitHub Migration: Move the current working repo to the official USACE GitHub organization and establish PR-based workflows.
Documentation Hosting: Finalize GitHub RST documentation hosting and begin pushing setup guides, Postman collections, and known issues.
Extension List: Provide a recommended VS Code extension list and decide whether to include a shared config directory.
Shutdown Contingency: Monitor government shutdown communications; work can continue unless explicitly paused.

Technical (to be reflected in Kanban Board)

Integrate Redis with OPA: Configure OPA containerized service and Fastify proxy foundation (In Progress)
Extends the existing proxy and OPA configuration tasks by adding the lightweight service that pulls time series IDs from the CWMS DB into Redis and updates OPA data documents dynamically.

Role and Policy UI Strategy

Project documentation structure (Ready to Pickup) and potentially a new task
The current board does not have a task focused on user-facing UI/CLI decisions.
Create a new task such as Define Role Management UI/CLI scope.

Traefik Gateway Decision

Container placement relative to Traefik (Ready to Pickup)
Direct continuation of the container placement and network configuration task.

Metrics Implementation

Fastify proxy foundation (In Progress) or create a sub-task
Add a sub-task like Integrate OpenTelemetry metrics and structured logging under the proxy foundation item.

Environment Hardening

Network configuration between services (Ready to Pickup)
Covers documenting and exposing the necessary container network ports and security settings.

Policy Repository Split

Project documentation structure (Ready to Pickup) or create a new task
If long-term policy storage is not captured, create a new task such as Create dedicated OPA policy repository and CI/CD pipeline.

Rego Rules Expansion

Develop base OPA policies (Backlog)
Expands on the existing task to move from the sample allow-all policy to real deny and role-based rules.

Bi-Weekly Status/Phase 3 Development Meeting 10/16/25

CWMS Database Authorization Bi-Weekly Status/Phase 3 Development Meeting 10/16/25

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 10/16/25
Date/Time	10/16/25 10:30am EST/7:30am PST (Moved from regular 10/13/25 spot for Federal Holiday)
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Review Open Action Items for Status and Completion: note change in Action Item Tracking to just administrative/non-delivery items.
Review Kanban Board And Provide Updates on Epics and Tasks
Demo of functionality/code: Structure of code, readme, Documentation, verification of multi-desktop functionality, Postman, UI, CLI
Discussion of Deliverable work for coming two weeks
General Discussion, Questions

Meeting Invitees and Attendees (Note: not all invitees are expected to be regular attendees)

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	N	USACE - HEC
Eric Novotny	Y	USACE - HEC
Fauwaz Hanbali	N	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Jorge Hassan	Y	SolidLogix
Milver Valenzuela	Y	SolidLogix
Todd Boss (host)	Y	SolidLogix
Ryan Cunningham	Y	SolidLogix
Christina Whitehead	Y	SolidLogix
Vairav Laxman	Y	SolidLogix
Raul Proenza	N	SolidLogix
Gabriel Zepeda	N	SolidLogix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date

Meeting Detailed notes

Highlights

The CWMS Database Authorization project successfully transitioned its codebase into the official USACE GitHub organization repository. All baseline architectural and foundational components are now in place.
The development environment setup guide was validated across Windows and macOS, ensuring cross-platform compatibility.
The containerized environment now includes Keycloak (authentication), OPA (policy engine), Redis (caching), Traefik (proxy), the Authorization Proxy, a Management API, and a Management UI.
The Management UI (React + Tailwind) and CLI (React-based terminal app) were demonstrated, both retrieving users, roles, and policies from Keycloak through the Management API.
The Postman collection was reorganized and integrated into the repository for consistent API validation, including health checks and proxy testing.
Keycloak JWT authentication is functional; authorization policy enforcement will be the next major milestone.
The team agreed to make progress with Architectural Decision Records (ADRs) reflecting Eric's feedback before implementing full policy enforcement.
CI/CD pipeline configuration will be finalized in the new repo to ensure quality and automated deployment.
USACE team members confirmed satisfaction with progress and requested use of existing USACE authentication context providers instead of creating a new one.

Gaps and Watch-Outs

Policy Enforcement Pending: The OPA container currently loads placeholder policies; no enforcement is implemented yet.
Auth Context Duplication: The proxy temporarily uses a custom authentication context. USACE requested replacing this with their existing standard implementation.
Documentation Expansion: Setup and architecture documentation need refinement to incorporate Eric's and USACE's previous feedback.
CI/CD Finalization: GitHub Actions workflows must be verified and ported completely to the USACE org repo.
Policy Detail in UI/CLI: Current policy view is minimal; detailed rule display and enforcement feedback are not yet implemented.

Action Items

Administrative (to be reflected in Action Items if new)

Solid Logix / Jorge: Incorporate Eric's architectural feedback into ADRs and documentation.
Solid Logix / Todd: Prepare Kanban subviews grouped by epics/features for clearer visibility.
USACE / Mike & Eric: Provide additional reference for the existing authentication context library to ensure integration alignment.
All: Confirm next bi-weekly meeting on October 27 and continue async collaboration via email and Rocket.Chat.

Technical (to be reflected in Kanban Board)

Add OPA Policy Enforcement → Expand existing "Develop base OPA policies" task to implement actual rule evaluation.
Integrate Existing Auth Context → New task under "Authorization Proxy foundation" to replace temporary login handling with USACE's standard OIDC/OAuth2 context.
Finalize CI/CD Pipeline → Under "Infrastructure setup," confirm GitHub Actions transfer and add automated test runs.
Enhance Management UI/CLI Policy Display → Extend "Management UI" and "CLI Tooling" tasks to show granular policy details.
Update Documentation & ADRs → Under "Documentation structure," add a subtask for Eric's feedback integration and architectural clarification.
Continue Postman Collection Maintenance → Add to "Testing & Validation" to ensure regression coverage grows with new endpoints.

Bi-Weekly Status/Phase 3 Development Meeting 10/27/25

CWMS Database Authorization Bi-Weekly Status/Phase 3 Development Meeting 10/27/25

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 10/27/25
Date/Time	10/27/25 10:30am EST/7:30am PST
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Introduction of new team member Gabriel Zepeda
Review Open Action Items for Status and Completion: note change in Action Item Tracking to just administrative/non-delivery items.
Review Kanban Board And Provide Updates on Epics and Tasks
Demo of functionality/code:
Discussion of Deliverable work for coming two weeks
General Discussion, Questions

Meeting Invitees and Attendees (Note: not all invitees are expected to be regular attendees)

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	N	USACE - HEC
Fauwaz Hanbali	N	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Jorge Hassan	Y	SolidLogix
Milver Valenzuela	Y	SolidLogix
Todd Boss (host)	Y	SolidLogix
Ryan Cunningham	Y	SolidLogix
Christina Whitehead	Y	SolidLogix
Vairav Laxman	Y	SolidLogix
Raul Proenza	N	SolidLogix
Gabriel Zepeda	Y	SolidLogix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date
Prepare Kanban subviews grouped by epics/features for clearer visibility.	Todd Boss	in progress: first two features done and live in Kanban Board	tbd

Meeting Detailed notes

Highlights

New engineer onboarded: Gabriel spun up the stack with minimal help and confirmed Docker can be used interchangeably with Podman for local dev. Team validated that core boilerplate and architecture are in place.
UI and CLI demos: React/Tailwind Management UI shows users/roles; React-based CLI (Ink) shares data adapters and access layers with the UI; both authenticate and list users/roles/policies. Next step is rendering OPA policies in the UI and CLI.
Proxy responsibility clarified: Transparent proxy will handle top-level denials (for example, unauthenticated POST), but fine-grained decisions and partial responses remain the CDA service's job. Team aligned on not over-validating at the proxy.
Code quality and process: Kanban epics/label views are being organized; small, frequent PRs encouraged; local containers have been stable; UI theming will align with USACE standards.

Gaps and Watch-Outs

Policies view and enforcement are not yet implemented in the UI/CLI; this is the stated next focus.
Auth context: Team intends to leverage USACE's existing auth context/provider; integration still pending.
Licensing/attribution: Portions of an Ink table component were ported; explicit attribution and a bill of materials must be added.
Access and adoption: Mike has not run the stack yet; access to the identity provider is still outstanding; Gabriel needs Rocket.Chat access for rapid feedback.

Action Items

Administrative

Resolve access to the identity provider for USACE participants who need it.
Finish organizing Kanban label/epic views so progress across tranches is visible.
Align UI theming with USACE standards and note any required style guides.

Technical (to be reflected in Kanban Board)

Implement Policies page in the Management UI and equivalent views in the CLI; surface policy details meaningfully.
Integrate USACE's existing auth context/provider into the proxy and management tooling; replace temporary local auth.
Add explicit license attribution and a bill of materials for the ported Ink table and any third-party code.
Document Docker vs Podman steps in the setup guide; confirm parity across Windows/macOS.
Keep proxy logic limited to top-level denials and pass contextual decisions to CDA; capture this boundary in ADRs.

Bi-Weekly Status/Phase 3 Development Meeting 11/10/25

CWMS Database Authorization Bi-Weekly Status/Phase 3 Development Meeting 11/10/25

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 11/10/25
Date/Time	11/10/2510:30am EST/7:30am PST
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Review Open Action Items for Status and Completion: note change in Action Item Tracking to just administrative/non-delivery items.
Review Kanban Board And Provide Updates on Epics and Tasks
Demo of functionality/code: Authorization Policies
Discussion of Deliverable work for coming two weeks
General Discussion, Questions

Meeting Invitees and Attendees (Note: not all invitees are expected to be regular attendees)

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	tbd	USACE - HEC
Fauwaz Hanbali	N	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Karl Tarbet	N	USACE - HEC
Jorge Hassan	Y	SolidLogix
Milver Valenzuela	Y	SolidLogix
Todd Boss (host)	Y	SolidLogix
Ryan Cunningham	Y	SolidLogix
Christina Whitehead	Y	SolidLogix
Vairav Laxman	Y	SolidLogix
Gabriel Zepeda	Y	SolidLogix
Raul Proenza	N	SolidLogix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date
Prepare Kanban subviews grouped by epics/features for clearer visibility.	Todd Boss	Done: all 10 Phase 3 epics created, with Kanban Views	10/29/25
Get new developer Gabriel Rocket Chat	Gabriel/Mike	emailed Mike 11/15/25	tbd

Meeting Detailed notes

Highlights

Policies were refactored into multiple role/persona-specific Rego files (e.g., Dam Operator, Data Manager), with public access rules separated from role rules.
Dam Operator rules include create within a shift window (e.g., 6am–6pm) and a 24-hour modification window; office membership checks are enforced.
Data Manager gains delete capability, but delete requires an approval concept whose source system is not yet defined; interim approach is to pass a context flag until a real approval source is identified.
Clear boundary discussion: proxy should perform fast top-level denials and simple request-shape checks, while CDA should handle deeper, data-aware decisions and transform inputs to the standardized OPA context.
Caching strategy articulated: proxy fetches user role/office via API (moving away from direct DB), caches attributes in Redis for ~30 minutes to avoid DB hammering.
Embargo and sensitivity clarified: embargo filtering should occur in CDA; "sensitive" will be reframed as an "approval/status" concept to avoid misinterpretation.
Acknowledge district variability: manual vs automated data and role capabilities vary by district; consider leveraging time series groups and caching catalogs to reduce per-request processing.
Next steps agreed: open draft PRs for proxy changes and CDA authorization-context helper; expand UI to display and toggle policies; show work early even if rough.

Gaps and Watch-Outs

Manual vs automated data identification is inconsistent across districts; no uniform marker exists and may need per-office rules or input processing hooks.
Delete approval workflow lacks a system of record; need to decide if CDA provides approval status or if another service owns it.
Potential overreach in the proxy: parsing diverse request bodies and performing embargo filtering in the proxy risks duplication and complexity; prefer CDA for data mutations and real-time logic.
Input standardization: CDA must consistently transform various request shapes (JSON/XML, path/query variations) into a stable OPA input object.
Risk of coupling: ensure the proxy's cache and attribute lookups use CDA APIs rather than direct DB access, given upcoming schema changes.

Action Items

Administrative

Start a Rocket.Chat thread to resolve manual vs automated identification, delete approval source, and embargo signaling semantics; capture decisions in ADRs.
Open draft PRs promptly (proxy changes, CDA authorization-context helper, UI policy view) to enable early feedback; annotate rough areas clearly.

Technical (to be reflected in Kanban Board)

Proxy–CDA Responsibility Split: Update design/ADRs and code to keep proxy limited to authentication checks, quick denials, request-shape validation, and passing standardized context; move embargo and delete approval enforcement to CDA.
Attribute Source Alignment: Replace any direct DB calls from the proxy with CDA API calls; implement Redis caching (~30 minutes, configurable) for user/office and catalog lookups.
Policy Inputs Standardization: Define the canonical OPA input schema (roles, office, resource identifiers, flags like apply_embargo/approval_required); implement CDA mappers for JSON/XML and path/query variants.
Delete Approval Integration: Introduce a context flag now (e.g., approval_required) and design integration to a future approval source in CDA; add tests to ensure proxy passes and CDA enforces.
Embargo Signaling: Implement proxy-to-CDA signaling (apply_embargo) and CDA-side filtering logic; remove any embargo filtering from the proxy.
Policy/UI Enhancements: Build Management UI views to render per-role policies and toggles; ensure personas/roles terminology is consistent; support switching among multiple policy files.
Catalog and Group Use: Cache time series catalogs and leverage time series groups to reduce runtime lookups; document refresh cadence and invalidation.

Bi-Weekly Status/Phase 3 Development Meeting 11/24/25

CWMS Database Authorization Bi-Weekly Status/Phase 3 Development Meeting 11/24/25

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 11/24/25
Date/Time	11/24/2510:30am EST/7:30am PST
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Review Open Action Items for Status and Completion: note change in Action Item Tracking to just administrative/non-delivery items.
Review Kanban Board And Provide Updates on Epics and Tasks
Demo of functionality/code: Authorization Policy viewing and UI functionality
Discussion of Deliverable work for coming two weeks
General Discussion, Questions

Meeting Invitees and Attendees (Note: not all invitees are expected to be regular attendees)

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	N	USACE - HEC
Fauwaz Hanbali	N	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Karl Tarbet	N	USACE - HEC
Jorge Hassan	Y	SolidLogix
Milver Valenzuela	Y	SolidLogix
Todd Boss (host)	Y	SolidLogix
Ryan Cunningham	Y	SolidLogix
Christina Whitehead	Y	SolidLogix
Vairav Laxman	Y	SolidLogix
Gabriel Zepeda	Y	SolidLogix
Raul Proenza	N	SolidLogix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date
Get new developer Gabriel Rocket Chat	Gabriel/Mike	emailed Mike 11/15/25	Gabriel has access, done.

Meeting Detailed notes

Highlights

Gabriel onboarded, got Rocket.Chat access, and demoed UI improvements: sidebar to toggle multiple policies, scrollable code view, optional line numbers, and safer syntax highlighting via textContent to avoid XSS. Read-only UI confirmed for scope; suggestion logged to add a copy button.
Kanban walkthrough: core authorization logic and embargo/advanced rules are actively in progress; Java integration underway; testing/benchmarking and most documentation will land later in the phase; new Access Management web interface tranche added with items moving to review.
Access patterns refined: Access Management will retrieve users/roles via CDA APIs rather than direct Oracle reads; unit tests being added on CDA side; two PRs open and targeted for updates despite holiday week.
Proxy vs CDA boundary clarified toward a hybrid: proxy handles fast top-level denials and common cases; CDA enforces deeper, data-aware rules (embargo, 24h edit windows, legacy bypass checks). Rare heavy policies may be invoked by CDA via a dedicated Access Management endpoint.
Schedule: next meeting Dec 8; team expects normal cadence post-Thanksgiving; epics will be split into smaller tickets for better movement and visibility.

Gaps and Watch-Outs

Policy editor is out of scope for web UI; read-only only. Ensure expectations are set and CLI remains the write path.
Time series automation remains largely in backlog; only parts kicked off. Track dependencies with CDA-side filters to avoid drift.
Hybrid boundary needs codified ADRs so proxy does not overreach into data-aware logic; plan the exceptional path where CDA calls Access Management for heavy policy evals.
Testing/benchmarking and most docs are backloaded; risk of crunch if not incrementally advanced alongside PRs.

Action Items

Administrative

Confirm Rocket.Chat access is recorded as complete; add Gabriel to any remaining channels.
Split large epics into smaller actionable tickets so progress is visible between meetings.
Hold to the Dec 8 session; note holiday availability in the invite for planning.

Technical (to be reflected in Kanban Board)

Finalize the two open PRs:
CDA: apply filter criteria, add unit tests, and enforce secondary checks for legacy bypass scenarios.
Access Management: switch user/role retrieval to CDA APIs and wire UI/CLI to display correct users/roles from CDA.
Implement proxy–CDA hybrid boundary: proxy handles quick denials and passes standardized headers; CDA enforces embargo rules, create/update windows, and deeper role logic; document in an ADR.
Add a UI copy button to the policy viewer; keep UI read-only and capture any edit-mode asks as out-of-scope items.
Plan the exceptional path: define an Access Management endpoint for CDA to invoke heavy/rare policy evaluations; add tests for that flow.
Advance time series automation tickets; ensure CDA-side authorization reflects DMZ include list changes end to end.
Stage testing/benchmarking tasks now (smoke, latency baselines) to avoid end-loaded risk; tie Postman flows to CI once PRs land.

Bi-Weekly Status/Phase 3 Development Meeting 12/8/25

CWMS Database Authorization Bi-Weekly Status/Phase 3 Development Meeting 12/8/25

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 12/8/25
Date/Time	12/8/25 10:30am EST/7:30am PST
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Review Open Action Items for Status and Completion: note change in Action Item Tracking to just administrative/non-delivery items.
Review Kanban Board And Provide Updates on Epics and Tasks 3c: primary area of focus this last 2 weeks: 4 now in PR 3d: cleaned up a couple tasks, closed now moot/duplicate tasks 3e: Embargo rule testing now in progress 3h: closed out much of this Epic, one now in PR 3i; 3 new tasks in PR 3k: 3 new tasks in PR
Demo of functionality/code: 3 PRs out; WIP: Embargo and Timed Access functionality
Discussion of Deliverable work for coming two weeks
General Discussion, Questions

Meeting Invitees and Attendees (Note: not all invitees are expected to be regular attendees)

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	Y	USACE - HEC
Fauwaz Hanbali	N	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Karl Tarbet	N	USACE - HEC
Jorge Hassan	N - travel	SolidLogix
Milver Valenzuela	Y	SolidLogix
Todd Boss (host)	Y	SolidLogix
Ryan Cunningham	Y	SolidLogix
Christina Whitehead	Y	SolidLogix
Vairav Laxman	Y	SolidLogix
Gabriel Zepeda	Y	SolidLogix
Raul Proenza	N	SolidLogix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date

Meeting Detailed notes

Highlights

Focus areas: work centered on Embargo & Advanced Rules and Time Series automation; several items moved to PR or review in the last two weeks.
PR commitment: engineering lead committed to submitting a PR within days to advance embargo and timed-access logic plus time series handling.
Time series approach: stakeholders reinforced a Groups-first model (DMZ include list) accessed via CDA endpoints rather than raw DB reads; engineering will follow up in Rocket.Chat to finalize the pattern.
CWMS Vue awareness: request to validate how districts actually manage time series in CWMS Vue to ensure our automation aligns with current user workflows.
Kanban momentum:
- Embargo & Advanced Rules: primary focus; multiple tasks in review with open PRs.
- Java Integration: structure cleanup and duplicate closures completed.
- Testing & Benchmarking: embargo tests started; task moved to In Progress.
- Authorization Proxy Core: most of the epic closed previously; one open PR remains.
- Time Series Automation: three new tasks opened as PRs.
- Web Interface: multiple items in PR; two closed; additional pages nearly ready for review.
Community engagement: proposal to schedule a show-and-tell with a broader audience once embargo and time series PRs land.

Gaps and Watch-Outs

Authoritative source and workflow fit: need to lock in Groups via CDA as the source of truth and verify that behavior mirrors CWMS Vue usage patterns.
Automation framework clarity: a concrete design is still needed for generating OPA from Groups, refresh triggers, and Redis invalidation.
Boundary discipline: keep the proxy limited to quick denials and context pass-through; push embargo windows and advanced role checks into CDA.
Holiday cadence: the next iteration overlaps with year-end PTO; pre-slice work and stage reviews to reduce stall risk.

Action Items

Administrative

Schedule show-and-tell: plan a broader demo after embargo and time series PRs merge to collect feedback.
Adjust iteration plan: update the 12/22 and early January goals to reflect holiday availability; note expected reduced velocity.

Technical (to be reflected in Kanban Board)

Confirm Groups-first design and CWMS Vue parity:
- Start a short Rocket.Chat thread to confirm the Groups via CDA approach and list CWMS Vue behaviors to match, including bulk add or remove, filters, and audit.
- Document decisions in an ADR.
Time Series Automation Design:
- Define the pipeline: CDA reads Groups, generator emits OPA, Redis cache, OPA refresh.
- Decide refresh triggers, event or periodic, and cache invalidation strategy.
- Include audit hooks to trace why a series is public.
Embargo Enforcement:
- Implement office default plus per-time-series overrides.
- Add unit and integration tests and Postman flows for allow and deny around window edges.
Proxy and CDA Boundary ADR:
- Record that embargo, role checks, and data-aware logic are enforced in CDA.
- Keep proxy to auth checks, quick denials, and standardized context forwarding only.
CWMS Vue Behavior Mapping:
- Capture key CWMS Vue operations and ensure API and automation support equivalent actions and UX expectations.
Testing and Benchmarking:
- Expand embargo and timed-access tests; establish latency baselines for proxy to CDA to OPA.
- Wire critical Postman flows into CI for regression.
Web Interface:
- Complete read-only pages to visualize policies and current public time series and embargo state.
- Add copy-to-clipboard for policy snippets.
Java Integration Cleanup:
- Reflect recent module changes, close duplicates, and align remaining tasks with the updated structure.

Bi-Weekly Status/Phase 3 Development Meeting 12/22/25

CWMS Database Authorization Bi-Weekly Status/Phase 3 Development Meeting 12/22/25

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 12/22/25
Date/Time	12/22/25 10:30am EST/7:30am PST
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Action Item review: none this week
Functionality Demo: Vairav & Jorge
Discussion of Deliverable work for coming two weeks
General Discussion, Questions

Meeting Invitees and Attendees (Note: not all invitees are expected to be regular attendees)

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	tbd	USACE - HEC
Fauwaz Hanbali	N	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Karl Tarbet	N	USACE - HEC
Jorge Hassan	Y	Solid Logix
Milver Valenzuela	N - OOO	Solid Logix
Todd Boss (host)	N - OOO	Solid Logix
Ryan Cunningham	N - OOO	Solid Logix
Christina Whitehead	Y	Solid Logix
Vairav Laxman	Y	Solid Logix
Gabriel Zepeda	N - OOO	Solid Logix
Raul Proenza	N	Solid Logix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date

Meeting Detailed notes

Highlights

Timed Access: Office-hours enforcement (9:00 a.m.–5:00 p.m.) for dam operators is fully implemented via OPA policy and working as expected, rejecting access outside the allowed window.
Embargo Rules: Agreed that embargo is a property of the time series, not the user. Custom database columns will be removed, and embargo hours will be derived from standardized time series group names (e.g., role_privilege_embargoTime), with global, non-editable groups and office-level overrides.
Performance: Initial slow queries (24–36s on ~22M rows) were resolved; optimized joins now return results in ~10–15ms.
API Design: User profile and time series group privileges will be retrieved via separate, independently cached API calls to avoid coupling non-user properties to the user profile.
Authorization Endpoint: A new /authorize endpoint is in place, applying the same policies as the proxy and returning xwms-o-context–equivalent results for downstream authorization checks and testing.
Next Focus: Access Management is nearing stability; upcoming work will concentrate on CLI tooling for policy inspection, TS group membership checks, and embargo validation.

Gaps and Watch-Outs

Embargo logic embedded in group names effectively creates a schema-in-name pattern; this must be clearly documented and restricted to controlled/global groups to prevent accidental breaking changes
User profile APIs must remain clean and focused; TS group data should not be treated as a user attribute.
Caching strategy must ensure embargo/group changes propagate correctly without excessive coupling to user cache entries.
CLI work is critical for operability and validation; risk exists if delayed too long.

Action Items

Technical

CDA Pull Request Updates (Vairavan Laxman)
Remove custom database columns created for embargo hours.
Derive embargo hours exclusively from time series group naming convention.
Update implementation to use two separate cached calls: user profile and time series group privileges
Ensure office-level decisions override global group rules.

Access Management

Finalize /authorize endpoint integration and ensure parity with proxy enforcement.
Maintain consistent policy evaluation logic across proxy and explicit authorization calls.

CLI Development

Expand CLI with administrative commands to: check effective policies, validate TS group membership, confirm embargo rules for specific time series IDs
Use CLI as a primary validation and troubleshooting tool.

Planning

Next meeting: January 5th
Focus will be on cleanup, stabilization, and planning a demo for the full team.
Targeting code completion around mid to third week of January, followed by polish and documentation.

Bi-Weekly Status/Phase 3 Development Meeting 1/5/26

CWMS Database Authorization Bi-Weekly Status/Phase 3 Development Meeting 1/5/26

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 1/5/26
Date/Time	1/5/26 10:30am EST/7:30am PST
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Action Item review: none this week
Functionality Demo: time series groups have the embargo information
Discussion of Deliverable work for coming two weeks and macro Project planning as we near contract end date.
Administrative: is USACE off for MLK day on 1/19? If so will reschedule that biweekly meeting to 1/20, same time
Full team Demo: we're tentatively thinking Friday 1/23; what is a good time for Demo and who needs to be invited?
Contract completion planning: Definition of Done, Scope completion, and next steps post-contract
General Discussion, Questions

Meeting Invitees and Attendees (Note: not all invitees are expected to be regular attendees)

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	Y	USACE - HEC
Fauwaz Hanbali	N	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Karl Tarbet	N	USACE - HEC
Jorge Hassan	Y	Solid Logix
Milver Valenzuela	Y	Solid Logix
Todd Boss (host)	Y	Solid Logix
Ryan Cunningham	N	Solid Logix
Christina Whitehead	Y	Solid Logix
Vairav Laxman	Y	Solid Logix
Gabriel Zepeda	N	Solid Logix
Raul Proenza	N	Solid Logix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date

Meeting Detailed notes

Highlights

Definition of done is documentation plus runnable compose: The government stakeholder explicitly framed success as being able to stand the system up locally using Docker Compose, then change policies and observe behavior. As stated: "I'll be satisfied if in one of these projects docker compose files I can do a docker compose up".
Time series group naming and embargo semantics were actively refined before code lands: The team discussed the TS group naming convention (role + optional markers + action + embargo duration) and removed earlier extra columns to keep it simpler.
Zero-hour embargo clarified as "no embargo": The stakeholder recommended using 0 or 0h to represent no embargo for a public group, rather than inventing another sentinel.
Overlapping embargo rules: Overlap was characterized as likely an invalid configuration, but the safe default should be the longest embargo window (more restrictive).
Docs direction: The group converged on using Sphinx (Read the Docs style) and capturing changes like the x-cwms-auth-context header behavior in repo docs. They also suggested placing docs in the CDA repo since it already has the Read the Docs integration, rather than standing up a new integration elsewhere.
Backward-compatible rollout toggle: The implementation plan includes a CDA-side configuration where the access management layer is default off so existing behavior continues unchanged unless enabled.
Next technical focus after embargo/TS groups: The plan is to shift back to CLI capabilities to (1) assign TSIDs to TS groups and (2) assign/remove users to roles, then move into end-to-end testing, performance benchmarking, and documentation.
Performance target and test concept: The team called out a local performance check targeting roughly 50ms policy evaluation response time and proposed a small load test scenario (virtual users and sustained request rate) to validate it.

Gaps and Watch-Outs

TS group naming still has open design edges: There was pushback on carrying markers like raw inside the TS group name, with guidance to keep naming focused on role, permission, and embargo, and put other metadata elsewhere (like descriptions).
Overlap handling is not just a coding detail: The team needs a clear rule for when overlaps are allowed vs. treated as misconfiguration, and what the enforcement posture should be (warn, fail closed, or accept with longest embargo).
Documentation is behind by intent, but now becomes the critical deliverable: The team acknowledged documentation has not been done in earnest yet and is planned for the tail end, but the stakeholder explicitly prioritized it over implementation perfection.
Docs location still needs an explicit decision and a PR: There was agreement that CDA repo docs may be easiest, but it still needs execution and contribution guidance (how to build Read the Docs locally).
Offboarding and closure mechanics: There was discussion that closure may be as simple as the final invoice being marked "final", but it may still be prudent to confirm if any additional closeout steps are expected.

Action Items

Administrative

Confirm whether any additional closeout steps are required beyond submitting a final invoice marked "final".
Align on offboarding expectations for repository access at the end of the contract and execute removal as appropriate.
Get external-reader feedback on documentation clarity from stakeholders who are not already deep in the project context.

Technical (to be reflected in Kanban Board)

Finalize TS group naming rules, including whether to exclude markers like raw from the name and rely on descriptions or another metadata channel.
Implement and document embargo semantics:
- Support 0 or 0h as a "no embargo" convention.
- Resolve overlap behavior to default to longest embargo window as the safe choice, and document overlaps as likely invalid configuration.
Deliver a runnable, documented local workflow that matches the stakeholder's definition of done: docker compose up, then modify policies and observe effect.
Produce Sphinx-based documentation in the agreed repo location, including:
- How to build docs locally.
- The x-cwms-auth-context header behavior and the related CDA changes.
Complete the CDA-side feature toggle so access management is default off and can be enabled safely without breaking existing behavior.
Complete CLI capabilities for TSID-to-group assignment and user-to-role assignment/removal, then proceed to end-to-end integration testing, perf checks, and documentation.
Run the initial local performance validation against the stated target (policy evaluation latency) and capture results in documentation.

Bi-Weekly Status/Phase 3 Development Meeting 1/20/26

CWMS Database Authorization Bi-Weekly Status/Phase 3 Development Meeting 1/20/26

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 1/20/26
Date/Time	1/20/26 10:30am EST/7:30am PST (moved one day forward on account of 1/19/26 federal holiday)
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Action Item review: none this week
Functionality Demo: Gabe: Access Management CLI User & Role Addition/Removal.
Status Edge Case for Time Series changes from last meeting
Quick review of Kanban Board
Discussion of Deliverable work for coming two weeks and macro Project planning as we near contract end date.
FYI: Full team Demo: set for 1/26/26 at Noon Est/9am PST
Review of Draft Presentation slides for Full Team Demo
General Discussion, Questions

Meeting Invitees and Attendees (Note: not all invitees are expected to be regular attendees)

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	Y	USACE - HEC
Fauwaz Hanbali	Y	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Karl Tarbet	N	USACE - HEC
Jorge Hassan	N - conflict	Solid Logix
Milver Valenzuela	Y	Solid Logix
Todd Boss (host)	Y	Solid Logix
Ryan Cunningham	N	Solid Logix
Christina Whitehead	Y	Solid Logix
Vairav Laxman	Y	Solid Logix
Gabriel Zepeda	Y	Solid Logix
Raul Proenza	N	Solid Logix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date

Meeting Detailed notes

Highlights

Embargo logic and multi-office aggregation were validated end to end: The team demonstrated that a single user can carry multiple office-specific time series group policies and the system aggregates them, then applies the most restrictive embargo by selecting the highest embargo value across matching groups.
"Zero hours" embargo is implemented: The team confirmed 0h means no embargo, and day-based values are converted to hours consistently (for example 7 days becomes hours).
Role and group test data was tightened for integration testing: Test users, office assignments, and role memberships were updated in the compose SQL seed so integration tests can validate role priority ordering and embargo behaviors using realistic permutations.
Prometheus metrics are now part of the default operational story: Metrics were enabled to observe OPA cache hit behavior and overall request patterns during load testing. The government stakeholder explicitly requested: "Keep it turned on by default."
Performance testing approach is now concrete and repeatable: A k6-based quick start exists to reproduce local benchmarks; reported local results were roughly average low single-digit milliseconds with P95 around 3ms and P99 typically 15 to 30ms after ramp stabilization, with higher spikes during ramp-up due to local resource contention.
Docs have been moved into the CDA repo and are being rendered with Sphinx live reload: The team consolidated prior markdown content, improved formatting, and generated architecture pages with Mermaid diagrams, plus a configuration section documenting the access management feature toggle (default off).
CLI and Web UI are converging into a single management experience: The demo showed user add/remove and role add/remove via CLI with immediate reflection in the Management UI, indicating shared backing APIs and a tight feedback loop.

Gaps and Watch-Outs

UI cache refresh and multi-user editing risk: Today the UI relies on manual refresh; if multiple admins edit roles/users concurrently, stale UI state could cause confusion. This needs an explicit refresh strategy (polling, focus refresh, websockets, or ETag-based revalidation).
Terminology drift for public access: The demo mixed "viewer users", "public", and "unauthenticated". This needs to be normalized in docs and code comments to avoid misconfigurations and misunderstanding.
Rate limiting is out of scope in-app: The team confirmed there is no built-in rate limiter, relying on Kubernetes ingress or service mesh controls (for example Envoy). This is reasonable, but it should be stated clearly as an external dependency for production hardening.
Local benchmark caveats: The testing was performed on a single machine with load generation and containers sharing resources, plus ARM-to-x86 translation overhead. Results are directionally useful but not a substitute for a split-host or cluster benchmark.

Action Items

Administrative

Confirm the policy for Prometheus in deliverables: keep enabled by default, document how to access it, and call out that nothing is wired to scrape it yet.
Decide the standard terminology for public access (public vs guest vs anonymous vs viewer) and apply consistently across docs, examples, and UI labels.
Ensure the full-team demo invite list is complete and includes anyone who needs to attend the final walkthrough.

Technical (to be reflected in Kanban Board)

UI refresh strategy: Implement a deterministic mechanism for keeping the Management UI in sync after CLI actions and when multiple users modify roles/users (polling interval, focus refresh, or server push).
Embargo rule finalization: Codify and document the "highest embargo wins" aggregation rule, including how office-specific groups are discovered and how 0h is interpreted across offices.
Test suite publication decision: Decide where unit and integration tests live long term (Access Management only vs integrated into CDA suites), and document how to run them locally in one command.
Performance testing documentation: Add a short, reproducible guide for running the k6 benchmarks and interpreting results (P50, P95, P99) with clear caveats about local contention.
Observability defaults: Keep Prometheus metrics enabled by default and document key metrics (OPA cache hit rate, request throughput, proxy pass-through) plus how to validate they are working.
Docs consolidation completion: Finish the Sphinx docs migration in the CDA repo including configuration toggle behavior (default off), architecture diagrams, and updated quick start steps.
Proxy scalability posture: Document the stateless, horizontally scalable design and the expectation that HA and autoscaling are handled at the Kubernetes layer (even if K8s manifests are not delivered in this phase).

Bi-Weekly Status/Phase 3 Development Meeting 2/2/26

CWMS Database Authorization Bi-Weekly Status/Phase 3 Development Meeting 2/2/26

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 2/2/26
Date/Time	2/2/26 10:30am EST/7:30am PST
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Action Item review from prior meeting: none outstanding.
Post-Mortem discussion from multi-vendor Demo: are there any action items prior to Project close?
Quick review of Kanban Board; what work remains?
Functionality Demo: nothing for this week
Discussion of Work to be done in final two weeks of contract: finish up CLI feature, Finish outstanding Documentation, Finalize Testing, Finalize Deployment tasks.
Final bi-weekly meeting: was to be 2/16/26 but that's post-contract end date and a holiday: suggest moving to Wednesday 2/11/26 to give a few add'l days to address any last items before end date.
What technology to use for next meeting, if Google Meet is now blocked?
General Discussion, Questions

Meeting Invitees and Attendees (Note: not all invitees are expected to be regular attendees)

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	Y	USACE - HEC
Fauwaz Hanbali	Y	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Karl Tarbet	Y	USACE - HEC
Jorge Hassan	Y	Solid Logix
Milver Valenzuela	Y	Solid Logix
Todd Boss (host)	Y	Solid Logix
Ryan Cunningham	N	Solid Logix
Christina Whitehead	Y	Solid Logix
Vairav Laxman	Y	Solid Logix
Gabriel Zepeda	Y	Solid Logix
Raul Proenza	N	Solid Logix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date
Send PWS for CMS contract to Mike	Jorge	todo	tbd
Download and Upload Demo Video	Charles/Mike	todo	may be troublesome, but desired
Post Demo PPT to Wiki	Charles/Mike	todo	Jorge emailed PPT pdf to Army staff post meeting; should we upload it?
Change final contract meeting to 2/10 10:30est	Todd	todo	tbd

Meeting Detailed notes

Highlights

The team re-stated the core goal: move authorization out of Oracle VPD into a transparent policy layer so rules like time-based access, embargoes, emergency overrides, and machine access can be expressed, tested, and audited as code.
Architecture and flow were clarified: a transparent proxy verifies JWT, fetches needed context via CDA, evaluates Rego in OPA, caches inputs in Redis, and then forwards to CDA with an auth-context header so downstream Java can apply filters without changing URLs or payloads.
Rollout sequencing was explicitly framed as low-risk: deploy in shadow mode (log decisions, do not block), validate parity with current behavior, then introduce admin tooling (CLI), then enable enforcement for embargo and shift-hour rules.
USACE described the near-term path: get it functional in CWBI first, integrate as an IaC module in CWBI dev, then promote through environments. They called out that CWBI test/prod differ from dev today and will need a deliberate transition plan.
Demo progress was shown across three surfaces: Postman flows proving allow/deny decisions and embargo behavior, plus a management UI and CLI that can list and manage users, roles, and policies. CLI is positioned as the primary admin interface initially.

Gaps and Watch-Outs

CWBI environment mismatch risk: CWBI dev matches the desired architecture pattern, but CWBI test/prod were built differently and must be transitioned. This is a future schedule and integration dependency, not just a Docker-image concern.
Documentation visibility: the updated docs were noted as sitting in an unmerged PR, meaning most stakeholders cannot easily find or rely on the latest guidance until it is merged and announced.
Adoption friction for users: accounts and role assignments will need to be set up again in CWBI, and there is an implied prerequisite that users must first log in via CAC to be registered before automation can fully help.
Policy ownership expectations: USACE expects local data managers are not writing Rego, and that policy authorship will be handled by a national team with inputs from managers. This needs a clear PolicyOps workflow to avoid bottlenecks.
Scope reality check: minimum success for the contract is time series (because embargo is the immediate driver), while broader endpoint coverage remains an intent over time. Plan and messaging should keep that ordering.

Action Items

Administrative

USACE: send the formal announcement that the CWBI module is being expanded, then open the deployment tickets needed to integrate the module in CWBI dev.
USACE: decide the preferred channel for post-demo questions (Discourse vs CDA team vs GitHub Discussions) and publish that guidance for internal and external participants.
Solid Logix: merge documentation PR(s) and coordinate an announcement once the updated docs are visible and discoverable.

Technical

USACE: define and execute the CWBI dev integration steps as an IaC module and validate the standard promotion path end-to-end with a smoke test.
USACE: lead a transition plan for CWBI test/prod to align with the dev pattern, with explicit sequencing and rollback approach.
Solid Logix: formalize the shadow-mode parity criteria and a repeatable parity validation procedure so enforcement can be enabled confidently later.
USACE: finalize onboarding and migration automation approach in CWBI, including the CAC-first registration prerequisite and a scriptable path leveraging the CLI for bulk operations.
Solid Logix: confirm performance targets and produce a short, reproducible benchmark recipe that CWBI operators can rerun to validate overhead stays within expectations.

Bi-Weekly Status/Phase 3 Development Meeting 2/11/26: Final Project Meeting

CWMS Database Authorization Bi-Weekly Status/Phase 3 Development Meeting 2/11/26

Core Meeting Metadata

topic	detail
Meeting Title	CWMS Database Authorization Bi-Weekly Status Meeting 2/11/26
Date/Time	2/11/26 10:30am EST/7:30am PST (moved from 2/16/26 to get final meeting in prior to project end date, then moved from 2/10 to 2/11 to avoid conflicts)
Meeting Location	Virtual (Google Meet)
Meeting Remote Link information	See meeting Invite
Meeting Purpose	Bi-Weekly Status Meeting for CWMS Database Authorization Project

Meeting Agenda

Action Item review from prior meeting
Final review of Kanban Board;
Functionality Demo: none for today
Testing Findings: any last-minute findings, bugs, requests prior to 2/15 project end?
General Discussion, Questions

Meeting Invitees and Attendees (Note: not all invitees are expected to be regular attendees)

Invitee	Present?	Org
Michael Neilson	Y	USACE - HEC
Charles Graham	Y	USACE - HEC
Eric Novotny	N	USACE - HEC
Fauwaz Hanbali	Y	USACE - HEC
Dave Kaplan	N	USACE - HEC
Matthew Fleming	N	USACE - HEC
Karl Tarbet	N	USACE - HEC
Jorge Hassan	Y	Solid Logix
Milver Valenzuela	Y	Solid Logix
Todd Boss (host)	Y	Solid Logix
Ryan Cunningham	N	Solid Logix
Christina Whitehead	Y	Solid Logix
Vairav Laxman	Y	Solid Logix
Gabriel Zepeda	Y	Solid Logix
Raul Proenza	N	Solid Logix

Open Action Item discussion

Action Item	Assignee	Status	Completion Date
Send PWS for CMS contract to Mike	Jorge	In progress; Jorge/Milver working on content that can be sent.	tbd
Download and Upload Demo Video	Charles/Mike	Charles coordinating with Peter	still tbd
Post Demo PPT to Wiki	Charles/Mike	Charles todo	Jorge emailed PPT pdf to Army staff post meeting; should we upload it?
Change final contract meeting to 2/10 10:30est	Todd	done	done 2/3/26
Cancel Meeting series post 2/15/26	Todd	done	done 2/3/26

Meeting Detailed notes

Highlights

Post-demo feedback was minimal and interpreted as positive. USACE noted only a single follow-up request that likely came from someone not fully tracking the demo content.
Kanban status showed the phase is largely complete: 107 tasks marked done, 18 remaining in progress, mostly documentation/finalization plus a small number of integration, deployment, testing, and CLI items.
Multiple PRs were created to close out architecture documentation and ADRs, and the ADRs were aligned to the expected format. There is also a separate PR in progress for Java changes pending local validation due to CI issues.
CLI maturity improved materially: the team reported roughly 43 unit tests and one end-to-end integration test focused on the auth flow (login to IdP, JWT issuance, CDA decoding, then a representative call such as listing users).
A cleanup milestone was called out: everything is now running through the container compose setup, reducing reliance on ad hoc services running outside the compose stack.
USACE stated the near-term plan is to test after merges, focusing on manual exploratory testing and bug reporting. One participant explicitly described the intent to "utterly break it" during testing.

Gaps and Watch-Outs

ADR organization needs a small correction: USACE feedback suggested consolidating ADR placement/naming to reduce index churn during rebases and to align with the "properly defined place and starting number" now that earlier ADRs are merged.
Video and deck distribution has policy risk. USACE discussed new rules around posting videos and the need to confirm what is allowed before making recordings broadly available, with a preference to share internally first and verify with PAO if publishing.
Final acceptance is now mostly dependent on USACE-led validation. The plan to wait until PRs are merged before testing is sensible, but it compresses the bug-fix window near the contract end date if unexpected issues appear.
Access cutoff at contract end was raised as a practical concern. Even if support continues informally, disabled accounts would prevent fixes unless a path is planned (or forks are used).

Action Items

Administrative

USACE: confirm an approved internal location for the demo deck and recording, and confirm whether video publication requires PAO review or can remain internal.
Solid Logix: send the requested example PWS reference material to USACE for contract-writing benchmarks.
Solid Logix: confirm offboarding checklist requirements with the USACE contracting contact, and ensure the final invoice is labeled as "final."

Technical (to be reflected in Kanban Board)

Solid Logix: finalize and submit ADR and documentation PR updates, including ADR directory and numbering adjustments consistent with the now-merged baseline.
Solid Logix: complete CLI hardening by pushing the unit tests and the integration test, then move PRs to ready-for-review once the final pass is complete.
Solid Logix: complete Java PR validation by running CDA integration tests locally and updating PR notes to reflect test results (given CI constraints).
Solid Logix: land the compose/containerization cleanup so the full system runs consistently through the compose stack for easier CWBI adoption and repeatable testing.
USACE: perform manual exploratory testing after merges and report defects quickly to preserve time for fixes before contract closeout.
Solid Logix + USACE: schedule the final closeout meeting earlier than the holiday week conflict, with a focused goal of validating merged functionality and closing any final issues.

Data Authorization‐W912HQ25P0049

Project Overview

Key Links and Resources for project

Meeting Minutes

Project Kickoff 5/19/25

Bi-Weekly Status Meeting 5/27/25

Bi-Weekly Status Meeting 6/9/25

Bi-Weekly Status Meeting 6/23/25

Bi-Weekly Status Meeting 7/7/25

Bi-Weekly Status Meeting 7/21/25

Bi-Weekly Status Meeting 8/4/25

Bi-Weekly Status Meeting 8/18/25

Bi-Weekly Status Meeting/Phase 3 Development Meeting 9/2/25

Bi-Weekly Status/Phase 3 Development Meeting 9/15/25

Bi-Weekly Status/Phase 3 Development Meeting 9/29/25

Bi-Weekly Status/Phase 3 Development Meeting 10/16/25

Bi-Weekly Status/Phase 3 Development Meeting 10/27/25

Bi-Weekly Status/Phase 3 Development Meeting 11/10/25

Bi-Weekly Status/Phase 3 Development Meeting 11/24/25

Bi-Weekly Status/Phase 3 Development Meeting 12/8/25

Bi-Weekly Status/Phase 3 Development Meeting 12/22/25

Bi-Weekly Status/Phase 3 Development Meeting 1/5/26

Bi-Weekly Status/Phase 3 Development Meeting 1/20/26

Bi-Weekly Status/Phase 3 Development Meeting 2/2/26

Bi-Weekly Status/Phase 3 Development Meeting 2/11/26: Final Project Meeting

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Clone this wiki locally