Essential session storage is required to sign in. Optional analytics remain off unless you allow them.
Choose a non-trivial system (real or designed) and document its architecture using the C4 model. Produce at least the System Context diagram (the system, its users, and external systems) and the Container diagram (the deployable/runnable units — apps, services, datastores — and how they communicate), plus a short narrative. Identify the driving quality attributes and explain how the architecture serves them. Use diagrams-as-code (e.g. Structurizr, Mermaid, or PlantUML) so the docs are versionable. Note what you deliberately did NOT diagram (avoid over-documentation).
Context and Container levels used correctly (Container = a deployable/runnable unit, not a Docker container); right elements at each level.
Diagrams communicate the real structure and interactions; narrative ties it to the driving quality attributes.
Diagrams authored as code (versionable); legend/notation clear; appropriate level of detail (no over-documentation).
Explicit about scope — what was and was not documented, and why.
Use this README structure to make the work reviewable.
DevPath fetches a read-only, size-capped snapshot. Submitted code is never executed.
# Document a system with the C4 model ## Goal Choose a non-trivial system (real or designed) and document its architecture using the C4 model. Produce at least the System Context diagram (the system, its users, and external systems) and the Container diagram (the deployable/runnable units — apps, services, datastores — and how they communicate), plus a short narrative. Identify the driving quality attributes and explain how the architecture serves them. Use diagrams-as-code (e.g. Structurizr, Mermaid, or PlantUML) so the docs are versionable. Note what you deliberately did NOT diagram (avoid over-documentation). ## Acceptance criteria - [ ] C4 correctness: Context and Container levels used correctly (Container = a deployable/runnable unit, not a Docker container); right elements at each level. - [ ] Architecture clarity: Diagrams communicate the real structure and interactions; narrative ties it to the driving quality attributes. - [ ] Docs-as-code: Diagrams authored as code (versionable); legend/notation clear; appropriate level of detail (no over-documentation). - [ ] Judgment: Explicit about scope — what was and was not documented, and why. ## Verification - [ ] Document installation and run commands. - [ ] Record automated checks and their exact commands. - [ ] Add representative output, screenshots, or a short demo where useful. - [ ] Confirm failure paths and known constraints. ## Decision log ### Decision title - Context: - Choice: - Alternatives considered: - Tradeoffs: ## Evidence - Link each rubric criterion to the file, test, or artifact that demonstrates it. ## Known limitations - List what is intentionally out of scope and what should be improved next.