How the AI-DLC Extension System Manages Opt-In Mechanisms for Security Rules

The AI-DLC extension system uses standardized *.opt-in.md files to conditionally load security rules during the Requirements Analysis stage, merging rule documents only when users explicitly answer "Yes" to opt-in prompts.

The awslabs/aidlc-workflows repository implements a modular architecture that separates optional security constraints from core workflows. This design ensures lightweight execution for prototypes while enabling production-grade enforcement when needed. Understanding how the AI-DLC extension system manages opt-in mechanisms for security rules allows teams to control when heavyweight blocking constraints are applied without modifying the underlying workflow code.

Opt-In Prompt Definition and Structure

Each extension ships a companion *.opt-in.md file that defines a standardized question presented during the Requirements Analysis stage. These Markdown-formatted prompts serve as the single source of truth for user intent regarding optional rule enforcement.

The Security Baseline Question

In aidlc-rules/aws-aidlc-rule-details/extensions/security/baseline/security-baseline.opt-in.md, the prompt asks users to select their preferred security posture:

## Question: Security Extensions

Should security extension rules be enforced for this project?

A) Yes — enforce all SECURITY rules as blocking constraints (recommended for production-grade applications)
B) No — skip all SECURITY rules (suitable for PoCs, prototypes, and experimental projects)
X) Other (please describe after [Answer]: tag below)

[Answer]:

This file establishes the contract between the user and the AI-DLC runner. When the user selects option A, the system interprets this as explicit consent to load blocking security constraints.

Extension Hook Processing

The core workflow discovers and processes opt-in files dynamically at runtime. This mechanism ensures that extensions remain truly optional and do not impact baseline performance unless explicitly requested.

Discovery and Loading

According to aidlc-rules/aws-aidlc-rules/core-workflow.md, the workflow engine scans for all *.opt-in.md files in the extensions directory. The engine loads each discovered prompt and presents it during the Requirements Analysis phase.

Conditional Rule Merging

When the user answers Yes, the corresponding rule document (security-baseline.md) is merged into the active rule set. If the user answers No, the workflow skips the entire extension, keeping the baseline execution fast and unencumbered. This conditional merge operation happens before the Design and Implementation stages begin.

Runtime Decision and Metadata Storage

The opt-in answer is captured in the clarifying questions payload and stored in the run's metadata. Subsequent stages—such as Design and Implementation—consult this metadata to determine whether to enforce the blocking security constraints defined in the extension.

The following Python snippet demonstrates how a runner might query this metadata to apply the correct configuration:

import yaml, os

# Load the opt‑in answers from the run metadata (generated by the AIDLC runner)

with open("run-meta.yaml") as f:
    meta = yaml.safe_load(f)

security_opt_in = meta.get("extensions", {}).get("security-baseline", "no")

if security_opt_in.lower().startswith("a"):
    # Load the security rules into the active rule set

    load_rules("aidlc-rules/aws-aidlc-rule-details/extensions/security/baseline/security-baseline.md")
else:
    # Skip the security extension – proceed without its constraints

    pass

This approach ensures that the decision made during Requirements Analysis propagates consistently through all downstream stages without requiring redundant user input.

Testing the Opt-In Flow

The repository includes a dedicated test harness to verify that extension gating works as expected across both configurations. Documented in scripts/aidlc-evaluator/docs/extension-hook-testing.md, the run_extension_test.py utility executes the workflow twice for each test scenario:

# Run the baseline (no security) configuration

python run.py ext-test --scenario sci-calc --configs no-extensions

# Run the full‑security configuration

python run.py ext-test --scenario sci-calc --configs all-extensions

The generated extension-test-config.yaml records which opt-in values were applied for each run. This enables automated comparison of outputs, token usage, and quality metrics between the lightweight baseline and the fully secured variant.

Summary

• Standardized opt-in files: Each extension uses a *.opt-in.md file to define a clear Yes/No question presented during Requirements Analysis.
• Conditional rule loading: The core workflow merges security rules only when users explicitly opt in, keeping baseline executions lightweight.
• Metadata persistence: Opt-in responses are stored in run metadata and consulted by subsequent stages to maintain consistent enforcement decisions.
• Comprehensive testing: The run_extension_test.py harness validates both Yes and No code paths to ensure reliable extension gating.

Frequently Asked Questions

What happens if I answer "No" to the security baseline opt-in prompt?

If you select "No" (option B), the workflow skips loading the security-baseline.md rules entirely. The system proceeds with the lightweight core workflow only, making this configuration ideal for proof-of-concept development where security constraints might impede rapid iteration.

Can custom extensions use the same opt-in mechanism?

Yes. The extension system is generic—any custom extension can include an *.opt-in.md file following the same pattern as property-based-testing.opt-in.md. The core workflow automatically discovers and processes these files regardless of the extension's domain or author.

How does AI-DLC store my opt-in responses for later stages?

The runner captures your answer in the clarifying questions payload and persists it in the run metadata (typically run-meta.yaml). Later stages query this metadata to determine whether to apply blocking constraints, ensuring your initial decision governs the entire workflow execution.

Where can I find documentation on testing extension loading behavior?

The scripts/aidlc-evaluator/docs/extension-hook-testing.md file provides detailed documentation on the run_extension_test.py harness. This tool validates that extensions are correctly gated by running scenarios with both enabled and disabled configurations, generating comparison metrics for quality assurance.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}