Verdict Console Filament Laravel Package

Technical Evaluation

Architecture fit The plugin is a thin adapter layer sitting on a three-package stack: laravel/ai (LLM abstraction), fissible/verdict (evaluation/evidence core), and fissible/verdict-console (console UI, evidence browser, doctor). Its surface area is narrow and test-oriented: a queue-recording agent (captures prompts/usage for assertions), evidence-browser fixtures (seeds the console's evidence tables), and a doctor baseline (declares the expected clean-install state). That is a good architectural fit — it adds integration glue rather than runtime behaviour, so it does not constrain application design. The cost is coupling: the plugin consumes internal seams of two pre-1.0 cores (prompt() input union, TextUsage, evidence column set, doctor config keys), so its stability is capped by theirs.

Integration feasibility Feasible but strictly lockstep. v0.4.0 is a coordinated bump — plugin → verdict-console ^0.11 → laravel/ai ^1.0 + verdict ^0.18. It cannot be adopted partially, and it cannot coexist with a host pinned to laravel/ai 0.x. Feasibility therefore reduces to two questions: does the host already consume laravel/ai directly (and can it move to 1.0), and does the host's DB schema permit the two new evidence columns?

Technical risk (medium-high for this release)

• Transitive breaking change. The breaking signal originates in the core, not the plugin. Hosts must treat this as a laravel/ai 1.0 upgrade with the plugin as a passenger, not as a patch bump.
• Schema drift. review_outcome and review_request_fingerprint (added in Verdict 0.16/0.17) are now required by the evidence-browser fixtures. If migrations are owned by verdict and not published/run, fixture seeding and browser queries fail at runtime rather than install time.
• Silent widening of prompt(). Laravel AI 1.0's widened input union means inputs previously rejected at the type boundary may now be accepted. Tests that asserted on rejection will invert; worse, invalid shapes may reach the provider and fail later, more expensively.
• TextUsage swap. Any host or plugin code doing token/cost accounting against the old usage type will break at the type level — noisy, but at least fail-fast.
• Doctor baseline change. Recording verdict-console.evidence.accepted_off in the baseline makes a clean install read clean. Correct for new installs; for existing installs it can convert a previously visible warning into silence. Confirm the default posture (off) is what the team actually intends.

Key questions

1. Is the laravel/ai ^1.0 requirement hard, or is there a compatibility shim for 0.x hosts?
2. Who owns the migrations for review_outcome and review_request_fingerprint — the plugin, verdict, or the host? Are they publishable?
3. Is there a documented upgrade guide from v0.3.x, or is the changelog the only artifact?
4. What is the support window on verdict-console 0.10 and below — security-only, or dropped?
5. Does the doctor check now assert accepted_off, or only record the host's value? If it asserts, hosts overriding the default will get false failures.
6. PHP/Laravel version matrix for the new trio.

Integration Approach

Stack fit Good fit for Laravel apps already using laravel/ai for prompt execution and wanting deterministic, testable evidence of LLM behaviour. The plugin is opt-in test infrastructure — it does not belong in production request paths. The dependency footprint is the deciding factor: it pulls three pre-1.0 packages, so it is best adopted in a single service or an internal tool rather than a shared platform dependency.

Migration path Treat as a coordinated three-package upgrade, not a plugin upgrade. Recommended path:

1. Branch and pin: plugin v0.4.0, verdict-console ^0.11, verdict ^0.18, laravel/ai ^1.0.
2. Confirm no other dependency requires laravel/ai <1.0; resolve conflicts before touching plugin code.
3. Publish and run migrations for the two new evidence columns; verify in a scratch DB.
4. Regenerate evidence-browser fixtures rather than patching them — they are schema-coupled.
5. Update any TextUsage consumers to the 1.0 type.
6. Review prompt() call sites for inputs now accepted that were previously rejected; add explicit validation where the union is too permissive.
7. Run the doctor command and diff the baseline output against the pre-upgrade run.

Compatibility No dual-version support is implied by the notes. Expect a hard break with laravel/ai 0.x hosts. Consumers on verdict-console 0.10 cannot upgrade in place without moving the whole stack.

Sequencing Upgrade the core trio first, on a branch, with the plugin last and the fixtures regenerated after migrations. Do not attempt to stage the schema change separately from the dependency bump — the fixtures make them one unit of work.

Operational Impact

Maintenance The dominant ongoing cost is version tracking, not code. Three pre-1.0 dependencies moving on independent cadences (verdict 0.16 → 0.18 inside one plugin release) means upgrade work arrives in bursts. Budget a recurring allocation for dependency upkeep rather than treating this as a one-off integration.

Support Supportability depends on artifacts not evidenced here: an upgrade guide, a doctor command that produces actionable diagnostics, and a changelog that names breaking changes explicitly. The v0.4.0 notes are unusually good on what changed and thin on what to do about it — expect to write the internal runbook yourself.

Scaling Plugin overhead is negligible at runtime (test/console paths only). The scaling concern is schema: two new evidence columns add width to a table that grows per evaluation run. Confirm indexing on review_request_fingerprint before evidence volume becomes material, and set a retention policy on evidence rows early.

Failure modes

• Missing migrations → fixture seeding fails, evidence browser returns empty or errors.
• laravel/ai version conflict → composer resolution failure at install, which is the good failure.
• TextUsage mismatch → type errors in accounting paths.
• Doctor baseline suppression → a misconfigured evidence policy (accepted_off) goes unreported on existing installs.
• Widened prompt() union → invalid inputs reach the provider, surfacing as runtime errors and spend rather than test failures.

Ramp-up Low for engineers already fluent in Laravel testing and Pest/PHPUnit-style assertions — the plugin's mental model is conventional. The real ramp-up is conceptual: understanding evidence-as-artifact, the doctor baseline contract, and why fixtures are schema-coupled. Half a day for a Laravel-comfortable engineer; longer for anyone new to laravel/ai 1.0's usage types.

Recommendation Adopt v0.4.0 for new work where laravel/ai 1.0 is already the target or is on the near roadmap. For existing installs, schedule it as a deliberate stack upgrade with a migration step and a doctor-baseline review — do not take it as a routine dependency refresh.