Requirement extraction
Atomic, typed requirements (FR-001…) with actor, priority, pre/post-conditions and source page, in one searchable registry.
ArchMindDoc Analyser · A product by Kalajna Labs
Does the code do what the documents say?
ArchMind reads your RFP, BRD, HLD, LLD, API and DB designs and the GitHub repositories that implement them. It turns both into one evidence-backed knowledge model, then generates traceability, conflict reports and architecture diagrams from it. Everything runs on your own hardware.
100% local inference
Ollama + pgvector
Mermaid · PlantUML · Graphviz
Page-level evidence
0
Analysis agents
0
Diagram types
0
Languages parsed
0
External AI calls
How it works
From a folder of documents to a verified model
Five stages, each persisted server-side. You can close the tab mid-analysis and come back later.
Ingest
PDF, DOCX, PPTX, XLSX and Markdown are parsed with page mapping and local OCR, then classified, split into sections and chunked with tables kept intact.
DeterministicInterpret
Seven local-model agents extract requirements, roles, workflows, services, APIs, tables, events and classes as schema-constrained JSON. Each item carries a quote and a page number.
Local LLMValidate
A cross-document validator compares RFP ↔ HLD ↔ LLD. Each item gets a confidence level, and an architect can approve, edit or reject it.
LLM + rulesTrace & draw
The traceability matrix and every diagram are pure functions of the validated model. Same model in, same output out.
No LLMCompare with code
Linked repositories are parsed into a symbol graph, matched to the model, and checked for drift after every push.
No LLM
Capabilities
Everything an architecture review needs
Role intelligence
A deduplicated role catalog with aliases, responsibilities and UPPER_SNAKE_CASE permissions, ready for your RBAC design.
Workflow intelligence
Ordered steps, actors, decision branches, states and exception paths for every process the documents describe.
End-to-end traceability
Requirement → Role → Workflow → Service → API → Data → Class → Method, exportable as a CSV matrix.
Conflicts & gaps
Role mismatches, contradictions between documents, unimplemented requirements, untraced design and missing NFRs.
Ask the documents
Grounded Q&A over hybrid vector, full-text and knowledge-graph retrieval. Every answer cites the document, page and section.
Code intelligence
Java/Spring, Python, TypeScript/JavaScript, C#/.NET and PHP parsed into packages, classes, methods, REST endpoints, ORM entities and events.
Evidence & confidence
Every object shows its quote and a confidence level based on evidence strength, cross-document agreement and rule checks.
Multi-user workspaces
GitHub, Google or email sign-in, per-project membership and four roles: Admin, Architect, Analyst and Viewer.
Diagrams
How ArchMind prepares its diagrams
ArchMind never asks a model to “draw a diagram”. Diagrams come from the validated knowledge model, so each box and arrow traces back to a line in your documents or your code.
1
ExtractAgents pull workflows, services, APIs, tables, events and classes out of the documents, each with its evidence.
2
ValidateCross-document checks and architect review decide what goes into the model.
3
GenerateA deterministic generator turns the model into Mermaid, PlantUML and Graphviz source. Re-running it on the same model gives the same diagram.
4
AnnotateAfter each analysis, drift findings are overlaid on the diagrams. Parts that are designed but not built show up red and dashed.
Every diagram, and what it's for
Twelve views of the same model, each for a different conversation. Red dashed elements show drift ArchMind has found between design and code.
Process
Process flowchart
Process flowchart Mermaid
- How it's built
- One per workflow the Workflow Analyzer finds. Ordered steps become boxes, decision points become diamonds with their yes/no branches, and exception paths loop back. The document's trigger and outcome become Start and End.
- What it's for
- Walk a business process with stakeholders, and spot branches the documents never finish describing — an approval with no rejection path, a step with no owner.
Process
Role workflow
Role workflow Mermaid
- How it's built
- For each role in the catalog, ArchMind collects every workflow where that role is the primary actor or performs a step, and lays them out as that persona's journey from login to done.
- What it's for
- Write UAT scripts per persona, onboard new users, and run access reviews — you see exactly what each role is expected to do.
Behaviour
Sequence diagram
Sequence diagram Mermaid · PlantUML
- How it's built
- Built from each workflow's steps: actors call services, services persist to their tables, and published events appear as async messages — in the order the documents give.
- What it's for
- Agree API contracts, see sync vs. async hops, and debug integration order before anyone writes code.
Behaviour
State machine
State machine Mermaid · PlantUML
- How it's built
- Uses the states and transitions the design declares. When a document only implies them, they are inferred from each step's “state after”. Approved, Rejected, Closed and Completed are marked as final states.
- What it's for
- Validate lifecycle rules, find dead-end or unreachable states, and drive the status enum and its tests.
Structure
Component diagram
Component diagram Mermaid · PlantUML
- How it's built
- Every service, UI, gateway and external system in the architecture model, plus the tables they persist to and the topics they publish and subscribe to. Parts the code doesn't implement are drawn red and dashed.
- What it's for
- A one-page system overview for architecture reviews and new joiners — with the unbuilt parts impossible to miss.
Structure
Service dependency graph
Service dependency graph Graphviz
- How it's built
- The service-level slice of the architecture graph: who depends on whom, rendered as a directed graph.
- What it's for
- Estimate blast radius before a change, order deployments, and catch dependency cycles.
Design
Class diagram
Class diagram Mermaid · PlantUML
- How it's built
- Classes, attributes, methods and relationships extracted from the low-level design, with composition and inheritance parsed from the text.
- What it's for
- Review the domain model with developers and compare it with the classes that were actually written.
Data
ER diagram
ER diagram Mermaid
- How it's built
- Tables, columns, primary and foreign keys, and cardinalities taken from the database design documents.
- What it's for
- Review schemas, plan migrations, and settle which service owns which data.
Integration
Event flow
Event flow Mermaid
- How it's built
- Domain events linked to their producers and consumers across services. A topic with nobody subscribing — or a subscriber the code never wires — is flagged.
- What it's for
- Audit async coupling and find orphan events before they turn into silent data loss.
From code
Code maps
Code maps Mermaid
- How it's built
- Packages, classes, REST endpoints and ORM entities parsed straight from the repositories (Java/Spring, Python, TypeScript/JavaScript, C#/.NET, PHP) using imports, annotations and declarations. No model guesses these edges.
- What it's for
- See what was actually built: the API surface, package layout and repository mind map, set side by side with the design.
Traceability
Mind graph & traceability
Mind graph & traceability Interactive
- How it's built
- Starts from a requirement or a drift finding and follows the links outward: requirement → role → workflow → service → API → class → method → commit.
- What it's for
- Impact analysis and audits: ask what breaks if this changes, and which requirements a finding puts at risk.
Output
Export anywhere
Export anywhere DSL · CSV
- How it's built
- Each diagram is stored as its source DSL, not a picture — Mermaid, PlantUML or Graphviz. The traceability matrix exports as CSV.
- What it's for
- Paste diagrams into Confluence, GitHub, Markdown docs or your own tooling, and keep them under version control.
Architecture drift
Know the moment design and code diverge
Drift detection compares the knowledge model with the code model on exact keys: route, table name, topic. No model is involved, so a finding is something you can verify. Each finding keeps a stable ID across runs, and one that stops happening is marked resolved rather than deleted, which leaves an audit trail.
API_NOT_IMPLEMENTED
API_METHOD_MISMATCH
SERVICE_NOT_IMPLEMENTED
UNDOCUMENTED_ENDPOINT
UNDOCUMENTED_COMPONENT
UNDOCUMENTED_TABLE
ENTITY_NOT_PERSISTED
EVENT_NOT_WIRED
UNDECLARED_TOPIC
Severity is raised automatically when a finding affects must-have requirements.
Private by design
Your documents and code never leave your servers
RFPs and source code are often client-confidential, which is why ArchMind does all inference locally. It calls no hosted AI service at runtime.
✓
Local models via OllamaReasoning, extraction, vision and embeddings are routed by capability. Swapping a model is a config change.
✓
Strict project isolationEvery retrieval is scoped to one project. A non-member gets a 404, so they can't even tell another project exists.
✓
Read-only GitHub accessThe GitHub App requests only Contents and Metadata, and ArchMind never writes to your repositories.
Knowledge · Architecture · Code
The blue half of the mark is the design; the teal half is the code. ArchMind is the line joining them.
Under the hood
Built on a proven stack
Backend
Python, FastAPI modular monolith, background analysis runner
Frontend
React 19, TypeScript, Tailwind 4, shadcn/ui
AI (local)
Ollama: Llama 3.1, Mistral, Llama 3.2 Vision, nomic-embed
Retrieval
PostgreSQL + pgvector, full-text search, knowledge graph, RRF fusion
Storage & queue
MinIO for documents, Redis
Integrations
GitHub App with webhooks, Keycloak SSO, Mermaid / PlantUML / Graphviz