Statamic Aida Laravel Package

Technical Evaluation

Architecture fit

• The package is a Statamic addon, not a standalone library, so it slots into the Laravel service container via Statamic's AddonServiceProvider lifecycle. That is the correct integration seam for this capability: it can subscribe to asset events, register config, and expose commands without touching application code.
• Functionally it belongs to the asset ingestion pipeline. The natural design is an event listener on AssetUploaded/AssetSaved that calls a vision-capable model and writes the result to the asset's alt field. Confirm whether it works that way or via a fieldtype/control-panel action, because that determines whether it is a write-path dependency or an editorial tool.
• It is a horizontal capability (accessibility/SEO) rather than a domain feature. Low blast radius, wide applicability across content repositories — a good candidate for a contained pilot.
• Release 2.2.0 (Statamic v6 support) does not change the architecture fit. It changes the compatibility envelope and the maintenance signal, not the integration seam.

Integration feasibility

• Integration surface is small: composer require the addon, publish config, set an API key in the environment, enable per asset container or field. Typical effort is hours, not sprints.
• The main feasibility question is not installation but policy: images leave the infrastructure for a third-party inference API. That requires a data-handling and vendor review before production, independent of code quality.
• Version constraints must be checked against the actual Statamic major (4 vs 5 vs 6) and Laravel/PHP floor. 2.2.0 adds Statamic 6 support, but supporting a new major is sometimes implemented by dropping older ones in the same release — verify the statamic/cms constraint in 2.2.0's composer.json before assuming it is a safe in-place upgrade for a Statamic 4 or 5 application.
• Vendor/package identity needs confirming. The release notes point at 21stdigital/statamic-aida, while the current assessment records the install as tfd/statamic-aida. Confirm the canonical package name and whether this was an ownership transfer or a fork; picking the wrong one means tracking a package that will never get the v6 fix.

Technical risk

• Adoption/vendor risk is the dominant one, marginally improved. Five stars and zero dependents still means effectively no production validation and no community fallback, but 2.2.0 landing within a reasonable window of Statamic 6 shows the maintainer is responsive to major-version churn. That is the single most common cause of silent addon abandonment, and it has been addressed once. It does not establish a support commitment.
• Statamic major-upgrade coupling. The addon's release cadence is now tied to Statamic's. Every future Statamic major is a gate on this capability continuing to work, and there is still one maintainer. Keep this in the risk register rather than treating 2.2.0 as durable proof of health.
• AI provider coupling. The package inherits the provider's API churn, pricing changes, and deprecations. Model quality changes underneath a pinned addon version.
• Correctness risk. Alt text is an accessibility artifact; a confidently wrong description is worse than no description for screen-reader users. There is no automatic quality gate.
• Write-path risk. If generation is synchronous on upload, an API outage becomes a CMS outage. If it overwrites existing alt text, it destroys editorial work.
• Cost risk is per-image and scales with publishing velocity; without a budget cap or caching keyed on image hash, retries and re-saves multiply spend.
• 2.2.0 is a minor feature release and non-breaking for existing 2.x consumers on the same Statamic major. It does not address any of the substantive open questions below (queueing, provider abstraction, overwrite behaviour, review state, backfill). The opportunity/quality read stands: a well-built but narrow-value package — worth a pilot, not a platform commitment.

Key questions

1. What is the statamic/cms constraint in 2.2.0 — does it support 4/5/6 simultaneously, or does it require 6 and drop earlier majors?
2. What Laravel and PHP floors does 2.2.0 impose, and do those force an application framework upgrade?
3. Is 21stdigital/statamic-aida the canonical package (renamed/transferred from tfd/statamic-aida) or a separate fork? Which one should we depend on?
4. Which providers/models are supported, and is the provider abstracted or hardcoded?
5. Synchronous or queued? Does it respect Laravel queues, retries, and backoff?
6. Does it overwrite manually authored alt text, and is there a review/approval state before publish?
7. Multi-site and multi-language support — can alt text be localized per site?
8. Is there a bulk backfill command for existing assets, and is it idempotent?
9. How are asset types handled (SVG, PDF, animated GIF) and are unsupported types skipped cleanly?
10. Where are API keys stored, and is anything logged that shouldn't be?
11. What is the per-image cost at our expected upload volume?

Integration Approach

Stack fit

• Assumes a Laravel + Statamic application with Composer-based dependency management and an existing asset container structure. No database migrations expected (Statamic stores metadata in YAML/JSON alongside assets), which keeps rollback cheap.
• Requires an external inference API account and secret management. That is the only real infrastructure addition.
• Statamic 6 raises the framework floor for the whole application, not just this addon. If the target app is on Statamic 4 or 5, adopting 2.2.0 may be gated behind a full CMS upgrade — which reclassifies this from "addon install" to "platform upgrade" and should be sequenced as such.

Migration path

• Non-destructive by design if the addon only writes the alt field: disable the addon and prior values remain. Verify it does not mutate asset filenames or move files.
• Determine the target dependency first: on a Statamic 4/5 app, pin to the latest 2.1.x and treat 2.2.0 as available only after (or alongside) a CMS upgrade. On a Statamic 6 app, 2.2.0 is the entry point.
• Recommended path: staging install → single low-traffic asset container → upload five to ten representative images → inspect output and cost → then expand to one production container → backfill historical assets as a separate, rate-limited batch.
• Preserve a rollback switch (config flag) that disables generation without uninstalling.

Compatibility

• Verify the statamic/cms constraint, PHP floor, and Laravel major in 2.2.0 against the current application before committing. Confirm whether the 2.2.0 constraint is additive (4|5|6) or replacement (6 only).
• Check for conflicts with existing asset blueprint fields and any custom alt-text conventions already in the content model.
• Confirm queue driver behavior — on sync the addon will block the request; a real queue worker is a prerequisite for safe production use.
• Confirm the vendor name resolves to an installable, maintained package before writing it into a dependency manifest.

Sequencing

1. Security/privacy review of sending media to the AI provider.
2. Dependency and version-constraint verification in a branch — read 2.2.0's composer.json, confirm package identity, decide 2.1.x vs 2.2.0 based on the app's Statamic major.
3. Staging install, key provisioning via secret store, config publish.
4. Enable on one container; test upload, re-save, and manual-override behavior.
5. Cost and latency measurement over a defined sample.
6. Editorial workflow definition: who reviews AI alt text, and how a rejection is recorded.
7. Production rollout to one container, then broaden.
8. Backfill existing assets in bounded batches with monitoring.

Operational Impact

Maintenance

• Low code footprint but high external surface: the addon, the AI SDK, the provider API, and now the Statamic major cycle all move independently. Pin the addon version and treat upgrades as planned work, not automatic.
• 2.2.0 is a positive maintenance signal: the maintainer shipped Statamic 6 support in a minor release rather than letting the package rot. Weight it accordingly — it reduces but does not eliminate the single-maintainer, low-adoption risk. Assume you may still need to fork; budget for it in the risk register rather than discovering it during an incident.
• Track the addon's release cadence against Statamic's. The first Statamic major that ships without a matching addon release is the trigger for a fork-or-replace decision.

Support

• No SLA, no vendor relationship, community-grade issue response. Internal ownership must be explicit: one team owns the integration, the API key, and the cost line.
• A short internal runbook is required — how to disable generation, rotate keys, and re-run a failed batch.

Scaling

• Cost scales linearly with image volume; latency scales with queue depth. Neither is large at typical editorial throughput, but bulk backfills are a burst event that needs throttling.
• Rate limits on the inference API are the practical ceiling. Batch jobs should chunk and back off.
• Cache generated alt text against an image hash so re-saves and retries do not re-bill.

Failure modes

• Provider outage → uploads blocked (if synchronous) or a queue of silent failures. Must fail open: asset saves, alt text stays empty and is flagged.
• Hallucinated or generic alt text published without review → accessibility regression and possible SEO/legal exposure.
• Cost overrun from retry loops or unbounded backfill.
• API key exposure through logs or committed config.
• Silent skip of unsupported asset types, leaving gaps that look like coverage.
• Abandoned package after a future Statamic major upgrade.
• New: a version-constraint mismatch during install — 2.2.0 resolving against an incompatible Statamic major, or being blocked entirely on a Statamic 4/5 app and stalling the pilot until a CMS upgrade lands. Check this on day one, not at rollout.

Ramp-up

• Developer: roughly half a day to install, configure, and validate on staging, plus up to half a day to verify version constraints and package identity across the Statamic 4/5/6 matrix; one to two days including backfill and monitoring.
• Editors: minimal tooling training, but a real workflow change — they must review AI output rather than author from scratch. Plan a one-page guideline and an accessibility stakeholder sign-off on the acceptable quality bar before broad rollout.
• Overall: still a low-effort, low-risk pilot with a clear go/no-go gate on output quality, cost per image, and privacy approval. 2.2.0 improves the odds the dependency survives a platform upgrade; it does not change the go/no-go criteria.