Chapter 5 established that retrieval and resolution are different problems. A publisher can possess several valid facts while the information available in a particular request remains insufficient to determine which one applies.
That distinction becomes more useful once we stop treating it only as a problem for the answer engine.
Publishers often know the conditions that govern applicability. Their product systems know which configuration matters. Their pricing systems know which market determines the rate. Their eligibility systems know which characteristics affect a benefit. Their applications already ask users for the information necessary to distinguish among otherwise valid possibilities.
Much of that knowledge remains operational. It lives in software, business rules, database relationships, or the experience of people who understand the domain.
A Knowledge Object gives the publisher an opportunity to preserve some of those limits alongside the facts they govern.
The objective is not to prescribe how an external machine should reason. It is to represent enough of what the publisher knows that a consuming system can distinguish between a fact that has been found and a fact that has been resolved for the current context.
12.1 Some Facts Require a Discriminator
Return briefly to the Medicare Plan-ID problem.
A parent plan may contain several geographic segments:
H5216-043
|
+-- H5216-043-1 → $0
+-- H5216-043-2 → $18
+-- H5216-043-3 → $27The publisher knows all three premiums.
It also knows that geography determines which segment applies.
That does not mean every question about H5216-043 requires geographic resolution. If all three segments are offered by the same organization, the question Who offers H5216-043? may be answerable at the parent-plan level.
The question What is my premium? is different.
The same identifier is sufficiently precise for one assertion and insufficiently precise for another.
This is easier to see outside Medicare.
Suppose the Apex X5 camera family has two generations:
Apex X5
|
+-- Mark I → 4K/60
+-- Mark II → 4K/120A customer asks:
Who manufactures the Apex X5?
The product-family identity may be all the publisher needs. Both generations have the same manufacturer.
Now the customer asks:
Can my Apex X5 shoot 4K at 120 frames per second?
The required identity has become more specific. The publisher needs to know which generation the customer owns.
Nothing about the product identity is inherently incomplete. It is simply not resolved to the depth required by that particular assertion.
This gives us a useful way to think about resolution depth.
The necessary depth is not a universal property of the Knowledge Object. It depends on what the publisher is being asked to assert.
A vehicle model may be sufficiently identified for a question about its manufacturer but require an engine configuration for a replacement-part question. A telecommunications provider may know that it serves a ZIP code while requiring a street address to determine whether service is available at a particular home. A university may identify a degree program while needing the campus and academic year to determine the applicable tuition.
The assertion determines how much resolution is required.
That has an important consequence for KNOL.
Resolution requirements do not necessarily belong to the Knowledge Object as one global condition. They may belong to the particular Knowledge Aspect or assertion whose applicability depends on them.
The publisher does not merely know the facts.
It knows which distinctions matter to which facts.
12.2 Publish What Is Required to Know
Most organizations already use this kind of knowledge.
A camera retailer’s product system may distinguish the Apex X5 Mark I from the Mark II because compatibility and specifications differ between them. A parts retailer asks for year, make, model, engine, or trim because those attributes determine fitment. A service provider asks for an address because availability cannot be established reliably from a city or ZIP code alone.
The interface reveals something about the underlying knowledge model.
When a system asks a customer for another piece of information before returning a result, the organization has often already determined that the missing information is necessary for resolution.
That requirement can be just as meaningful as the candidate facts themselves.
The camera publisher knows:
Apex X5 Mark I supports 4K/60.
and:
Apex X5 Mark II supports 4K/120.
It also knows:
Generation must be established before a generation-dependent video capability can be applied to an unspecified Apex X5.
The Medicare publisher knows the segment premiums.
It also knows:
Geography must be established before a segment-specific premium can be applied to the parent Plan ID.
Those statements describe the domain.
They are not merely interface instructions.
That distinction changes what it means for the publisher to have complete knowledge.
Suppose someone asks for the premium of H5216-043 without providing geography.
The publisher may know the parent plan, every segment beneath it, every segment premium, the service area of every segment, and the rule connecting geography to the applicable segment.
Nothing is necessarily missing from the publisher’s Knowledge Space.
What is missing is one discriminator from the request.
The difference is substantial.
I don’t know the premium describes a gap in the publisher’s knowledge.
I need your county to determine which premium applies describes knowledge about the conditions required to answer.
The second state is richer than the first.
This is particularly relevant to conversational systems because the missing discriminator can become the next question.
A camera retailer can ask which generation the customer owns. A Medicare resource can ask for the county. A parts system can ask for the engine configuration.
The publisher does not have to manufacture the conversation in advance for this knowledge to be useful. It needs to make available the fact that the discriminator matters.
The consuming system remains responsible for deciding what to do with that information.
It may ask a clarifying question. It may explain the ambiguity. It may present the candidate possibilities. It may decline to select among them until more context becomes available.
KNOL does not prescribe that behavior.
The publisher’s responsibility is narrower: preserve the knowledge that makes correct resolution possible.
12.3 Publish the Boundary
Resolution also changes how publishers should think about the scope of an assertion.
Consider:
Apex X5 Mark II supports 4K/120.
If the specification is authoritative, that may be a perfectly valid assertion.
Now remove the generation:
Apex X5 supports 4K/120.
The value has not changed.
The scope has.
If the Mark I supports only 4K/60, the second statement has generalized the first beyond the context in which it is true.
The same thing happens with the Medicare premium.
The publisher may know:
H5216-043-2 has a monthly premium of $18.
That does not necessarily justify:
H5216-043 has a monthly premium of $18.
The first assertion attaches the value to the segment where it is valid.
The second attaches the same value to the parent plan, where other segment-specific values may also exist.
Nothing about $18 became inaccurate.
The assertion became broader than the evidence supporting it.
This is the practical significance of the boundary of valid assertion introduced earlier in the book.
The boundary is not something an answer engine discovers only after a question arrives. The publisher begins establishing it when the knowledge is modeled.
Which subject owns the assertion?
Which configuration does it describe?
During which period is it valid?
Within which geography?
For which population?
Under which conditions?
If those distinctions determine whether the assertion remains true in use, they are part of its boundary.
A well-constructed KNOL therefore does more than accumulate facts. It preserves enough of their limits to keep them from becoming broader claims simply because they have been removed from their original context.
That does not mean the KNOL itself reasons.
It does not decide whether to answer a question. It does not interrogate the user or select among candidate facts.
It represents what the publisher knows.
That representation can include the candidate facts, the contexts in which they apply, the relationships among relevant variants, and the discriminator required when those facts cannot yet be safely reduced to one applicable conclusion.
Sometimes that allows a consuming system to answer immediately.
Sometimes it reveals that another piece of context is required.
Both are legitimate outcomes of the same knowledge architecture.
The important thing is that the publisher has not erased the distinction merely to make the information appear simpler.
A Knowledge Object should be capable of representing not only what is known, but where the publisher’s knowledge stops supporting a more specific conclusion.
Until the required discriminator is known, this is as far as the evidence allows us to go.