Lrs Laravel Package

Product Decisions This Supports

• xAPI / Learning Record Store capability (build vs. buy): This package gives your Laravel app an LRS endpoint — the store that receives and serves xAPI statements ("I did X with Y, result Z"). If your roadmap includes SCORM/xAPI content, offline-capable activity tracking, or interoperable reporting, this is a buy/adopt lever rather than a multi-sprint build.
• Analytics and reporting roadmap: An LRS is the substrate for completion, engagement, and competency reporting. Adopting it early decouples "capture everything" from "decide what to report on later," which buys you optionality on the analytics roadmap.
• Ecosystem/interop decisions: Because it speaks xAPI, content authored in third-party tools (Articulate, dominKnow, custom players) can report to you without bespoke integration work. This is a strong argument against hand-rolled tracking tables.
• Platform bets: This is an EscolaLMS-family package. Adopting it is a soft commitment to that ecosystem's conventions (auth model, package layout, pre-1.0 release cadence). Worth flagging as an explicit architectural decision, not an incidental dependency.
• Release 0.0.13 relevance: Adds PHP 8.2 support (removes a blocker if your fleet is on 8.2+) and updates AuthServiceProvider. The auth change is the one to interrogate — depending on your authorization setup, it can affect how statement access is gated. Treat this release as "PHP 8.2 unblocked, auth surface touched — validate before upgrading."

When to Consider This Package

Adopt when:

• You need xAPI statement storage and don't want to design the data model, validation, and query surface yourself.
• You're already on Laravel and comfortable with its service-provider/policy idioms.
• You're on PHP 8.2 (newly supported as of 0.0.13) or can upgrade.
• You can tolerate a 0.0.x version line: no semver guarantees, thin release notes, and API churn is plausible between minors.
• You're either inside the EscolaLMS ecosystem or willing to own the integration surface yourself (it is not a drop-in for arbitrary auth stacks).

Look elsewhere when:

• You need production-grade stability guarantees, long-term support, or a vendor SLA — a 0.0.x community package is not that.
• Your tracking needs are simple (video progress, course completion). Plain Eloquent tables will be cheaper to own than an xAPI abstraction.
• You need SCORM 1.2/2004 runtime specifically — xAPI is a different (and better, but not equivalent) standard; check content compatibility first.
• Your auth model diverges from the package's expectations and you're unwilling to fork or maintain a patch set.
• Release-notes quality is itself a signal: 0.0.13's notes are two PR titles with no migration guidance. Budget review time for every bump.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost dependency that unlocks standards-based learning analytics. It lets us collect activity data from off-the-shelf e-learning content without custom integration per vendor, and it positions us to report on learner progress using an industry-standard format (xAPI) rather than a proprietary one. Cost is engineering time, not licence spend.

To engineering: It's a Laravel package providing an xAPI-conformant Learning Record Store — statement ingestion, actor/verb/object modelling, and querying. Version 0.0.13 adds PHP 8.2 support and adjusts AuthServiceProvider, so re-verify authorization behaviour around statement access during upgrade. Caveats to plan around: pre-1.0 versioning, sparse changelogs, and EscolaLMS-coupling. Recommend pinning the version, wrapping it behind our own service boundary, and treating upgrades as reviewed changes rather than routine bumps.

Bottom line: Worth a spike, not a mandate. Validate against real content and your auth model before it becomes load-bearing.