ACC 1.0.0

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.

Source of truth

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.

System model

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.

Path governance

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.

Direction matters

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.

Fail closed

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.

Interpret the evidence

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.

Before implementation

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.

Public CLI

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.

Repair the boundary

Violation handling

Treat a violation as architecture evidence to investigate, not a prompt to weaken the guard.

  1. Run scan to separate missing ownership from dependency violations.
  2. Run metrics and guard to confirm the analyzed scope and failing checks.
  3. Inspect the generated analysis report or the source import and its policy decision.
  4. Use impact and plan with canonical layer names to evaluate a safer direction or migration.
  5. Change ownership or policy only when the canonical responsibilities genuinely changed; otherwise move or invert the dependency.
  6. 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.

Operate safely

Operational guidance

Begin with read-only views and distinguish report generation from source mutation.

  • Use status, scan, metrics, validate, policy, and guard for current-state inspection.
  • Treat report and graph as 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.
Verified syntax

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 guard

Evaluate an allowed dependency without changing code

acc architecture impact Release Core
acc architecture plan Release Core

Evaluate a prohibited dependency and expect rejection

acc architecture impact Runtime CLI
acc architecture plan Runtime CLI

Regenerate reviewable architecture evidence

acc architecture report
acc architecture graph
git diff -- docs/architecture/analysis-report.md \
  docs/architecture/dependency-graph.md
Continue

Connect architecture to operation

Use the Runtime guide for governed execution boundaries or the CLI reference for routing and exit behavior.