Technique 5.2: KCS Article State
Article state is comprised of three metadata fields: article confidence, article audience, and article governance. The KCS proficiency model indicates which users have demonstrated the ability to create quality articles and the judgment to make them visible to the appropriate audience.
- Article confidence tells us about the level of certainty we have in the article's structure and content.
- Article audience determines who can see which articles.
- Article governance has to do with who can create and modify articles that contain sensitive, critical, or regulated information.
Article Confidence
To manage the readiness of a KCS article, we use article confidence to indicate where it is in its life cycle. All articles, regardless of the confidence we have in them, are worth sharing in case someone else is dealing with the same issue. As the article is resolved and then reused, we gain confidence in its quality. Knowledge is never complete or static; it continues to evolve as it is used. Within this evolution, the KCS article life cycle is non-linear—KCS articles may move through the various qualities in many different ways.
- Work in Progress (WIP)

- Not Validated
- Validated
- Archived
WORK IN PROGRESS (WIP)— the article does not include a resolution; the problem or question and some information about the environment has been captured but the resolution is not yet known. This is sometimes referred to as a "framed" article.
-
Having WIP articles in the knowledge base helps us avoid duplicate work. This is especially true in moderate to highly complex environments where the resolution of issues often takes days or weeks. WIPs inform other knowledge workers that the issue is being worked on if they encounter a similar request. This visibility to work in progress promotes collaboration across the organization.
-
WIPs are temporary. Generally they should become either Not Validated, Validated, or they should be deleted. If the issue is never resolved and the request is closed because it was abandoned by the requestor, the responder needs to decide if anything of value has been captured in the article. If the request is no longer being worked and there is nothing of value in the article, then it should be deleted.
-
WIP helps responders manage pending work (as the name implies). WIPs give us an easy way to identify and manage incomplete articles in the knowledge base.
Thanks to improvements in incident management and search tools, organizations are increasingly using case notes as Work in Progress articles. This works well as long as those open case notes are searchable for other knowledge workers in the domain.
NOT VALIDATED — the article has a resolution, but we are not confident in the content or structure due to either lack of feedback or non-compliance with the content standard.
-
Not Validated gives us a way to capture the collective experience of the organization and distinguish between those articles we have confidence in (Validated) and those we don't (Not Validated). This allows knowledge workers to capture and share all their experiences.
-
The Not Validated designation supports the concept of "capture everything." If the issue is worth answering or solving for the requestor, it is worth having in the knowledge base. It also supports the concept of "sufficient to solve." People are often hesitant to capture all of their experiences as articles if they are not confident in the resolution. Not Validated provides a way to indicate, "here is what I did in this situation, but I have not been able to validate the resolution or answer."
-
Efficiency - Let reuse of Not Validated articles be the review and drive the article life cycle. Reviewing all Not Validated articles creates overhead and expense that produces very little value.
-
The users of the knowledge base who have visibility to Not Validated articles need to understand that Not Validated articles should not be used unless the article is relevant to the situation they are working on, and they have confidence in the resolution. Judgment is required.
-
KCS Candidates (people learning the KCS Practices) can only create and modify Not Validated articles, which are then reviewed by a KCS Coach.
VALIDATED—The article is considered complete and reusable, and we are confident in it. The article is being worked by a trained KCS user (KCS Contributor, Publisher, KDE or Coach) or by a KCS Candidate and it has been reviewed by their Coach. The criteria to designate an article as validated are:
-
Confidence (Accurate) - Responder confidence can be the result of confirmation from the requestor that the resolution worked, or the problem was recreated and the responder was able to validate the resolution, or, simply based on their experience, the responder is confident in the resolution.
-
Compliance with the content standard (Complete) - The article is compliant with the content standard, written in the context of the requestor.
ARCHIVED—Archiving an article from the knowledge base is normally done only when the article is defined as having no value. Archiving an article is better than deleting it. If an article has been linked to a request, you will not want to delete the actual article from the knowledge base as it will result in a broken link between the knowledge base and the system of record. A common method to remove the article from a searchable knowledge base is to set it to Archived. The article is logically deleted from the knowledge base so that it will no longer be presented in a search results or browse function. It can still be viewed from a previously linked incident or by an advanced search function that includes archived knowledge articles.
The confidence, audience, and governance fields are stored as part of the KCS article metadata. As an article evolves and is used, reviewed, and enhanced, the article state is updated. The article confidence affects the trust users place in its accuracy. Article confidence is extremely important and frequently referenced by the users of the knowledge; therefore technology should make the article confidence visible to the users.
An article can move through from the Not Validated to Validated qualities several times throughout its life cycle. The process will vary depending on:
- The KCS maturity of the organization
- The usage of the KCS article
- The KCS role of the person interacting with the article
Due to this dynamic, it can be helpful to keep a copy of an article as it existed when delivered it to a specific requestor. When supporting a mission-critical product or process, there are often regulatory compliance requirements that mandate capturing the situation exactly, noting the KCS article recommended, and explaining why. The exact KCS article can be preserved by copying a snapshot into the incident or by having version control for articles in the knowledge base.
Confidence Transitions
Following are a few examples of quality transitions.
Work in Progress (WIP)
- A WIP is created at or near the point in time the first search is done on the issue
- A WIP becomes a Not Validated if:
- The article is complete but created by a KCS Candidate
- The article is complete, created by a KCS Contributor or Publisher but confidence in the resolution is low
- A WIP becomes Validated if:
- The article is being worked by KCS Contributor, KCS Publisher, or Coach, they have confidence that the article resolved their issue, and it complies to the content standard.
- It is important to note that WIP articles should exist only while the issue is being worked on, or when the associated incident is open. When the incident is closed, the WIP should either be deleted because an existing article was found that resolved the issue, or the article should be updated with the resolution and moved to Not Validated or Validated based on the KCS role and confidence in the resolution. If the problem is not resolved and the incident is closed, as a general rule, the WIP should be deleted or set to Archive. An exception to consider in dealing with unresolved issues and WIP articles is the situation where there is valuable, reusable information that has been captured in the WIP; for example, a diagnostic process was documented in the article. In this case, set the article into the appropriate confidence setting based on role and confidence in the content in the article.
Not Validated, Validated
- Not Validated becomes Validated if the article is being worked/reused by a KCS Contributor, KCS Publisher, or Coach, they have confidence that the article resolved the issue, and the article complies to the content standard.
Archived
- Any article can become Archived when the objective is to remove the article from the searchable knowledge base without physically deleting it.
- An archived article can be restored to any other confidence setting should it be discovered the article was prematurely archived.
All of the above approaches align with the fundamental KCS Principle of a demand-driven process. Demand drives our attention to the articles that have value. Do not review articles for the sake of review, as they may never be reused. If we are reviewing articles in absence of demand, we are not doing KCS. Remember that internal demand is still demand. A Coach reviewing an article with a KCS Candidate is fulfilling the demand of the Candidate to learn KCS. Knowledge Domain Experts look at big-picture demand when doing Evolve Loop assessments of clusters, patterns, trends, and the new vs. known analysis.
Article Audience: Who Gets to See What
To manage who can see which KCS articles, we use article audience. As an organization, you may decide that you want to control what an external customer or an unidentified requestor has access to. Business rules can then be established based on both article audience and article confidence. As an article is designated as Validated, it may become visible to a given audience. Or, as the KCS implementation matures, the audience may expand. Audience options include:
- Internal

- Within a Domain
- Partners
- Customers
- Public
INTERNAL - Only an audience internal to an organization will be able to see the article. Note: anything with wider visibility than Internal is referred to as External.
WITHIN A DOMAIN - A group associated with a particular product domain, topic, job function, department etc.
PARTNERS - Someone who is not an employee but acts as a trusted extension of the organization.
CUSTOMERS - Customers or users of our products or services . These articles typically are made accessible via a self-service experience for registered users.
PUBLIC -The KCS article is publicly viewable by anyone. A common practice is to have these articles optimized and indexed for publicly available search appliances like Google, although this conversation is shifting in light of generative AI.
As we find and use KCS articles, we should improve them; reuse is review. As "flag it or fix it" becomes part of the culture, we are taking responsibility for the content that we interact with. This dynamic ensures the content being used is constantly being reviewed and improved. As the KCS articles improve and are validated through use, they should become visible to a broader audience and eventually be made visible externally. Early on in the KCS adoption process, organizations implement the concept of migrating content to be visible to customers through a variety of demand-driven techniques. In a mature KCS environment, a high percentage of content publishing is happening in real-time or just-in-time. (See case studies for examples of just-in-time publishing in action.)
A KCS Publisher can modify a Validated article. Those who are not yet KCS Publishers, but who notice that the article does not comply with the KCS content standard, or otherwise requires improvement, should flag the article and mark it as Not Validated for review by a KCS Publisher. Some knowledge management technologies allow those who are not yet KCS Publishers to edit an unpublished version of the document while the current version stays visible; this is desirable as it removes rework by the KCS Publisher, who need only approve the changes. In general, articles that have been published should not be removed from visibility if they have been flagged, although if the knowledge worker feels a Published article poses an active risk of harming customers, he or she should escalate the issue to a Coach or Knowledge Domain Expert immediately.
To manage article audience, and thus appropriate levels of security for the knowledge, create an Article State Matrix (example shown). This reference document maps the audiences (internal, partners, external) against the KCS article attributes that affect visibility (state, knowledge domain, special considerations) and defines access rights.
As the KCS Practices mature in the organization, a just-in-time model for external visibility should be adopted, so that a high percentage of knowledge workers are trained to make articles externally visible without review. This level of maturity takes time to develop and is most appropriate when the KCS workflow and content standard are well understood and have become second nature for the responders. Just-in-time external publishing requires people to make good judgments about technical and content accuracy. If they are trained and confident in the article's accuracy, they should make the article visible to the largest audience externally. If they are not confident in the article's accuracy, they should request a technical review. Judgment is required.
Audience Transitions
To fully capitalize on what we know internally, we must make a high percentage of that available externally, and quickly. In some environments, while we are learning to do KCS, demand or reuse is a reasonable way to know what should be published. However, making articles externally visible based on reuse should be temporary, replaced by the just-in-time publishing model of a mature KCS environment.
If you must limit what is published during the learning phase, two models are worthy of consideration:
- In some organizations, a Validated article becomes External automatically when the reuse count is hit. The philosophy here is the article has been used and therefore reviewed a couple of times, so it is sufficient to be External.
- The "conveyor belt model." Some Members have had success with a conveyor belt model of automatically making articles External. Once an article has been reused three times internally, a timer starts for that article and it will be External in five days. People in the organization can opt-in to review the article or pull the article off the conveyor belt by changing the state or audience at any point during the five-day period. The article will be External when the timer expires, whether or not it is Validated.
Patterns of reuse external to the organization are different than patterns of reuse internally. Requestors will pursue resolutions for many issues through a self-service mechanism for which they would never open an incident. This is why the "make External after reuse" model should be a short-term practice on the KCS journey.
KCS Stagnation
The flow or movement of articles through the life cycle states is an important indicator of the health of the KCS system. This is not to say all articles should necessarily move through the life cycle states, as reuse should be the driver of what moves and what doesn't. Not Validated articles that have never been reused, or that we don't have confidence in, should stay Not Validated; Not Validated articles are not a problem in and of themselves. However, articles that are being reused or that we have confidence in must eventually make it to Validated and visible outside of the organization, when appropriate, in order to maximize the benefits of KCS.
Some organizations who do a great job at Adopting in Waves and Building Proficiency will realize significant operational improvement, and then see the system slowly die. People lose interest, participation rates drop off, and the benefits decline. The common underlying theme in these scenarios is KCS stagnation: the flow of articles stops. Either the organization has not created a self-service mechanism, or the rate at which articles are getting made available outside the organization is not sufficient to support success with self-service. A primary motivation for people to create and maintain the knowledge base is the promise of reducing redundant work: not solving the same problem over and over. If articles are not visible externally, or there is no effective self-service model, the responders will not see a change in the ratio of known vs. new issues they are working on. They will lose interest in the KCS Practices. The flow of articles through the states is critical for the sustainability of the KCS system.
The Time Value of a KCS Article
Knowledge base content is different from, and should be managed differently from, other types of technical content, such as documentation, white papers, or manuals. Knowledge is dynamic and needs to be captured and delivered for just-in-time accuracy and freshness. The value of support knowledge begins to diminish 30 days after an issue is first discovered. Many non-KCS organizations take 60-90 days or more to identify, document, and release new articles. This is an expensive proposition that misses a major portion of the content's window of opportunity. The metadata fields of confidence, audience, and governance provide a system of checks and balances that allow us to publish articles quickly and appropriately so that we can leverage knowledge in the time frame it's needed.
Self-Service Success
One indicator that we are expanding into the Building Proficiency phase of KCS adoption is that enough content has been collected in the knowledge base that customers have a better than 50% probability of finding something helpful through self-service. The indicator for this is that the internal article reuse rate is equal to or greater than the create rate. As we build proficiency, our goal is that 90% of what is known internally, and usable by the customer, will be published to self-service at the time we know it (at or before case closure). It is a bold goal, and more information can be found in this case study.
We want to get as much of what we know to the self-service model as quickly as possible. This is because in mature KCS environments with effective self-service models, we see the reuse patterns of articles in self-service is very different from the internal reuse patterns. Most support organizations only see a very small percent (typically less than 3%) of the total customer demand for support (10 minute video on the Customer Demand Model here). This means customers don’t open an incident for the majority of the exceptions or issues they encounter. Data from Consortium Members shows that customers will use a good self-service mechanism ten times more often than they will use the support center. Internal reuse is a reasonable short-term indicator of the value of an article, but in the long term, we want to enable customers to access most of what we know because they will often reuse articles, or solve issues, through self-service for which they would never have opened an incident.
While many issues resolved by customers using self-service will be those for which they would not have opened an incident, some of their self-service success will be on issues for which they would have opened an incident. This means the nature of the work coming into the assisted model will shift over time. A higher percentage of incoming incidents will be new, as many of the known issues are now solved through self-service. Knowledge workers will be spending more of their time solving new issues, and this results in a dynamic that may not be expected.
As self-service becomes more effective, many of the support measures will move, in what traditional terms would be “the wrong direction." Time to resolution and cost per incident will increase due to the fact that we have removed many of the known or easy issues from the work mix, and it takes longer to solve new issues. This is reflected in an increase in the new vs known ratio, and this ratio is an excellent indicator of the effectiveness of your self-service model.
See Measuring Self-Service Success for more on building a successful self-service model.
Article Governance: Who Can Create or Modify
Article governance is an attribute of an article that allows you to control sensitive, critical, or regulated information. Not all articles have the same requirement for compliance reviews. Some articles are based on the collective experience of those who use the articles (experienced based articles). Other articles have policy or legal information that require tight control (compliance based articles). The governance attribute used in conjunction with KCS roles enables us to manage articles and their state specific to compliance requirement.
Experience Based - The Experience Based attribute is the most open level of governance, and control is a function of being a member of the community and having an identity. Sign-in is required. The number of people with this level of rights and privileges will be very large; they can create and improve articles with the experience based attribute. The individual's KCS role defines their rights and privileges in setting the audience attribute (Internal, Partner, External) and the confidence attribute (Not Validated, Validated)
Compliance Based - The Compliance Based attribute is restrictive, in that only designated individuals or specific groups of individuals can create and modify articles within it. These articles contain information that describes policy, regulatory, or legal information. While everyone should be able to comment on or flag all types of articles, not everyone can create or improve articles with the Compliance attribute.
