VeriGov: Designing Public Transparency Around Reviewed Evidence
By Raymund Zyron Abella /
A team-built Cebu City platform connects public project browsing with scoped preparation, evidence review, procurement, and financial records.
In this article
A project photograph, a payment record, and a public progress update describe different parts of construction work. Putting them on the same dashboard does not automatically make them consistent. VeriGov's central problem is deciding how those records move through preparation, review, and publication without losing their relationships.
The platform brings public infrastructure browsing and authorized operational workflows into one Cebu City project system. Citizens can explore published projects, locations, progress, and updates. Staff and designated officers work with procurement, field submissions, budgets, and supporting documents behind that public view.
I serve as Project Leader and Developer in the three-person team, alongside John Lorenzo Flores on frontend and quality assurance and Jhon Paul Noquiana on backend and systems development. The VeriGov project page includes screenshots, the stack, and the supplied Android build. The public portal provides the reader-facing entry point.
Start With One Project, Not a Dashboard Total
A useful first visit is to locate a project, inspect its location, and follow its published activity. The directory and map offer different ways to reach the same record: a person may know the project name, or only the place where work is happening.
Once inside that record, the questions become specific. What work is described? What supporting evidence is visible? When was the last published update? How does physical progress relate to the recorded financial activity?
These questions give the public interface a purpose beyond displaying totals. A summary number helps orient a visitor, but a traceable project record helps them investigate. Public dashboard totals use a persisted seven-day snapshot, so they should also be understood separately from operational screens with their own update rules.
Preparation and Approval Are Different Actions
VeriGov separates Staff preparation from formal submission. Administrators assign functions and record scopes; a Staff member can prepare inputs within those assignments without receiving every permission of the parent role. Prepared work still passes through Admin review and submission.
That distinction affects the database, API, and interface. A saved draft is not a published project update. A correction request needs to preserve the context of the earlier submission. A person revising an assigned record should see the relevant fields without inheriting unrelated administration powers.
The same principle extends across the larger role model. Project Managers handle assigned project and reporting work. Contractors submit progress and evidence. Budget Officers handle allocations and payment-related records. Auditors inspect information and document findings. Citizens browse the published view and can use account features such as following projects.
The Go API enforces role and scope boundaries. Hiding a button alone cannot establish who may update a record; the server must make the same decision when a request arrives directly.
Evidence Review Connects Photos to Decisions
Field reports combine progress information with photos and captured locations. Their value depends on the review path that follows: a reviewer needs to inspect the material, understand the associated record, request corrections where necessary, and decide what can update the official project information.
The application includes AI-assisted image checks, but the models support that human process. EfficientNet-B0 is used for suspected AI-generated imagery, SegFormer-B2 for building elements, and DMS46 for material segmentation. An output from one of these models is not, by itself, proof of authenticity, structural safety, or completed construction.
This is an important interface decision. A model result should be attached to its evidence and interpreted in context. Presenting it as an automatic approval would collapse an uncertain observation into an authoritative workflow action.
For a practical reading exercise, compare an approved update with the evidence attached to it. The useful question is whether you can understand why the update exists and what supports it. Public visibility and staff review should communicate different stages of that process.
The Stack Follows the Work
The web application uses React 19, TypeScript, React Router, Vite, and Tailwind CSS. The Android client uses Expo and React Native. Both interact with a Go/Fiber API with JWT authentication and role/scope middleware.
PostgreSQL with PostGIS stores relational and location-aware records. Redis supports shared read caching, mutation invalidation, and fallback to the database. Cloudinary handles media, and a separate Python/FastAPI/PyTorch service performs image analysis. The local deployment also includes Nginx for proxying, compression, connection reuse, and request controls.
The division matters because each component owns a different kind of work. A public project lookup does not need to run image inference. A photo upload does not imply that a financial record has been approved. Cached reads need a path to become fresh after the underlying data changes.
The Android client adds another delivery surface, not a second independent source of truth. Its screens still need to respect the same protected actions and publication rules as the web client.
Financial and Physical Progress Need Context
Allocation review, payment requests, and disbursement records sit alongside construction progress. Showing them together helps reveal questions that would be hidden in separate tools, but the application should retain the meaning of each measure.
A financial percentage and a physical percentage can differ for legitimate reasons. The platform's job is to make the supporting records inspectable and the review actions attributable, rather than suggest that equal percentages prove a healthy project.
Activity logs and correction history support that approach. A record's latest state is useful; knowing how it reached that state helps an authorized reviewer investigate a discrepancy.
What I Would Evaluate With Users
For a citizen, I would observe whether they can find the intended project, identify its latest published update, and distinguish a snapshot total from an individual record. For Staff, I would test preparing an assigned input, responding to a correction, and understanding which step still needs approval.
These are proposed evaluation tasks, not reported adoption or impact metrics. Completing the wrong workflow quickly is not a success. The useful outcome is an understandable chain from input, to evidence, to review, to the published information a visitor can inspect.
Start with the public portal, or use the portfolio case study to inspect the screenshots, Android download, and implementation excerpt. The project earns its place here because transparency depends on the structure of the workflow underneath the screen.