Architecture
Understand who owns each core path, which layer dependencies are governed, how the static analysis surface should be interpreted, and how to evaluate a proposed boundary change before implementation.
Architecture overview
ACC represents architecture as code: a canonical layer registry, path ownership rules, dependency contracts, explicit policies, static import analysis, and fail-closed governance commands.
The public acc architecture group observes or generates architecture evidence; it does not rewrite source files or apply a proposed migration. The model distinguishes where a subsystem belongs from whether one layer may depend on another. Both must be healthy for the combined guard to pass.
Canonical model
Six named layers define responsibilities. Ordered path-prefix rules assign top-level core areas to those layers.
Governance model
Static Python imports become dependency edges. Same-layer edges are internal; cross-layer edges require an explicit allow policy.
Canonical layers
Layer names are registry values and command arguments, not informal labels.
CLI
User entry surface
Command routing, interactive interfaces, and user operations.
Core
Core platform
Configuration, registry, manifests, documentation, and release responsibilities.
Runtime
Execution platform
Runtime, execution, recovery, audit, and authorization workflows.
Intelligence
Decision systems
Cognitive, decision, planning, and recommendation capabilities.
Platform
Infrastructure services
Events, history, diagnostics, and security.
Release
Release lifecycle
Validation, packaging, verification, and integrity.
Use the canonical names shown here when calling impact, plan, orevolve. Unknown layer names fail closed rather than becoming new architecture.
Ownership model
Ownership is inferred from the most specific matching canonical path prefix.
The ownership scanner examines immediate directories under core/. Examples includecore/cli as CLI, core/architecture andcore/documentation as Core, core/runtime andcore/actions as Runtime, and core/release as Release. A directory without a matching rule is UNMAPPED and degrades architecture governance.
Ownership describes responsibility, not import permission. Adding a path rule must point to an existing canonical layer; it does not automatically authorize new cross-layer dependencies.
Dependency boundaries
The source is the importing layer and the target is the layer being imported.
CLI
Allowed targets: Core, Runtime, Release
Core
Allowed targets: Platform
Runtime
Allowed targets: Platform, Intelligence
Intelligence
Allowed targets: Runtime, Platform
Platform
Allowed targets: None
Release
Allowed targets: Core, Runtime
Same-layer dependencies are classified as INTERNAL. For cross-layer imports, an explicit allow policy yields ALLOW, an explicit prohibition yieldsDENY, and a missing policy yields UNDEFINED. Both deny and undefined are violations.
Architecture policy and guard
Policy records name a source, target, allow or deny decision, severity, and stable ARCH identifier.
The policy registry includes allowed relationships and explicit critical prohibitions such as Runtime → CLI, Platform → Runtime, Core → CLI, and Release → Intelligence. A cross-layer relationship absent from the registry is not implicitly safe: enforcement returns no policy and rejects it.
acc architecture guard combines four checks: ownership has no unmapped paths, the policy registry is valid, static import analysis has no violations, and the dependency graph is healthy. A failure in any check returns a failed guard.
Graph, metrics, and reports
Metrics and generated reports summarize the current static Python dependency surface; counts are observations, not architecture permissions.
Metrics and score
Files are production Python files considered by the scanner. Edges are internalcore.* imports. Cross-layer counts show boundary traffic, while violations count denied or undefined traffic. The impact baseline starts at 100, subtracting 25 per violation and 10 per unmapped owner; it is a planning signal, not test coverage.
Graph and report
The graph aggregates import edges by source and target layer, including internal edges. The report summarizes files, edges, layer distribution, and violations. Both commands write generated Markdown under docs/architecture/.
Current analysis excludes core/testing from production enforcement and does not model shell sourcing, runtime loaders, generated dependencies, event wiring, or other dynamic mechanisms. A healthy graph means the analyzed Python surface is healthy, not that every possible runtime dependency has been proven safe.
Impact analysis and change planning
Simulation evaluates a proposed layer edge against the current baseline without changing the repository.
impact classifies a proposal as INTERNAL, ALLOW,DENY, or UNDEFINED. Internal and allowed proposals are accepted with low risk. A denied proposal is critical and reduces the projected score by 30; an undefined proposal is high risk and reduces it by 20.
plan adds ordered change steps, a recommendation, and an optional migration path. Its exit status is 0 for executable IMPLEMENT or MIGRATErecommendations and 2 when redesign is required. evolve ranks candidates, but neither command applies the recommendation.
Architecture commands
The versioned help surface exposes inspection, generation, enforcement, and simulation as separate operations.
acc architecture status
Combine contract, policy, ownership, and static-analysis health.
acc architecture scan
Map top-level core directories to canonical owners and list unmapped paths.
acc architecture metrics
Count scanned Python files and internal, cross-layer, and violating import edges.
acc architecture validate
Exercise the canonical dependency contract.
acc architecture policy
Validate the architecture policy registry.
acc architecture report
Regenerate docs/architecture/analysis-report.md from static Python analysis.
acc architecture graph
Regenerate docs/architecture/dependency-graph.md with a Mermaid graph and matrix.
acc architecture guard
Fail closed across ownership, policy, static imports, and dependency-graph health.
acc architecture impact <SOURCE> <TARGET>
Simulate one layer dependency and report decision, risk, and projected score.
acc architecture plan <SOURCE> <TARGET>
Build a recommendation and migration-aware change plan.
acc architecture evolve <SOURCE> <TARGET>
Rank architecture evolution candidates without applying a code change.
Violation handling
Treat a violation as architecture evidence to investigate, not a prompt to weaken the guard.
- Run
scanto separate missing ownership from dependency violations. - Run
metricsandguardto confirm the analyzed scope and failing checks. - Inspect the generated analysis report or the source import and its policy decision.
- Use
impactandplanwith canonical layer names to evaluate a safer direction or migration. - Change ownership or policy only when the canonical responsibilities genuinely changed; otherwise move or invert the dependency.
- Regenerate evidence and rerun the guard after the code change.
Do not add a blanket allow rule merely to reach zero violations. Undefined relationships are deliberately rejected, and a generated report is evidence of analysis rather than approval for the proposed design.
Operational guidance
Begin with read-only views and distinguish report generation from source mutation.
- Use
status,scan,metrics,validate,policy, andguardfor current-state inspection. - Treat
reportandgraphas writes because they replace generated Markdown outputs. - Use layer names exactly as registered; the source/target order changes the policy decision.
- Preserve the command, commit identity, output, and generated diff together when using results as review evidence.
- Review non-Python and dynamic dependencies separately because the static graph cannot certify them.
- Run the full architecture guard after changes to path ownership, policies, imports, or layer responsibilities.
Accurate examples
Inspect first, simulate proposed dependencies, and generate tracked evidence intentionally.
Read the current architecture state
acc architecture status
acc architecture scan
acc architecture metrics
acc architecture guardEvaluate an allowed dependency without changing code
acc architecture impact Release Core
acc architecture plan Release CoreEvaluate a prohibited dependency and expect rejection
acc architecture impact Runtime CLI
acc architecture plan Runtime CLIRegenerate reviewable architecture evidence
acc architecture report
acc architecture graph
git diff -- docs/architecture/analysis-report.md \
docs/architecture/dependency-graph.mdConnect architecture to operation
Use the Runtime guide for governed execution boundaries or the CLI reference for routing and exit behavior.