Filament Autograph Laravel Package

Technical Evaluation

Architecture fit. This is a Filament form field — a Field subclass registered by a service provider, a Blade view, and a canvas-based signature pad bound into Livewire component state. Architecturally it is an additive leaf node: no migrations, no routes, no controllers, no jobs, no service-layer coupling. It slots into a form schema exactly where a TextInput or FileUpload already sits. From a planning perspective that matters because it means the integration has no cross-team surface area: no API contract to agree, no data model to negotiate with another squad, no infrastructure change. The corollary is equally important — if the target application is not already Filament + Livewire + Alpine, the package has effectively zero applicability and the correct decision is to integrate a plain JS signature library instead.

Integration feasibility. composer require, optionally publish config/views, one line in the form schema, and a storage decision. A first working field is realistically under a day of engineering. There is no architectural debate to schedule; the open items are version compatibility and payload handling, both of which are spike questions, not design questions.

Technical risk.

• Adoption risk (primary). 82 stars, zero dependents, single maintainer, MIT. There is no evidence of production use at scale and no second contributor to absorb abandonment. This is not disqualifying because the surface is small enough to fork and own outright — but it must be planned as vendored source with an upstream, not as infrastructure with a support contract.
• Version-coupling risk. Filament's form-component and asset-registration hooks changed materially between v3 and v4. A form field is precisely the component type that breaks on a major bump, and it breaks quietly: a missing asset or a renamed hook renders a blank canvas, the form still submits, and a null signature is persisted with no exception. That failure shape — silent, data-corrupting, discovered months later — is the single most important thing to design against.
• Data-handling risk. If capture holds a base64 data URL in Livewire component state rather than routing through Livewire temporary uploads, request size becomes a hard constraint via post_max_size and the signatures table bloats. This is a storage-architecture decision the TPM should force early, because retrofitting it means rewriting saved records.
• Compliance risk. The package captures pixels; it does not establish intent. Signer identity, timestamp, IP/user agent, document version, consent text, retention window, and immutable audit trail are entirely our responsibility. Nothing in the dependency helps with any of it.
• Maintenance signal. The published release date (2026-10-08) is future-dated relative to normal expectation. Verify it against actual tags and commit history before treating it as a liveness signal — do not let a dashboard read substitute for a manual check on a single-maintainer package.

Key questions.

1. Which Filament majors are declared in composer.json, and which are actually exercised in CI?
2. Is output raster (PNG/JPEG) or vector/point data, and is raw point data retrievable for a stronger evidentiary record?
3. Does capture use Livewire temporary uploads, or base64 in component state?
4. Are assets published locally or pulled from a CDN (CSP implications)?
5. Is empty-canvas submission blocked, or can a blank signature be saved?
6. Does it honor ->disk(), ->directory(), ->visibility(), required/disabled state, and deletion-on-update consistent with FileUpload?
7. Accessibility: keyboard/stylus/touch support and any assistive-tech fallback.
8. Test coverage and maintainer responsiveness behind the star count.

Integration Approach

Stack fit. Laravel + Filament + Livewire + Alpine. Native fit for an existing Filament panel — the field inherits validation, state binding, and layout for free. If the target is Livewire-but-not-Filament, stop and re-scope to the underlying JS library; the wrapper's entire value is the Filament field contract.

Migration path. Purely additive and reversible, which is the strongest argument for running the spike at all. Add a nullable column or a dedicated disk path, add the field to a single form, and let existing signature workflows (wet-signature scans, file uploads, or a third-party e-sign vendor) coexist behind a flag during pilot. No schema rewrite, no backfill, no historical data migration — existing signatures stay as-is, and reverting to a FileUpload is a one-line change. This is a cheap-to-enter, cheap-to-exit dependency, which is exactly the risk profile to prioritize when engineering capacity is contested.

Compatibility. Pin the Filament major and the package minor in composer.json. Fluent method names have drifted between releases, and an unpinned composer update produces "my ->disk() call silently does nothing" bugs that surface as data-quality incidents rather than build failures. Resolve the constraint against our exact Laravel/Filament/Livewire versions in a scratch project before touching the main app. Also confirm Tailwind coverage: if the Blade view uses utility classes absent from Filament's compiled CSS, the field renders unstyled unless assets ship compiled.

Sequencing.

1. Spike (1–2 days, one engineer). Throwaway Filament panel on our exact versions; confirm render, capture, save, retrieve, delete, and required-field validation. Exit criterion: a written answer to the eight questions above.
2. Storage decision (same week). Disk + path-in-column over base64-in-column. If the package doesn't support it natively, wrap it — do not accept blobs in component state as the default. This decision gates everything downstream.
3. Internal wrapper. A SignatureField extending or composing the package field, so a fork or vendor swap is a one-file change and upstream internals never leak into application code. This is the insurance policy that makes the adoption risk acceptable.
4. Pilot. One low-stakes internal form — waiver, acknowledgement, delivery receipt — explicitly not a customer-facing contract. Success metric is not "it works," it's "the saved record is usable as evidence."
5. Policy gate (parallel, not after). Consent language, retention period, access control, and audit logging agreed and implemented before a second form ships. This is organizational work owned by legal/compliance/ops, not engineering, and it is the actual critical path.
6. Rollout and re-evaluation. Remaining forms, then reassess vendor/fork posture at the next Filament major upgrade.

Operational Impact

Maintenance. Small code surface, low drag — realistically 1–2 days per year for Filament version bumps, plus the cost of a fork if the maintainer goes dormant. Budget for that fork from day one by keeping the wrapper thin and the diff against upstream clean. Pin versions; do not float.

Support. No vendor, no SLA, community issues only. Name a single backend owner — this is a one-person package, not a team-scale dependency, and it should not be owned by a team that assumes someone else is watching it. Track upstream tags and issues directly rather than treating the star count or release metadata as a health proxy.

Scaling. Storage cost is negligible at any realistic volume — signature images are tens of kilobytes. The scaling concern is the write path: base64 payloads riding through Livewire component state grow request size, hit post_max_size, and turn the signatures table into a hot, bloated table that is expensive to index and back up. Routing through Livewire temporary uploads to object storage removes both problems. The read path is trivial and needs no attention.

Failure modes to instrument.

• Filament major upgrade removes an asset-registration hook → canvas renders blank, form still submits, null signature persisted silently. Mitigate with a server-side assertion (model observer) that the stored artifact is non-empty and decodable, and fail loudly.
• CDN-hosted JS blocked by CSP → same silent-blank failure. Prefer locally published assets.
• Oversized payload rejected at PHP/web-server limits → 413 or silent field loss. Log and alert.
• Empty canvas accepted → a legally useless record. Validate at the model/observer layer, never trust client-side required state alone.
• Unbounded retention of biometric-adjacent data → compliance exposure. Enforce deletion via a scheduled job, not a manual process.

Ramp-up. Engineering ramp is trivial — an afternoon for anyone fluent in Filament. The real ramp-up is organizational: agreeing on consent language, retention window, view access, and whether a PNG of a scribble actually satisfies the business requirement. Settle that before the pilot, not after, because it determines whether the second form ever ships.