Generating a C4 model from a Git repository can accelerate the first draft. The difficult step is deciding what the repository proves. A package does not necessarily define a component, and a service directory does not necessarily correspond to an independently deployed application.
UXXU’s codeToC4 workflow is in early access with a waitlist. Treat repository generation as a starting-model workflow to evaluate, not a generally available promise of automatic architectural correctness. Visual modeling and the UXXU MCP can be used independently.
Start with a reference architecture
Download the checkout model. Its context, container and component views form a compact review target. The example is authored for learning; it was not generated from a real repository.
For an equivalent repository, first locate the web application entry point, API startup, database connection configuration and payment client. Then check deployment manifests to determine which parts actually run independently.
Keep an evidence ledger
| Proposed element | Evidence to inspect | What still needs a human decision |
|---|---|---|
| Storefront | Build target, entry point, delivery configuration | Whether it belongs to this system’s scope |
| Checkout API | Server startup and deployment target | Public versus internal responsibility |
| Orders store | Schema and connection configuration | Data ownership and other clients |
| Payment adapter | Client implementation and request contract | External provider ownership and fallback behavior |
Download the repository evidence template. Its example Checkout API and payment relationship are explicitly unconfirmed. Replace the repository and revision placeholders, attach observations and assign a reviewer before accepting either proposal. This is a review ledger, not a model import.
Record the file path and commit for each observation. When evidence is missing, mark the relationship as unconfirmed. A failed search for a direct import does not prove that a runtime dependency is absent; event subscriptions and injected configuration often hide those connections.
Review in C4 order
Agree on the context boundary first. Validate runnable applications and stores next. Only then examine components inside a selected container. Keep generated code details separate from the architecture summary so a reviewer can challenge one without losing the other.
After a code change, compare the implementation evidence with the model. Reusing elements prevents diagram copies from drifting apart, but it does not by itself detect differences between code and architecture.
Join the codeToC4 early-access list if this workflow fits your team. While evaluating, use the C4 model tool to maintain a reviewed model and connect its views to the documentation readers actually use.