Policy Playground#
Our Final Product#
With the conclusion of phase 4, we have finally finished our app: Policy Playground. We have put many combined hours into this project and are very proud of the application we have created. Our three ML models have been fully developed as well as our database structures and functioning Rest API routes.
One our first phase 4 implementations included adding multiple users to each personas. Now a user has the ablity to login as three different people for each of the three personas. The users all feel unique and individual features like saved notes and policies are only accessible for the respective user who interacted with or created such policy.
Policy Maker#
Additionally, we have fully optimized our two ML models to make them as accurate as possible. We integrated the data from phase 3 into the database for phase 4 and created additioanl routes that allow a new user persona (The Admin) to train the models. We added routes to allow the user to test these models on the various fiscal and monetary policies. We added various graphs to visually display this information against other similar indicators to compare.
To expand on our work with the two ML models, we included some visualizations to display differences in indicator plots before and after our adjustments.
SP500 Before#
SP500 After#
As you can see in the first plot, it fails to meet any of the assumptions and displays heteroscedasticity, autocorrelation, and a lack of a linear pattern. The second pattern displays the residual plots after adjusting for time. We added 6 lag values in equal spaces, which greatly reduced the patterns in our resiudal plots. This same adjustment can be seen in our currency models which also greatly benefited as you can see below.
Currencies Before#
Currencies After#
GDP/Capita features against time#
GDP/Capita Residual Plots#
More Features for the Policy Maker#
When a user is satisfied the policy they have tested, they now have the ability to save this policy and publish it. Published policies can then be accessed by the Economist Persona. To do this, we expanded our database with additional tables such as SavedPolicy and added more routes. The policy maker is also able to delete and modify policies through PUT and DELETE routes. One of the major feedbacks we received from Phase 3 was the lack of cohesion and interconnectedness between the Economist and Policy Maker Personas. By adding these functionality features, we made these two personas more intertwined.
Economist#
To expand on the economist, we added another simple machine learning model using cosine similarity. When a user favorites a policy and selects it on the View Favorite Policy page, information is displayed on the 5 policies that are most similar to it. This model was trained on three numeric features: budget spending, duration of enforcement in months, date, and the population size that it will be affecting. It was also trained on country, and topic. In order to standardize the values, we had to one hot encode the categorical features and do min-max normalization for the numeric features. For date we standardized it based on the range of fake policies we had.
This addition makes the economist role of analyzing policy more effective through the ability of comparison. The fake data generated for this persona remains mostly the same with the addtion of those three features mentioned prior.
Other additons to this persona included adding a Politician Contact Information button that brings up more information on a policy and more filter cirteria to the Historical Data Viewer page.
Lobbyist#
The lobbyist had also undergone major changes from Phase 3. Again, to make this persona more aligned to the Policy Maker persona, we added the ability for the user to adjust sliders on based features that are directly related to the monetary and fiscal policies. When the Lobbyist creates this note, the same model is used to also produce graphs that are visible by the lobbyist.
Front End Final Details.#
Our team has also put in work to improving the interface and visuals of our application. We completly revamped our color theme with the additon of animations to page headers and new fonts. Despite being limited Streamlit, we used CSS and HTML to make our app look as clean as possible. We strived to make our pages look unique and interesting, while also containing a overlying theme.
Updated Rest API Matrix#
We took the feedback from phase 3 and updated our route handler names to be nouns while combining similar ones though GET, POST, PUT, and DELETE method types. Below is our updated matrix that counts for the added routes as well.
Updated DDL#
With more tables our DDL has also changed. Below is our updated relational table.
Conclusion#
Overall, we are very proud of the work we have put into this project. We felt we really transformed Policy Playground from a sundry of functionalities to one cohesive and fully implemented application.