v1
A vendor-neutral standard · running live in three public deployments

Project status is a build artifact.

Charters, requirements, and risk registers live in Git as plain files. Every change is tested and gated before it merges, and the pipeline compiles the documents into status, roadmaps, and dashboards. Nobody types a status anywhere.

It takes the Infrastructure-as-Code / GitOps playbook and points it at the PMO.

The problem it answers

The reporting is stale and the reasoning is lost.

Today's PMO runs on PowerPoint, Excel, SharePoint, and email. Nothing is authoritative, and nobody records why decisions were made.

Stale artifacts
A deck is out of date the moment it's shared.
RAG fiction
Red, amber, and green are whatever the PM reports.
Unauditable governance
Approval is an email in an inbox no one can audit.
An army of PMs
It takes a team just to keep the decks current.
1Principles

The five defaults.

Declarative sources of truthoverhand-maintained artifacts
Automation and auditovergates and approvals
Traceabilityoverdense documentation
Derived statusoverself-reported status
Composable definitionsoverone-off, siloed tools

The right-hand column is not banned. It is the exception, and exceptions get documented.

Read the principles
Validation

Declared, then checked.

You author the document; the pipeline checks its fields, sections, and requirement links on every change. Watch it run:

documents/PRJ-001-AUR/charter.md
---
kind: charter
project: PRJ-001-AUR
id: AUR-charter
status: approved
---
## Objective
Cut onboarding from 14 days to under 2.
## Success Criteria
- Onboarding p50 below 48 hours.
docassert validate
All checks passed
frontmatter-schema · valid, all required sections present
measurable-success-criteria · every criterion states a threshold
risks-have-owner-and-mitigation · every risk names both
clear to merge

The checks decide what counts as done, the same way every time, and the same checks run for real in CI.

Traceability

Follow the thread: why does this test exist?

The links carry the value. Documents stay thin and richly connected, so any test walks back to the business reason it exists.

Test CaseAUR-TC-001
Complete the self-serve wizard → account active, zero support tickets.
↑ tests
Acceptance CriterionAUR-AC-001
A new customer completes setup with no support ticket created.
↑ verifies
Product RequirementAUR-PR-014
The product shall provide a self-serve onboarding flow.
↑ traces to
Business RequirementAUR-BR-001
Reduce median customer onboarding time to under 2 days.
↑ which serves
Charterobjective
Cut customer onboarding from 14 days to 2.

Five hops, no slide-hunting. The pipeline generates this walk from the links; it is the same graph behind the traceability matrix. (Aurora is the fictional sample project used in examples across this site; its people are invented. The deployments below are real.)

From one document to a portfolio

Every project has a unique ID and its own live page.

Each project carries a stable identity, PRJ-001-AUR, that namespaces its documents (documents/PRJ-001-AUR/) and its items (AUR-BR-001). Nothing collides, and every item says which project it belongs to. The pipeline compiles all of it into a portfolio dashboard with a page per project. Each page opens on a verdict sentence built from that project's recorded causes, then shows its milestones, its risk matrix, and its features charted by dependency order and scope size. Hover any number and a tooltip explains where it came from.

portfolio dashboard · illustrated● AMBER
AUR
Aurora — Customer Onboarding
PRJ-001-AUR · 20 docs · 2 open risks
AMBER
ATL
Atlas — Partner Portal
PRJ-002-ATL · 5 docs · fully traced
GREEN
PHX
Phoenix — Support Response
PRJ-004-PHX · charter · project
GREEN

Each RAG is computed from that project's own documents, using coverage, open risks, and failing audits. The panel above shows the format; the live dashboard has today's states. See the live dashboard →

Live proof

The method is running in public right now.

This site is ordinary hand-written web pages. The pipeline it describes runs in public, in three deployments that regenerate their dashboards and badges from their documents on every push. The meta-portfolio is PMO as Code governing its own development, Refuge for Humans is a real product spec converted from a Word BRD, and Aurora is the reference portfolio of disclosed-fiction samples.

The meta-portfolio live derived status
The portfolio that builds PMO as Code, run as PMO as Code: five real projects, every gate binding, ambers published. How it governs itself.
Reference portfolio live derived status
Four sample projects, the gate on every pull request, a published traceability matrix. The badge above is the live derived status.
Refuge for Humans live derived status
A real 14-section BRD converted faithfully, with its gaps on display. The case study covers what the audit found.