Domains
Every codebase has architectural regions — "Authentication," "Billing," "Background Jobs," "Notifications." Most teams know these regions exist, but they don't have a current, accurate map of them. Scrubby discovers them automatically, scoped to the actual code, and uses them to power every review.
Why a domain map matters
The directory layout of a codebase is rarely a reliable architectural map. A services/ folder in one project might be thin wrappers around external APIs; in another it's the core business logic. The same goes for lib/, util/, or core/. These names mean different things in different repos, and they drift over time.
What you actually want, when you're making a change, is a map of capabilities — what part of the system this code belongs to, what's adjacent to it, what's coupled to it. That's the domain map. It's also exactly the mental model your senior engineers carry around in their heads, formed over months of working in the codebase. Scrubby surfaces the same thing, automatically, on day one.
How domains get discovered
During the first index, Scrubby walks the file tree, parses imports, and sends directory structure, file metadata, and a sample of file contents to its domain classifier. The classifier identifies cohesive areas of responsibility — semantic groupings, not pattern matches on path segments — and assigns each file to a domain.
This is real semantic classification of what each part of the codebase does. A file with a path like app/services/billing/charge_processor.rb ends up in a Billing domain not because of the path, but because the classifier read enough of it to know it's billing logic. The same file under a renamed directory would still land in Billing.
Two layers: global and repo-scoped
Domains come in two flavors that work together.
Global domains are pre-defined templates that activate based on your stack. When Scrubby sees Ruby in your Gemfile, it activates Ruby and Rails. When it sees React in package.json, it activates React and frontend domains. Global domains carry shared knowledge across many repositories — conventions and connection patterns that have been validated across the broader ecosystem. They're why a fresh app gets reasonable reviews on day one.
Repo-scoped domains are unique to your project, discovered during indexing. These are the capabilities specific to your system — "Transaction Processing," "Risk Assessment," "Regulatory Reporting" for a fintech app. They don't exist anywhere else and they're refined every time Scrubby looks at your code.
The two layers compose. A file in your custom "Risk Assessment" domain can also pick up signal from the global "Security" domain, and the network learns over time which combinations actually produce useful findings for your repo.
Domain connections
Domains aren't isolated. They're connected by weighted edges that represent how tightly coupled different areas are. The weights are learned from cross-domain imports, co-change history, and the findings produced during reviews. Higher weights mean changes in one domain are more likely to ripple into the other.
Where domains show up
In your AI editor. When the agent is about to edit a file, it can ask Scrubby what domain that file belongs to and what conventions apply there. The code it writes is shaped by that context instead of guessed at from filenames.
On every PR. When a changeset crosses domain boundaries, Scrubby flags it. Cross-domain changes need a different kind of review attention — they often touch areas the author didn't expect to touch.
In the dashboard. The repository view visualizes the domain map with its connection graph. It's the closest thing your team has to a current, accurate architecture diagram — and it stays current automatically.
For CTOs and architects
Most engineering leaders don't have a confident answer to "how is this codebase actually organized?" They have an org chart and an architecture diagram someone drew in 2023. Neither reliably matches the code. The gap between intended architecture and actual architecture is where the worst tech debt lives.
Scrubby's domain map is the actual architecture — generated from the code as it exists today, kept current automatically, and queryable from your editor or your dashboard.
For decisions like "should we extract this domain into its own service?" or "what's the blast radius if we change this contract?", the map turns a multi-week investigation into a queryable answer.