<!--  
LLM INSTRUCTIONS: Fill in the [ Add details... ] placeholders based on project context.

A portfolio roadmap is a time-phased, visual representation of the programs,
projects, and operations in a portfolio, showing their sequence, expected
outcomes, and the dependencies between them. Its purpose is to communicate
strategy and to let decision-makers see the consequence of a change before the
change is made, rather than discovering it a quarter later when funding has
already been committed.

The intent behind carrying dependencies, funding, and capacity as separate
sections is that a roadmap listing only initiatives and dates is a calendar, not
a plan. It looks complete while telling the reader nothing about what will
happen if one initiative runs late.

Alignment: the portfolio roadmap should be aligned and consistent with the
following documents: Program charter, Business case, Portfolio management plan,
Resource capacity matrix.

Writing guidance:

*   Give every initiative a stable identifier. A roadmap reviewed over several
    cycles is unreadable if an initiative is referred to by a different name
    each time it appears, and the reader cannot tell whether two rows are the
    same initiative or two of them.

*   Write dates at the precision the decision actually needs. An annual
    portfolio may legitimately be planned by quarter; a release with a fixed
    commercial date may not. Mixed precision in one table is the thing to
    avoid, because the reader compares the rows against each other.

*   Record the status as a value from a fixed set such as Proposed, Funded,
    In Progress, On Hold, or Complete. A free-text status cannot be sorted or
    filtered, and a roadmap that cannot be filtered is a picture.

*   Record funding as a planned envelope rather than a spend forecast. The
    roadmap answers whether the money is available in the period, not whether it
    is being spent, and the two are routinely confused.

*   Where an initiative is dependent on another, name the predecessor in the
    dependency section rather than in a free-text note. A dependency recorded
    only in prose is a dependency nobody can query.

Tailoring Notes:

*   A programme-level portfolio roadmap may aggregate to programmes only, and
    the initiative rows may be several levels down where a division plans its
    own portfolio.

*   The roadmap may be presented graphically rather than as a table. The
    sections below carry the same content in either form, and the form should
    say which presentation is expected.

*   Add or remove rows as needed. If an initiative carries more detail than the
    roadmap can hold, link to its charter or business case rather than
    compressing it here.

*   Where the organisation runs a fixed planning cycle, record the cycle in the
    context section and reuse it, so that successive roadmaps are comparable.

Column guidance, by column:

Initiative rows:

*   **ID:** The stable identifier for the initiative, used by every later cycle
    of this roadmap and by the dependency and funding sections.

*   **Initiative Name:** The name of the program, project, or operation. Use the
    name from its charter so the same initiative is not tracked under two.

*   **Type:** Whether the row is a Program, Project, or Operation. The type
    determines what governance applies, so an initiative recorded without one
    has no defined approval path.

*   **Strategic Objective:** The specific objective this initiative serves, named
    from the strategy rather than from the initiative's own charter. An
    initiative that maps to no objective is a candidate for removal, and the
    roadmap is where that is visible.

*   **Start:** When the initiative is expected to start.

*   **End:** When the initiative is expected to deliver its outcomes, which is
    not the same as when its budget is spent.

*   **Budget:** The funding envelope allocated to the initiative for the
    planning period.

*   **Status:** Where the initiative currently stands against the fixed set
    used in this roadmap.

Dependency rows:

*   **ID:** The identifier of the initiative whose dependency is being recorded.

*   **Dependent Initiative:** The initiative that cannot proceed without the
    predecessor.

*   **Dependency Type:** Whether the dependency is Finish to Start, Start to
    Start, Finish to Finish, or Start to Finish. The type determines the amount
    of float the successor has, so an untyped dependency cannot be planned.

*   **Predecessor:** The initiative on which this one depends.

*   **Required By:** The date by which the dependency must be satisfied for the
    dependent initiative to hold its own date.

*   **Impact if Late:** What happens to the dependent initiative if the
    predecessor does not deliver in time.

Funding and capacity rows:

*   **Period:** The planning period the row covers.

*   **Planned Funding:** The money available in the period across the portfolio.

*   **Planned Capacity:** The resource capacity available in the period, in the
    unit the organisation uses.

*   **Committed Load:** The capacity already committed to initiatives in the
    period.

*   **Available:** The difference between planned and committed, which is the
    figure that tells the reader whether the plan is feasible.

*   **Notes:** Anything that changes the interpretation of the row, such as a
    known shortage or a hiring assumption the row depends on.

Assumption and constraint rows:

*   **ID:** The identifier for the assumption or constraint.

*   **Type:** Whether the row is an Assumption or a Constraint.

*   **Description:** What is being assumed or constrained.

*   **Impact on Roadmap:** The effect on the roadmap if this proves false or
    proves tighter than stated.

*   **Owner:** Who is responsible for confirming or managing it.

*   **Review Date:** When it will next be checked, because an assumption nobody
    revisits is indistinguishable from a fact.

Roadmap change rows:

*   **Change ID:** The identifier for the change.

*   **Description:** What changed in the roadmap.

*   **Reason:** Why it changed, which is what the next reader needs in order to
    judge whether the same reasoning applies again.

*   **Affected Initiatives:** The initiatives the change touches.

*   **Approved By:** Who authorised the change.

*   **Date:** When the change was approved, which fixes the version of the
    roadmap in which it took effect.
-->

<h3 dir="ltr" align="right">{{Company_Name}}</h3>
<h2 dir="ltr" align="right">{{Portfolio_Name}} - {{Portfolio_ID}}</h2>
<h1 dir="ltr" align="center">PORTFOLIO ROADMAP</h1>

| **Date Prepared:** {{Current_Date}} | **Portfolio Director:** {{Portfolio_Director_Name}} | **Prepared By:** {{Prepared_By}} |
| :--- | :--- | :--- |  

---

## 1. Portfolio Context and Planning Basis
<!-- What this portfolio covers, over what period, and how often the roadmap is
 refreshed. Record the planning cycle here rather than in a note, because
 successive roadmaps are only comparable if they were built on the same basis.
 Record the roadmap status as a version statement: which planning cycle this
 represents and which meeting approved it. Without that, two roadmaps differing
 by a few initiatives cannot be read as a change of direction rather than as two
 views of the same portfolio. -->

**Portfolio Purpose and Scope:** [ Add details... ]

**Planning Period:** [ Add details... ]

**Roadmap Horizon:** [ Add details... ]

**Portfolio Owner:** [ Add details... ]

**Planning Cycle:** [ Add details... ]

**Roadmap Version and Status:** [ Add details... ]

---

## 2. Roadmap Initiatives
<!-- One row per program, project, or operation, ordered by start date. Use the
 names from each initiative's charter so the same initiative is not tracked
 under two names across cycles. Record the status from the fixed set agreed for
 this roadmap, because a free-text status cannot be filtered, and a roadmap that
 cannot be filtered is a picture rather than a plan. Where an initiative serves
 no strategic objective, leave that cell saying so explicitly rather than
 leaving it blank, since the blank is indistinguishable from an oversight. Add
 or remove rows as needed. -->

| ID | Initiative Name | Type | Strategic Objective | Start | End | Budget | Status |
| :---: | :--- | :--- | :--- | :---: | :---: | ---: | :---: |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 3. Dependencies and Sequencing
<!-- Where one initiative cannot proceed until another delivers, record it here
 with a typed dependency rather than in a free-text note, because a dependency
 recorded only in prose is a dependency nobody can query. Finish to Start is
 the common case; Start to Start and Finish to Finish arise where two
 initiatives must move together. State the impact of a late predecessor in
 money, schedule, or both, since a dependency with no stated impact is not
 actionable when the predecessor slips. -->

| ID | Dependent Initiative | Dependency Type | Predecessor | Required By | Impact if Late |
| :---: | :--- | :--- | :--- | :--- | :--- |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 4. Funding and Capacity by Period
<!-- Whether the plan is feasible, not merely what is planned. The Available
 column is the one that matters: it is planned funding or capacity less what is
 already committed, and a roadmap where that figure is negative in some period
 is a roadmap that will be broken in that period. Record assumptions the row
 depends on, such as a hiring date or a funding decision that has not yet been
 taken, because a capacity row without them reads as a commitment. Add or remove
 rows as needed. -->

| Period | Planned Funding | Planned Capacity | Committed Load | Available | Notes |
| :---: | ---: | ---: | ---: | ---: | :--- |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 5. Assumptions and Constraints
<!-- What the roadmap takes for granted, and what limits it. An assumption
 without an owner and a review date is indistinguishable from a fact, and the
 roadmap then carries it forward indefinitely after the conditions that made it
 true have gone. Record constraints with the same seriousness, since a
 constraint recorded without its impact cannot be traded off against anything.
 Add or remove rows as needed. -->

| ID | Type | Description | Impact on Roadmap | Owner | Review Date |
| :---: | :--- | :--- | :--- | :--- | :---: |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 6. Roadmap Changes
<!-- What changed between this version of the roadmap and the last, and why. A
 reader comparing two roadmaps needs the reason as much as the change, because
 the reason is what tells them whether the same reasoning applies to the next
 change. Record the approver, since a roadmap altered without one is a roadmap
 nobody owns. Add or remove rows as needed. -->

| Change ID | Description | Reason | Affected Initiatives | Approved By | Date |
| :---: | :--- | :--- | :--- | :--- | :---: |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 7. Sign-off and Approvals

| Role | Name | Signature | Date |
| :--- | :--- | :---: | :---: |
| **Portfolio Manager** | {{Portfolio_Manager_Name}} | _______________________ | [ .... - .... - .... ] |
| **Head of PMO** | {{PMO_Lead_Name}} | _______________________ | [ .... - .... - .... ] |
| **Executive Sponsor** | {{Executive_Sponsor_Name}} | _______________________ | [ .... - .... - .... ] |
---

<div dir="ltr" align="right" style="margin-top: 20px; font-size: 12px; color: #7f8c8d;">
  <span>Electronic Audit Trail: Hash SHA256: {{Audit_Trail_SHA256_Hash}}</span> <br>
  <strong>Template:</strong> Portfolio Roadmap | <strong>Ref:</strong> PMO-00.01 <br>
  <i>Generated on: {{Current_Timestamp}}, by <a href="https://github.com/fakhruldeen/Tasleemat/" style="color: #7f8c8d;">Tasleemat</a></i>
</div>

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://tasleemat.pmo/schemas/completed/PMO-00.01.schema.json",
  "title": "Completed Portfolio Roadmap Data Contract",
  "description": "Additive structural schema validating completed Portfolio Roadmap artifact data payloads (PMO-00.01).",
  "type": "object",
  "properties": {
    "artifact_id": {
      "type": "string",
      "const": "PMO-00.01"
    },
    "metadata": {
      "type": "object",
      "properties": {
        "project_name": {
          "type": "string",
          "minLength": 1
        },
        "project_code": {
          "type": "string"
        },
        "date_prepared": {
          "type": "string",
          "format": "date"
        },
        "project_manager": {
          "type": "string",
          "minLength": 1
        },
        "prepared_by": {
          "type": "string",
          "minLength": 1
        },
        "version": {
          "type": "string"
        },
        "status": {
          "type": "string",
          "enum": [
            "draft",
            "baselined",
            "in_review",
            "approved"
          ]
        }
      },
      "required": [
        "project_name",
        "date_prepared",
        "project_manager",
        "prepared_by"
      ]
    },
    "portfolio_context_and_planning_basis": {
      "type": "object",
      "properties": {
        "portfolio_purpose_and_scope": {
          "type": "string",
          "minLength": 1,
          "description": "What this portfolio covers and what it deliberately excludes, in the terms the strategy uses. A roadmap that does not state its boundaries cannot be read against a strategy that is wider than the portfolio, and the gap is mistaken for missing initiatives."
        },
        "planning_period": {
          "type": "string",
          "minLength": 1,
          "description": "The period the roadmap plans for, and whether it is a financial year, a rolling three years, or a fixed cycle agreed elsewhere. Successive roadmaps are only comparable if this is the same each time."
        },
        "roadmap_horizon": {
          "type": "string",
          "minLength": 1,
          "description": "How far ahead the roadmap looks. Record the horizon even where it equals the planning period, because the two are frequently confused and the confusion shows up later as a gap between what was planned and what was expected."
        },
        "portfolio_owner": {
          "type": "string",
          "minLength": 1,
          "description": "The single role accountable for the portfolio as a whole, which is usually not the owner of any one initiative in it. Where this is left blank, the roadmap has an author but no owner, and reprioritisation becomes nobody's decision."
        },
        "planning_cycle": {
          "type": "string",
          "minLength": 1,
          "description": "How often the roadmap is refreshed and by what governance forum, such as a quarterly investment board. The cycle is what makes two versions of the roadmap comparable, and a roadmap refreshed on no cycle is a document nobody can diff."
        },
        "roadmap_version_and_status": {
          "type": "string",
          "minLength": 1,
          "description": "Which planning cycle this represents, its version number, and whether it is draft or approved. Without a version, two roadmaps differing by a few initiatives cannot be read as a change of direction rather than as two views of the same portfolio."
        }
      },
      "required": [
        "portfolio_purpose_and_scope",
        "planning_period",
        "roadmap_horizon",
        "portfolio_owner",
        "planning_cycle",
        "roadmap_version_and_status"
      ]
    },
    "roadmap_initiatives": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "minLength": 1,
          "description": "The stable identifier for the initiative, used by every later cycle of this roadmap and by the dependency and funding sections. A roadmap reviewed across several cycles is unreadable if an initiative is named differently each time, because the reader cannot tell whether two rows are one initiative or two."
        },
        "initiative_name": {
          "type": "string",
          "minLength": 1,
          "description": "The name of the program, project, or operation, taken from its charter so the same initiative is not tracked under two names. Where a name has changed, record the former name rather than replacing it, or the history becomes impossible to follow."
        },
        "type": {
          "type": "string",
          "minLength": 1,
          "description": "Whether the row is a Program, Project, or Operation. The type determines what governance applies, so an initiative recorded without one has no defined approval path, and the roadmap cannot answer what kind of decision is needed about it."
        },
        "strategic_objective": {
          "type": "string",
          "minLength": 1,
          "description": "The specific objective this initiative serves, named from the strategy rather than from the initiative's own charter. An initiative that maps to no objective is a candidate for removal, and the roadmap is the only place that becomes visible; where the mapping is genuinely absent, say so in the cell rather than leaving it blank."
        },
        "start": {
          "type": "string",
          "minLength": 1,
          "description": "When the initiative is expected to start, at the precision this table uses throughout. Mixed precision within one table is the thing to avoid, because the reader compares the rows against each other and a month beside a quarter invites a wrong conclusion."
        },
        "end": {
          "type": "string",
          "minLength": 1,
          "description": "When the initiative is expected to deliver its outcomes, which is not the same as when its budget is spent. An initiative that delivers early and closes its accounts later is normal, and recording the accounts date as the end date moves every dependent initiative on the roadmap."
        },
        "budget": {
          "type": "string",
          "minLength": 1,
          "description": "The funding envelope allocated to the initiative for the planning period, not a spend forecast. The roadmap answers whether the money is available in the period, not whether it is being spent, and the two are routinely confused when the figure is taken from a finance system."
        },
        "status": {
          "type": "string",
          "minLength": 1,
          "description": "Where the initiative currently stands against the fixed set agreed for this roadmap, such as Proposed, Funded, In Progress, On Hold, or Complete. A free-text status cannot be sorted or filtered, and a roadmap that cannot be filtered is a picture rather than a plan."
        }
      },
      "required": [
        "id",
        "initiative_name",
        "type",
        "strategic_objective",
        "start",
        "end",
        "budget",
        "status"
      ]
    },
    "dependencies_and_sequencing": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "minLength": 1,
          "description": "The identifier of the initiative whose dependency is being recorded, matching the ID used in the initiatives section so the row can be joined to it."
        },
        "dependent_initiative": {
          "type": "string",
          "minLength": 1,
          "description": "The initiative that cannot proceed, or cannot proceed on its own dates, without the predecessor. Name it rather than describing it, because a dependency stated in terms of a category rather than a named initiative cannot be actioned when it is threatened."
        },
        "dependency_type": {
          "type": "string",
          "minLength": 1,
          "description": "Whether the dependency is Finish to Start, Start to Start, Finish to Finish, or Start to Finish. The type determines how much float the successor has, so an untyped dependency cannot be planned; Finish to Start is the common case and the others arise where two initiatives must move together."
        },
        "predecessor": {
          "type": "string",
          "minLength": 1,
          "description": "The initiative on which this one depends, named and identified. A dependency recorded only in prose is a dependency nobody can query, and it is therefore a dependency that will not be checked before the predecessor slips."
        },
        "required_by": {
          "type": "string",
          "minLength": 1,
          "description": "The date by which the dependency must be satisfied for the dependent initiative to hold its own dates. Where the required date is later than the predecessor's planned finish, the gap is the risk and should be visible here rather than discovered later."
        },
        "impact_if_late": {
          "type": "string",
          "minLength": 1,
          "description": "What happens to the dependent initiative if the predecessor does not deliver in time, in money, schedule, or scope terms. A dependency with no stated impact is not actionable when the predecessor slips, because nobody knows whether to escalate, re-sequence, or absorb the delay."
        }
      },
      "required": [
        "id",
        "dependent_initiative",
        "dependency_type",
        "predecessor",
        "required_by",
        "impact_if_late"
      ]
    },
    "funding_and_capacity_by_period": {
      "type": "object",
      "properties": {
        "period": {
          "type": "string",
          "minLength": 1,
          "description": "The planning period the row covers, using the same periods as the planning basis section so the two can be read together. Where a quarter appears in one table and a month in another, the reader has to reconcile them before drawing any conclusion."
        },
        "planned_funding": {
          "type": "string",
          "minLength": 1,
          "description": "The money available in the period across the whole portfolio, from the approved budget rather than from requests. The roadmap's purpose is to test the plan against what is actually available, so a figure taken from requests tests nothing."
        },
        "planned_capacity": {
          "type": "string",
          "minLength": 1,
          "description": "The resource capacity available in the period, in the unit the organisation uses, whether that is person-days, FTEs, or machine hours. The unit matters because a capacity row expressed in a different unit from the rest of the roadmap cannot be added up with anything else."
        },
        "committed_load": {
          "type": "string",
          "minLength": 1,
          "description": "The capacity already committed to initiatives in the period, including work that will not finish inside it. Excluding the part that spills into the next period is the most common way a capacity table overstates what is free."
        },
        "available": {
          "type": "string",
          "minLength": 1,
          "description": "The difference between planned and committed. This is the column that tells the reader whether the plan is feasible; a roadmap where this figure is negative in some period is a roadmap that will break in that period, and the shortfall is visible here or nowhere."
        },
        "notes": {
          "type": "string",
          "minLength": 1,
          "description": "Anything that changes how the row should be read, such as a known shortage, a hiring assumption the row depends on, or a funding decision not yet taken. A capacity row without its assumptions reads as a commitment, and the reader treats it as one."
        }
      },
      "required": [
        "period",
        "planned_funding",
        "planned_capacity",
        "committed_load",
        "available",
        "notes"
      ]
    },
    "assumptions_and_constraints": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "minLength": 1,
          "description": "The identifier for the assumption or constraint, so it can be referred to from the change log and from the initiative rows that depend on it."
        },
        "type": {
          "type": "string",
          "minLength": 1,
          "description": "Whether the row is an Assumption or a Constraint. An assumption may prove false and be replaced; a constraint may not be replaced at all, only planned around, and recording both under one heading loses that distinction exactly where it matters."
        },
        "description": {
          "type": "string",
          "minLength": 1,
          "description": "What is being assumed, or what is limiting the portfolio. State it as a testable statement rather than a sentiment, since an assumption phrased as a hope cannot be shown to have failed."
        },
        "impact_on_roadmap": {
          "type": "string",
          "minLength": 1,
          "description": "The effect on the roadmap if this proves false, or proves tighter than stated. An assumption recorded without its impact cannot be prioritised for testing, because nothing distinguishes the consequential ones from the trivial."
        },
        "owner": {
          "type": "string",
          "minLength": 1,
          "description": "Who is responsible for confirming or managing it. An assumption with no owner is not being watched, and the roadmap carries it forward indefinitely after the conditions that made it true have gone."
        },
        "review_date": {
          "type": "string",
          "minLength": 1,
          "description": "When the assumption will next be checked. This is what separates an assumption from a fact in practice: an assumption nobody revisits is indistinguishable from a fact, and it stops being questioned precisely when it should be."
        }
      },
      "required": [
        "id",
        "type",
        "description",
        "impact_on_roadmap",
        "owner",
        "review_date"
      ]
    },
    "roadmap_changes": {
      "type": "object",
      "properties": {
        "change_id": {
          "type": "string",
          "minLength": 1,
          "description": "The identifier for the change, used to link it to the decision record and to the meeting that authorised it."
        },
        "description": {
          "type": "string",
          "minLength": 1,
          "description": "What changed in the roadmap, stated concretely enough to be diffed against the previous version. A change described only as a realignment cannot be checked to see whether it actually happened."
        },
        "reason": {
          "type": "string",
          "minLength": 1,
          "description": "Why it changed. A reader comparing two roadmaps needs the reason as much as the change itself, because the reason is what tells them whether the same reasoning applies to the next change or whether the reasoning has been overtaken."
        },
        "affected_initiatives": {
          "type": "string",
          "minLength": 1,
          "description": "The initiatives the change touches, by identifier where possible. This is what allows the reader to see whether a change described as minor has in fact moved a committed date."
        },
        "approved_by": {
          "type": "string",
          "minLength": 1,
          "description": "Who authorised the change. A roadmap altered without an approver is a roadmap nobody owns, and the next alteration is as likely to be an error as a decision."
        },
        "date": {
          "type": "string",
          "minLength": 1,
          "description": "When the change was approved, which fixes the version of the roadmap in which it took effect and lets the change log be read in order."
        }
      },
      "required": [
        "change_id",
        "description",
        "reason",
        "affected_initiatives",
        "approved_by",
        "date"
      ]
    }
  },
  "required": [
    "artifact_id",
    "metadata",
    "portfolio_context_and_planning_basis",
    "roadmap_initiatives",
    "dependencies_and_sequencing",
    "funding_and_capacity_by_period",
    "assumptions_and_constraints",
    "roadmap_changes"
  ]
}

{
  "_llm_instructions": "Fill in the 'project_title' and 'date_prepared' properties, and the 'value' property of each field, based on the provided project context. Reference parameters.md for global project variables.",
  "form_name": "Portfolio Roadmap",
  "document_reference": "PMO-00.01",
  "project_title": "",
  "date_prepared": "",
  "fields": {
    "f01_Portfolio_Purpose_and_Scope": {
      "section": "Portfolio Context and Planning Basis",
      "label": "Portfolio Purpose and Scope",
      "guidance": "What this portfolio covers and what it deliberately excludes, in the terms the strategy uses. A roadmap that does not state its boundaries cannot be read against a strategy that is wider than the portfolio, and the gap is mistaken for missing initiatives.",
      "value": ""
    },
    "f02_Planning_Period": {
      "section": "Portfolio Context and Planning Basis",
      "label": "Planning Period",
      "guidance": "The period the roadmap plans for, and whether it is a financial year, a rolling three years, or a fixed cycle agreed elsewhere. Successive roadmaps are only comparable if this is the same each time.",
      "value": ""
    },
    "f03_Roadmap_Horizon": {
      "section": "Portfolio Context and Planning Basis",
      "label": "Roadmap Horizon",
      "guidance": "How far ahead the roadmap looks. Record the horizon even where it equals the planning period, because the two are frequently confused and the confusion shows up later as a gap between what was planned and what was expected.",
      "value": ""
    },
    "f04_Portfolio_Owner": {
      "section": "Portfolio Context and Planning Basis",
      "label": "Portfolio Owner",
      "guidance": "The single role accountable for the portfolio as a whole, which is usually not the owner of any one initiative in it. Where this is left blank, the roadmap has an author but no owner, and reprioritisation becomes nobody's decision.",
      "value": ""
    },
    "f05_Planning_Cycle": {
      "section": "Portfolio Context and Planning Basis",
      "label": "Planning Cycle",
      "guidance": "How often the roadmap is refreshed and by what governance forum, such as a quarterly investment board. The cycle is what makes two versions of the roadmap comparable, and a roadmap refreshed on no cycle is a document nobody can diff.",
      "value": ""
    },
    "f06_Roadmap_Version_and_Status": {
      "section": "Portfolio Context and Planning Basis",
      "label": "Roadmap Version and Status",
      "guidance": "Which planning cycle this represents, its version number, and whether it is draft or approved. Without a version, two roadmaps differing by a few initiatives cannot be read as a change of direction rather than as two views of the same portfolio.",
      "value": ""
    },
    "f07_ID": {
      "section": "Roadmap Initiatives",
      "label": "ID",
      "guidance": "The stable identifier for the initiative, used by every later cycle of this roadmap and by the dependency and funding sections. A roadmap reviewed across several cycles is unreadable if an initiative is named differently each time, because the reader cannot tell whether two rows are one initiative or two.",
      "value": ""
    },
    "f08_Initiative_Name": {
      "section": "Roadmap Initiatives",
      "label": "Initiative Name",
      "guidance": "The name of the program, project, or operation, taken from its charter so the same initiative is not tracked under two names. Where a name has changed, record the former name rather than replacing it, or the history becomes impossible to follow.",
      "value": ""
    },
    "f09_Type": {
      "section": "Roadmap Initiatives",
      "label": "Type",
      "guidance": "Whether the row is a Program, Project, or Operation. The type determines what governance applies, so an initiative recorded without one has no defined approval path, and the roadmap cannot answer what kind of decision is needed about it.",
      "value": ""
    },
    "f10_Strategic_Objective": {
      "section": "Roadmap Initiatives",
      "label": "Strategic Objective",
      "guidance": "The specific objective this initiative serves, named from the strategy rather than from the initiative's own charter. An initiative that maps to no objective is a candidate for removal, and the roadmap is the only place that becomes visible; where the mapping is genuinely absent, say so in the cell rather than leaving it blank.",
      "value": ""
    },
    "f11_Start": {
      "section": "Roadmap Initiatives",
      "label": "Start",
      "guidance": "When the initiative is expected to start, at the precision this table uses throughout. Mixed precision within one table is the thing to avoid, because the reader compares the rows against each other and a month beside a quarter invites a wrong conclusion.",
      "value": ""
    },
    "f12_End": {
      "section": "Roadmap Initiatives",
      "label": "End",
      "guidance": "When the initiative is expected to deliver its outcomes, which is not the same as when its budget is spent. An initiative that delivers early and closes its accounts later is normal, and recording the accounts date as the end date moves every dependent initiative on the roadmap.",
      "value": ""
    },
    "f13_Budget": {
      "section": "Roadmap Initiatives",
      "label": "Budget",
      "guidance": "The funding envelope allocated to the initiative for the planning period, not a spend forecast. The roadmap answers whether the money is available in the period, not whether it is being spent, and the two are routinely confused when the figure is taken from a finance system.",
      "value": ""
    },
    "f14_Status": {
      "section": "Roadmap Initiatives",
      "label": "Status",
      "guidance": "Where the initiative currently stands against the fixed set agreed for this roadmap, such as Proposed, Funded, In Progress, On Hold, or Complete. A free-text status cannot be sorted or filtered, and a roadmap that cannot be filtered is a picture rather than a plan.",
      "value": ""
    },
    "f15_ID": {
      "section": "Dependencies and Sequencing",
      "label": "ID",
      "guidance": "The identifier of the initiative whose dependency is being recorded, matching the ID used in the initiatives section so the row can be joined to it.",
      "value": ""
    },
    "f16_Dependent_Initiative": {
      "section": "Dependencies and Sequencing",
      "label": "Dependent Initiative",
      "guidance": "The initiative that cannot proceed, or cannot proceed on its own dates, without the predecessor. Name it rather than describing it, because a dependency stated in terms of a category rather than a named initiative cannot be actioned when it is threatened.",
      "value": ""
    },
    "f17_Dependency_Type": {
      "section": "Dependencies and Sequencing",
      "label": "Dependency Type",
      "guidance": "Whether the dependency is Finish to Start, Start to Start, Finish to Finish, or Start to Finish. The type determines how much float the successor has, so an untyped dependency cannot be planned; Finish to Start is the common case and the others arise where two initiatives must move together.",
      "value": ""
    },
    "f18_Predecessor": {
      "section": "Dependencies and Sequencing",
      "label": "Predecessor",
      "guidance": "The initiative on which this one depends, named and identified. A dependency recorded only in prose is a dependency nobody can query, and it is therefore a dependency that will not be checked before the predecessor slips.",
      "value": ""
    },
    "f19_Required_By": {
      "section": "Dependencies and Sequencing",
      "label": "Required By",
      "guidance": "The date by which the dependency must be satisfied for the dependent initiative to hold its own dates. Where the required date is later than the predecessor's planned finish, the gap is the risk and should be visible here rather than discovered later.",
      "value": ""
    },
    "f20_Impact_if_Late": {
      "section": "Dependencies and Sequencing",
      "label": "Impact if Late",
      "guidance": "What happens to the dependent initiative if the predecessor does not deliver in time, in money, schedule, or scope terms. A dependency with no stated impact is not actionable when the predecessor slips, because nobody knows whether to escalate, re-sequence, or absorb the delay.",
      "value": ""
    },
    "f21_Period": {
      "section": "Funding and Capacity by Period",
      "label": "Period",
      "guidance": "The planning period the row covers, using the same periods as the planning basis section so the two can be read together. Where a quarter appears in one table and a month in another, the reader has to reconcile them before drawing any conclusion.",
      "value": ""
    },
    "f22_Planned_Funding": {
      "section": "Funding and Capacity by Period",
      "label": "Planned Funding",
      "guidance": "The money available in the period across the whole portfolio, from the approved budget rather than from requests. The roadmap's purpose is to test the plan against what is actually available, so a figure taken from requests tests nothing.",
      "value": ""
    },
    "f23_Planned_Capacity": {
      "section": "Funding and Capacity by Period",
      "label": "Planned Capacity",
      "guidance": "The resource capacity available in the period, in the unit the organisation uses, whether that is person-days, FTEs, or machine hours. The unit matters because a capacity row expressed in a different unit from the rest of the roadmap cannot be added up with anything else.",
      "value": ""
    },
    "f24_Committed_Load": {
      "section": "Funding and Capacity by Period",
      "label": "Committed Load",
      "guidance": "The capacity already committed to initiatives in the period, including work that will not finish inside it. Excluding the part that spills into the next period is the most common way a capacity table overstates what is free.",
      "value": ""
    },
    "f25_Available": {
      "section": "Funding and Capacity by Period",
      "label": "Available",
      "guidance": "The difference between planned and committed. This is the column that tells the reader whether the plan is feasible; a roadmap where this figure is negative in some period is a roadmap that will break in that period, and the shortfall is visible here or nowhere.",
      "value": ""
    },
    "f26_Notes": {
      "section": "Funding and Capacity by Period",
      "label": "Notes",
      "guidance": "Anything that changes how the row should be read, such as a known shortage, a hiring assumption the row depends on, or a funding decision not yet taken. A capacity row without its assumptions reads as a commitment, and the reader treats it as one.",
      "value": ""
    },
    "f27_ID": {
      "section": "Assumptions and Constraints",
      "label": "ID",
      "guidance": "The identifier for the assumption or constraint, so it can be referred to from the change log and from the initiative rows that depend on it.",
      "value": ""
    },
    "f28_Type": {
      "section": "Assumptions and Constraints",
      "label": "Type",
      "guidance": "Whether the row is an Assumption or a Constraint. An assumption may prove false and be replaced; a constraint may not be replaced at all, only planned around, and recording both under one heading loses that distinction exactly where it matters.",
      "value": ""
    },
    "f29_Description": {
      "section": "Assumptions and Constraints",
      "label": "Description",
      "guidance": "What is being assumed, or what is limiting the portfolio. State it as a testable statement rather than a sentiment, since an assumption phrased as a hope cannot be shown to have failed.",
      "value": ""
    },
    "f30_Impact_on_Roadmap": {
      "section": "Assumptions and Constraints",
      "label": "Impact on Roadmap",
      "guidance": "The effect on the roadmap if this proves false, or proves tighter than stated. An assumption recorded without its impact cannot be prioritised for testing, because nothing distinguishes the consequential ones from the trivial.",
      "value": ""
    },
    "f31_Owner": {
      "section": "Assumptions and Constraints",
      "label": "Owner",
      "guidance": "Who is responsible for confirming or managing it. An assumption with no owner is not being watched, and the roadmap carries it forward indefinitely after the conditions that made it true have gone.",
      "value": ""
    },
    "f32_Review_Date": {
      "section": "Assumptions and Constraints",
      "label": "Review Date",
      "guidance": "When the assumption will next be checked. This is what separates an assumption from a fact in practice: an assumption nobody revisits is indistinguishable from a fact, and it stops being questioned precisely when it should be.",
      "value": ""
    },
    "f33_Change_ID": {
      "section": "Roadmap Changes",
      "label": "Change ID",
      "guidance": "The identifier for the change, used to link it to the decision record and to the meeting that authorised it.",
      "value": ""
    },
    "f34_Description": {
      "section": "Roadmap Changes",
      "label": "Description",
      "guidance": "What changed in the roadmap, stated concretely enough to be diffed against the previous version. A change described only as a realignment cannot be checked to see whether it actually happened.",
      "value": ""
    },
    "f35_Reason": {
      "section": "Roadmap Changes",
      "label": "Reason",
      "guidance": "Why it changed. A reader comparing two roadmaps needs the reason as much as the change itself, because the reason is what tells them whether the same reasoning applies to the next change or whether the reasoning has been overtaken.",
      "value": ""
    },
    "f36_Affected_Initiatives": {
      "section": "Roadmap Changes",
      "label": "Affected Initiatives",
      "guidance": "The initiatives the change touches, by identifier where possible. This is what allows the reader to see whether a change described as minor has in fact moved a committed date.",
      "value": ""
    },
    "f37_Approved_By": {
      "section": "Roadmap Changes",
      "label": "Approved By",
      "guidance": "Who authorised the change. A roadmap altered without an approver is a roadmap nobody owns, and the next alteration is as likely to be an error as a decision.",
      "value": ""
    },
    "f38_Date": {
      "section": "Roadmap Changes",
      "label": "Date",
      "guidance": "When the change was approved, which fixes the version of the roadmap in which it took effect and lets the change log be read in order.",
      "value": ""
    }
  }
}