Make Every AI-DLC Session Organization-Aware: Capture Your Standards Once, Inherit Them in Every Session

A step-by-step AI-DLC style workflow for extracting organizational standards from scattered artifacts into AI-actionable specs that eliminate repeated context and ensure first-attempt consistency across every team.

Singhal, Samar

Published Jun 29, 2026

Last modified Jun 29, 2026

How to capture organizational standards from scattered artifacts - codebases, design files, API specs, ADRs, team knowledge - and make them available to every AI-DLC session automatically. Consistent output, faster time-to-first-output, zero repeated explanations.

AI-DLC transforms how teams build software. Its adaptive workflow - Inception through Construction through Operations - takes a project from requirements to working code with the precision of a senior architect guiding every decision. Teams adopting AI-DLC see immediate productivity gains: faster time-to-code, better architecture decisions, comprehensive test coverage. But speed without shared context creates a new problem: the faster teams ship, the faster inconsistency compounds across the organization.

But watch what happens when you start an AI-DLC session on a new service. The conventions are all there - spread across the existing codebase, the OpenAPI spec, ADRs, linter configs, the Figma design system, CI/CD pipelines. The AI could piece it together, but it would need to correlate patterns across dozens of artifacts - comparing three repos to find the common error handling pattern, cross-referencing the OpenAPI spec with actual handler code to understand naming conventions, reading 12 ADR files to understand why certain technologies were chosen. So during Inception, the developer shortcuts this: "What's your API error response format?" They type out the JSON structure. "How do you handle cross-service communication?" They explain event-driven patterns already implemented in five other repos. Twenty minutes spent manually providing what could be extracted once from those artifacts.

The next developer on the next project hits the same problem. The same conventions live in the same artifacts. Same correlation problem. Same 20 minutes. Every team, every project, independently explaining standards that are already visible - just scattered across too many artifacts for the AI to correlate in real-time at the start of every session.

The AI-DLC workflow is working perfectly in each session. The problem isn't AI-DLC - it's that organizational knowledge hasn't been captured in a format that AI-DLC can consume automatically. Every session starts smart but uninformed about the organization.

This is where an organizational context layer adds value. When AI-DLC sessions start with pre-loaded organizational standards - design system, API conventions, architecture decisions, code patterns - Inception focuses entirely on what's new about the current project. Code Generation produces output matching team standards on first attempt.

Pre-loaded context doesn't constrain AI-DLC's adaptiveness - it enhances it. AI-DLC still adapts to each project's unique needs, still asks clarifying questions, still skips stages that don't apply. The context layer simply eliminates redundant rediscovery of organizational standards, freeing AI-DLC to focus its adaptive intelligence on what's actually new and unique about the current project.

This post walks through building that context layer using the Context Extraction rule set - an AI-DLC structured workflow that captures your standards and feeds them into every future session. The difference isn't in AI-DLC's capability - it's in what the AI knows before the session starts.

What Is the Organizational Context Layer?

It's a set of spec files - markdown documents at AI-actionable depth - that capture your organization's standards in a format AI tools consume automatically. They live in project repositories and are loaded by AI-DLC supported tools at session start.

Here's what a context spec looks like in practice. This is an excerpt from an API conventions spec:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
# API Conventions

RESTful JSON APIs with cursor-based pagination and structured error responses.

## URL Structure
- Base path: `/api/v1`
- Resource naming: plural nouns, kebab-case (`/payment-intents`, `/user-profiles`)
- Nested resources: `/merchants/{merchantId}/transactions`
- Actions: POST to sub-resource (`POST /payments/{id}/refund`)

## Parameter Casing
| Location | Case | Example |
|----------|------|---------|
| Path segments | kebab-case | `/payment-intents` |
| Path parameters | camelCase | `{merchantId}` |
| Query parameters | camelCase | `?pageSize=20&startDate=2024-01-01` |
| Request body | camelCase | `{ "merchantId": "mer_123" }` |
| Response body | camelCase | `{ "createdAt": "2024-01-15T10:30:00Z" }` |

## Error Response Format
{
  "code": "PAYMENT_DECLINED",
  "message": "Payment was declined by the issuing bank",
  "details": [
    { "field": "cardNumber", "reason": "Card reported lost" }
  ],
  "traceId": "req_abc123xyz"
}

## Pagination
- Style: Cursor-based (never offset/limit)
- Default page size: 20, max: 100
- Response envelope:
{
  "data": [...],
  "pagination": {
    "nextCursor": "eyJpZCI6InR4bl8wMDIifQ==",
    "hasMore": true
  }
}

## Do's and Don'ts
### Do
- Always return traceId in error responses
- Use 422 for business rule violations (not 400)
- Use prefixed random IDs (pay_, mer_, txn_)
- Include createdAt and updatedAt on every resource

### Don't
- Never expose stack traces or internal error messages
- Never use verbs in URLs (/createPayment) - use HTTP methods + nouns
- Never use sequential/guessable IDs
- Never use offset pagination - cursor-based only
- Never return 200 for errors

When this spec is loaded into .kiro/steering/api-conventions.md, every AI-DLC session on that project generates endpoints matching these exact conventions. No explanations needed. No corrections required.

Context specs aren't limited to code conventions. They can capture design assets and frontend patterns too - actual CSS token values, component markup patterns, logo usage rules, layout templates. When a developer asks AI-DLC to "build a dashboard page," the AI already knows the exact color palette, spacing scale, button styles, card patterns, and responsive breakpoints. It produces UI that matches the design system without a designer reviewing every screen.

Why Organizations Need This

The Artifact Correlation Problem

AI tools let any developer build a working solution in minutes. But "working" and "consistent with organizational standards" are different outcomes. When ten teams ship ten services in the time it used to take to ship one, ten different interpretations of the same convention ship with them.

Organizational conventions aren't missing - they're scattered. The error response format lives in a handler file across 5 repos. The spacing scale lives in Figma. The deployment strategy lives in CI/CD YAML. The database choice rationale lives in an ADR. The auth pattern lives in a security doc. The naming conventions are encoded in ESLint configs.

No single AI-DLC session can see all of these simultaneously. The AI would need to clone multiple repos, open Figma, read wiki pages, parse linter configs, and cross-reference PR review history - all before writing the first line of code. That correlation work is what developers do manually every session: "We use kebab-case because..." "Our error format is..." "The reason we chose EventBridge is..."

The context extraction workflow does this correlation once. It reads across all those artifacts, identifies the patterns, and produces spec files that AI-DLC loads instantly.

The Consistency Problem

When conventions live only in scattered artifacts, each developer interprets them slightly differently when explaining to their AI tool. One developer describes the error format from memory (slightly wrong). Another copies it from a different service (older version). A third says "just use standard REST errors" (too vague to be actionable).

1
2
3
4
5
6
7
Same convention, three interpretations:
  Dev A (from memory):    { error: "message", code: 500 }
  Dev B (from old service): { errorCode: "ERR_01", msg: "..." }
  Dev C (vague):           "use standard error handling"

Actual standard (from the OpenAPI spec + error middleware):
  { code: "PAYMENT_DECLINED", message: "...", details: [...], traceId: "req_abc" }

At enterprise velocity - where AI enables multiple teams to ship daily - these small divergences don't stay small. They multiply with every new service, every new endpoint, every new developer onboarded.

The produced specs capture the exact convention at AI-actionable depth - not an interpretation, not from memory, not vague. Every AI-DLC session gets the same spec, produces the same output.

The Onboarding Problem

When a new team starts using AI-DLC, they need to know the organization's conventions before they can provide them as context. Without pre-built specs, there's a learning curve - reading docs, studying existing code, asking senior engineers - before AI-DLC delivers full value. With specs pre-loaded, new teams get organizational consistency from their first session.

How It Works: The Context Extraction Rule Set

The extraction workflow is packaged as an AI-DLC rule set - the same structure AI-DLC itself uses. Drop it into a workspace and the AI executes the extraction workflow:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
context-extraction-rules/
├── aws-context-extraction-rules/
│   └── core-workflow.md
└── aws-context-extraction-rule-details/
    ├── common/
    │   ├── process-overview.md
    │   ├── question-format-guide.md
    │   ├── welcome-message.md
    │   ├── session-continuity.md
    │   └── error-handling.md
    ├── inception/
    │   ├── context-discovery.md
    │   ├── source-inventory.md
    │   ├── gap-analysis.md
    │   └── scope-definition.md
    ├── construction/
    │   ├── pattern-extraction.md
    │   ├── depth-validation.md
    │   └── ai-validation.md
    ├── operations/
    │   ├── distribution.md
    │   ├── monitoring.md
    │   └── maintenance.md
    └── templates/
        └── spec-format-reference.md

Inception Phase - Discover and Plan

The workflow starts by understanding what exists and what's needed:

Context Discovery classifies the situation:

Greenfield: No context specs exist yet
Brownfield: Some specs exist but are incomplete or shallow
Enhancement: Specs work but new sources or teams need coverage

Source Inventory catalogs everything available. The workflow accepts any source where organizational knowledge lives:

Code repositories (the gold-standard ones), shared libraries, monorepos
UI screenshots, Figma files, Storybook instances, design token JSON/YAML
OpenAPI/Swagger specs, Postman collections
ADRs, wiki pages, Confluence docs, coding standards documents
Linter/formatter configs (ESLint, Prettier, Ruff - conventions encoded as rules)
CI/CD pipeline YAML, IaC templates (CDK, Terraform)
PR review comments (repeated corrections = unwritten conventions)
Team knowledge ("what would you correct if AI got this wrong?")

The workflow asks about sources through a question file (not in chat) - it creates a markdown file with structured questions and [Answer]: tags. You fill in the answers, say "done," and the workflow continues. This ensures thorough coverage even when you've already provided sources upfront.

Example source inventory for a fintech company:

1
2
3
4
5
6
Sources provided for this extraction:
├── Code: payment-service repo, merchant-portal repo, shared-libs repo
├── Design: Figma design system (link), production screenshots
├── Docs: OpenAPI spec v2.1, 12 ADR files, API guidelines wiki
├── Config: .eslintrc, prettier.config, GitHub Actions workflows
└── Implicit: "We always use cursor pagination" (team knowledge)

Scope Definition determines what specs to produce - driven entirely by the sources, not a predetermined list. The workflow might produce 3 specs or 12, depending on what patterns the sources reveal. Common outputs include API conventions, code patterns, UI design systems, architecture decisions - but also CI/CD patterns, security standards, data conventions, event schemas, or any domain your sources contain. One source can produce multiple specs. Multiple sources can feed one spec.

Construction Phase - Extract and Validate

Pattern Extraction analyzes sources and generates spec files. For code repositories, it looks for patterns that repeat across repos - those ARE the conventions:

1
2
3
4
5
6
7
Analyzing 3 repositories for common patterns:
├── payment-service/src/handlers/     → kebab-case files ✓ (3/3 repos)
├── merchant-portal/src/components/   → PascalCase files ✓ (2/2 frontend repos)
├── All repos: AppError class hierarchy ✓ (3/3 repos)
├── All repos: Vitest + co-located tests ✓ (3/3 repos)
├── All repos: Pino structured logging ✓ (3/3 repos)
└── Variation: import order differs between repos → needs standardization

When conflicting patterns are found, the workflow doesn't guess - it asks:

1
2
3
4
5
6
7
8
9
10
11
12
⚠️ Conflict detected: Import ordering

  payment-service: external → internal → relative → types
  merchant-portal: external → relative → internal
  shared-libs: no consistent order

Options:
  A) Standardize on payment-service pattern (most repos follow it)
  B) Standardize on a different order (specify)
  C) Keep both - backend uses pattern A, frontend uses pattern B (team-specific specs)

[Answer]:

This handles the real-world reality that not every convention is universal. Some conflicts resolve to one standard. Others are legitimately different per team - the workflow captures both as separate team-specific specs.

Depth Validation ensures every entry meets the AI-actionable depth standard:

1
2
3
4
5
6
7
8
9
10
Depth check for api-conventions.md:
├── ✓ Error format: exact JSON structure provided
├── ✓ Pagination: exact response envelope provided
├── ✓ Naming: specific case per location with examples
├── ✗ Auth: "Use JWT" - TOO SHALLOW
│   Fix: "Bearer JWT in Authorization header, 1hr lifetime,
│          refresh via POST /api/v1/auth/refresh, 
│          service-to-service uses mTLS + signed JWT"
├── ✓ Do's and Don'ts: 8 Do's, 9 Don'ts with reasons
└── Result: 1 entry needs depth enhancement

AI Validation tests the specs against actual AI behavior:

1
2
3
4
5
6
7
8
9
10
Test: "Create an endpoint for listing merchant transactions with pagination"

With spec loaded, AI generates:
├── ✓ URL: GET /api/v1/merchants/{merchantId}/transactions (kebab-case, nested)
├── ✓ Pagination: cursor-based with { data, pagination: { nextCursor, hasMore } }
├── ✓ Error handling: AppError hierarchy, traceId in response
├── ✓ Naming: camelCase body fields, merchantId parameter
├── ✗ Missing: didn't include X-Correlation-Id header propagation
│   Fix: Added to spec under "Required Headers" section
└── Re-test: ✓ All checks pass

The spec is complete when AI generates output that passes code review on first attempt.

Operations Phase - Deploy and Maintain

Distribution deploys validated specs to all platforms:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Kiro - multi-file
cp specs/*.md project/.kiro/steering/

# Amazon Q Developer - multi-file  
cp specs/*.md project/.amazonq/rules/

# Cursor - wrap with frontmatter
for f in specs/*.md; do
  name=$(basename "$f" .md)
  printf -- '---\ndescription: %s\nalwaysApply: true\n---\n\n' "$name" | \
    cat - "$f" > "project/.cursor/rules/${name}.mdc"
done

# Claude Code - single file
cat specs/*.md > project/CLAUDE.md

# GitHub Copilot - single file
cat specs/*.md > project/.github/copilot-instructions.md

# Cline - single file
cat specs/*.md > project/.clinerules

One extraction cycle, all platforms covered simultaneously. Enterprises with mixed tooling (some teams on Kiro, others on Cursor or Q Developer) get consistent context everywhere from a single extraction run.

Integrating with AI-DLC: The produced specs go into the same location AI-DLC already reads from. For Kiro, specs sit alongside AI-DLC steering rules:

1
2
3
4
5
6
7
8
project/.kiro/
├── steering/
│   ├── aws-aidlc-rules/                 ← AIDLC workflow (already there)
│   │   └── core-workflow.md
│   ├── api-conventions.md               ← Extracted spec (add here)
│   ├── code-patterns.md                 ← Extracted spec (add here)
│   └── ui-design-system.md              ← Extracted spec (add here)
└── aws-aidlc-rule-details/              ← AI-DLC rule details (already there)

When a developer starts an AI-DLC session, the AI loads both - the AI-DLC workflow AND the organizational specs. Inception already knows the conventions. Code Generation matches standards immediately. No additional configuration needed.

Monitoring tracks correction rates and consistency - feeding gaps back into the next cycle.

Maintenance triggers re-extraction when sources change - new ADR accepted, design system updated, API spec revised.

Greenfield and Brownfield: Complementing AI-DLC in Both

Greenfield Projects (Highest Value)

No codebase exists. AI-DLC's Reverse Engineering has nothing to analyze. Without context specs, Inception must ask every organizational question from scratch.

With context specs pre-loaded, Inception skips organizational Q&A entirely:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
WITHOUT specs (greenfield):
  AI-DLC Inception asks:
  - "What language and framework?" → TypeScript, Express (org standard)
  - "What API conventions?" → kebab-case, cursor pagination (org standard)
  - "What error format?" → { code, message, details, traceId } (org standard)
  - "What auth mechanism?" → JWT Bearer, 1hr lifetime (org standard)
  - "What event patterns?" → CloudEvents via EventBridge (org standard)
  - "What testing framework?" → Vitest, 80% coverage (org standard)
  Total: 15-30 min answering questions already decided

WITH specs (greenfield):
  AI-DLC Inception asks:
  - "What are the unique business requirements for this service?"
  - "What entities does this service own?"
  - "What events does it publish/consume?"
  Total: 5 min on project-specific questions only

AI-DLC works perfectly either way. With specs, it works faster and produces consistent results from the first line of generated code.

Brownfield Projects (Complementary Value)

AI-DLC's Reverse Engineering analyzes the existing codebase brilliantly - extracting patterns, structure, and conventions from the code itself. Context specs complement this by providing standards that live outside the current repo:

What RE Sees (in the repo)	What Specs Add (outside the repo)
File naming patterns	Design system tokens from Figma
Error handling code	Architecture decisions from ADR repo
Test structure	Security requirements from compliance docs
Import patterns	CI/CD standards from platform team
API response shapes	Cross-service event format conventions

Reverse Engineering + context specs together give AI-DLC the complete picture. RE handles project-specific patterns. Specs handle org-wide standards. No duplication - they cover different knowledge sources.

Implementation Walkthrough: First Extraction Cycle

Here's a concrete walkthrough of running the extraction workflow for the first time.

Step 1: Set Up the Rule Set

1
2
3
4
5
6
7
8
9
10
11
# Clone the context extraction rule set
git clone <context-extraction-repo>
cd context-extraction-rules

# Copy to your platform (example: Kiro)
mkdir -p your-workspace/.kiro/steering
cp -R aws-context-extraction-rules your-workspace/.kiro/steering/
cp -R aws-context-extraction-rule-details your-workspace/.kiro/

# Verify structure
find your-workspace/.kiro/aws-context-extraction-rule-details -type f

Expected output:

1
2
3
4
5
6
7
8
9
10
11
12
your-workspace/.kiro/aws-context-extraction-rule-details/common/process-overview.md
your-workspace/.kiro/aws-context-extraction-rule-details/inception/context-discovery.md
your-workspace/.kiro/aws-context-extraction-rule-details/inception/source-inventory.md
your-workspace/.kiro/aws-context-extraction-rule-details/inception/gap-analysis.md
your-workspace/.kiro/aws-context-extraction-rule-details/inception/scope-definition.md
your-workspace/.kiro/aws-context-extraction-rule-details/construction/pattern-extraction.md
your-workspace/.kiro/aws-context-extraction-rule-details/construction/depth-validation.md
your-workspace/.kiro/aws-context-extraction-rule-details/construction/ai-validation.md
your-workspace/.kiro/aws-context-extraction-rule-details/operations/distribution.md
your-workspace/.kiro/aws-context-extraction-rule-details/operations/monitoring.md
your-workspace/.kiro/aws-context-extraction-rule-details/operations/maintenance.md
your-workspace/.kiro/aws-context-extraction-rule-details/templates/spec-format-reference.md

Step 2: Trigger the Workflow

Start an AI session (Kiro, Q Developer, Cursor, Claude Code - any AI-DLC supported tool) and state your intent using the trigger phrase:

1
2
3
4
5
6
7
"Using Context-Extraction, extract context specs from these repositories:
- github.com/acme/payment-service
- github.com/acme/merchant-portal
Additional sources:
- Design: [Figma link]
- API spec: ./openapi.yaml
- ADRs: ./docs/architecture/decisions/"

The AI loads the rule set, displays a welcome message, and begins executing the workflow. All artifacts are produced in context-docs/ - question files in context-docs/inception/, produced specs in context-docs/specs/, validation results in context-docs/validation/.

Step 3: Inception Executes

The workflow discovers your situation (greenfield - no existing specs), inventories your sources, and proposes scope:

1
2
3
4
5
6
7
8
9
10
11
Context Discovery: Greenfield - no existing spec files found
Source Inventory: 5 sources cataloged (2 repos, 1 Figma, 1 OpenAPI, 12 ADRs)
Scope Definition: Proposing 6 spec files based on source analysis:
  - api-conventions.md (from OpenAPI + payment-service handlers)
  - code-patterns.md (from both repos + linter configs)
  - ui-design-system.md (from Figma + merchant-portal)
  - architecture-decisions.md (from ADRs + repo structure)
  - ci-cd-conventions.md (from GitHub Actions workflows)
  - docker-patterns.md (from Dockerfiles across repos)

Proceed with extraction? [Yes/Modify scope]

Step 4: Construction Produces Specs

The workflow extracts patterns from your sources, validates depth, and tests against AI. You'll see it working through each spec:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Extracting api-conventions.md...
  ✓ URL patterns detected: kebab-case, /api/v1 prefix
  ✓ Error format extracted from payment-service error middleware
  ✓ Pagination pattern: cursor-based (found in 3 list endpoints)
  ✓ Auth: JWT Bearer (from OpenAPI securitySchemes)
  ✓ Do's and Don'ts: 8 generated from patterns + ADR constraints

Depth validation...
  ✓ All entries at AI-actionable depth
  
AI validation...
  Test: "Create a list endpoint for merchant transactions"
  ✓ Output matches all conventions
  
api-conventions.md COMPLETE (127 lines)

Step 5: Operations Deploys

The workflow deploys produced specs to your target platforms:

1
2
3
4
5
6
7
8
9
Distribution:
  ✓ Copied to .kiro/steering/ (for Kiro users)
  ✓ Copied to .amazonq/rules/ (for Q Developer users)
  ✓ Generated .cursor/rules/*.mdc (for Cursor users)
  ✓ Generated CLAUDE.md (for Claude Code users)
  ✓ Generated .github/copilot-instructions.md (for Copilot users)
  ✓ Generated .clinerules (for Cline users)

All teams can now start AI-DLC sessions with full organizational context.

Step 6: Verify

Start a new AI-DLC session on any project with the specs deployed. Ask it to generate something:

1
2
3
4
5
6
7
8
Prompt: "Using AI-DLC, Create a new endpoint for listing payment refunds"

Expected: AI generates endpoint with:
  - URL: GET /api/v1/payment-intents/{paymentIntentId}/refunds
  - Cursor-based pagination response
  - Error responses using { code, message, details, traceId }
  - Correct file naming and project structure
  - No corrections needed

If corrections are still needed, feed them back into the next extraction cycle - the workflow is iterative.

The Iterative Model: Context Grows Over Time

Each extraction cycle is a full Inception → Construction → Operations pass. Context accumulates:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Cycle 1 (Week 1):
  Sources: OpenAPI spec + 2 repos
  Output: api-conventions.md, code-patterns.md
  Impact: Corrections drop from 11 to 5/session

Cycle 2 (Week 2):
  Sources: Figma file + Storybook + screenshots
  Output: ui-design-system.md
  Impact: Corrections drop from 5 to 2/session

Cycle 3 (Week 3):
  Sources: ADR folder + architecture wiki + CI/CD configs
  Output: architecture-decisions.md, ci-cd-patterns.md
  Impact: Corrections drop from 2 to 0/session

Cycle 4+ (ongoing):
  Trigger: New ADR accepted, design system updated, new team onboarded
  Output: Updated specs, team-specific overlays
  Impact: Maintained at 0 corrections, new teams productive immediately

The Layering Model

Enterprises have diverse systems - Java microservices, Python data pipelines, React frontends, Go infrastructure tools - each with different conventions. The context layer reflects this reality:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌─────────────────────────────────────────────────────────────────┐
│  Organizational specs (all projects inherit)                    │
│  security-standards.md + event-patterns.md + git-workflow.md    │
└─────────────────────────────────────────────────────────────────┘
                              │
┌─────────────────────────────────────────────────────────────────┐
│  Team / language-specific specs                                 │
│  java-backend/ → api-conventions.md + java-patterns.md          │
│  python-data/ → pipeline-patterns.md + python-patterns.md       │
│  react-frontend/ → ui-design-system.md + react-patterns.md      │
│  go-platform/ → infrastructure-patterns.md + go-patterns.md     │
└─────────────────────────────────────────────────────────────────┘
                              │
┌─────────────────────────────────────────────────────────────────┐
│  Project-specific (AI-DLC handles per-session)                  │
│  Reverse Engineering + Requirements + User Stories              │
└─────────────────────────────────────────────────────────────────┘

A Java backend team and a Python data team share organizational standards (security, events, git workflow) but have completely different code patterns. The workflow produces separate specs for each - not a one-size-fits-all document that tries to cover everything.

When developers run AI-DLC with multiple specs loaded, AI-DLC intelligently applies only what's relevant to the current task - using the API conventions spec when building an endpoint, the UI design system when creating a component, the architecture spec when designing service interactions. If context is ambiguous or conflicting for the task at hand, AI-DLC asks which patterns to follow rather than guessing.

Measuring the Value

Immediate Impact

Metric	Without Context Layer	With Context Layer
Org-standard questions per Inception	5-10	0 (pre-loaded)
Corrections per Code Generation	8-12	0-2
Cross-team output consistency	~40%	95%+
New team ramp-up to full AI-DLC value	2-3 days	Immediate
Time to first usable output	25-40 min	5-8 min

Evolving Standards - Governance Without Friction

The deeper value isn't just speed - it's that standards propagate automatically:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Architecture team publishes new ADR (e.g., "migrate from REST to gRPC for internal services")
    → Re-run extraction cycle against the updated ADR
    → Specs update
    → Every AI-DLC session immediately follows the new decision
    → No team needs to read the ADR themselves - the AI already knows

Security team changes auth pattern (e.g., "move from API keys to short-lived JWT")
    → Re-extract security specs
    → All generated code uses new auth pattern from next session
    → Compliance without manual enforcement

Platform team simplifies CI/CD (e.g., "consolidated to single reusable workflow")
    → Update ci-cd-conventions spec
    → New projects inherit the simplified pipeline automatically
    → Teams don't need to learn the new standard - AI applies it

This is governance through context, not governance through code review corrections. Standards are enforced at generation time, not review time.

Who Contributes to the Context Layer

Team	What They Own	When They Re-Extract
Architecture	Tech choices, communication patterns, service boundaries	On new ADR
Security	Auth, encryption, secrets management, compliance	On policy change
Platform	CI/CD, infrastructure patterns, deployment strategy	On tooling change
Design	UI tokens, component specs, layout patterns	On design system release
Backend leads	API conventions, error formats, data patterns	On API spec change

Each team owns their domain's specs. The context layer is a living artifact maintained by the teams who set the standards - not a one-time document that goes stale.

Getting Started

For Solutions Architects

When helping enterprises adopt AI-DLC at scale:

Start with AI-DLC - get teams productive with the core workflow
Observe repeated context - notice what teams keep explaining each session
Deploy the extraction rule set - run cycles to capture those standards
Distribute org-wide - every team's AI-DLC sessions improve immediately
Establish ownership - assign spec owners who re-extract on source changes

For Platform Teams

1
2
3
4
5
6
7
8
9
10
11
# 1. Set up the extraction rule set in a dedicated workspace
mkdir org-context-extraction && cd org-context-extraction
cp -r <context-extraction-repo>/context-extraction-rules/ ./

# 2. Run extraction cycles (one per source batch)
# Trigger via AI session: "Using Context-Extraction, extract specs from these sources: [list]"

# 3. Deploy produced specs to a shared template repo
# All project repos inherit from this template

# 4. Teams get context automatically on next AI-DLC session

For Engineering Leadership

The business case: Context specs ensure AI-DLC generates code that follows your current best practices - and automatically adapts when those practices evolve.

Without context layer: AI-DLC delivers individual productivity, conventions vary. With context layer: AI-DLC delivers consistent, governed output that stays current as standards evolve.

Conclusion

AI-DLC is the workflow that transforms how teams build software. The organizational context layer is what makes it work with your organization's specific standards - and keeps working as those standards evolve.

The context extraction workflow solves three problems simultaneously:

Correlation - conventions scattered across dozens of artifacts are correlated into consumable specs
Consistency - every developer, every tool, every session gets the same standards
Evolution - when architecture, security, or platform teams update best practices, the specs update and every AI-DLC session follows the new standards immediately

It's packaged as an AI-DLC rule set - the same structure AI tools already know how to execute. Provide sources, run the lifecycle, deploy the specs. Architecture teams, security teams, platform teams each own their domain. Standards propagate through AI behavior, not through code review corrections.

The result: Inception focuses on what's new. Code Generation matches conventions immediately. New teams are productive from day one. Best practices evolve and propagate automatically. The AI isn't just smart - it's smart about YOUR organization, and stays current as your organization grows.

Resources and Next Steps

The complete implementation including the Context Extraction rule set, templates, and example specs is available in the Context Extraction Workflows repository .

For deeper learning:

AI-DLC Workflows — AI-Driven Life Cycle adaptive workflow steering rules for AI coding agents
AWS Kiro — AI-DLC supported IDE for running extraction workflows

About the Author

Samar Singhal is a Sr. Solutions Architect at AWS specializing in Advanced AI Systems. With deep passion for Generative AI, Containers, and Kubernetes, Samar focuses on developing next-generation solutions that combine artificial intelligence with cloud-native technologies to solve complex enterprise challenges.

Follow this project on GitHub

Next in this series: "Measuring Context Drift" — How to detect when your specs fall out of sync with evolving codebases, set up automated drift detection, and trigger re-extraction cycles before
inconsistency creeps back in.

# ai-dlc # kiro # claude-code # agents # vibe-coding

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Make Every AI-DLC Session Organization-Aware: Capture Your Standards Once, Inherit Them in Every Session

Singhal, Samar

What Is the Organizational Context Layer?

Why Organizations Need This

The Artifact Correlation Problem

The Consistency Problem

The Onboarding Problem

How It Works: The Context Extraction Rule Set

Inception Phase - Discover and Plan

Construction Phase - Extract and Validate

Operations Phase - Deploy and Maintain

Greenfield and Brownfield: Complementing AI-DLC in Both

Greenfield Projects (Highest Value)

Brownfield Projects (Complementary Value)

Implementation Walkthrough: First Extraction Cycle

Step 1: Set Up the Rule Set

Step 2: Trigger the Workflow

Step 3: Inception Executes

Step 4: Construction Produces Specs

Step 5: Operations Deploys

Step 6: Verify

The Iterative Model: Context Grows Over Time

The Layering Model

Measuring the Value

Immediate Impact

Evolving Standards - Governance Without Friction

Who Contributes to the Context Layer

Getting Started

For Solutions Architects

For Platform Teams

For Engineering Leadership

Conclusion

Resources and Next Steps

About the Author