Extractor Laravel Package

Product Decisions This Supports

• Feature scoping for "ingest unstructured input → structured record." This package is the shortest path to shipping a first-party capability for receipts, CVs, menus, contact cards, job postings, supplier quotes, or any "paste a document, get fields" flow inside an existing Laravel app. It answers the "can we do this at all, this quarter?" question before you commit roadmap to it.
• Build vs. buy on the plumbing layer. Text adapters for PDF/Word/HTML/web, JSON-mode prompting, nested field schemas, Spatie DTO mapping, and a custom-extractor registry are roughly 3–6 weeks of undifferentiated work. MIT-licensed and free: buy the plumbing, spend engineering on domain validation, confidence thresholds, and the human review experience that actually differentiates the feature.
• Model/provider strategy as a config decision, not an architecture decision. OPENAI_BASE_URI (Ollama, Together, Groq) plus Azure override support lets you treat model choice as an experiment variable — cost, latency, and data-residency options stay open. You are not voting for OpenAI permanently by adopting this.
• Sequencing the roadmap. Text-first (Text::pdf, Text::text) → structured fields → image/vision last. The Vision feature is explicitly WIP; don't put image extraction on a committed roadmap until you've spiked it.
• Effort estimation via reference implementations. The bundled Contacts and Receipt extractors are working examples you can point at to size a domain extractor. The fields() API with nested schemas covers most list-of-subitems cases (line items, work history) without custom classes.
• Output contract. Returning arrays or Spatie data objects means extraction feeds your existing validation, DTOs, and persistence — no parallel serialization layer, no new conventions for the team to learn.
• Define success metrics up front. Straight-through-processing rate, per-field accuracy against a labeled set, human-correction rate, cost per document, p95 latency. This package makes those measurable cheaply; a bespoke pipeline does not.

When to Consider This Package

Consider it when:

• You're on Laravel and already have or can add an OpenAI (or OpenAI-compatible) key and billing relationship.
• Volume is low-to-moderate and per-document inference cost is not the dominant unit-economics term.
• You can tolerate non-deterministic accuracy, and a human reviews or corrects output in phase one.
• Inputs are mostly text-bearing PDFs, emails, HTML, or Word docs — or you already have AWS Textract for scans.
• You can assemble a 50–200 document labeled eval set and a per-field accuracy target before committing.
• You want a time-boxed spike or internal back-office tool, not a multi-year platform bet.

Look elsewhere when:

• Cost or latency per document dominates the business case, or you need deterministic, reproducible extraction at high volume.
• You need bounding boxes, per-field confidence scores, or high-fidelity table reconstruction — that's a document-AI platform (Azure Document Intelligence, Textract Analyze, Google Document AI), not an LLM wrapper.
• Data is regulated (PII, PHI, financial) and requires redaction before third-party inference, BAAs/DPAs, or on-prem-only processing.
• You need SLAs, vendor support, audit trails, prompt versioning, or multi-tenant cost attribution out of the box.
• Your stack isn't Laravel/PHP, or your team won't own prompt and eval maintenance.

One structural caveat for the adoption decision: 226 stars, zero dependents, and a single maintainer. Treat it as code you may need to fork. Pin the version, wrap it behind an internal extraction interface, and keep the swap to a managed document AI service a contained change.

How to Pitch It (Stakeholders)

To executives: This package compresses several weeks of LLM integration work — multi-format document parsing, structured JSON output, typed DTOs — into a few days, under an MIT license with effectively zero switching cost. It lets us validate demand for document automation with a small, metered inference spend instead of a headcount or platform commitment, and it unlocks backlog items (receipt capture, CV parsing, contact enrichment) that currently need manual entry. The risk is bounded: it's a thin wrapper we can replace or fork, and the only durable spend is per-request inference that scales with usage.

To engineering: Thin, idiomatic Laravel — facades, JSON-mode responses, Spatie data output, a custom-extractor registry for domain prompts, and a swappable base URI so we're not locked to one provider. Known gaps we own: no built-in retries, caching, cost controls, or eval harness; the Vision path is WIP; single maintainer with no downstream dependents, so we pin and wrap it.

The ask: a two-week spike — 100 labeled documents, three success metrics (per-field accuracy, straight-through rate, cost per document), and a go/no-go on whether the review UI or a managed document-AI vendor is the real next investment.