Statamic Classify Laravel Package

Product Decisions This Supports

• Build vs. buy for editorial automation: statamic-classify adds automatic classification (taxonomy/tag assignment) to Statamic content, so the decision is whether to buy a small maintained addon versus building an in-house classifier hook into the entry-save lifecycle. v4.0.0 keeps the buy case intact — it's actively maintained, now on Laravel 13 and Statamic 6, and the maintenance work in this release (Pest 4, CI matrix fix) signals a maintainer still investing rather than a stalled repo.
• Roadmap sequencing for content-ops features: auto-tagging is usually a prerequisite for personalization, related-content modules, and search relevance. This package de-risks that first step, so it can slot in ahead of those roadmap items without committing to a bespoke ML pipeline.
• Platform upgrade planning: this is a breaking release. Minimum PHP 8.3, Statamic 4 and Laravel 10 support dropped. If our hosting/pipeline is on PHP 8.2 or Laravel 10, adopting this version is gated behind an infrastructure upgrade — that coupling belongs in the upgrade roadmap now, not at feature kickoff.
• Taxonomy governance / content model decisions: automatic classification only works if the taxonomy is well-defined. Evaluating this package forces a useful product conversation about whether we have controlled vocabularies worth enforcing, or whether free-form tagging is acceptable.
• Scope sizing for the CMS migration or new site build: for any greenfield Statamic build, this is a low-cost capability to include in the initial scope rather than a later bolt-on.

When to Consider This Package

Consider it when all of the following hold:

• The CMS is Statamic (v5 or v6) on Laravel 11–13, and the engineering team can commit to PHP 8.3+. This is non-negotiable in v4.0.0.
• Editorial volume is high enough that manual tagging is a measurable bottleneck — roughly thousands of entries, or a backlog of untagged legacy content.
• The content model already has, or is ready to have, a defined taxonomy. Classification against a vague or fast-changing vocabulary produces inconsistent results and erodes editor trust.
• The team accepts AI-assisted tagging as suggestion-then-review rather than fully unattended. Budget review time in the editorial workflow.
• Someone owns ongoing taxonomy curation. The addon classifies; it doesn't decide what "good" categories are.

Look elsewhere when:

• We're pinned to PHP 8.2, Laravel 10, or Statamic 4. Staying on the v3.x line is possible short-term, but it is now a dead end — no security or compatibility patches going forward.
• The need is general AI content generation, summarization, or search embeddings rather than taxonomy assignment. This package is narrow by design.
• Category definitions are unstable or genuinely ad hoc; a fixed-vocabulary classifier will fight the editorial team.
• Compliance or data-residency rules prohibit sending content to a third-party model provider. Confirm the underlying provider and data flow before adoption, and note that this is the dominant integration risk in v4.0.0-era deployments.
• Very low content volume — manual tagging is cheaper than the integration, review, and curation overhead.

How to Pitch It (Stakeholders)

To executives: We're evaluating a small, actively maintained addon that automates tagging and categorization of CMS content using AI. It's a force multiplier for the editorial team, not a platform bet — low cost, contained blast radius, and reversible if results disappoint. The v4.0.0 release confirms the maintainer is keeping pace with current Laravel and Statamic versions, which reduces the "abandoned dependency" risk that usually kills addons like this.

To engineering: v4.0.0 is a breaking release: PHP 8.3 minimum, Statamic 4 and Laravel 10 dropped, Laravel 13 added, tests migrated to Pest 4. That means adoption is coupled to our PHP runtime upgrade — check that first. Beyond the version gate, the integration surface is small and idiomatic to Statamic; the real work is defining the taxonomy and building a review step so editors can override machine suggestions. Flag one dependency risk: the release's compatibility matrix is the most important line in the changelog, and we should pin to a known-good version rather than floating.

Recommendation: proceed to a time-boxed spike on a non-production Statamic 5/6 environment running PHP 8.3+, scoped to one content collection with an existing, stable taxonomy. Success criteria: editor-reported accuracy above an agreed threshold, and review time per entry materially below manual tagging. If PHP 8.3 isn't available, defer — do not adopt v3.x as a workaround.