Identity Core Filament Laravel Package

Technical Evaluation

What it is. liberusoftware/identity-core-filament is a thin Filament presentation adapter over a separately configured Liberu identity model. It does not appear to own identity domain logic; it exposes admin resources/pages for whatever model the host application binds. That is the right architectural instinct for an admin adapter — keep the domain in identity-core, keep Filament at the edge — but it also means the package is only as good as an implicit, undocumented contract between the adapter, the identity model, and the Filament version in use.

Architecture fit. Fit is high only if we are already standardizing on Laravel + Filament + the Liberu identity module. In that context the adapter is a legitimate separation-of-concerns layer: panel registration, resources, forms/tables, and navigation live outside the domain package. Fit is poor if we are not on Liberu, because the package presumes a model shape it does not define. The “configured model” pattern is flexible at runtime but weak at compile time — there is no formal interface visible in the package metadata, so field names, relationships, tenancy scoping, and authorization expectations are effectively a handshake contract. A TPM should treat that contract as the primary integration artifact and require it to be written down and tested, not inferred.

Integration feasibility. Technically feasible for a small team: Filament adapters are usually low-LOC, and the integration surface is Composer install, service-provider/panel registration, config for the model class, and policy/authorization wiring. The practical cost is not installation; it is contract discovery — confirming which Filament major is supported, how the identity model is resolved (config key vs. container binding), whether policies and migrations ship with the adapter or are expected from identity-core, and whether multi-tenant or multi-guard scenarios are handled. With zero stars, zero dependents, and a single release timestamp (future-dated relative to normal review cycles, which suggests automated tagging rather than a maintained release cadence), we would be the first production adopter. That is acceptable for an internal or reference implementation, not for a dependency we expect the ecosystem to harden for us.

Technical risk.

• Version coupling. Filament has breaking changes across majors (resource/form/table APIs, panel registration). A zero-adoption adapter is unlikely to track them promptly.
• Implicit model contract. Renaming or reshaping identity fields in identity-core can break forms/tables silently; no published contract or contract tests are visible.
• Security-sensitive surface. This is an identity administration UI — user records, roles, possibly credentials and PII. Low community review means authorization gaps and mass-assignment exposure must be audited by us, not assumed safe.
• Supply-chain and bus factor. Single-vendor namespace, one maintainer, no dependents. MIT license is fine; operational continuity is not.
• Data-quality signals. A 19.89 score with 0 stars/dependents is a weak adoption signal, not a code-quality verdict. The opportunity score (43.48) suggests niche usefulness inside the Liberu ecosystem rather than broad demand.

Key questions.

1. Which Laravel, PHP, and Filament majors are supported, and are Composer constraints explicit?
2. How is the identity model resolved — config class string, container binding, or hard reference — and is there an interface we can implement?
3. Does the package ship authorization policies, or does it rely entirely on host gates/policies? Are there default-deny guarantees?
4. Are migrations, factories, and seeders included, or owned by identity-core?
5. Does it support tenancy, multiple guards, impersonation, and audit logging, or are those host responsibilities?
6. Is there CI/test coverage, and is the repository a read-only split from a monorepo (common in modular Liberu projects)? If so, where do issues and PRs go?
7. Who is the accountable maintainer, and what is the expected upgrade cadence for new Filament majors?

Integration Approach

Stack fit. Adopt only if the target application is Laravel + Filament and already committed to the Liberu identity module. If we are on Filament but not Liberu, the adapter’s value collapses to “reference implementation”; building equivalent resources in-house is typically a few days and gives us full control of the model contract. If we are on Liberu but not Filament, this package is irrelevant. The decision is therefore a stack-commitment decision, not a package-selection decision.

Migration path.

1. Source review before install. Read the service provider, resource classes, and config. Confirm the model resolution mechanism and list every field/relationship the UI assumes.
2. Scratch-app spike. Stand up a disposable Laravel + Filament + identity-core app at pinned versions. Register the panel and exercise create/read/update/delete, search, filters, and authorization as a non-admin and admin.
3. Contract test. Write a small test suite asserting our identity model satisfies the adapter’s assumptions (fields, relationships, policy methods). This becomes the regression gate for upstream changes.
4. Authorization and data-exposure review. Treat the generated UI as an attack surface: check policy coverage, mass assignment, tenant scoping, and whether sensitive fields are exposed in tables/exports.
5. Pin and vendor if necessary. Pin exact versions in composer.lock. If the package is a monorepo split with no issue tracker, plan to fork or vendor under our namespace rather than depend on upstream responsiveness.
6. Feature-flag rollout. Ship behind a flag with the in-house resource path as fallback. Identity admin is not a place for a big-bang cutover.

Compatibility. Verify PHP/Laravel/Filament constraints in composer.json, service-provider auto-discovery, and whether the package assumes Filament v3 or v4 namespaces. Check alignment with the specific identity-core version — the adapter and core should be upgraded as a pair, not independently. Confirm CSS/asset publishing requirements and whether the package registers its own panel or expects ours.

Sequencing. Do the spike and contract test before committing to the dependency; do the authorization review before any staging exposure; do the fallback implementation estimate in parallel so the build-vs-adopt decision is priced, not assumed. If the spike reveals more than a day of contract mismatch, switch to in-house resources.

Operational Impact

Maintenance. Assume we own this code in practice. With one maintainer and no dependents, upstream fixes for new Filament majors may lag or never arrive. Budget a named internal owner, a pinned-version policy, and a quarterly diff against upstream. Prefer vendoring/forking with a documented patch set over waiting on releases.

Support. There is no community to lean on: no Stack Overflow corpus, no issue history, no third-party tutorials. Support is “read the source.” That is workable for a small Filament-fluent team and expensive for anyone else. Escalation path is internal, not vendor.

Scaling. The adapter itself is unlikely to be the bottleneck; Filament admin performance is dominated by table queries, search, and relationship loading. Risks are N+1 queries on identity lists, unindexed search across large user tables, and tenant scoping that silently widens result sets. Plan query review and pagination defaults before user volumes grow. The adapter does not address caching, queues, or read replicas — those remain host concerns.

Failure modes.

• Filament major upgrade breaks resources/forms with no upstream patch.
• Identity model field or relationship rename breaks the UI silently (forms render, writes fail or drop data).
• Missing or incomplete policies expose identity data to unauthorized admins.
• Model resolution fails at boot after a config or container change.
• Composer constraint conflict forces an older Filament or Laravel than the platform requires.
• Monorepo split leaves the package stale relative to identity-core, producing version skew between UI and domain.

Ramp-up. For a developer already fluent in Filament, ramp-up is hours to first running panel and one to three days to production confidence once the contract test and authorization review are in place. For a team without Filament experience, plan one to two weeks including panel conventions, policy patterns, and resource customization. The hidden cost is not learning Filament; it is discovering and documenting the implicit identity-model contract, which is the same cost whether we adopt this package or build our own — but with the package we inherit someone else’s undocumented assumptions.

TPM recommendation. Treat this as an internal reference implementation or a justified dependency only inside an existing Liberu + Filament commitment. Do not adopt it as a standalone bet. Gate adoption on the source review, scratch-app spike, contract test, and authorization audit; price the in-house alternative in parallel. The low adoption score is not disqualifying for a niche adapter, but it does mean the operational burden transfers to us on day one.