Your single source of truth for business-value driven delivery
Purpose: The context folder preserves business intent from Phase 0 through Phase 5 Setup Time: 30 seconds with provided script Key Principle: Context is the DNA of your BVDLC implementation
Tailor the Context Folder to Your Org
Startups / Small Teams
Keep everything in one repo with lightweight Markdown; founders/product own updates.
Combine Phase 2/3 folders if the tech lead is the same person.
Focus on linking real customer names, not formal approvals.
Growth-Stage / Multi-Squad
Give each squad a subfolder inside 03-planning/ and share Phase 0/1 across squads.
Treat the context repo as the “source of truth” for Jira epics.
Use the templates below to keep decisions and prompts consistent.
Enterprise / Regulated
Mirror the structure in your doc system if Git access is limited.
Add compliance subfolders (audits, legal approvals) under 00 and 04.
Assign a context steward per portfolio to run weekly health checks.
Quick Setup (30 seconds)
Run this in your terminal to create the complete BVDLC folder structure:
#!/bin/bash
# Create BVDLC context folder structure
mkdir -p project-context/{00-business-context,01-prototyping,02-architecture,03-planning,04-build-test-deploy,05-monitoring-value}
# Create subfolders for Phase 1
mkdir -p project-context/01-prototyping/{prototype-experiments,user-feedback,validation-reports}
# Create subfolders for Phase 2
mkdir -p project-context/02-architecture/{architecture-decision-records,diagrams}
# Create subfolders for Phase 3
mkdir -p project-context/03-planning/{ai-prompts,acceptance-criteria}
# Create subfolders for Phase 4
mkdir -p project-context/04-build-test-deploy/{test-results,quality-reports,deployment-logs,dev-notes}
# Create subfolders for Phase 5
mkdir -p project-context/05-monitoring-value/{monitoring-dashboards,value-realization-reports,operations-runbooks,handover-docs,improvement-backlog}
echo "✓ BVDLC context folder structure created successfully!"
echo "Next: cd project-context && git init"
# Executive Intent - Phase 0
**Date Created:** [Date]
**Created By:** [Name]
**Approved By:** [Executive Sponsor]
## The Business Problem
[Describe in 2-3 paragraphs what problem we're solving and why it matters]
## Who Is Affected
- **Primary Users:** [Who]
- **Secondary Users:** [Who]
- **Business Stakeholders:** [Who cares about outcomes]
## Success Looks Like
**Primary KPI:** [Metric] from [baseline] to [target] by [date]
**Secondary KPIs:**
- [Metric 2]: [Baseline] → [Target]
- [Metric 3]: [Baseline] → [Target]
## Strategic Alignment
This initiative supports:
- [ ] Company OKR: [Which one]
- [ ] Department Goal: [Which one]
- [ ] Market Opportunity: [What opportunity]
## Investment Justification
**Total Investment:** $[Amount]
**Expected Annual Benefit:** $[Amount]
**Payback Period:** [Months]
**3-Year ROI:** [%]
## Critical Success Factors
1. [What must be true for this to succeed]
2. [What must be true for this to succeed]
3. [What must be true for this to succeed]
Phase 1: Go/No-Go Decision Template
Save as: 01-prototyping/go-no-go-decision.md
# Phase 1: Go/No-Go Decision
**Date:** [Date]
**Decision Maker:** [Name]
## Prototype Testing Results
**Prototypes Built:** [Number]
**Users Tested With:** [Number]
**Testing Duration:** [Days]
## Value Hypothesis Validation
**Hypothesis:** We believed [X] would achieve [Y] because [Z]
**Result:** [ ] VALIDATED [ ] PARTIALLY VALIDATED [ ] INVALIDATED
**Evidence:**
- [Data point 1]
- [Data point 2]
- [Data point 3]
## Technical Feasibility
[ ] Proven feasible
[ ] Feasible with modifications
[ ] Not feasible with current approach
**Technical Learnings:**
- [Learning 1]
- [Learning 2]
## User Feedback Summary
**Positive Feedback:**
- [Feedback 1]
- [Feedback 2]
**Concerns Raised:**
- [Concern 1]
- [Concern 2]
## Decision
[ ] **GO** - Proceed to Phase 2 (Architecture)
[ ] **PIVOT** - Modify approach and re-prototype
[ ] **KILL** - Stop initiative (didn't validate value)
**Rationale:** [Why this decision]
**Next Steps:** [What happens next]
**Sign-off:** [Name] [Date]
Phase 2: Architecture Decision Record Template
Save as: 02-architecture/architecture-decision-records/ADR-[NUMBER]-[NAME].md
# ADR-[NUMBER]: [Decision Title]
**Date:** [Date]
**Status:** [Proposed | Accepted | Deprecated | Superseded]
**Deciders:** [Names]
## Context
**Phase 0 Business Requirement:** [What business need drives this]
**Phase 1 Learnings:** [What prototype taught us]
**Technical Challenge:** [What problem are we solving]
## Decision
[What we decided to do]
## Options Considered
### Option 1: [Name]
**Description:** [How this works]
**Pros:**
- [Benefit 1]
- [Benefit 2]
**Cons:**
- [Trade-off 1]
- [Trade-off 2]
**Complexity:** [High/Medium/Low]
**Cost Impact:** [$Amount or %]
### Option 2: [Name]
**Description:** [How this works]
**Pros:**
- [Benefit 1]
- [Benefit 2]
**Cons:**
- [Trade-off 1]
- [Trade-off 2]
**Complexity:** [High/Medium/Low]
**Cost Impact:** [$Amount or %]
## Rationale
[Why we chose this option]
## How This Serves Phase 0 Objectives
[Connect decision back to business value]
## Consequences
**Positive:**
- [Consequence 1]
- [Consequence 2]
**Negative:**
- [Trade-off 1]
- [Mitigation strategy]
## Success Criteria
We'll know this decision is correct when:
- [Measurable criterion 1]
- [Measurable criterion 2]
## Rollback Strategy
If this proves wrong: [How to undo this decision]
Best Practices
✅ Do This:
Keep context current—update as you learn, don't wait
Make it AI-friendly—use structured formats (YAML, Markdown tables)
Link everything—every decision should trace to Phase 0
Version control—context lives in Git alongside code
Daily commits—treat context like code, commit frequently
❌ Don't Do This:
Don't create context as "final documentation" at the end
Don't let context live only in someone's head
Don't separate context from code (keep them together)
Don't make it bureaucratic (keep it lightweight and useful)
Don't skip phases or merge context folders
💡 The Three-Touch Rule:
Every significant decision follows: AI generates → Human validates → System records (in context folder)