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.

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 (not just upfront costs)

• Value proposition with measurable metrics

• Running cost projections by category

• Marketing and selling strategy

• Revenue model per use case

• Early identification of areas of concern

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

Trigger: /SE-BUSINESS (UC15)

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

The Business Plan includes development costs, running/operational costs, maintenance costs, opportunity costs, quantitative and qualitative benefits, ROI calculation, break-even point, and a lifecycle view (not just upfront).

Acceptance criterion: The business_plan.json twin contains a cba section with all eight fields populated; the generated CBA_A3.html renders a cost-benefit table with totals and a break-even indicator.

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.

Acceptance criterion: The business_plan.json twin contains a value_proposition section with benefits (each with a measurable metric), beneficiaries, and a value-realisation timeline.

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 — with mitigation strategies and early warning indicators.

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

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