Model Laravel Package

Product Decisions This Supports

A go/no-go on a foundational architecture commitment, not a feature purchase. orchestra/model only becomes useful if domain models extend Orchestra\Model\Model instead of Illuminate\Database\Eloquent\Model. That puts a third-party class at the root of the domain layer — the single most expensive place in a Laravel codebase to reverse. The PM decision is "do we accept a foreign base class at the core of our product," and for a greenfield product the answer is no.

Build vs. buy, scoped to four concrete capabilities. Strip the framing down to what the package actually adds over vanilla Eloquent: Validable (validation on the saving event), Searchable (request-driven query scoping), Metable (model metadata), and Presenter (presentation bootstrapping). Each is reproducible in tens to low hundreds of lines with full internal control. The honest framing for a roadmap conversation is "extract the one trait we need into App\Models\Concerns," not "adopt a model layer."

Roadmap gating for Laravel modernization. The latest release line (v6.0.0) is explicitly a Laravel 8 support bump. Committing here means the product's upgrade cadence is bounded by an upstream project with no visible release momentum. That belongs in the platform roadmap as a named constraint, not discovered during a framework upgrade planning cycle.

Legacy containment and exit-cost tracking. If an inherited Orchestra Platform codebase already depends on this, the decision is maintain / contain / migrate — with an explicit budget. Exit cost scales linearly with the number of models extending the base class, so model count becomes a tracked product metric, surfaced at each Laravel major.

A dependency-governance precedent. Zero dependents, no star signal, 0.3 package score against a 41.25 opportunity score. This is the clean textbook case of opportunity without maintenance. Use it to set the bar: a low-signal, single-maintainer package cannot enter the core domain layer regardless of how neatly it solves a narrow problem.

Owning the "no" (and the counter-case). The opportunity score will be cited by someone as a reason to adopt. The PM position: opportunity scores are a prompt to evaluate build-vs-buy, not adoption evidence. Where a team wants to proceed, sanction only a 1–2 day spike to enumerate capabilities gained — and if that list is internally reproducible, reimplement.

When to Consider This Package

Consider it only when:

• An existing Orchestra Platform application already depends on it, and an immediate swap creates more delivery risk than temporarily containing it.
• You require exact parity with Orchestra model conventions and cannot move Composer constraints or platform assumptions.
• You have a named internal owner plus engineering capacity to audit, vendor, fork, and patch — and you accept that maintenance burden as a standing line item.
• You need a short-lived migration bridge, confined behind a single App\Models\BaseModel, with a pre-agreed fork-or-remove trigger.
• A time-boxed spike (1–2 days, three representative models, diffed against vanilla Eloquent) proves the needed traits save materially more than reimplementation. Realistically only Validable and Searchable are plausible candidates.

Look elsewhere when:

• You are building a greenfield Laravel product — use Illuminate\Database\Eloquent\Model directly, plus internal traits as needed.
• You require active maintenance, security releases, documentation, community support, or current Laravel majors. A Laravel 8 ceiling in the latest release line is a strong lag signal.
• The package would become central to a multi-tenant model layer, a SaaS domain, or any core domain modeling.
• No internal owner will accept responsibility for a low-signal legacy dependency. No owner, no adoption.
• The justification rests on stars, dependents, or a composite score — those signals are weak or absent here (zero dependents means no community canary; we absorb all breakage first).
• You only want validation-on-save or query scoping — a small internal trait set or an established community package covers that with real support.
• Adoption would drag orchestra/testbench into the test harness with constraints that conflict with the existing CI stack. Treat a resolution failure as a stop signal, not a workaround to engineer around.

How to Pitch It (Stakeholders)

Executive summary. orchestra/model is a niche base-model component from the Orchestra Platform ecosystem, not a strategic dependency. With zero dependents, no visible star signal, and a 0.3 package score, it is a maintenance and continuity risk rather than a platform investment. Its latest release line targets Laravel 8, which would cap our upgrade path. The 41.25 opportunity score reflects latent usefulness — it is not evidence that the package is safe to adopt.

Recommendation. Do not adopt it for new products; standardize on native Laravel Eloquent. If it is already present in an inherited Orchestra codebase, contain it rather than expand it: forbid domain models from extending Orchestra\Model\Model directly, introduce a single App\Models\BaseModel so the dependency lives in one file, pin the version, commit the lockfile, document exactly which features we rely on, and set a fork-or-remove trigger at the next Laravel major. Reassess at every major upgrade rather than renegotiating under pressure.

Engineering guidance. Integration is mechanically trivial — a Composer require plus a base-class swap. The real cost is compatibility validation and exit cost. Before any continued use: audit the illuminate/* constraint against the target Laravel/PHP matrix (validate oldest and newest supported PHP), confirm orchestra/testbench resolves alongside existing test dependencies, check the license permits an internal fork, and identify a security disclosure path and support window. Assume we own maintenance — there are no downstream dependents to catch upstream breakage before it reaches us. Watch the concrete failure modes: a missing Laravel major blocking the whole application upgrade, silent semantic drift in casting/mutators/save-time events, trait collisions between Validable/Searchable and application-level model behavior, and test-harness breakage disabling CI mid-port.

Product guidance. This package creates no product differentiation; at best it protects legacy compatibility. The PM decision is to minimize exposure, avoid new build cost around it, keep the migration path open, and hold the line on scope: if a team argues for adoption, the correct response is a bounded spike to list capabilities gained — and if that list is reproducible internally, extract the two or three traits actually needed and drop the dependency entirely.