Knowledge Lifecycle & Governance Framework
A governance framework for a 9-person knowledge team whose entire publication pipeline depends on SME reviewers who owe the team no formal time. The design followed a duplicated article and two confused new hires, which showed that ownership existed as suggestion, not control.
Nine controlled statuses, each with one named owner, observable entry and exit criteria, and required evidence. Endorsed by the Team Lead; partially implemented, with full rollout targeted for Q1 2027.
| Role | Knowledge Management Analyst, self-initiated |
|---|---|
| Context | 9-person knowledge team: 5 analysts in one regional pod, 4 internal counterparts, enterprise tax compliance software |
| Timeline | Designed late July 2026, after pipeline and measurement work exposed the gaps |
| Status | Endorsed by Team Lead. Partially implemented. Retrofitted onto the current tracker; two proposed status additions (In SME Review, Migrated) under observation, not yet adopted. Target implementation window: Q1 2027, with pieces already being incorporated incrementally |
| Artifacts | Lifecycle/status guide, governance glossary, operating model document, lifecycle diagram, reusable template |
The status flow
Solid nodes are the deployed nine-status lifecycle: A revision loops back through Authoring rather than straight to the SME, and staging in the CCMS happens before Good for Publish.
Dashed nodes are trial additions under observation, not yet adopted into the core nine. Cancelled and Already in Product Docs can be declared by either the analyst or the SME.
The problem
Two failures, both traceable to no intake control and no single record of ownership:
- A duplicated draft. Two analysts independently drafted articles from the same source document, caught before publication, but at the cost of duplicated authoring and duplicated SME review time, the scarcest resource in the pipeline. Nobody could answer “why are there two of these.”
- Two new hires. The team couldn’t explain its own process or where any article stood, because there was no structure to explain it with.
One failure cost money and expert time; the other costs the team’s ability to describe itself, and recurs with every hire.
Business impact and value delivered
The framework's value is control and visibility where there had been convention. Its measured value arrives with the rollout; what is delivered today is the control model itself, endorsed as the knowledge function's single source of truth for process improvement.
- Duplicated work removed by design. The framework closes the gap that let two analysts independently draft articles from the same source document, which spent authoring time and SME review time, the pipeline's scarcest resource, twice for one article. One named owner per status makes that collision structurally impossible rather than merely discouraged.
- Visibility for anyone who asks. Where an article stands, who owns the next move, and what evidence is required to advance it are answerable from the tracker instead of from memory. "What is blocking this article" has one source of truth.
- Commitments SMEs can honor. Review commitments split acknowledgement from decision, so the only promises asked of reviewers who owe the team no formal time are ones they can keep. Escalation paths give a stalled article a defined route instead of a personal favor.
- A written answer where there was none. The two new-hire questions that triggered the design now have a documented answer: The lifecycle guide, glossary, and operating model exist as named artifacts, not as things someone explains when asked.
- Evidence for decisions. The framework defines five tracker-derived metrics for monthly reporting, so process decisions can be argued from observed flow rather than impressions once the rollout lands.
Claim limit: No throughput, cycle-time, or quality improvement is claimed. The framework is partially implemented, with full rollout targeted for Q1 2027, and nothing is reported as measured before it is.
Constraints
- Favor-based review. SME review gates every article, and the KM team has no authority over reviewer time. Every review is a favor, since reviewers are primarily support operators.
- Limited review support. Dedicated review support scaled to only one product area; it can’t be requested everywhere.
- Ambiguous ownership. Existing ownership language used “or” between roles, which meant no one was actually accountable.
- Unenforced commitments. Service commitments (e.g., a 3-day review turnaround) existed as examples with no enforcement or escalation behind them.
- No transition timestamps. The tracker couldn’t yet timestamp status transitions, which blocks measuring cycle time until it’s fixed.
- Realistic commitments. Any new commitment on reviewers had to be realistic enough that a busy SME could actually honor it.
The design
Nine statuses, each a controlled checkpoint
Authoring · For SME Review · For Revision · Ready with Edits · Ready for Migration · Good for Publish · Published · Cancelled · Already in Product Docs.
Every status carries the same five parts:
- Entry criteria.
- One named owner.
- Exit criteria.
- Required evidence.
- Allowed next statuses.
The criteria are observable only (“has passed self-review and been assigned to the correct reviewer,” not “is mostly ready”).
Two trial statuses under observation
A later redesign introduces two more statuses.
- An In SME Review status. Inserted once the SME actually starts reviewing, it separates queue wait from active review time, which the current single status conflates.
- A Migrated status. Proposed to replace Good for Publish with a more precisely defined state.
Both are under observation and not yet part of the core nine.
One owner per status, no “or”
Where an owner genuinely wasn’t decided, the document carries a visible placeholder rather than a guessed answer.
Evidence as a control, not a “should”
A status change without its required evidence is invalid and gets reverted. That is what turns the tracker into an audit trail instead of a self-reported board.
Acknowledgement split from decision
The commitment depends on whether the product has a dedicated reviewer.
Where a product has a dedicated reviewer
- One business day to acknowledge.
- Three to decide.
- Up to three follow-ups spaced three days apart.
Everywhere else
- Most products, since reviewers are support operators juggling other work.
- Only acknowledgement is asked.
- No hard decision deadline is imposed.
An acknowledgement a busy expert can honor; a forced decision often can’t be, so only the enforceable half gets committed.
The follow-up rule
Follow up only after the date the reviewer themselves committed to, never before.
If it is still open, three steps follow instead of holding capacity open through an unbounded renegotiation loop:
- Close the intake ticket (not the article, which keeps its lifecycle status).
- Move on.
- Circle back on a scheduled follow-up.
Throughput as a rate, not a fixed number
Completed articles ÷ available writer-weeks (headcount minus absence and overhead).
A rate reads a short-staffed week as arithmetic, not failure, and stays comparable as staffing changes.
Five tracker-derived metrics, reported monthly
They add no new logging burden, since an abandoned metric produces confidently wrong data.
One status, in full
For SME Review
The status the team controls least, so it had to be defined most carefully.
- Entry
- Draft complete, self-reviewed, correct SME assigned, technically mature enough for meaningful review.
- Owner
- SME (writer stays available for questions).
- Exit
- Recorded approval · approval with minor edits · actionable revision feedback · cancel/pivot decision · confirmation equivalent content already exists. Silence is not approval.
- Evidence required
- At least one of an approval comment, an approval email or message, source-document review comments, a documented revision or cancellation decision, or a link to the existing article.
- Allowed next
-
Ready for Migration Ready with Edits For Revision Cancelled Already in Product Docs
The entry criteria protect reviewer time; the evidence list makes approval retrievable; the allowed transitions mean nothing skips straight to publication. The other eight statuses are specified to the same depth.
Key decisions
Left post-publication statuses unwritten
Maintenance, retirement, and archiving stay undesigned until one real maintenance cycle has run by hand.
A status for work nobody’s done yet gets used by nobody.
No quality metrics in phase one
A quality metric on an unstable process just measures the instability; visibility and measurement had to come first.
Anchored publication targets to the tax season cycle
The driver is the season, not internal preference, since that peak is also the only window with enough traffic to measure whether articles actually close support gaps.
What’s already mechanized
The Claude Cowork drafting pipeline (its own case study) already runs parts of this model as code, enforcing two of its exception rules directly:
- Repeat-failure stop. Two consecutive failures on one file stop the run.
- Split-plan gate. A source spanning multiple topics stops for an approved split plan before drafting begins.
That is the same triage control that would have prevented the original duplicate. Every draft also carries a mandatory review tail (flags, structure suggestions, changes), so uncertainty surfaces as a reviewable item instead of being resolved silently.
Controls that can be mechanized get mechanized in code. Controls that need judgment get written down and assigned to a person instead.
The same model decides whether a RAG-based support chatbot finds the right guide. Across my product area I designed the article boundaries, naming, and metadata conventions that set the retrieval unit, then applied that structure for SEO as well, so the article that answers the chatbot also ranks for the person searching directly. Chatbot and human readers are one content set, not two.
What changed after testing
- Split ownership language. Every “or” came out, after tracing how accountability died inside it.
- Made evidence a hard gate. It had been a “should,” and the tracker drifted from reality without one.
- Split acknowledgement from decision. The two commitments separated once it was clear a forced deadline on a favor-based reviewer would be ignored.
- Added the follow-up rule. A promised date had slipped into an unbounded renegotiation loop.
- Deferred metrics and post-publication statuses. Neither was designed ahead of real usage data.
Limitations and next step
Endorsed but only partially implemented. It is retrofitted onto the current tracker, with full rollout targeted for Q1 2027 while pieces are incorporated incrementally in the meantime.
What the missing timestamps block
- Blocked on timestamps. Measurement is blocked until the tracker logs status-change timestamps automatically (see the open item below).
- Cycle and wait time invisible. Until then, cycle time and reviewer wait time can’t be measured at all.
What I would scope and sequence differently
- Measurement layer before instrumentation. In hindsight, the measurement layer (commitment table, five indicators) was specified before the tracker could measure anything, so instrumentation should have shipped first.
- A 70-term glossary. It was written as a maintained artifact when only about a dozen terms actually carry rules; the rest was a one-time alignment exercise, not an asset to maintain.
Next: Ship the tracker timestamping. Then validate three measures against the pre-framework baseline:
- Wait time.
- Rework rate.
- Duplicate/cancellation rate.
Tracker instrumentation status and the measurements it unblocks will be added as they become available.
What I’ve proposed next
Two further pieces, both proposed and not started:
- A controlled vocabulary. Product/UI terminology with one approved term per concept, which also improves RAG retrieval for the downstream support AI and SEO for people searching directly.
- A standing QA function. It would own editorial consistency and migration fidelity, which nobody currently owns as a job.
Supporting artifacts
The repository, implementation details, published artifacts, and related documentation will be added as they become available.