From 4c5fbe10ddc962af31e92f97b0c6075e4baa36aa Mon Sep 17 00:00:00 2001 From: Vijay Mandava Date: Sat, 31 May 2025 15:18:25 -0500 Subject: [PATCH] Architecture Decision Records --- .../adr/0001-record-architecture-decisions.md | 21 +++++++++++++++ docs/adr/0002-python-monorepo-structure.md | 27 +++++++++++++++++++ ...003-document-loader-plugin-architecture.md | 24 +++++++++++++++++ docs/adr/0004-usepytest-for-testing.md | 21 +++++++++++++++ .../0005-use-ruff-and-flake8-for-linting.md | 21 +++++++++++++++ docs/adr/0006-llm-agnostic-extraction.md | 20 ++++++++++++++ 6 files changed, 134 insertions(+) create mode 100644 docs/adr/0001-record-architecture-decisions.md create mode 100644 docs/adr/0002-python-monorepo-structure.md create mode 100644 docs/adr/0003-document-loader-plugin-architecture.md create mode 100644 docs/adr/0004-usepytest-for-testing.md create mode 100644 docs/adr/0005-use-ruff-and-flake8-for-linting.md create mode 100644 docs/adr/0006-llm-agnostic-extraction.md diff --git a/docs/adr/0001-record-architecture-decisions.md b/docs/adr/0001-record-architecture-decisions.md new file mode 100644 index 0000000..a348020 --- /dev/null +++ b/docs/adr/0001-record-architecture-decisions.md @@ -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. \ No newline at end of file diff --git a/docs/adr/0002-python-monorepo-structure.md b/docs/adr/0002-python-monorepo-structure.md new file mode 100644 index 0000000..f3a6578 --- /dev/null +++ b/docs/adr/0002-python-monorepo-structure.md @@ -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. \ No newline at end of file diff --git a/docs/adr/0003-document-loader-plugin-architecture.md b/docs/adr/0003-document-loader-plugin-architecture.md new file mode 100644 index 0000000..ca3011d --- /dev/null +++ b/docs/adr/0003-document-loader-plugin-architecture.md @@ -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. \ No newline at end of file diff --git a/docs/adr/0004-usepytest-for-testing.md b/docs/adr/0004-usepytest-for-testing.md new file mode 100644 index 0000000..8579b73 --- /dev/null +++ b/docs/adr/0004-usepytest-for-testing.md @@ -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. \ No newline at end of file diff --git a/docs/adr/0005-use-ruff-and-flake8-for-linting.md b/docs/adr/0005-use-ruff-and-flake8-for-linting.md new file mode 100644 index 0000000..9e55867 --- /dev/null +++ b/docs/adr/0005-use-ruff-and-flake8-for-linting.md @@ -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. \ No newline at end of file diff --git a/docs/adr/0006-llm-agnostic-extraction.md b/docs/adr/0006-llm-agnostic-extraction.md new file mode 100644 index 0000000..57b3f09 --- /dev/null +++ b/docs/adr/0006-llm-agnostic-extraction.md @@ -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. \ No newline at end of file