Laravel Anydoc Laravel Package

Product Decisions This Supports

• Unblocks "chat with your documents" / RAG features for real-world document sets. Most enterprise and consumer document corpora are not clean, digitally-generated PDFs — they include scans, phone photos, faxes, and image-only exports. Until v1.4.0, those files were the silent failure mode of any ingestion pipeline: they parse to empty strings, embeddings are meaningless, and users conclude the feature "doesn't work." Opt-in OCR turns a large, previously unsupported segment of uploads into first-class content.
• A clean build-vs-buy answer for document ingestion. Extraction plus OCR is a deceptively deep problem (layout detection, deskewing, language coverage, table reconstruction). Buying this as a one-line call is almost always correct for a product team whose differentiation is what you do with the content, not how you read a PDF.
• Creates a natural monetization / packaging lever. Because OCR is opt-in and metered (hosted, per-page), it maps directly onto a tiered pricing model: free tier = digital PDFs only; paid tier = scanned-document support. The flag is effectively a feature gate you can expose in product settings rather than a hidden infrastructure toggle.
• Roadmap sequencing signal. This is infrastructure that pays off across multiple roadmap items at once: document Q&A, contract and invoice analysis, support-ticket attachment triage, compliance archive search, and knowledge-base sync from legacy file shares. It should be justified as platform investment, not as a single-feature dependency.
• Enables a "confidence/quality" UX. Knowing whether OCR ran lets you surface honest states in the UI — "we read this from a scan, so results may be less precise" — and route low-confidence extractions to a human review queue. That's a product differentiator, not a technical detail.
• Cheap to trial, cheap to reverse. Opt-in and opt-out are one boolean apart, so this can ship behind a flag to a small cohort, be measured on extraction success rate and downstream answer quality, and be rolled back without touching the ingestion contract.

When to Consider This Package

Adopt when:

• You are on Laravel/PHP and already use this package's markdown() conversion path for digital PDFs — v1.4.0 is additive and non-breaking, so the cost of trying it is a single argument.
• Your document mix genuinely includes scanned or image-only PDFs, and you can quantify that share (audit a sample of production uploads; if it's under ~5%, the added vendor relationship may not be worth it yet).
• Downstream consumers want markdown — LLM prompts, vector stores, embeddings, summarization, or search indexing — rather than pixel-perfect layout reproduction.
• You can accept a third-party data processor. Confirm a DPA, subprocessor disclosure, retention policy, and regional processing options before the first production document is sent.
• You can tolerate asynchronous or slightly elevated latency on the OCR path and can model per-page cost against your pricing or margin.

Look elsewhere when:

• Regulated or highly sensitive content — health records, financial account documents, government ID, legal privilege, or anything under contractual data-residency obligations. Hosted OCR means documents leave your boundary; that is often a hard no regardless of vendor terms. Evaluate self-hosted OCR (Tesseract, PaddleOCR, or a containerized commercial engine) instead.
• Volume economics don't work. Per-page pricing is fine at hundreds of pages and punishing at millions. Model your expected OCR volume at 12-month forecast before committing; past a threshold, running your own OCR workers on existing infrastructure is cheaper despite the maintenance burden.
• You need layout fidelity. Markdown flattens tables, multi-column layouts, forms, footnotes, and figure captIONS. If the product requirement is "reproduce this invoice line-item table exactly," markdown is the wrong output format and this is not the right tool.
• Offline, air-gapped, or on-premise-only deployments are in scope — a hosted dependency disqualifies it outright.
• You need broad format coverage (DOCX, XLSX, PPTX, HTML, email) or non-Latin scripts and handwriting at high accuracy. Check language and handwriting support explicitly rather than assuming; scanned handwriting is a materially harder problem than printed scans.
• You need deterministic SLA behavior — hard vendor rate limits or quotas on the OCR path can become your ingestion bottleneck during traffic spikes.

How to Pitch It (Stakeholders)

For executives (one paragraph): Our document features currently fail silently on scanned files, which are a large fraction of the documents our users actually upload. The v1.4.0 release adds an opt-in OCR path that turns those files into readable content with a single argument in our existing code — no new infrastructure, no migration, no change to current behavior. It is off by default, so there is zero added cost or vendor exposure until we choose to enable it, and it gives us a clean, metered handle for packaging scanned-document support into a paid tier. Recommended action: approve a limited pilot behind a feature flag, gated on a signed data processing agreement, with a cost model based on measured scanned-document volume.

For engineering: The change is additive and backwards compatible — markdown() behavior is unchanged unless ocr: true is passed, so this is a low-risk adoption. Work required is not in the parser but around it: a feature flag, per-tenant rate limiting and page-count budgeting, error and timeout handling with a graceful fallback to the existing (possibly empty) extraction so ingestion never hard-fails, telemetry to distinguish OCR'd from native extractions, and secret management for the hosted service credentials. Please also instrument extraction success rate and downstream answer quality before and after, so we can prove value rather than assume it.

For legal/security/compliance: This introduces a new third-party subprocessor that receives document contents — including potentially scanned documents containing sensitive information. We need a DPA, confirmed retention and deletion terms, regional processing guarantees, and a documented answer to "what happens to a user's file after OCR?" before enabling in production. A tenant-level opt-out should exist for customers with contractual restrictions, and the flag must default to off.