Example outputs & use cases

Showcase

See what the output artifacts look like, how the defect scan works, which models deliver the best results, and what kind of codebases benefit most.

01 · Example outputs

What a completed analysis bundle contains.

These are real output sizes from a 6-phase run analyzing CodeCartographer itself. A small codebase produced over 21,000 tokens of structured findings.

~3,100 tokens

Architecture map

System structure with 5 layers, 12 public surfaces catalogued, dependency direction analysis, runtime lifecycle documentation, and concurrency model notes. Each architectural claim tagged with its evidence level.

~2,400 tokens

Defect report

Six-pass scan finding 18 defects: 1 critical, 3 high severity, 8 medium, 6 low. Each defect includes file location, reproduction steps, recommended action, and evidence classification.

~4,500 tokens

Behavioral contracts

Feature-by-feature behavior with defaults, error handling, and acceptance tests. Nine feature areas catalogued with explicit black-box acceptance scenarios.

~3,900 tokens

Protocols and state

Event flows, state machines, persistence formats. Two state machines documented, five event protocols traced, persistence layer compatibility hazards flagged.

~3,400 tokens

Porting bundle

Synthesis layer ranking what matters and what is risky. Priority-ranked module list with rationale, portability hazard inventory, and dependency graph for rewrite sequencing.

~4,400 tokens

Reimplementation spec

Language-agnostic build plan with 8 modules, acceptance scenarios per module, and a known-unknowns section for what could not be determined from available sources.

02 · Defect scan passes

Six specialized analysis passes on every audit.

The defect scan is not one general-purpose review. It runs six sequential passes, each with domain-specific instructions. Findings are triaged by severity and mapped to a recommended action.

Logic and correctness

Off-by-one errors, null handling gaps, boundary condition violations, type coercion risks, control flow dead spots.

Error handling

Swallowed exceptions, missing fallback paths, error propagation gaps, inconsistent error taxonomy, silent failure modes.

Concurrency

Race conditions, deadlock risks, missing synchronization, shared state without guards, async ordering assumptions.

Security

Injection surfaces, missing input validation, hardcoded secrets, auth bypass risks, dependency vulnerability exposure.

API contract violations

Parameter mismatches, return type drift, undocumented side effects, versioning hazards, broken backward compatibility.

Configuration hazards

Hardcoded paths, missing env validation, unsafe defaults, environment drift between dev and production, secret rotation gaps.

Severity and action mapping

Every finding gets a severity (critical, high, medium, low) and a recommended action: fix before porting, port differently, or leave behind. The deep audit variant adds a second semantic pass with full contracts and protocols context, catching issues the mechanical scan misses.

03 · Model compatibility

Which models produce the best results.

CodeCartographer is LLM-agnostic by design, but model choice affects what you can analyze and how good the results are.

Frontier

High-reasoning frontier models

Best for full-with-deep-audit on larger codebases. The semantic defect pass benefits most from strong reasoning, long context, and reliable tool use.

Strong mid-tier

Balanced cost/quality models

Good for architecture, contracts, and protocols. Recommended starting point: lite pipeline, then escalate only if the output is grounded and specific.

Smaller

Fast or budget models

Use for quick structural orientation. Multi-phase pipelines can drift; prefer architecture-only unless you can manually review each phase.

Testing a new model

Start with pipeline-architecture-only.yaml on a codebase you already understand. Compare the output against your own knowledge. That gives you a fast signal on whether to trust the model with deeper phases.

04 · Use cases

When CodeCartographer earns its keep.

Different pipelines serve different goals. Here is when each one makes sense.

Inherited a codebase with no docs

Run the full pipeline. Start with architecture to get your bearings. Continue through contracts and protocols to recover the behavior. End with porting and reimplementation specs if a rewrite is on the table.

Planning a rewrite or port

Full with deep audit. The split defect scan means the reimplementation spec is designed around defects that were found with full contracts and protocols context. You get a build plan that accounts for the real state of the code.

Maintenance audit before handoff

Defect scan pipeline. Two phases: architecture plus six-pass audit. You get a triaged defect report with severity and actions. Nothing more.

Quick orientation on a library

Architecture only. One phase. System layers, public API surfaces, dependency direction, runtime notes. Low cost, fast signal.

Understanding behavior without a rewrite

Lite pipeline. Architecture, contracts, protocols. The fastest path to knowing how a system works and what it promises, without the porting bundle overhead.

Repeated analysis across a monorepo

Drop .codecarto/ into each package. Run architecture-only on packages you are curious about. Run full on packages you are targeting for changes. The status file keeps each analysis independent.

Try it on your own codebase.

Download the repository, drop .codecarto/ into your project, and point an LLM at the guide.

Read the installation docs Download ZIP