Prepared 2026-09-16. The baseline below records the initial audit; see the delivery update for completed work. The growth plan is not a forecast.

All 29 baseline issues have been closed through reviewed fix/feature batches #364–#376. The resolution ledger records implementation and verification evidence, including unavailable private/live reproductions. The core offline suite now has 231 passing tests; an optional MCP suite covers service contracts and transport.

The documentation refresh replaces the redirect homepage, provides a runnable text invoice quickstart, documents new APIs and separates unreleased main features from the existing PyPI package. Docker/MCP can be built from source. No package release or star-growth outcome is claimed.

Still outstanding beyond the issue backlog: publishing the prepared CI workflow changes (OAuth workflow scope required), reviewing five older contributor PRs, release/version preparation, broader dependency/tooling cleanup, public evaluation fixtures, and the adoption work below. These are roadmap items, not silently completed tasks.

Position ExtractThinker as “Turn complex documents into validated Python objects.”

Supporting promise: “Classify, split, and extract with typed contracts, your choice of document parser, and your choice of LLM.” Keep “an ORM for documents” as a supporting analogy. Lead with a working result rather than an architecture vocabulary or an exhaustive list of integrations.

The relaunch should combine reliable installation, a convincing document-to-object demo, refreshed documentation, and an observable maintenance cadence. Use existing parser integrations as an advantage; make reliable extraction workflows the reason to choose this library.

Interpretation: “10k” means GitHub stars. Treat stars as an outcome of adoption and contributor trust. No deadline or guarantee is implied.

Remote references were fetched and stale references pruned. The existing checkout and its edits were preserved. The new worktree is the synchronized baseline; the original branch was not reset or merged.

Current main includes configurable loaders, Docling, MarkItDown, Mistral OCR, EasyOCR, Markdown conversion, model routing, reasoning-related configuration, and async wrappers. Do not scope these as entirely new features. First verify their behavior, compatibility, and documentation.

The README still emphasizes the older feature set. There is an opportunity to make existing work visible before expanding the API.

These are source-review findings and reported issues, not claims that every report has been reproduced.

Direct PyPI JSON checks on the audit date returned the candidates below. “Latest” is not synonymous with “compatible.” Recheck when implementing, review upstream migration notes, and update in separate batches.

Sequence: (1) support policy and reproducible baseline; (2) development/docs tooling; (3) Pydantic/Instructor/LiteLLM together with adapter tests; (4) PDF/image/native libraries; (5) optional cloud/parser extras. Review all remaining declared and locked dependencies in the implementation pass. Audit the resolved environment for advisories, record exceptions, and regenerate one canonical lock. Align or retire the separate legacy requirements.txt rather than maintaining inconsistent install paths.

Keep the current API working wherever possible. Use a proposed 0.2 release for intentional support-policy/API changes with migration notes; use a patch release for compatible fixes first. Version numbers are proposals until release scope is settled.

1. A reliable first extraction. A five-minute quickstart with one sample invoice, one typed contract, explicit credentials, installation prerequisites and sample output. Provide a credential-free loader smoke test. Mark recorded output as recorded.
2. Long-document correctness. Clear behavior for truncation, pagination, concatenation, validation failure, retries and partial results. Add representative multilingual/table/mixed-document fixtures and known limitations.
3. Evidence with extraction. Explore optional page/source references without changing existing Contract return values. Bounding boxes depend on loader capability; never imply all adapters can supply them. Build on #287.
4. Predictable operations. Bounded concurrency, documented cancellation behavior, consistent timeout units, usage/cost metadata when providers supply it, structured logs with document contents excluded by default. Existing extract_async uses asyncio.to_thread; document that behavior before promising native async streaming.
5. Agent integration after reliability. A small optional CLI/MCP integration is a candidate from #252, not the initial release blocker. Keep the Python library usable independently.

Defer a hosted platform, many new loaders, an extensive UI application and blanket performance claims until the core journey is proven.

Recommended direction: retain recognizable pink as a restrained accent, with ink-colored text, warm light surfaces and a properly supported dark theme. Use a document-to-typed-object motif consistently in the logo refinement, diagrams, README banner and social preview. Keep illustrations subordinate to readable code and real output.

Homepage composition:

1. Hero: “Turn complex documents into validated Python objects.” Supporting sentence, Get started and View on GitHub.
2. Side-by-side sample invoice, a short contract and resulting JSON. Highlight source-to-field correspondence only where supported; otherwise label it explanatory artwork.
3. Three workflow cards: extract an invoice; classify and split a mixed packet; process using a local model.
4. A compact ecosystem row showing tested integrations, linking to capability/version guidance.
5. Reproducible evaluation results with corpus, model, date, failure rate, latency and cost methodology. No invented accuracy number.
6. Contributor invitation and recent release notes.

README: outcome → short demo → verified install/quickstart → why this library → recipes → supported integrations → contribution/license. Replace the current long feature tour with links to task-oriented guides.

Docs navigation: Start here / Recipes / Concepts / Integrations / API reference / Migration & releases / Contributing. Split getting-started paths for hosted LLMs and local processing. Make optional system dependencies discoverable before users hit import errors.

Retain MkDocs initially; a framework migration does not itself improve extraction or onboarding. Acceptance criteria: useful HTML without the homepage redirect, no placeholder navigation, visible keyboard focus, readable contrast, mobile navigation, correct code-copy behavior, accessible light/dark palettes, and verified internal links. Capture desktop and mobile previews before publishing.

Docling focuses on document conversion; Unstructured offers document transformation/ETL tooling; Instructor centers on structured LLM outputs. These official project descriptions support the following positioning inference: ExtractThinker can distinguish itself through the complete classify → split → contract extraction workflow, while composing with parsers and structured-output libraries.

Publish a factual “when to use which” guide with runnable examples. Avoid unsupported superiority or speed claims. Partner tutorials with existing integrations are more credible than presenting every adjacent project as a competitor.

Review all 29 issues and 5 PRs. Preserve attribution and prefer improving existing contributions over duplicating them. Do not automatically merge or close anything based on this audit.

• PR #362: review stability/logging/temp-directory work first; test cleanup, concurrency and sensitive logging.
• PR #353: evaluate with the concatenation regressions above.
• PR #363: verify what a first-class MiniMax integration adds beyond existing provider support and require adapter tests.
• PR #335: reuse useful architecture decisions in contributor documentation.
• PR #72: review entity masking separately; clarify its limits and compatibility before adding public guarantees.
• #309: reproduce Docling import compatibility against the supported integration versions.
• #141: include split/classification correctness in the regression corpus.

Use labels for reproducible bug, needs reproduction, documentation, integration, and proposed feature. Assign an owner and next action to every accepted relaunch item.

Assumption: one active maintainer with targeted community help. Dates are planning estimates, not a commitment; move the launch if the release gates fail.

Suggested small PRs, in order: 01 tested quickstart; 02 offline CI and test taxonomy; 03 contributor tooling; 04 dependency/support-policy batches; 05 long-document regressions and fixes, incorporating existing PRs; 06 release provenance and changelog; 07 README and visual/docs redesign; 08 recipes/evaluations; 09 optional agent integration after launch gates.

The gap is 8,403 stars. At an assumed net gain of 250 / 500 / 1,000 stars monthly, the arithmetic is about 34 / 17 / 9 months. These are scenarios, not forecasts; no growth history or funnel baseline was measured in this audit.

Record a baseline and review monthly: net stars, docs traffic and quickstart clicks where measurement is available, package downloads with bot/mirror caveats, first-response time, issue age, unique contributors and repeat contributors. Track successful first runs through opt-in feedback/usability sessions rather than silently adding library telemetry. Do not equate downloads or stars with active users.

Proposed operating targets: acknowledge new issues within three working days; review actionable PRs weekly; publish a monthly maintenance update; ship only when release checks pass. Revisit these targets against available maintainer time.

Use focused launch posts and demonstrations in relevant developer communities, honoring their posting rules. Publish one useful tutorial per week during the launch window and request feedback from existing contributors. Do not buy stars, automate promotional messages, or optimize for attention that does not produce successful users.

• Fetch succeeded; fresh worktree matches current origin/main.
• All 67 library Python files parsed successfully with the local Python 3.14.4 interpreter. Syntax parsing is not runtime compatibility validation.
• All 48 Markdown destinations in MkDocs navigation exist; placeholder links remain a separate finding.
• poetry check --lock passed with metadata-deprecation warnings. This does not establish dependency/runtime compatibility.
• GitHub metadata, issues, releases and recent Actions history were inspected; package candidate versions were queried from PyPI.
• Full runtime tests, provider calls, a clean installation, vulnerability audit, docs rendering and benchmark runs were not performed. No claim of a passing current runtime suite is made.
• This pass adds a plan only. Dependencies, production code, public docs, repository settings, releases and external conversations were not changed. Original local work remains intact.