Is the license a SaaS subscription or a one-time purchase?

Annual license covering a single repository. The fee covers access to the versioned configuration package and all updates during the license period. Multi-repository pricing is available.

What happens if the license expires?

The installed configuration files continue to function — the boundary linter, CI/CD pipeline, and preservation marker check keep running. The team loses access to updates but the installed version continues to enforce the rules it was configured with.

Is the license appropriate for a team that has never done a structural audit?

The license is most effective when the team knows the current violation baseline. The recommended sequence: run the included ACI diagnostic script first, fix the most critical violations, then enable enforcement. Enabling enforcement before fixing violations produces a pipeline that blocks all merges.

Architecture Enforcement License: AI Code Guardrails as a Tool

The Architecture Enforcement License is a self-serve tooling license that gives development teams the complete ASA enforcement stack — boundary linter configuration, preservation marker framework, CI/CD pipeline templates, and AI governance files — as a versioned, maintainable package. It is the tool-first alternative to the service-first engagement model: teams that want to run the enforcement infrastructure themselves, without ongoing consulting involvement.

The license is not a SaaS product. It is a set of configuration files, scripts, and templates that the team installs in their repository and maintains as part of their standard development infrastructure. The ASA Standard defines the rules; the license packages them in a form that is immediately deployable.

This page explains what the license includes, how it differs from the service packages, and what the expected structural outcome looks like for a team that deploys it.

What the License Includes

The Architecture Enforcement License packages the complete ASA enforcement stack into five components:

Component 1: Boundary Linter Configuration

Pre-configured dependency-cruiser rules for TypeScript/JavaScript codebases and a Python boundary checker script — covering all five boundary violation categories:

Rules included:
  ✓ no-circular          — circular dependency detection
  ✓ no-cross-domain      — cross-domain import prevention
  ✓ no-db-in-handlers    — database access in transport layer
  ✓ no-business-in-ui    — business logic in presentation layer
  ✓ no-slice-internals   — direct import from slice internal files
  ✓ no-shared-utils-overuse — shared utility import frequency threshold

The configuration is parameterized — teams adjust the path patterns to match their directory structure without modifying the rule logic.

Component 2: Preservation Marker Framework

The complete preservation marker system:

Included:
  ✓ check_preservation_markers.py — CI/CD enforcement script
  ✓ Marker syntax specification   — BEGIN/END USER CODE convention
  ✓ .cursorrules template         — AI governance instructions
  ✓ CLAUDE.md template            — Claude-specific governance
  ✓ .aider.conf.yml template      — Aider-specific governance
  ✓ Marker placement guide        — which files to protect and why

The AI governance templates instruct the AI tool to respect preservation markers, to check for existing implementations before generating new ones, and to never modify files in protected directories without explicit confirmation.

Component 3: CI/CD Pipeline Templates

Ready-to-deploy pipeline configurations for the three most common CI providers:

Included:
  ✓ .github/workflows/ci.yml      — GitHub Actions (four-stage pipeline)
  ✓ .gitlab-ci.yml                — GitLab CI (equivalent stages)
  ✓ .pre-commit-config.yaml       — Pre-commit hooks (local enforcement)
  ✓ jest.config.js (coverage)     — Coverage threshold configuration
  ✓ setup.cfg (pytest coverage)   — Python coverage configuration
  ✓ Branch protection guide       — GitHub/GitLab settings documentation

Each template is parameterized with comments indicating which values to adjust for the specific codebase (coverage thresholds, path patterns, Node/Python versions).

Component 4: AI Governance Files

Governance files that configure AI tools to operate within the ASA boundary model:

# .cursorrules (excerpt from license template)
architecture:
  - Always import from slice public interfaces (index.ts / __init__.py)
    Never import from internal slice files directly
  - Never add logic to route handlers — delegate to service layer
  - Never add database queries outside of repository files
  - Check for existing implementations before generating new ones
  - Never regenerate files containing === BEGIN USER CODE === markers
    without explicit user confirmation

naming:
  - Python: snake_case for all identifiers
  - TypeScript: camelCase for variables/functions, PascalCase for types
  - Database columns: snake_case
  - API responses: camelCase
  - Boolean fields: always prefixed with is_ or has_

generation:
  - Maximum file size: 300 LOC for service files, 150 LOC for handlers
  - When a file approaches the limit, suggest splitting before continuing
  - Always generate corresponding test file when generating a service file

Component 5: Scoring Model and Detection Scripts

The complete AI Chaos Index detection scripts — the same scripts documented on the failure pattern pages — packaged as a runnable diagnostic tool:

# Run the full ACI diagnostic locally
python scripts/aci_scan.py --path ./src --output report.json

# Output: JSON report with per-root-cause severity scores
# {
#   "aci_score": 47,
#   "risk_band": "Elevated",
#   "rc01_severity": 6.5,
#   "rc02_severity": 4.0,
#   "rc03_severity": 3.5,
#   "rc04_severity": 7.0,
#   "rc05_severity": 5.0,
#   "findings": [...]
# }

License vs Service: When to Use Which

The Architecture Enforcement License and the Vibecodiq service packages address the same structural problems through different delivery models:

	License	Core Package	Module A
Delivery	Self-serve tooling	Structured sprint	Structured sprint
Implementation	Team installs and configures	Vibecodiq implements	Vibecodiq implements
Existing violations	Team remediates	Vibecodiq remediates	Vibecodiq remediates
Time to enforcement	Days to weeks (team-paced)	5–8 days (sprint)	3–5 days (sprint)
Ongoing support	Documentation only	30-day support included	30-day support included
Best for	Teams with strong engineering capacity	Teams that need implementation help	Teams restructuring one domain
Price	CLI License (annual)	from $900	from $1,200

The license is the right choice for teams that have the engineering capacity to implement the enforcement infrastructure themselves and want a versioned, maintainable package rather than a one-time consulting engagement. It is not the right choice for teams that need the existing violations addressed — the license stops new violations from accumulating, but does not fix the existing ones.

What the License Does Not Include

The Architecture Enforcement License is tooling, not implementation:

Does not include remediation of existing circular dependencies, layer violations, or oversized files
Does not include writing the test baseline for existing code
Does not include a diagnostic audit of the current codebase state
Does not include architectural consulting or code review
Does not include support calls or async Q&A

For teams that need implementation help alongside the tooling, the Core package or Module A is the correct starting point. The license can be added after the sprint to maintain the enforcement infrastructure independently.

Deployment Sequence

Day 1 (2–3 hours): Install and configure
  → Clone the license package into the repository
  → Adjust path patterns in .dependency-cruiser.js to match directory structure
  → Set coverage thresholds in jest.config.js / setup.cfg
  → Copy AI governance files (.cursorrules, CLAUDE.md) to repository root

Day 1–2 (variable): Establish the violation baseline
  → Run the boundary linter against the current codebase
  → Run the ACI diagnostic script
  → Document the current violation count per category
  → Decide which violations to fix before enabling enforcement

Day 2–N (team-paced): Fix baseline violations
  → Address circular dependencies first (highest blast radius risk)
  → Address cross-layer imports second
  → Establish test baseline for highest-risk modules
  → Add preservation markers to files with custom logic

Day N+1 (1–2 hours): Enable enforcement
  → Add CI/CD pipeline configuration to .github/workflows/
  → Configure branch protection
  → Run a test PR that intentionally fails each stage to verify enforcement
  → Enable pre-commit hooks for local enforcement

Ongoing: Maintain
  → Raise coverage thresholds as coverage improves
  → Update boundary rules as new domains or layers are added
  → Review AI governance files quarterly for relevance

Versioning and Updates

The license is versioned. When the ASA Standard updates the boundary rules, detection scripts, or AI governance templates, license holders receive the update as a versioned release. Teams apply updates on their own schedule — the update is a pull request against the license configuration files, not an automatic change to the running enforcement.

License version: 1.x.x (semantic versioning)
  Major: breaking changes to rule structure or script API
  Minor: new rules, new detection scripts, new AI governance templates
  Patch: bug fixes, documentation updates, threshold adjustments

Update process:
  1. Review the changelog for the new version
  2. Apply the updated configuration files to the repository
  3. Run the boundary linter and ACI diagnostic to verify no regressions
  4. Commit the updated configuration as a standard PR