PortfolioPlane

Proof, not status.

Portfolio delivery for the agentic era

Run the portfolio from strategy to proof.

Objectives, projects, requirements, code and evidence in one governed workspace. Trace every requirement to the source that resolves it and the test evidence recorded against it; agents do the legwork, named people sign the gates, and every count carries its denominator.

Already onboarded? Sign in — or your organization’s own entrance at /portal/your-workspace.

The organization it assumes

Built for the team you’re becoming, not the one you had.

  • The delivery team is getting smaller.

    Gartner predicts 60% of organizations will run smaller software engineering teams at scale by 2029, up from 15% in 2026. Gartner, 2026 (opens in a new tab)

  • Fewer people write the code. Someone still signs every gate.

    BCG Platinion describes software factories run by “as few as three engineers,” where humans no longer write code and “every stage gate has a human accountable for approval.” BCG Platinion, 2026 (opens in a new tab)

  • Portfolio governance does not thin with the team. It becomes load-bearing.

    Forrester now calls strategic portfolio management “one of the most critical capabilities for enterprises navigating constant disruption.” Forrester, 2026 (opens in a new tab)

Every other portfolio tool instruments the delivery organization you are dismantling. This one instruments the one you are building — fewer people, more agents, and a governance layer that can prove who accepted what.

01 How it reads

Three moments, drawn by the product itself.

The panels below are the product’s own markup on the product’s own tokens, not screenshots. The organization and the figures in them are invented, and each frame says so in its own chrome. The columns, the vocabulary and the ladder are exactly what a delivery lead opens on Monday.

The register

Counts that carry their denominators.

Every requirement holds its place on the binding ladder — mapped, resolved, verified — and every figure states what it is out of. Nothing is blended into a score, so there is nothing on this screen a steering committee cannot check.

Example Health Plan · RequirementsSpecimen · invented data

42 requirements42 / 42 mapped31 / 42 resolved6 / 42 verified

  • AE-01Applicant identity is proofed before an application is accepted test-executed · passed
  • AE-04An eligibility determination records the rule version that produced it file-resolved + proposed
  • PM-09Retention of enrollment evidence follows the published schedule unbound · claim without evidence
Three of forty-two rows, checked against a1c4f80b — one pinned commit, never “the repo”. Every figure is invented; every column is real.

The acceptance queue

Agents propose. A named person accepts.

An agent reads the estate and proposes bindings; the proposals wait until a person at publishing grade signs them. The column recording who accepted is a foreign key into the authentication system’s user table — an agent has no row there and cannot acquire one.

Example Health Plan · ProposalsSpecimen · invented data

PM-08 binds to refund.spec.ts · test-executed · passed

Proposed by Reconciliation agent · held for a named person

AE-01 accepted by M. Alvarez — written to the append-only trail

Accept is reserved to a person at publishing grade. An agent cannot occupy that column — the constraint is in the database, not in a style guide.

The deck

The quarterly review is generated, not typed.

The deck reads from the register at its pinned commit, so a slide cannot drift from the evidence behind it. Change the register and the next deck changes with it — nobody retypes a number the night before the meeting.

Example Health Plan · PresentSpecimen · invented data

Quarterly portfolio review

Enrollment modernization — where it stands

31 / 42resolved6 / 42verified

Read from the register at a1c4f80b12

The deck reads from the register at its pinned commit; no figure on a slide is typed by hand. Change the register and the next deck changes with it.

02 Doctrine

What this product refuses to say.

Dashboards fail in one direction: they say more than anyone checked. The refusals below are constraints in the schema and the design system, not lines in a style guide — there is no setting that turns any of them off.

No blended health score.
Nothing averages 119 separate truths into one number. A defensible 98 of 119 beats an indefensible 87% — the second can only ever be repeated, never checked.
No traffic-light verdicts.
Status is a count against a denominator, and a word beside a shape. A cell that turns green is a judgement someone should have signed; here the signature is the record, and no color ever appears without the word it rides on.
No unattributed claims.
Every acceptance is a named person, stamped by the database from the session — never sent by the client, never a service account, never an agent. The trail that records it is append-only for everyone.
No figure without its denominator.
“98 resolved” is not a fact until it says out of what, and as of which commit. The denominator and the pin travel with the number through every view, every export and every slide.

03 Instead of a logo wall

No customer logos. Claims you can test instead.

Nobody has agreed to appear on a logo wall, so this page does not have one. What it has is what the platform enforces in the database — where a policy cannot be stepped around by a clever URL.

Tenancy is forced in the database.
Row Level Security on every tenant table — a policy, not an application filter. It is proved three ways: impersonated inside Postgres, through a real signed-in session, and over HTTP through the app — and every proof greps the entire response body for strings that exist only in the other tenant’s rows. npm run prove:isolation
The trail refuses deletion.
The governance trail is append-only for everyone — owners included, the database superuser included. That was established by attempting the delete and being refused, which is the only way anyone can know it.
Releases go out gate-green.
The design law, the tenancy proofs and the type checks are executable tests that fail the build — not review notes. A release that has not passed the gate does not ship.

Point it at a register and a commit.

Import the register you already keep, pin the commit you want it checked against, and read the counts that come back. The first pass usually reports fewer verified requirements than anyone expects. That number is the product working.

Running a wider estate? Talk to us — priced per estate.

What it reads
The register, specification or agent instruction file you already have. Nobody rewrites requirements into our format.
What it needs
One repository and one 40-hex commit. Every citation is resolved in that tree and nowhere else.
What it returns
Counts with denominators, findings in six named classes, and a Standing column that never merges with them.