AI PROJECT GOVERNANCE STANDARD — BUSINESS LAYER ADDITION

v4.0 · 7 September 2026 · Owner: Zaid Al Dabbag

This document records the Business Planning & Value Assurance layer (PIL-BZ) added to the Standard.

It supplements v3.9 and will be merged into the controlled .docx when Zaid ratifies the change.

Aligned with: PRINCE2 Business Case, PMI PMBOK Benefits Management, TOGAF Business Architecture, OGC Gateway Process.

CHANGE RECORD

1. PURPOSE

Every governed project must demonstrate that the work being asked for has value and a clear path to achieving it. The business layer enforces:

• A mandatory Business Plan at project intake

• Lifecycle cost-benefit analysis with NPV, IRR and payback period (not just upfront costs)

• Options analysis comparing do-nothing, do-minimum, do-something approaches

• Value proposition with measurable metrics and measurement methods

• Strategic alignment with organizational goals and KPIs

• Running cost projections by category

• Marketing and selling strategy with competitive landscape

• Revenue model per use case with confidence levels

• Benefits realization plan — how benefits will be tracked post-delivery

• Dependencies and assumptions — what must be true for the plan to work

• Sensitivity analysis — best case, worst case, most likely scenarios

• Early identification of areas of concern with escalation criteria

• Success criteria — specific, measurable targets for go/no-go decisions

• Efficiency audit before building (search for cheaper/better ways)

Trigger: /SE-BUSINESS (UC15)

Industry Alignment

2. NEW REQUIREMENTS

REQ-BUS-001 — Business Plan mandatory at intake

Every governed project carries a business_plan.json twin and a generated BUSINESS_PLAN_A3.html before /SE-NEW-PROJECT can ratify. No plan = no approval to build.

Acceptance criterion: A governed project cannot pass /SE-NEW-PROJECT ratification without an initial business_plan.json twin and the generated BUSINESS_PLAN_A3.html present in 01_System/; --check exits 0 on the seeded twin.

REQ-BUS-002 — Lifecycle cost-benefit analysis with NPV/IRR

The Business Plan includes development costs, running/operational costs, maintenance costs, opportunity costs, quantitative and qualitative benefits (tangible, intangible, cost-avoidance), ROI calculation, Net Present Value (NPV), Internal Rate of Return (IRR), payback period, break-even point, and a lifecycle view (not just upfront).

Acceptance criterion: The business_plan.json twin contains a cost_benefit section with NPV, IRR, payback_months, roi_percentage, and break_even_months populated; benefits are classified as tangible/intangible/cost-avoidance.

REQ-BUS-003 — Value proposition with measurable metrics

The Business Plan includes a clear value proposition stating the key benefits the project delivers, who benefits, and how the value is achieved — with metrics for measuring value realisation. Each benefit includes a measurement method specifying how the metric will be collected and verified.

Acceptance criterion: The business_plan.json twin contains a value_proposition section with benefits (each with a measurable metric, baseline, target, and measurement_method), and a differentiation statement.

REQ-BUS-004 — Running cost projections

The Business Plan includes running costs and operational expense projections for the full lifecycle, broken down by category (infrastructure, personnel, licences, support, hosting, AI-engine tokens).

Acceptance criterion: The business_plan.json twin contains a running_costs section with at least 5 cost categories, each with annual projections over the lifecycle.

REQ-BUS-005 — Marketing and selling strategy

The Business Plan includes a marketing and selling strategy identifying the target audience per use case, the go-to-market approach, pricing model, competitive positioning, and sales channels.

Acceptance criterion: The business_plan.json twin contains a marketing_strategy section with target_audience, go_to_market, pricing, positioning, and channels.

REQ-BUS-006 — Revenue model per use case

The Business Plan includes a revenue model per use case, projecting potential revenue for each user case over the lifecycle.

Acceptance criterion: The business_plan.json twin contains a revenue_model section with at least one use case entry, each carrying a revenue projection and the assumptions behind it.

REQ-BUS-007 — Areas of concern identified early

The Business Plan identifies areas of concern early — risks to value realisation, cost overruns, market risks, technical risks, competitive threats, regulatory risks, dependency risks — with mitigation strategies, early warning indicators, risk owners, and escalation criteria (when to stop or pivot).

Acceptance criterion: The business_plan.json twin contains an areas_of_concern section with at least 3 identified risks, each with a mitigation strategy, early warning indicator, and owner. Escalation criteria are stated.

REQ-BUS-011 — Options analysis

The Business Plan compares at least 2 options (including do-nothing) with their costs, benefits, and risks, and recommends one with justification.

Acceptance criterion: The business_plan.json twin contains an options_analysis section with at least 2 options and a recommended_option with justification.

REQ-BUS-012 — Strategic alignment

The Business Plan links the project to organizational goals and KPIs it will improve.

Acceptance criterion: The business_plan.json twin contains a strategic_alignment section with strategic_driver, goals_supported, and kpi_impact.

REQ-BUS-013 — Benefits realization plan

The Business Plan includes a plan for tracking and measuring benefits after delivery, with owners, measurement dates, and target values.

Acceptance criterion: The business_plan.json twin contains a benefits_realization section with at least 1 item, each with owner, measurement_date, target_value, and measurement_method.

REQ-BUS-014 — Dependencies and assumptions

The Business Plan identifies dependencies and assumptions that must hold for the plan to work, with validation methods and risks if wrong.

Acceptance criterion: The business_plan.json twin contains a dependencies_assumptions section with at least 1 dependency and 2 assumptions, each with validation_method and risk_if_wrong.

REQ-BUS-015 — Sensitivity analysis

The Business Plan includes at least 3 scenarios (best case, worst case, most likely) showing how changes to key assumptions affect ROI and payback.

Acceptance criterion: The business_plan.json twin contains a sensitivity_analysis section with at least 3 scenarios, each with assumption_change, impact_on_roi, and impact_on_payback.

REQ-BUS-008 — Efficiency audit before building (SP07)

An efficiency audit is conducted before every build step: the operator researches existing solutions, compares build vs. buy, evaluates technology choices for cost-effectiveness, and documents recommendations.

Acceptance criterion: SP07 is drawn and registered; a sampled build task shows an efficiency audit record with alternatives researched, a build-vs-buy decision, and the chosen approach justified.

REQ-BUS-009 — Business Plan updated with significant changes

The Business Plan is updated when a significant change occurs (Class 1 or Class 2 change that affects scope, cost, timeline, or value proposition).

Acceptance criterion: A change record that affects cost, scope or value carries a dated update to the business_plan.json twin.

REQ-BUS-010 — Value validated at gates

Value is validated against investment at key gates: /SE-VALIDATE checks that the work done so far still delivers the value promised in the Business Plan; /SE-AUDIT checks that running costs are within projections.

Acceptance criterion: UC08 includes a value-check step comparing actual benefits delivered against the Business Plan's projections; UC10 includes a cost-check step comparing actual spend against the Business Plan's running-cost projections.

3. NEW USE CASE — UC15 /SE-BUSINESS

Purpose: Produce or update the Business Plan, conduct cost-benefit analysis, validate value, and run efficiency audit.

Actor: AI operator

Entry criteria: A project is being stood up, a significant change is proposed, or Zaid requests a business review.

Exit criteria: business_plan.json exists with all seven mandatory sections populated; BUSINESS_PLAN_A3.html generated; efficiency audit recorded.

Gate: G2, G3

Steps

4. NEW SUB-PROCESS — SP07 EFFICIENCY AUDIT

Purpose: Find the cheaper, better way before you build.

Called by: UC04, UC06, UC15

Steps

5. PORTABLE LAYER RULES (PIL-BZ)

Added to 01_System/portable/PORTABLE_CORE.md:

PIL-BZ — BUSINESS PLANNING & VALUE ASSURANCE. Every project earns its investment.

- PIL-BZ-1 — Business Plan mandatory at intake. business_plan.json twin + generated BUSINESS_PLAN_A3.html required before /SE-NEW-PROJECT ratifies. Covers: purpose, target market, value proposition (measurable metrics), lifecycle CBA (dev/running/maintenance costs, ROI, break-even), running-cost projections by category, marketing strategy, revenue per use case, areas of concern with mitigations, efficiency audit (SP07).

- PIL-BZ-2 — Efficiency audit before building (SP07). Research alternatives, compare build vs. buy, justify technology choices on cost-effectiveness. Skipping is a process defect.

- PIL-BZ-3 — Value validated at gates. /SE-VALIDATE checks value delivered vs. promised. /SE-AUDIT checks costs vs. projections. Variance beyond threshold = risk.

6. TEMPLATES

6.1 JSON Schema

Location: 01_System/portable/templates/business_plan/business_plan.schema.json

The schema defines12 validation rules (C-BP1 through C-BP12) covering:

• Project metadata (name, owner, date, status)

• Purpose and problem statement

• Target market segments with size and needs

• Value proposition with measurable metrics per benefit

• Cost-benefit analysis (dev costs, running costs, ROI, break-even)

• Running cost projections by category (3-year)

• Marketing strategy (audience, go-to-market, pricing, positioning, channels)

• Revenue model per use case with assumptions

• Areas of concern (risks with likelihood, impact, mitigation, early warning)

• Efficiency audit (alternatives, build-vs-buy, recommendation)

• Value validation (verdict, justification, conditions)

• Footer (generated_from, generator_version)

6.2 Generator

Location: 01_System/portable/templates/business_plan/build_business_plan.py

Reads business_plan.json from the current directory and generates BUSINESS_PLAN_A3.html — a single-page A3 landscape document with:

• Header strip (project name, owner, class, version, status)

• 3-column card grid with9 sections

• Metric boxes for CBA (dev cost, ROI, break-even)

• Tables for benefits, costs, revenue, risks, alternatives

• Verdict box (green/amber/red) for value validation

Usage:

cd 01_System
python3 ../01_System/portable/templates/business_plan/build_business_plan.py --check  # validate only
python3 ../01_System/portable/templates/business_plan/build_business_plan.py           # generate HTML

7. FILE PLACEMENT

8. INTEGRATION WITH EXISTING USE CASES

UC02 /SE-NEW-PROJECT

New step UC02S9: Seed the mandatory Business Plan: an initial business_plan.json twin and the generated BUSINESS_PLAN_A3.html, with all seven sections populated from the project framing.

UC04 /SE-DESIGN

New edge: UC04S9 calls SP07 efficiency audit when regenerating project documents.

UC06 /SE-BUILD

New edge: UC06S1 calls SP07 efficiency audit before building.

UC08 /SE-VALIDATE

Implicit: Value-check step compares actual benefits delivered against the Business Plan's projections.

UC10 `/SE-AUDIT

Implicit: Cost-check step compares actual spend against the Business Plan's running-cost projections.

9. CHECKER UPDATES

10. COMPLIANCE NOTES

This addition is compliant with the existing framework:

1. Follows the trace chain: IT-127 → REQ-BUS-### → UC15/SP07 → templates → evidence

1. Uses the existing pattern: JSON twin + generator + A3 HTML (same as project_docs)

1. Integrated into the process: New use case, new sub-process, updated lifecycle diagram

1. Registered properly: All rows in USE_CASES.md, PIL_REQUIREMENTS.md, INSTRUCTION_TRACE.md

1. Checked mechanically: check_instructions.py passes all 24 checks

1. File placement correct: All files in their mapped folders per FILE_PLACEMENT_MAP.md

11. NEXT STEPS

1. Zaid ratifies the 14 new REQ rows (PROPOSED → RATIFIED)

1. CR-012 raised to formalise the change

1. Sample business_plan.json created for the governance project as exemplar

1. Standard v4.0 .docx updated with the new Part J

1. Rollout pack updated to include the new templates

1. Other projects get the business layer installed

EVIDENCE: 01_System/portable/templates/business_plan/ | METHOD: Inspection | PRODUCED-BY: GLM-5.3 (ZCode) | VERIFIED-BY: Unverified | DATE: 2026-09-07