Scanner / CLI
The scanner/CLI is designed as the deterministic analysis entry point for local runs, CI, and report generation.
Project
Rigoryn
Deterministic software intelligence for architecture governance
Rigoryn is a deterministic software-intelligence platform for architecture analysis, dependency intelligence, and technical-debt governance across multiple programming languages.
Its analysis engine is designed to produce evidence-backed findings from shared models, metrics, and graph relationships. Archimet is the optional AI layer that explains those findings without replacing deterministic analysis.
Problem
Architecture drift rarely shows up as a single lint error. The harder problems are structural: coupling hotspots, dependency cycles, layering erosion, N+1 patterns, and slow technical-debt accumulation across services and modules.
Rigoryn is designed to make those issues measurable and reviewable while keeping the source of truth in deterministic analysis rather than opaque model output.
Approach
The platform is designed around a unified analysis model that can normalize multiple languages into one dependency and architecture view.
Deterministic rules, shared metrics, and framework-aware classification provide the evidence. The AI layer remains optional and is intended to explain verified findings, summarize risk, and support remediation workflows.
- Deterministic engine first, optional LLM second.
- One normalized language model instead of separate per-language reports.
- Evidence-backed findings with metrics, thresholds, and graph paths attached.
- Self-hosted-first deployment with BYO-LLM as an explicit choice rather than a requirement.
Architecture
The architecture separates language-specific parsers from a shared class and dependency model so findings can be scored consistently across ecosystems.
The analysis model is designed to capture metrics such as WMC, LCOM, CBO, RFC, fan-in/fan-out, and cyclomatic complexity, alongside higher-level detections like god classes, coupling hotspots, circular dependencies, and N+1 query patterns.
The design separates a scanner/CLI, server-side reporting, and the optional Archimet interpretation layer.
Server REST API
The service layer is designed to separate report persistence and analysis jobs from the analysis engine.
Archimet optional LLM layer
Archimet is the optional AI interpretation layer for grounded explanations, refactoring guidance, and natural-language interaction around deterministic findings.
Key Decisions
Deterministic findings before LLM commentary
The deterministic engine is the source of truth so reports remain reproducible, CI-friendly, and reviewable without trusting model output.
Unified multi-language model
Normalizing multiple ecosystems into one model enables cross-language scoring and governance instead of producing isolated parser-specific reports.
Optional graph and queue infrastructure
Neo4j and Kafka are kept optional so teams can adopt graph exploration or queue-backed analysis jobs without making them mandatory for every deployment.
Validate evidence before explanation
LLM recommendations are intended to stay grounded in already-validated metrics and paths rather than inventing unsupported remediation advice.
Tradeoffs
Higher implementation complexity than lint-only tooling
A calibrated, graph-aware, multi-language engine is more expensive to build and maintain than isolated rule packs, but it targets architecture problems that simpler tooling often misses.
Optional platform services add operational weight
Server, dashboard, graph storage, and queueing broaden the product surface, which creates more deployment choices and more system ownership overhead.
LLM value depends on evidence quality
Keeping the LLM layer optional protects determinism, but it also means the usefulness of natural-language guidance depends entirely on the fidelity of the underlying engine.
Engineering design
Deterministic architecture analysis
The analysis design combines deterministic parsing, dependency graphs, and architecture-aware rules for evidence-backed findings.
Unified multi-language analysis model
The platform is designed around a shared analysis model, with language adapters feeding one governance-oriented view instead of isolated parser reports.
Evidence-backed risk scoring
Metrics, thresholds, and graph paths are intended to stay attached to each finding so architectural decisions can be reviewed and defended.
Optional LLM interpretation
Archimet is designed as an explanation layer that works from verified findings rather than generating them.
Technology Stack
- Java
- Kotlin
- Gradle
- Eclipse JDT
- Kotlin compiler PSI
- Roslyn
- Python ast
- SWC
- Spring Boot
- PostgreSQL
- Redis
- Neo4j
- Kafka
- Next.js
- Docker
- Ollama
- llama.cpp
- OpenAI-compatible providers
Privacy and deployment
- Rigoryn is positioned as self-hosted first so source code and findings can stay inside the team infrastructure.
- The AI layer is designed around BYO-LLM support, including local model options such as Ollama or llama.cpp when teams want deterministic analysis without mandatory cloud inference.
- That separation keeps deterministic analysis useful on its own while AI-assisted interpretation remains an explicit deployment choice.
Rigoryn is the product name. Archimet names the optional AI interpretation layer, and the original AMF codename remains in machine-facing identifiers for compatibility.