A process you can point at
Most teams have a process in a wiki that nobody reads and nothing enforces. The Standard is published, versioned and pinned — and the agent doing the work reads it before every plan.
Two documents: the loop, and the agents
The loop is how a task moves from a plan to a landed change: the gates, the reviews, the hand-off, the recovery procedures. The agents document is who does what, and what each role may write. Together they are the process, written down once.
A published version never changes
Once a version is published it is frozen, and a revision to it is written once. So when a plan cites the process it followed, that citation still means the same thing a year later — which is the whole reason to have a version at all.
Your product pins one
A product names the version it follows. Moving the pin is a deliberate act by a person, not a background upgrade, so a change in process never arrives in the middle of somebody’s work.
Extension points are where your team differs
The Standard says every phase ends green; it does not say what your gate command is. Each extension point is filled per product — the gate, the environment, the branch and worktree naming, the registration ledgers, what landing means, what shipping means — so the shared process fits a repository without being rewritten for it.
The feature-plan process
A plan is drafted against the pinned revision, then adversarially reviewed before anyone builds it: the measured rate is three to eight factually wrong premises per plan, in plans that read as finished. A plan nobody has tried to destroy is not ready, and its status says so.
Coming: a library a firm forks
A platform-owned library of Standard versions a firm can fork and make its own is planned, so a team can start from a process that already works rather than writing one. It does not exist yet.