Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions docs/adr/0001-record-architecture-decisions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# 1. Record architecture decisions

Date: 2024-06-09

## Status

Accepted

## Context

We need to record the architectural decisions made in this project to ensure that future contributors understand the reasoning behind key choices and can maintain consistency as the project evolves.

## Decision

We will use Architecture Decision Records (ADRs), following the format described by Michael Nygard in [Documenting Architecture Decisions](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions.html).

## Consequences

- All significant architectural decisions will be documented in the `adr/` directory.
- Each ADR will have a unique number and a clear title.
- ADRs will be kept under version control.
27 changes: 27 additions & 0 deletions docs/adr/0002-python-monorepo-structure.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
# 2. Use a Python monorepo structure

Date: 2024-06-09

## Status

Accepted

## Context

The project consists of multiple components: core logic, document loaders, models, tests, and examples. Managing these as a monorepo simplifies dependency management, testing, and deployment.

## Decision

We will use a single Python repository with the following structure:

- `extract_thinker/` for core code and modules
- `tests/` for all test code
- `examples/` for usage examples and scripts
- `docs/` for documentation
- Project configuration files at the root

## Consequences

- Easier to manage dependencies and code sharing between modules.
- Simplifies CI/CD and testing.
- All code and documentation are versioned together.
24 changes: 24 additions & 0 deletions docs/adr/0003-document-loader-plugin-architecture.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
# 3. Document loader plugin architecture

Date: 2024-06-09

## Status

Accepted

## Context

ExtractThinker needs to support multiple document types and OCR backends (Tesseract, EasyOCR, etc.). We want to make it easy to add new loaders without modifying the core extractor logic.

## Decision

We will use a plugin-like architecture for document loaders:
- Each loader implements a common interface (`DocumentLoader`).
- Loaders are registered and discovered by the extractor at runtime.
- Loader configuration is handled via config classes (e.g., `EasyOCRConfig`).

## Consequences

- New loaders can be added with minimal changes to the core.
- Loader-specific dependencies are isolated.
- The extractor can select the appropriate loader based on file type or capabilities.
21 changes: 21 additions & 0 deletions docs/adr/0004-usepytest-for-testing.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# 4. Use pytest for testing

Date: 2024-06-09

## Status

Accepted

## Context

We need a robust, flexible, and widely adopted testing framework for Python.

## Decision

We will use `pytest` for all unit and integration tests.

## Consequences

- Tests are easy to write and maintain.
- Fixtures and plugins can be leveraged for complex test scenarios.
- Test discovery and reporting are standardized.
21 changes: 21 additions & 0 deletions docs/adr/0005-use-ruff-and-flake8-for-linting.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# 5. Use Ruff and Flake8 for linting

Date: 2024-06-09

## Status

Accepted

## Context

Consistent code style and static analysis are important for maintainability and code quality.

## Decision

We will use [Ruff](https://github.com/astral-sh/ruff) as the primary linter, with Flake8 as a secondary tool for compatibility and additional checks.

## Consequences

- Code style is enforced automatically.
- Linting errors are caught early in development and CI.
- Contributors must ensure code passes linting before merging.
20 changes: 20 additions & 0 deletions docs/adr/0006-llm-agnostic-extraction.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
# 6. LLM-agnostic extraction

Date: 2024-06-09

## Status

Accepted

## Context

The project aims to support multiple LLMs (Language Model APIs) for extraction, not just a single provider.

## Decision

The extractor will be designed to load and use any LLM backend, with the LLM set at runtime via configuration.

## Consequences

- The system is flexible and can adapt to new LLMs as they become available.
- Users can select the LLM that best fits their needs and budget.