# Architecture Decision Notes

## ADR: OpenRefine is an adapter

Status: accepted

OpenRefine is the first integration target but must not define the internal architecture.

Reason:

- the same reconciliation core should later be usable in other applications,
- POST processing can be generalized,
- other interfaces such as REST API, CLI or batch processing should reuse the same logic.

Consequence:

- OpenRefine request parsing and response formatting should be isolated,
- Candidate[] is the internal neutral format,
- OpenRefine JSON is only one output adapter.

## ADR: Framework-independent PHP

Status: accepted for now

The project should not be converted into Laravel or Symfony at this stage.

Reason:

- the project is currently closer to a package or framework than a web application,
- the domain model is still being stabilized,
- framework independence supports reuse and open-source publication.

Consequence:

- keep plain PHP structure for now,
- optionally adopt selected components later,
- document compatibility with Laravel/Symfony rather than depending on them.

## ADR: Package-oriented architecture

Status: proposed

Long-term structure may split into packages:

- reconciliation-core
- adapter-openrefine
- client-xtree-json
- client-xtree-solr
- client-xtree-sparql
- client-wikidata
- client-gnd
- client-gbif
- spaCy-helper
- llm-helper

This is a direction, not an immediate refactoring task.