Reporting Governance
Reporting governance in Report Forge defines how your organisation controls the quality, consistency, and lifecycle of its reports across projects and teams. Without governance policies, teams create duplicated blueprints, inconsistent naming, and unreviewed outputs — leading to stakeholder confusion and audit risk.
This page provides the policies, checklists, and responsibility matrix recommended for organisations operating Report Forge at scale.
Core governance principles
- One blueprint per recurring report type. Duplication leads to diverging structures and stakeholder confusion about which template is current.
- Every blueprint has a named owner. The owner is accountable for blueprint quality, edition cadence, and the publication decision.
- All published outputs pass a reviewer gate. No output reaches external stakeholders without an approved edition.
- Naming follows a single convention. Consistent names across blueprints and editions enable cross-project search and historical comparison.
- Old content is archived, not deleted. Archiving preserves historical editions for audit while removing stale templates from active use.
Blueprint ownership
Every blueprint must have a Blueprint Owner — the person responsible for:
| Responsibility | Detail |
|---|---|
| Structural integrity | Ensuring the blueprint contains the right sections and fields for the report's purpose |
| Publishing decisions | Approving structural changes before publishing a new blueprint version |
| Cycle initiation | Creating or delegating creation of editions each reporting period |
| Review gate | Being listed as a reviewer (or delegating) for every edition |
| Archive decisions | Deciding when a blueprint should be archived or superseded |
Assigning blueprint ownership:
- Open the blueprint → Blueprint settings → Owner.
- Select the owner from the project member list.
- The owner receives notifications for all editions produced from this blueprint.
Blueprint owners are typically senior engineers, project managers, or document control leads — not general contributors. They should understand the report's audience and what constitutes acceptable data quality.
Naming conventions
A consistent naming convention makes blueprints and editions findable and comparable across projects.
Blueprint naming
Format: [Project / Programme] — [Report Type] — [Audience]
| Example name | Context |
|---|---|
North Station — Monthly Progress — PMO | Monthly progress for a specific project |
Portfolio — Executive Summary — Board | Board-level portfolio summary |
Airport Fitout — Commercial Update — Client | Client-facing commercial report |
PMO — Weekly Lookahead — Internal | Internal team lookahead |
If the blueprint is used across multiple projects (a shared template), prefix with the programme or portfolio name. If it is project-specific, prefix with the project name.
Edition naming
Format: [Project / Programme] — [Report Type] — [Period]
Period format depends on cadence:
| Cadence | Period format | Example |
|---|---|---|
| Weekly | YYYY-Www | 2026-W21 |
| Monthly | YYYY-MM | 2026-05 |
| Quarterly | YYYY-Q[n] | 2026-Q2 |
| Annual | YYYY | 2026 |
| Ad hoc | YYYY-MM-DD (issue date) | 2026-05-14 |
Edition cadence policy
For each recurring blueprint, define and document:
| Policy element | Example |
|---|---|
| Issue frequency | Monthly, first week of the month |
| Edition creation deadline | 3rd of each month |
| Contribution due date | 5th of each month |
| Review completion target | 8th of each month |
| Publication date | 10th of each month |
These deadlines should be configured as the Due date on each edition at creation time so contributors receive reminder notifications.
Pre-launch checklist (new blueprint going live)
Before creating the first edition from a new or substantially changed blueprint:
- Blueprint owner confirmed and assigned
- All sections reviewed against the intended report structure
- Required fields marked — no required fields on sections that may be blank in some periods
- At least two contributors given access
- At least one reviewer assigned
- Naming convention agreed and documented (project wiki or this file)
- Output template tested with sample data
- Export formats verified (PDF, Excel, or others as required)
- Stakeholder distribution list confirmed
- Archiving or supersession plan for any old blueprint being replaced
Review gate policy
All published outputs must originate from an Approved edition. Editions reach Approved only when:
- All required fields are complete (no Block-mode validation failures).
- Assigned reviewers have approved the edition.
Reviewer requirements to specify per blueprint:
| Policy | Options |
|---|---|
| Minimum reviewer count | 1 (default), 2, or All |
| Reviewer role | Internal reviewer, client representative, or both |
| Re-review required if changes requested? | Yes (default) / No |
Document these requirements in the blueprint description or your project governance document. They are not yet enforced automatically in Report Forge — the policy is admin-managed.
Quarterly governance review
Every quarter, conduct a governance review of your workspace:
Blueprint audit
- Go to Workspace Settings → Blueprints → view all blueprints.
- For each blueprint, check:
- Is the owner still active in the project?
- Is there an edition created for the current period?
- Are there stale editions in Draft status older than 30 days?
- Is the blueprint still needed, or should it be archived?
Edition health check
- Review all editions in Submitted status older than 14 days — these are stuck awaiting review. Contact the reviewer.
- Review all editions in Changes requested status older than 7 days — these are awaiting contributor action. Contact the contributor.
- Review editions with high warning counts — these were submitted with validation warnings that were never addressed. Add comments requesting correction in the next cycle.
Access review
- Go to Project Settings → Team for each project.
- Remove members who have left the project or organisation.
- Confirm contributor and reviewer assignments match the current team structure.
- Update blueprint ownership where the previous owner has departed.
Responsibility matrix
| Activity | Blueprint Owner | Contributor | Reviewer | Workspace Admin |
|---|---|---|---|---|
| Create / modify blueprint | R / A | — | C | — |
| Publish new blueprint version | A | — | C | — |
| Create edition | R | — | — | — |
| Enter data | — | R | — | — |
| Submit edition | — | R | — | — |
| Raise review comments | — | — | R | — |
| Approve / request changes | — | — | R / A | — |
| Generate and publish output | R | — | — | — |
| Archive blueprint | A | — | — | I |
| Manage workspace settings | — | — | — | R / A |
| Quarterly governance review | C | — | — | R / A |
R = Responsible, A = Accountable, C = Consulted, I = Informed
Version approval gates
When a blueprint owner wants to change a blueprint that has active editions:
- Minor change (field label, help text, option label): Can publish immediately. Active editions are unaffected.
- Moderate change (add/remove non-required field, add section): Notify active contributors. Publish when no edition is in Submitted or In review status.
- Major change (add required field, restructure sections, remove section): Create a new blueprint version. Close all active editions on the current version before activating the new one.
Removing a required field or section from a blueprint while editions are In review can cause confusion — reviewers are evaluating data against the old structure. Always coordinate major changes with the current edition cycle.
What's next
- Blueprint Governance — blueprint change control and decommissioning
- Team Roles — role assignment and escalation paths
- Blueprint Versioning — managing version history and change impact
- Notification Management — configuring reporting cycle notifications