by Tobin Albanese

Volume 0 Wed May 27 2026

A public policy and data systems project focused on reentry outcomes, incarcerated workforce programs, wage reporting, and post-release employment tracking. The project examines how correctional education and Transition to Employment programs can be evaluated through structured reporting, participant outcome tracking, and recidivism-aware workforce analysis.

This project started with a very practical problem: a large internal Excel process had become too important for how fragile it was. The broader purpose of the system was tied to recidivism ratios and external program oversight across all 31 California prisons, which meant the workflow was not just another reporting task. It connected directly to how correctional programs were being measured, checked, and understood across a massive institutional environment. On paper, the task looked like streamlining a spreadsheet. In reality, it was about rebuilding a process that had outgrown the tools it was relying on. The original workbook carried a heavy amount of operational responsibility, and while Excel can work well for smaller analysis or one-off reporting, it becomes risky when it turns into the center of a repeated, security-sensitive process. Files become bloated. Manual steps become inconsistent. Secure values become harder to protect. Version control becomes unclear. And after enough time, the entire system starts depending less on structure and more on memory, patience, and trust that every person will click the right thing every time. That is not a reliable system. In my view, this is where technical work begins to matter beyond just convenience. If a company or institution is using data to evaluate whether programs are operating correctly, then the process behind that data needs to be consistent, repeatable, and secure. Otherwise, the reporting loses strength before anyone even reads the final output. My role in the project was to take this massive spreadsheet-based workflow and turn it into a cleaner automation sequence that reduced the process into a three-click operation. That was the main idea: keep the final user experience simple while allowing the backend process to handle the complexity. I did not want to build something that looked technical just for the sake of looking technical. I wanted the system to actually remove friction. That mattered because the people running the workflow should not have to fight the tool every time they need an answer. The tool should guide the process, protect the sensitive parts, and produce the needed output without forcing users to manually move through a fragile workbook.

The foundation of the project was built around a C# frontend and a Microsoft SQL backend, which gave the workflow a much stronger structure than the original Excel environment. The C# side created a controlled interface where users could initiate the process without needing to touch every internal step directly. This was important because the goal was not just to automate clicks, but to create a more dependable operational pathway. The frontend became the point where the user could interact with the system in a clear and limited way, while the more sensitive and technical operations stayed protected behind the application logic. The SQL backend handled the storage and organization side, which was one of the most important shifts in the project. Instead of treating a spreadsheet as the main storage layer, the workflow moved toward a database structure where information could be stored, queried, and managed more reliably. That difference matters. A spreadsheet is easy to open and edit, but that same flexibility becomes a weakness when the data has to support repeated institutional reporting. SQL allowed the process to separate storage from execution, and execution from user interaction. It gave the project a stronger foundation for consistency, access control, and long-term maintenance. A lot of my work involved thinking through the sequence itself: what happens first, what needs to be checked, where secure values are decrypted, where the local network instance is created, how the access points are restricted, and how the final reporting flow should be triggered. That part was more detailed than it probably appears from the outside. Automation is only useful when the steps are arranged correctly. If the system decrypts something too early, exposes something unnecessarily, or depends on a user to manually intervene at the wrong point, then the workflow is not actually secure or efficient. It just looks faster. So the sequencing had to be built carefully. Secure values needed to be handled only when necessary, access needed to be narrowed, and the localized network instance had to support the internal process without creating broader exposure. This is where I started to see the project less as a normal automation task and more as a small operational system built around control, timing, and trust.

What made the project meaningful to me was the connection between technical structure and policy outcomes. Recidivism data is not just a set of numbers sitting in a workbook. It is tied to how programs are evaluated, how institutions understand performance, and how decision-makers interpret whether external services are actually working inside correctional environments. That does not mean a data workflow solves recidivism by itself. It obviously does not. But it does mean the system supporting that data has to be taken seriously. If the reporting process is slow, inconsistent, or too dependent on manual work, then the organization loses clarity. And when clarity weakens, accountability becomes harder to maintain. This matters because public-sector and correctional-adjacent systems often deal with real consequences while still relying on outdated internal processes. A lot of operations keep running because people find ways to make broken workflows work. They build habits around the inefficiency. They memorize which tabs to open, which cells to avoid, which values to copy, and which steps cannot be skipped. That can keep a process alive for a while, but it is not the same as building something reliable. From my perspective, the value of this project came from turning that kind of manual knowledge into a structured sequence. Instead of asking users to remember each part of the process, the application carried the sequence for them. Instead of leaving sensitive values exposed inside a workbook or relying on scattered steps, the system placed those operations inside a controlled flow. Instead of having the workflow depend on someone navigating a massive Excel file correctly every time, the process became more centralized, guided, and repeatable. At the same time, I had to keep the practical side in mind. A technical system can fail if it becomes too abstract for the people who actually use it. So the three-click structure was not just about speed. It was about usability. It gave the user a simple pathway while allowing the application and database to do the heavier work behind the scenes. That balance is important. Good internal tools should reduce confusion, not add another layer of work disguised as innovation.

By the end, the project became a strong example of how automation can improve operations without removing the need for oversight or judgment. The final workflow was not just faster than the original process; it was more controlled, more secure, and better aligned with the seriousness of the data being handled. It moved the process away from a large, fragile Excel dependency and into a system supported by a C# application layer, Microsoft SQL storage, localized access controls, secure value handling, and automated sequencing. That shift changed the entire nature of the workflow. It no longer felt like a file people had to manage carefully. It became a process people could run with more confidence. In my view, that is what makes this project stand out in a portfolio context. It was not just a technical build. It was an operational redesign. I had to understand the existing pain points, break down the full manual process, identify where security and consistency were weak, and then rebuild the workflow into something that could function across a much larger institutional setting. Working across all 31 California prisons adds another layer to that because scale changes everything. A process that works once is not enough. It has to work repeatedly, across different reporting needs, different institutional contexts, and different users. That requires structure. It requires a system that does not fall apart just because one person forgets a step or one workbook becomes too difficult to manage. What stands out to me most is that the project took something messy and made it orderly without overcomplicating the user experience. That is usually the best kind of technical improvement. Quiet, but important. The user may only see three clicks, but behind those clicks is a full sequence of database storage, secure access, decryption logic, and controlled automation. That is the part I am proud of. This project showed me that strong data systems are not only about writing code or storing information correctly. They are about building trust into the workflow itself, so that the people relying on the system can focus on the outcome instead of fighting the process that produces it.