The Product Design Manifesto is in the repo, and it is the bar
Release notes 2026-09-15 — docs/MANIFESTO.md (vocion-core#322, merged): seventeen principles, the loop Outcome → Work → Measure → Learn → Improve → Automate, the Outcome Contract every agent should carry, and a twelve-question test a change must pass before it ships.
Shipped: vocion-core#322, merged to main on 2026-09-15 — docs/MANIFESTO.md. Part of the 2026-09-15 release notes.
Why a document is a release
Because the rest of this release was built to it, and every future change will be judged by it. It is linked from the README, from the docs index, and from the repo's CLAUDE.md so that a coding agent working in the tree reads it before proposing product surface.
What it says, in one paragraph
Powerful systems should feel simple. Complexity belongs in the platform, not the experience. Work should roll up to an outcome — revenue, cost, time, risk, quality — and if it matters it should be measured. Every agent has an owner, a purpose, a scope, metrics, standards, escalation rules and permission boundaries. Simple beats flexible. Every interaction — an approval, a correction, a rejection, an override — should make the system smarter, and automation is earned rung by rung: observe, recommend, assist, execute with approval, execute within bounds, operate autonomously. Hide complexity; never hide truth.
The two artefacts a builder uses
The Outcome Contract. Purpose · Owner · KPI · Baseline · Target · Permissions · Quality threshold · Escalation policy · Current performance · Autonomy level. Where the platform already carries these — an agent's description and its team's goal, accountableUser, team kpis, approvalPolicy and trust.yaml, a mission's autonomyPolicy.level — the document names the field. Where it does not, it names the next thing to build. The team report in this release is the first surface that presents one.
The test. Twelve questions, asked before anything ships: what outcome does this improve; can we measure whether it worked; who is accountable; can this be simpler; does the user know what to do next; did this interaction teach the system something; will repeated use reduce human effort; can the system safely become more capable because of it; does this improve the business or the person doing the work; is complexity hidden without hiding the truth; does this feel good to use; would we be proud to use this every day. If we cannot answer them, it is not finished.
How it shows in this release
The Needs-you inbox answers what needs me, what changed, what happens next in its header and has one recommended action per question. The daily team report is ordered what changed → what needs me → are we on track → what happens next, with tokens last. Decisions become learning candidates because every correction is information. The model upgrade test reports cost per completed job, not price per token.
Changes to the document are product decisions: propose them as a pull request and say which principle you are changing and why.
Where this lives in the repo
- The document:
docs/MANIFESTO.md - Where it is pointed to:
README.md,docs/README.md,CLAUDE.md("Product design manifesto — read before any product decision") - PR: #322