Feature matrix
archAIc is a lightweight core plus a set of optional layers. Keyword search, browse, ground-truth, IIIF Manifest, the standard exports (TSDO / ALTO / PAGE / hOCR / Linked Art / EAD / METS), and the REST API all come together by default — they live inside gd-server and need only the engine plus the corpus database. Everything else is a separate component you opt into, sometimes a service, sometimes a hardware upgrade.
The matrix below says what each feature needs and what depends on what. Cross-reference the per-service RAM table on the deployment overview for the actual sizing numbers.
The matrix
Section titled “The matrix”| Feature | Status | Software it needs | Hardware it needs | Notes |
|---|---|---|---|---|
| Keyword search (PrIx KWS) | core | engine, LMDB index | engine RAM | The lexical surface — boolean, wildcard, fuzzy, phrase, proximity. |
| Browse + per-page export | core | engine, corpora.db | engine RAM | TSDO, ALTO, PAGE, hOCR. |
| IIIF Manifests, Annotation, Content Search | core | engine | engine RAM | Presentation 3.0, Content Search 1.0 + 2.0. |
| Ground Truth read/write | core | engine | engine RAM | Page-lock + heartbeat surface. |
| DLU CRUD (manual) | core | engine, corpora.db | engine RAM | Operators create and edit DLUs by hand. Works without any of the optional layers — manual setup is always available as an alternative to autofill and auto-segmentation. |
| Linked Art / EAD / METS / EAC-CPF / ISAD-JSON / DIP exports | core | engine | engine RAM | DLU- and libro-level exports. |
| REST API + Swagger UI + OpenAPI 3.1 | core | gd-server | engine RAM | At /swagger-ui/ and /api-docs/openapi.json. |
| Semantic search | optional | + Qdrant + ONNX embedding model | + ~5 GB RAM (Qdrant); GPU speeds the initial build | Hybrid dense μ-passage + sparse TF-IDF, fused with RRF at query time. |
| Auto-segmentation | optional | requires Semantic search | (same) | Heuristic over passage embeddings; proposes DLU boundaries the operator reviews. |
| Natural-language Q&A (RAG) | optional | requires Semantic search + LLM (Ollama) | + LLM RAM/VRAM (model-dependent) | POST /llm/answer — retrieve via semantic, answer via LLM. |
| DLU autofill | optional | requires LLM (Ollama) | + GPU strongly recommended | Six LLM phases per DLU: ~30–60 s for a 10-page DLU; minutes for larger ones. Manual DLU editing (above) is always available as an alternative. |
| Geocoded places (IIIF navPlace) | optional | + Nominatim service | + ~2 GB RAM | Resolves DLU place rows to WGS84 points; varies with the OSM extract you load. |
| IIIF tiled images (Cantaloupe) | optional | + Cantaloupe service | + ~0.5–3 GB RAM | The engine serves whole JPEGs natively; Cantaloupe is only for pyramid-TIFF tiles. |
| MCP server (agent access) | optional | + gd-mcp container | small | OAuth 2.1, Streamable HTTP, ~30 tools wrapping gd-server. |
| Sync to AtoM / Archivematica | optional | sync target configured | — | Idempotent push, dead-letter queue. |
| Local LLM (Ollama) | optional | + Ollama + a chosen model | + tens of GB of RAM or VRAM, model-dependent | Drives Q&A and autofill. See LLM setup. |
| Observability (Grafana stack) | optional | + Grafana + Prometheus + Loki + Tempo + Promtail | + ~900 MB RAM combined | The observability compose profile. |
Dependency chains worth knowing
Section titled “Dependency chains worth knowing”Three feature stacks compose, not just sit alongside one another:
- Q&A = Semantic search → LLM. The retriever (semantic) finds candidate pages; the LLM answers from them. Run the engine + Qdrant + Ollama all on the same host for the standard “Ask a question” surface.
- DLU autofill = LLM. A GPU on the same host is strongly recommended — autofill walks six LLM phases per DLU and the cost scales with extent length.
- Auto-segmentation = Semantic search. The heuristic walks passage embeddings looking for discontinuities; without Qdrant and the embeddings it has nothing to walk.
None of these three is a hard prerequisite for using DLUs at all: a deployment can run the core engine only and let operators build DLUs by hand from the curator UI. The optional layers speed and scale that work; they don’t replace it.
Where each piece lives in docker-compose.yml
Section titled “Where each piece lives in docker-compose.yml”Compose profiles roll the choices above into named bundles:
| Profile | What it brings up | Use it for |
|---|---|---|
rust | PHP UI + Rust engine + Qdrant + MCP server + Nominatim | The default. Semantic and MCP layers are on; Ollama is not pre-wired (add it for Q&A or autofill). |
cpp | PHP UI + C++ engine | Legacy, search-only — no semantic, no DLU, no sync, no MCP. |
both | rust plus the C++ engine | A/B comparison of the two engines. |
iiif | Cantaloupe + Mirador | Adds pyramid-TIFF tiling and the bundled IIIF viewer. Run alongside rust. |
observability | Grafana + Prometheus + Loki + Tempo + Promtail | Metrics, logs, traces. Run alongside rust. |
Sizing implications
Section titled “Sizing implications”A 16 GB box comfortably runs the engine tier — every core row plus semantic search and Nominatim — for a 350K-page collection. Add an LLM (and the GPU it wants) only when you turn on Q&A or DLU autofill. The per-service RAM table has the per-service breakdown.