Architecture C4 Modeling
Trigger Boundary
- •Use when architecture communication artifacts are missing or outdated.
- •Do not use to decide architecture options; use
architecture-tradeoff-analysis. - •Do not use as decision history storage; use
architecture-decision-records.
Goal
Produce accurate and traceable C4 views that align stakeholders on architecture.
Shared Architecture Contract (Canonical)
- •Use
skills/architecture-principles/references/architecture-governance-contract.mdas the only schema source. - •Validate all IDs, lifecycle states, and gate rules against the canonical contract.
- •Do not define local ID formats or alternate state machines.
Compliance & Governance Baseline (US, Japan, EU)
- •Mark sensitive data flows and regulated boundaries in relevant diagrams.
- •Avoid exposing credentials or internal secrets in architecture artifacts.
- •Prepare an
ARC-CMP-*evidence package for governance review.
Inputs
- •Current architecture and dependency information
- •Target audience and required abstraction level
- •Related ADRs and risks
Outputs
- •Updated C4 context, container, and component views
- •Relationship legend and assumptions list
- •Traceability links to ADRs and key risks
Workflow
- •Build context view with external actors and systems.
- •Build container view with runtime responsibilities.
- •Build component view for high-complexity containers.
- •Link diagrams to ADR and risk identifiers.
- •Validate naming and relationship consistency.
Quality Gates
- •Diagram scope matches intended audience.
- •Names and relationships are consistent across views.
- •
ARC-CMP-*evidence package is complete and approved. - •Greenfield designs exclude fallback paths; brownfield rollback requires trigger and runbook.
Failure Handling
- •Stop when source architecture information is stale or conflicting.
- •Stop when canonical contract validation fails.
- •Escalate when critical boundaries cannot be represented clearly.