What is built
Everything in the product, with an honest mark against it.
41 things work, 8 work but are still rough, and 8 are not built at all — that last group is named at the bottom of this page rather than left out of it. The marks below are the ones the internal inventory carries.
- works verified in the running product
- rough edges shipped, but the edges show
- not built absent — say so, and say why
01 · The charter model
A structure your five functions recognise on sight.
A new charter is not an empty page. It starts as a working operating model — departments, the handoffs between them with criteria and SLAs, the lifecycle stages with gate owners — and every metric in the product hangs off that structure.
Rename a stage, add a department, delete a handoff: the metrics regenerate, the document renumbers, and the signatures that were pinned to the old wording say so.
From the document · § 4 handoffs
| Handoff | Acceptance criteria | SLA |
|---|---|---|
| Marketing → Sales | Named buyer, stated need, budget signal | 2 days |
| Sales → Delivery | Countersigned order, scope agreed in writing | 5 days |
| Delivery → Customer Success | Go-live confirmed, success plan owned | 10 days |
Both sides of every handoff sign it — that is who the required signers are derived from.
Multi-charter workspaceworks
Create, list and delete charters in one workspace; deletion asks first, because a charter is an agreement.
One-click demo charterworks
Twelve months of sample data whose funnel math reconciles, two campaigns, prediction history and a v1 snapshot.
A seeded operating modelworks
Five departments, four handoffs with criteria, SLAs and joint owners, and seven lifecycle stages with gate owners, from day one.
Metrics that follow the stagesworks
Volume, conversion and time metrics are generated per stage, and re-key themselves when the stages change.
Custom lifecycle stagesworks
Add, rename, reorder or delete a stage; the metric set regenerates around whatever shape your lifecycle actually has.
Custom departments and handoffsworks
A handoff's flow picks from the departments that exist, so it can never point at a function you do not have.
Members and department leadsworks
A department's lead is picked from its members, so a signature lands on a name rather than a role string.
Offerings libraryworks
What you sell — nature, AOV and ACV, margin, description and talk track — versioned into the document with redlines.
Named lifecyclesworks
Stages group into a deal lifecycle and a customer lifecycle, shown as group bands in the published document.
Audience definitionsrough edges
Target ICP, buying groups and personas, versioned into the document with redlines. The editing still feels unfinished.
Evaluation and modeling policyrough edges
Charter-level cohort-evaluation and modeling-metric declarations, edited in a drawer and rendered as a document section.
02 · Governance & signatures
Agreement you can prove, months after the meeting.
Each function signs only what binds it, against a hash of the exact wording. The charter-wide alignment score is simply what share of those signatures are still current — and the ratify banner says, in words, what is missing.
Versions are computed by diffing snapshots, and any two of them can be redlined against each other, on screen or on paper.
From the document · § 11 sign-offs & ratification
| Handoffs | 8 of 8 definitions | AKDRPNSOMT |
| Metrics | 11 of 14 definitions | AKDRPNCSMT |
| Top-level goals | 5 of 5 definitions | AKDRPNSOMT |
| Offerings | 3 of 5 definitions | AKDRPNFD |
Ratification is blocked while anything on this list is open — and the banner names the function that has to move.
Per-definition approvalsworks
Who must sign is derived from structure: a handoff needs both sides, a stage its gate owners, the goals section every department.
Content-hash pinningworks
A signature is bound to a hash of the wording approved. Edit a signed definition and it is marked stale.
Sign-off progress and ratify-readinessworks
Per-section progress plus a charter-wide banner saying whether it can be ratified, and what is missing if not.
Versionsworks
Labelled, immutable snapshots of every definition; the version number is computed by diffing snapshots, never chosen by hand.
Tracked-changes redlinesworks
The document redlines itself against any earlier version — struck-out wording, underlined replacements.
Print stylesheetworks
A first-class surface, not an afterthought: page breaks controlled, redlines legible in grayscale, chrome removed.
ProseMirror JSON exportworks
The charter as structured TipTap/ProseMirror JSON, for anything that wants the document itself.
Decisions ledgerrough edges
One chronological record of versions cut, sign-offs and campaign charters, rendered as a document section.
Audience sign-offsrough edges
The owning function signs each ICP, buying group and persona; it goes stale on edit and counts toward the score.
Section include / excluderough edges
Sidebar checkboxes choose which sections the charter carries; contents and numbering recompute behind them.
Public share linkrough edges
A revocable, unguessable URL renders the charter read-only, with no login and no indexing.
Word exportrough edges
The published charter downloads as a real .docx honouring your section choices; PDF comes from the print stylesheet.
03 · Contracts & goals
A revenue number that knows how revenue is recognised.
“$1.2m by December” means something different if the contract is ratable over twelve months than if it lands on booking. The charter carries the recognition policy, each offering may override it, and the goal’s arithmetic follows.
From one dated goal the product derives the contribution rate, the last month a contract can be booked at full value, the bookings required, the deal count at your average deal value, and the date those deals must enter the pipeline.
From the document · § 6 offerings, contract terms
| Offering | Term | Renewal | Recognition |
|---|---|---|---|
| Platform subscription | 12 mo | 86% | ratable over the term |
| Implementation | — | — | on delivery |
| Usage overage | — | — | on booking |
These three lines are why the same $1.2m goal produces three different booking deadlines.
Revenue-recognition policyworks
Charter-level: on booking, ratable over the term, or on delivery, rendered inside the signed goals table with your billing terms.
Per-offering contract termsworks
Term months, renewal rate, recognition and billing overrides, the stages it transacts at, and its cross- and up-sell edges.
Dated goalsworks
Recognized revenue by date, TCV or ACV, linked to campaign targets; the goal inventory is a tree with pace-banded coverage.
Derivation mathworks
Contribution rate, booking deadline, required bookings, deal count and lead time — derived under every goal, 49 assertions.
04 · Campaigns
A goal is a claim somebody made on purpose.
This intervention, this window, this metric, this owner. Campaigns are the only way a goal enters the system — not by convention, but because the write path refuses anything else — and the charter’s goal inventory is their roll-up.
Campaign objectsworks
A window, an owner, a status, a hypothesis, the intervention and a budget — what makes a number somebody's.
Non-linear rampsworks
A target ramps linear, front-loaded, back-loaded, S-curve or step, so pace is judged against the plan you actually made.
Goals derive liveworks
No stored copies: striated goal rows per campaign, the most ambitious effective goal on the charts, per-target attainment.
Goals only through campaignsworks
Enforced at the write path, not by convention. There is no code path that writes a goal without a campaign target behind it.
05 · Measurement
Four series, and none of them can be quietly revised.
Actuals as entered, a baseline computed from each metric’s declared basis, the goal line ramped out of campaign targets, and a forecast frozen before the month it predicts — then scored against what happened.
The chart on the right is the component the app renders, fed sample numbers. Hover any month for its exact values; every series is labelled at its right end rather than in a detached legend.
Monthly actuals gridworks
A rolling twelve months of history beside a twelve-month plan zone; future-month actuals are refused server-side.
Typed metric definitionsworks
Owner department and basis — MoM, QoQ, YoY or rolling 3, 6 or 12 months. The basis is what drives the computed baseline.
Selectable forecast methodsworks
Linear trend, growth rate, three- or six-month average, or last value — chosen per metric.
Self-explaining forecastsworks
Each forecast shows its arithmetic in your own numbers, so no figure reaches a slide nobody can derive.
Forecast horizonworks
Month, quarter, six months or year, aggregated by metric family: volumes sum, rates and times average.
Prediction ledgerworks
On the first data save of each month, next month's forecast and goal are frozen immutably.
Prediction scoreboardworks
Frozen forecast against actual as a signed error, goal against actual as attainment — kept whether it flatters us or not.
Model backtestingworks
Every method is walk-forward tested against your own history, and the most accurate one is flagged.
The overview surfaceworks
Revenue chart, KPI stats, an all-metric glance table, and a funnel that reads stacked or one lens at a time.
Funnel math that reconcilesworks
Derived bookings — stage-four volume at average deal value — checked against entered revenue, and each point of conversion priced.
Per-metric detail chartsworks
Every sparkline in the grid expands into its own full chart in place, without leaving the grid.
06 · The platform
Everything the screen can do, a token can do too.
A bearer-token REST API covers charters, metric definitions, bulk time-series and campaigns, plus the computed report — the same numbers, from the same code, that the overview draws.
The MCP server puts those nine operations inside a chat, so recording a month of actuals or opening a campaign never needs the UI at all. Both paths run the same code as the screen, which is the only way the numbers can be guaranteed to agree.
The nine MCP tools, verbatim
- list_charters
- get_charter
- create_charter
- get_report
- get_data
- record_data
- update_metric
- list_campaigns
- create_campaign
The computed report, over HTTP
$ curl -H "Authorization: Bearer $TOKEN" \
https://…/v1/charters/{id}/report
{
"charter": { "name": "Go-to-market charter" },
"months": ["2025-10", …, "2026-09"],
"revenue": {
"latest": 70559,
"baseline": 48764,
"forecastTotal": 229077,
"explanation": "linear trend, 12 mo …"
},
"metrics": [
{ "key": "C2", "basis": "Rolling 6-mo", … }
]
}Every forecast comes back with the sentence that explains it.
REST API v1works
Bearer-token access to charters, metric definitions, bulk time-series, campaigns and the computed report.
MCP serverworks
Nine tools, so a Claude chat can list charters, read a report, record a month of actuals or open a campaign.
Real multi-tenant authworks
Database-backed users with scrypt hashing, signup creates a workspace, and cross-tenant access returns a 404.
Design systemworks
Grouping before shape before line: a semantic token layer, Inter with tabular numerals, an accessible Select everywhere.
Mobileworks
Every surface fits a 390px viewport; document tables become stacked records, not a sideways scroll.
Deploy and accessibilityworks
Vercel and Neon, page tours, labelled inputs, table semantics, AA contrast and described SVGs.
Database-level tenancyrough edges
App-level tenant scoping is live and verified; row-level security and a dedicated database are still pending.
Not built
8 things this product does not do.
None of these exist today, and none of them are hidden behind a “coming soon”. Two of them are being worked on now; the rest are candidates, not commitments — the roadmap says which is which.
CRM syncnot built
Every number is entered by hand today. The CRM-binding fields exist on stages and bind to nothing.
Custom metricsnot built
Metrics exist only as stage-derived volume, conversion and time. A metric that is not a funnel stage cannot be tracked at all.
Signature revocation historynot built
The audit log records signatures but not their withdrawal — revoking deletes the row, so a voided signature leaves no trace.
Sub-monthly granularitynot built
Weekly and daily reporting need CRM event data to mean anything.
Notifications and review remindersnot built
Review cadence is prose in the document, not a timestamp, so nothing can fire off it.
Product / line-of-business segmentationnot built
Actuals are not split by product line, and ACV is not held per offering for segmentation.
Revenue calculatornot built
Parked: the route redirects to the report. An offerings-based scenario model is a candidate, not a commitment.
Blog and changelognot built
Scaffolded only. It stays unlaunched until there is something worth reading on it.