The GRC Vibe Coding Recipe Book · Lesson 03 of 07
Build a Policy Approval Workflow
Use PHP, Laravel and Filament to move from a form to controlled reviews.
All 7 Lessons · Jump to a Lesson
Recipe 03 · At a glance
PHP + Laravel + Filament
GRC use case: Policy approval workflow
Ingredients: PHP runs server logic · Laravel handles workflows and authorization · Filament provides administrative screens
Know the boundary: Shared approvals require trusted permissions and appropriate record storage.
The GRC problem
Why would a team need this?
Policy reviews are buried in email, and nobody can reliably tell who approved which version.
A policy request form and reviewer queue with explicit approval states. This gives us a useful way to understand the technologies involved: start with the work people need to accomplish, then consider what the application must do to support them.
The underlying concepts
What changes from the previous lesson?
A form is only the visible beginning of an approval process. The important difference is that a server can check who is permitted to make a decision, and a database can preserve the state for other reviewers. Laravel supplies those server-side patterns; Filament helps present the workflow.
Remember the four responsibilities from Lesson 01: interface, application logic, storage, and hosting. As requirements become more demanding, those responsibilities may need different technologies. More sophisticated does not automatically mean better.
Meet the stack
What does each technology contribute?
PHP is the server-side language. Laravel is a PHP framework for routes, validation, and database access. Filament provides common admin screens. PostgreSQL can store shared requests.
Laravel views and Filament admin interfaces
PHP and Laravel application logic
PostgreSQL for shared structured records
GitHub
These ingredients have distinct responsibilities. Understanding those boundaries is more useful than memorizing a list of popular tools, because it helps you recognize when a project needs something different.
Under the hood
How would the information move?
Follow a single piece of information through the example. The input starts with a person or an existing record, a rule transforms or validates it, and the interface or report presents the result.
A fictional policy title, submitter, reviewer, and requested date.
Laravel validates a submission and checks who may approve it. Filament presents the queue to authorized reviewers.
Pending, Approved, or Returned status with a recorded decision.
The location of the rule matters. A browser can update its own display, but decisions about access to protected records must be enforced by a trusted service. A database stores information; it does not, by itself, make the surrounding application secure.
Understand the limits
What would change the stack?
Add audit history, reminders, and additional roles only after permission and status tests work.
There is also a reason not to add more technology yet: If a single reviewer needs only a local checklist or read-only policy catalog, a static site or version-controlled file may be simpler.
What to remember: Server-side authorization, audit history, backups, and separation of duties matter more than a polished admin screen. Use fictional data in tutorials. A good stack is one whose responsibilities and tradeoffs you can explain, not necessarily one with the most features.