← Back to Resources

BVDLC Context Folder Structure

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
Phase 0 is tiered: Lean (3 docs, 1–2 hrs), Standard (6 docs, 3–5 hrs), or Enterprise (8 docs, 5–8 hrs)
Key Principle: Context is the DNA of your BVDLC implementation

Phase 0 Has Three Tiers — Pick Yours

Same framework, three depths. The structure inside 00-business-context/ depends on which tier fits your initiative. Answer five questions to find your fit.

The Scoring Rubric

Each “Yes” = 1 point.

  1. Does this cross department or team boundaries?
  2. Does budget approval go beyond your direct leader?
  3. Are more than 8 stakeholders materially affected?
  4. Is regulatory, compliance, or audit review involved?
  5. Is this multi-quarter or platform-level change?

Your Score → Your Tier

0–1 points — Lean

3 docs, 1–2 hours. Best for startups, small teams, founder-led decisions.

  • 01-intent-and-case
  • 02-approach-and-investment
  • 03-decision-record

2–3 points — Standard

6 docs, 3–5 hours. Best for corporate departments, midsize companies, director-led initiatives.

  • 01-executive-intent
  • 02-business-case
  • 03-success-metrics
  • 04-solution-approach
  • 05-investment-and-approval
  • 06-handoff

4–5 points — Enterprise

8 docs, 5–8 hours. Best for board-level transformations, regulated industries, multi-year programs.

  • 01-executive-intent
  • 02-business-case
  • 03-success-metrics
  • 04-solution-approach
  • 05-investment-thesis
  • 06-stakeholder-alignment
  • 07-phase-0-approval
  • 08-handoff

Override Rules

Even if your score says otherwise:

You can start Lean and upgrade later. The logic is the same. You’re just adding depth.

Tailor the Folder to Your Tier

Once you’ve picked a Phase 0 tier above, here’s how the rest of the context folder bends to fit.

Lean Tier

  • Keep everything in one repo with lightweight Markdown; founders or product own updates.
  • Combine Phase 2 and Phase 3 folders if the tech lead is the same person.
  • Focus on linking real customer names, not formal approvals.

Standard Tier

  • Give each squad a subfolder inside 03-planning/ and share Phase 0/1 across squads.
  • Treat the context folder as the “source of truth” for Jira epics.
  • Use the templates below to keep decisions and prompts consistent.

Enterprise Tier

  • Mirror the structure in your doc system if Git access is limited.
  • Add compliance subfolders (audits, legal approvals) under 00-business-context/ and 04-build-test-deploy/.
  • Assign a context owner 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"

Complete Folder Structure

/project-context/ β”œβ”€β”€ README.md # Project overview and quick links β”œβ”€β”€ 00-business-context/ # Phase 0: pick ONE tier β”‚ β”‚ # (see the tier-picker above) β”‚ β”‚ β”‚ β”œβ”€β”€ [LEAN] 3 docs Β· 1–2 hours Β· founder-led, small teams β”‚ β”‚ β”œβ”€β”€ 01-intent-and-case.md β”‚ β”‚ β”œβ”€β”€ 02-approach-and-investment.md β”‚ β”‚ └── 03-decision-record.md β”‚ β”‚ β”‚ β”œβ”€β”€ [STANDARD] 6 docs Β· 3–5 hours Β· corporate departments, director-led β”‚ β”‚ β”œβ”€β”€ 01-executive-intent.md β”‚ β”‚ β”œβ”€β”€ 02-business-case.md β”‚ β”‚ β”œβ”€β”€ 03-success-metrics.md β”‚ β”‚ β”œβ”€β”€ 04-solution-approach.md β”‚ β”‚ β”œβ”€β”€ 05-investment-and-approval.md β”‚ β”‚ └── 06-handoff.md β”‚ β”‚ β”‚ └── [ENTERPRISE] 8 docs Β· 5–8 hours Β· board-level, regulated, multi-year β”‚ β”œβ”€β”€ 01-executive-intent.md β”‚ β”œβ”€β”€ 02-business-case.md β”‚ β”œβ”€β”€ 03-success-metrics.md β”‚ β”œβ”€β”€ 04-solution-approach.md β”‚ β”œβ”€β”€ 05-investment-thesis.md β”‚ β”œβ”€β”€ 06-stakeholder-alignment.md β”‚ β”œβ”€β”€ 07-phase-0-approval.md β”‚ └── 08-handoff.md β”‚ β”œβ”€β”€ 01-prototyping/ # Phase 1: Rapid Validation β”‚ β”œβ”€β”€ prototype-experiments/ β”‚ β”‚ β”œβ”€β”€ prototype-v1/ β”‚ β”‚ β”œβ”€β”€ prototype-v2/ β”‚ β”‚ └── prototype-v3/ β”‚ β”œβ”€β”€ user-feedback/ β”‚ β”‚ β”œβ”€β”€ session-notes/ β”‚ β”‚ └── feedback-summary.md β”‚ β”œβ”€β”€ validation-reports/ β”‚ β”‚ β”œβ”€β”€ feasibility-report.md β”‚ β”‚ β”œβ”€β”€ value-validation.md β”‚ β”‚ └── technical-learnings.md β”‚ β”œβ”€β”€ lessons-learned.md β”‚ └── go-no-go-decision.md β”‚ β”œβ”€β”€ 02-architecture/ # Phase 2: Production Design β”‚ β”œβ”€β”€ solution-architecture.md β”‚ β”œβ”€β”€ component-design.md β”‚ β”œβ”€β”€ integration-points.md β”‚ β”œβ”€β”€ nfr-specifications.md β”‚ β”œβ”€β”€ technology-decisions.md β”‚ β”œβ”€β”€ security-requirements.md β”‚ β”œβ”€β”€ architecture-decision-records/ β”‚ β”‚ β”œβ”€β”€ ADR-001-database-choice.md β”‚ β”‚ β”œβ”€β”€ ADR-002-api-design.md β”‚ β”‚ └── ADR-template.md β”‚ └── diagrams/ β”‚ β”œβ”€β”€ system-architecture.mmd β”‚ β”œβ”€β”€ data-flow.mmd β”‚ └── deployment-architecture.mmd β”‚ β”œβ”€β”€ 03-planning/ # Phase 3: Execution Planning β”‚ β”œβ”€β”€ implementation-roadmap.md β”‚ β”œβ”€β”€ task-breakdown.md β”‚ β”œβ”€β”€ dependencies.md β”‚ β”œβ”€β”€ risk-assessment.md β”‚ β”œβ”€β”€ resource-allocation.md β”‚ β”œβ”€β”€ ai-prompts/ β”‚ β”‚ β”œβ”€β”€ code-generation-prompts.md β”‚ β”‚ β”œβ”€β”€ test-generation-prompts.md β”‚ β”‚ └── review-prompts.md β”‚ └── acceptance-criteria/ β”‚ β”œβ”€β”€ 04-build-test-deploy/ # Phase 4: Implementation β”‚ β”œβ”€β”€ code-artifacts/ β”‚ β”‚ └── README.md # Links to actual code repository β”‚ β”œβ”€β”€ test-results/ β”‚ β”‚ β”œβ”€β”€ unit-test-reports/ β”‚ β”‚ β”œβ”€β”€ integration-test-reports/ β”‚ β”‚ β”œβ”€β”€ e2e-test-reports/ β”‚ β”‚ └── security-scan-results/ β”‚ β”œβ”€β”€ quality-reports/ β”‚ β”‚ β”œβ”€β”€ code-review-summary.md β”‚ β”‚ β”œβ”€β”€ technical-debt-log.md β”‚ β”‚ └── quality-metrics.md β”‚ β”œβ”€β”€ deployment-logs/ β”‚ β”‚ β”œβ”€β”€ deployment-checklist.md β”‚ β”‚ β”œβ”€β”€ rollback-procedures.md β”‚ β”‚ └── deployment-history.md β”‚ └── dev-notes/ β”‚ β”œβ”€β”€ implementation-decisions.md β”‚ β”œβ”€β”€ known-issues.md β”‚ └── technical-notes.md β”‚ └── 05-monitoring-value/ # Phase 5: Continuous Value β”œβ”€β”€ monitoring-dashboards/ β”‚ β”œβ”€β”€ business-metrics-dashboard.md β”‚ β”œβ”€β”€ technical-health-dashboard.md β”‚ └── dashboard-links.md β”œβ”€β”€ value-realization-reports/ β”‚ β”œβ”€β”€ week-1-report.md β”‚ β”œβ”€β”€ month-1-report.md β”‚ └── quarterly-review.md β”œβ”€β”€ operations-runbooks/ β”‚ β”œβ”€β”€ system-overview.md β”‚ β”œβ”€β”€ operational-procedures.md β”‚ β”œβ”€β”€ troubleshooting-guide.md β”‚ └── escalation-procedures.md β”œβ”€β”€ handover-docs/ β”‚ β”œβ”€β”€ operations-handover.md β”‚ └── training-materials/ └── improvement-backlog/ β”œβ”€β”€ optimization-opportunities.md β”œβ”€β”€ feedback-loop-triggers.md └── future-enhancements.md

Project README.md Template

Place this in the root of your project-context folder:

# [Project Name] - BVDLC Context **Last Updated:** [Date] **Project Status:** [Phase X - In Progress/Completed] ## Quick Links - [Business Context (Phase 0)](00-business-context/executive-intent.md) - [Prototype Results (Phase 1)](01-prototyping/go-no-go-decision.md) - [Architecture (Phase 2)](02-architecture/solution-architecture.md) - [Implementation Plan (Phase 3)](03-planning/implementation-roadmap.md) - [Code Repository](#) - [Monitoring Dashboard](#) ## Project Overview **Business Problem:** [1-sentence summary] **Target Outcome:** [1-sentence success metric] **Timeline:** [Start date] β†’ [Target completion] ## Key Stakeholders - Executive Sponsor: [Name] - Product Owner: [Name] - Tech Lead: [Name] - Team: [Names] ## Current Status **Phase:** [Current phase] **Progress:** [X% complete] **Blockers:** [Any blockers] **Next Milestone:** [What's next]

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)
← Back to Resources