← All selected work

Applications

Designing an audit-tracking workspace

Connecting analytical exploration, supporting documents, and operational oversight in an audit-tracking workspace.

The challenge

The project began with a gap between established reporting and the analytical investigation we wanted to pursue. Legacy databases and web-based reporting provided an existing information environment; consultation with Suffolk University on proposed machine-learning models in Jupyter notebooks opened up further questions. That exploration led to an analytical warehouse and the Audit Portal: a front end connecting analytical access with operational oversight.

The portal supports an Audit & Oversight department of approximately 10 staff users. I estimate that the department’s broader work involves more than 5,000 attorneys. That is an estimate of oversight scope, not a count of portal users or a verified current active-panel count. The challenge is to make complex information useful to a small, specialized team whose work supports investigation and management decision-making.

The department operates within the Committee for Public Counsel Services (CPCS). Its FY2027 agency appropriations total approximately $380 million across agency operations, private counsel compensation, and court costs. This is agency-wide financial context, not spending controlled by the portal or a financial outcome of the project.

My role

I am the sole hands-on developer across the analytical notebooks, warehouse, and Audit Portal. I consult with Audit & Oversight colleagues whose firsthand experience of attorney billing and casework adds context that is not apparent from database records alone. Their feedback informs analytical assumptions, model iteration, reports, and the audit interface. Model tuning is part of the process; this account makes no claim of a measured improvement in predictive performance.

University consultation informed the initial model proposals. IT colleagues contributed the data and access arrangements: an applications-team database analyst worked with me on scheduled master-data extracts, while infrastructure colleagues assisted with role-based access and application-identity permissions. These contributions are credited separately from the coding and development work.

From requirements to design

Departmental feedback connects analytical questions with the information people need to interpret a record and decide what to examine next. The tracker links record discovery with a detailed workspace: search and filters narrow the list, while the detail view distinguishes stable context, subsequent progress, and recorded changes.

Updates are deliberate. Permitted users can edit and save information, with explicit handling for unsaved work and conflicting changes. Historical compatibility matters too: validation accommodates specified gaps in earlier records rather than inventing information to make them appear complete.

Document attachments and functioning SharePoint folder synchronization connect supporting material to individual audits. Document-informed AI assistance lets users ask questions involving audit progress, analytical information, and policy guidance. The design must distinguish recorded facts, retrieved passages, and generated interpretations. A question spanning several documents is not evidence that every document has been read exhaustively or that the answer is correct; users retain responsibility for reviewing it.

  1. Find

    Narrow the view to the item that needs attention.

    Fictional record · first view

    Harbor review

    Needs context

    Next step: gather supporting material

  2. Understand

    Read the context before deciding what happens next.

    Same fictional record · context added

    Harbor review

    Ready for review

    Fictional briefing linked for review

  3. Update

    Make a deliberate change within the permitted workflow.

    Same fictional record · progress updated

    Harbor review

    Briefing reviewed

    Next step: prepare a summary

Conceptual workflow illustrated with fictional information. Not a screenshot of the internal application.

Why Blazor Interactive Server

I developed the portal with ASP.NET Core and Blazor Interactive Server, hosted on Azure App Service. This keeps application logic and data access on the server while providing a component-based interface. In departmental use, I have found the interface responsive for the team’s workflows; this is an observation, not a performance benchmark.

Working primarily in C# with reusable Razor components supports iterative refinement without maintaining a separate JavaScript application. Interface components, feature services, business rules, and persistence have distinct responsibilities. That introduces boundaries to maintain, but allows selected rules and failure conditions to be tested independently of a full screen. Departmental feedback can inform changes to shared patterns as well as individual views.

Microsoft Entra ID provides authentication. Application roles and server-side service checks restrict permitted actions beyond the visible controls. Managed identities support appropriately scoped access to approved backend Azure services, including analytical and workflow storage; this does not give portal users unrestricted Azure access or put database credentials in their browsers. Version-aware writes can reject updates based on outdated records.

The server-side approach also requires interactive connections, server resources, reconnect handling, and application-state management. Those responsibilities are part of the architecture and its trade-offs.

What the work enables

The implementation connects record creation and editing, searchable views, lifecycle information, progress and change-history views, document management, and workbook exports. Users work with synchronized supporting folders and document-informed questions in a common, permission-controlled workspace.

The practical value is helping a specialized team work with related analytical and operational information. Its significance is not a large login count: the workflow supports oversight questions involving records, documents, policy, and the data foundation behind them.

I have observed users updating tracker details without instruction. That is a qualitative observation, not a formal usability study or a measured reduction in time, cost, or errors. The integration enables review and investigation; it does not establish adoption levels, financial returns, or the accuracy of AI-generated answers.

What I learned

Software complexity is not determined solely by the number of users. A small team can work with information that has substantial financial and organizational significance. Building for that environment requires attention to authorization, data integrity, historical context, maintainability, and the practical judgment of the people using it. Colleagues’ experience continues to help me question assumptions and refine what an analysis or interface should make visible.