Process Standardization Lifecycle

Part of the Planning Week chain · previous: Process Shells for a Workforce Standard · next: Enterprise Interconnection Plan Process Standardization Lifecycle is the method by which a workforce function turns a process it runs into a process it has written down, approved, deployed and kept current: three phases (create · implement · sustain), seven steps and one return loop. It matters because a function assembled from several heritages cannot automate, compare or hand over work it has not specified, and because a process document with no lifecycle drifts from the work inside a year or two [A]. The lifecycle fills the shells of Process Shells for a Workforce Standard into the sections of Anatomy of a ROC Standard, and it is where highly specified is defined once for the chain. The page produces the lifecycle status row and the gate checklist that fill the lifecycle status and controls fields of the process L0 card (T4), and is worked in a session with Wiki:Packs/Process Decomposition (CP-OPS-001 v1.1) and with CP-OPS-003 ROC Standard Authoring once that pack is live.

The lifecycle in one table

The lifecycle assumes the documentation standard of Process Decomposition (L0–L3), an L0 cover sheet, a one-page L1 flow, a fifteen-column L2 step table and an L3 register of job aids; L0–L3 on this page means those documentation levels. Every step has an exit condition and a route, so the flow can be run end to end.

Phase	Step	What happens	Exit condition	Routes to	Who
Create	1.1 Identify and prioritize	A request is screened on importance and volume; the catalog is checked; the request is classed new or modify, a modify as major or minor	High on either parameter, not already cataloged (or a major modify), approved	Pass → 1.2 · minor modify → light edit, then 3.2 · fail → the deferred log with a review date	The standards committee; the function's leader approves a new package
Create	1.2 Author	Owners scheduled; a mapping workshop bundles like cases; the package is written to L0–L3; the author self-reviews	No further modification declared	→ 1.3	The process owner; the seats named on the L0
Create	1.3 Peer review	The reviewers named on the L0 review; a major finding adds a fixed penalty and loops; a minor one is applied in place	Closed with no open major finding	Major → 1.2 · closed → 2.1	The named peer reviewers
Implement	2.1 Sign off (the acceptance gate)	The approvers test the package against six criteria and return one of three responses inside a fixed turnaround	Approved, or conditionally approved with each condition owned and dated	Approved → 2.2 · conditional → 2.2 with the condition on the card · not approved → 1.2 with reasons	The approvers named on the L0; for a function's standard, its council
Implement	2.2 Deploy in two tracks	The package is baselined; the people track (training, desk reference) and the machine track (specification → build → acceptance test) run in parallel; soft launch; go/no-go	Live: people track trained; acceptance test passed or explicitly not started; the go recorded	→ 3.1 · no-go → 1.2 with the finding	Training; the automation analyst; the process owner
Sustain	3.1 Outcome and process review	The catch rate where a step is automated, and the odd cases the L2 did not cover; specification and step table revised together	Reviewed on cadence; every odd case absorbed or logged out of scope	Revision → 1.2 (the return loop) · none → 3.2	The overseer where automated; the process owner
Sustain	3.2 Compliance, remediation and expiry	Conformance checked against the maturity ladder on the standard's validation cadence; every package carries an expiry	Certified at a level, or remediation owned and dated	Expired → 1.1 as a modify request · certified → hold	The standard's validation owner

The return loop from 3.1 to 1.2 is the part most programs name and do not build; it is the only mechanism by which work-as-done corrects work-as-written, and without it a standard is accurate on the day it is signed and fictional soon after.

The acceptance gate

Step 2.1 is a gate in the literal sense: a package that does not pass it is not deployed, trained, built or cited as the standard. It is a different object from the agentic handover gate, and the distinction is load-bearing across the chain: the acceptance gate admits a document; the handover gate admits an agent. The handover gate's first test, documented, asks for a step table and work instructions to the L0–L3 standard; this chain reads that test as satisfied only by a package that has passed the acceptance gate, since an unapproved package has no owner who has agreed to defend it. Its other four tests are run afterward, on the process the document describes.

#	Criterion	The question each approver answers yes or no
1	Accurate	Does the package describe the process as it is meant to run, with no step the owner disowns?
2	Logical sequence	Can the L1 be walked start to end with every decision routed and every loop closed?
3	Clear and concise	Can the L1 be read in thirty seconds; does the L2 narrative column carry the how?
4	Active voice	Is every L2 row an instruction that names the act, not a description of a state?
5	Clear step ownership	Does every L1 step and L2 row carry exactly one owner, as a seat, none inherited by default?
6	Comprehensive	Are the job aids the L2 names present in the L3 register, with thresholds, screenshots and named systems kept at L3?

Three responses are possible: approved; conditionally approved, each condition an item with an owner and a date carried on the L0 card until closed; not approved, with reasons that route the package back to authoring. The turnaround is fixed and short, five business days in practice [E]. Approval is also a commitment: to drive adoption, to accept audit at step 3.2, and to release the package to training and to build.

Criteria 4 and 5 are in bold because they are the entry test for automation: an L2 row in the passive voice, or owned by nobody in particular, cannot be read by an automation analyst into a specification, whatever else it is. The observation is inferred from practice, not measured, and it is why the two criteria sit on the gate rather than in a later automation review. The rule that work be specified as to content, sequence, timing and outcome, so that a deviation is visible as it occurs, is the first of the four rules Spear and Bowen drew from the production system they studied.

"Highly specified," defined once

The chain uses one term for the property the gate confers, defined on this page only:

A process is highly specified when its resolution path is written to L2 before the interaction starts, its L2 has passed the acceptance gate, and its step-ownership and active-voice criteria are met without exception.

The three parts are deliberate: "before the interaction starts" excludes work whose path is discovered during the interaction; "passed the acceptance gate" makes the property a matter of record; "without exception" excludes an L2 that is mostly owned and mostly active, because an automation built on it breaks at the rows that are not.

The term is used in three places with this one meaning: as the entry condition for automation (only a highly specified step enters the machine track of step 2.2 or reaches the handover gate; Standardize Before You Automate); as the threshold for where oversight of supplied work may sit (Specification and the Placement of Vendor Oversight places the learn-the-business threshold at the edge of scripted work, so only highly specified back-office work is overseen from a shared-service team, while the commercial functions stay there at every point); and as the test a body of work passes before it is a candidate for a service-center node. Pages that need the term cite this one; none redefines it.

The committee and the queue

The catalog check at step 1.1 needs one body that knows the whole catalog, or two teams document the same process under different names; that body is the standards committee, and Process Shells for a Workforce Standard carries its composition, its first sitting and the queue it ranks. Its part in the lifecycle is three things: the intake of requests, the queue (the shells sorted by wave rank) and the deferred log; it does not author, the process owner named on each L0 does. A process-standard request arrives through the single intake door specified on Enterprise Interconnection Plan, whose six fields are the ones The Question Register and Knowledge Base specifies; it is classed on that plan's process-standard route and lands in the queue rather than on the executive register.

Deploy in two tracks and the return loop

Step 2.2 runs two tracks from one baseline: the people track turns the package into training and a desk reference; the machine track turns its highly specified steps into a specification, builds them, and runs an acceptance test against the L2's definition of done before anything touches live work. A step that fails the test stays on the people track.

Step 3.1 reads the catch rate where a step is automated, as The Agent Overseer defines it, and the odd cases where it is not: the interactions the L2 did not cover and a person resolved by judgment, each of which becomes an L2 row or is logged out of scope with the reason. The rule that keeps document and automation together is that the specification and the step table are revised together: neither changes without the other. That is the odd-case loop, the return arrow in the figure.

Step 3.2 is why every package carries an expiration date: conformance is checked on the standard's validation cadence against the maturity ladder, and an expired package is a visible fact on the catalog that re-enters at 1.1. The quality-management tradition treats the currency of documented information as a requirement, and this step is that requirement made operational. The lifecycle is not a continuous-improvement method: kaizen and value-stream work (Lean and Continuous Improvement Applied to WFM Processes) change what a process does and then enter at 1.1 as a modify request; this page governs custody of the document.

Worked example

The function of the chain's worked example adopted the lifecycle and chartered its committee on Day 2 afternoon of its planning week (Tue 21 Apr 2026, D-06) and defined "highly specified" immediately after (D-07), since the definition rests on the gate; the committee first sat on Wed 29 Apr 2026. Request RQ-001, for P-001 short-term forecast build and lock, passed the screen (importance high, volume daily), found no existing package, and was approved and scheduled that day, honoring the room's constraint since P-001 is the first agent team's process.

The mapping workshop ran Wed 6 May 2026; the package was written to L0–L3 by Mon 11 May [E]. Peer review opened Wed 13 May and raised one major finding on Fri 15 May, L1 step 10 having no owner when the planner is absent; the finding added five days [E], the deputy planner seat was named, and the review closed Fri 22 May. Sign-off, submitted the same day, returned conditionally approved on Fri 29 May 2026, five business days later [M], the date taken from the gate record, with one condition: the decomposition-method job aid named at L2 row 2.2 must exist in the L3 register before the machine track's acceptance test, the acceptance test being scheduled after the build, on Mon 15 Jun 2026; owner the process owner, date Fri 12 Jun 2026.

Both tracks ran from Mon 1 Jun 2026: the people track trained the book's two planners that week; the machine track built against the approved L2 on the book whose planning-loop team was already at the pilot rung, with the planner gate on every run (The Agent Team Ladder: Alpha to Production). The first odd case reached step 3.1 on Fri 12 Jun 2026, a client-driven volume shift the L2 routed nowhere; it became L2 row 4.3 and the scout's specification was revised in the same change. The package expires with the standard, Fri 30 Apr 2027. Releasing any class of action to run without a signature was left undated, waiting on a published catch rate for that class rather than on a date. Request to approval took 30 calendar days [C] against a nominal 20 [E].

The artifact this page produces

The lifecycle status row, one per process, written into the lifecycle status and controls fields of the process L0 card (T4) of Process Shells for a Workforce Standard; and the gate checklist, one per gate sitting. One filled example row:

ID	Process	Step reached	Gate response	Conditions open	Date	Next step and date	Owner (seat)
P-001	Short-term forecast build and lock	3.1 outcome and process review	Conditionally approved (2.1, Fri 29 May 2026)	none; JA-05 closed Fri 12 Jun 2026	Fri 12 Jun 2026	3.2 with the standard's validation, before Fri 30 Apr 2027	the process owner (the book's planning seat)

Produced in a working session with Wiki:Packs/Process Decomposition (CP-OPS-001 v1.1; its process-shell.md block carries the status vocabulary); the filled set is part of blueprint v0.1.

What would change this

The page's central claim is that active voice and clear step ownership are the entry test for automation: a package that passes the gate on those two is buildable and one that fails them is not. The observation that would overturn it is a machine-track build that runs at a published catch rate from an L2 that met neither criterion, or a run of packages that passed both and could not be specified for reasons the other four criteria did not catch; either would move the entry test off the gate, and "highly specified" would lose its third clause.

How this connects

• Previous in the chain: Process Shells for a Workforce Standard — the shells that are this lifecycle's queue
• Next in the chain: Enterprise Interconnection Plan — the intake door a process-standard request arrives through
• Defers to: Process Decomposition (L0–L3) (the four artifacts, the fifteen columns) · The Agentic Handover Gate (the five tests an agent passes after this gate) · Lean and Continuous Improvement Applied to WFM Processes (improvement of the work) · Specification and the Placement of Vendor Oversight (the threshold) · Anatomy of a ROC Standard (the document each package becomes a section of) · Expanding Intraday Automation and The Agent Team Ladder: Alpha to Production (they cite the definition)

Maturity Model Position

The lifecycle is Level 2 work by intent, since Level 2 is the level whose apparatus is dedicated planning roles and standardized, documented processes; steps 2.2 (the machine track) and 3.1 (the catch rate) carry a function into Level 3, where the return loop runs on the catch rate rather than on complaint; at Level 4 and above the L2 tables become machine-readable inputs to process automation and conformance checking (Process Decomposition (L0–L3)). Where a class of action is released to run without a signature, the condition is the single sentence on Human Gates and Number Grades — a published catch rate for that class, not a level — and the wiki's level pages state it alike. Four scales on this wiki use the word level; the launch page states which is which.

See Also

• Planning Week for a Workforce Function
• Process Shells for a Workforce Standard
• Anatomy of a ROC Standard
• Process Decomposition (L0–L3)
• The Agentic Handover Gate
• Standardize Before You Automate
• The Automation Analyst
• The Agent Overseer
• Executive Issue Register