Knowledge Integrity
A Knowledge Object is dependable only when its identity, source, time context, rules, and ownership can survive scrutiny.
On this pageSeven dimensions⌄
Seven dimensions of integrity
1. Identity
The object resolves to the correct entity, type, market, jurisdiction, version, or reporting period. Similar names and aliases do not cause silent substitution.
Identity failures are easy to miss because the surrounding page can make the intended meaning obvious to a person. A ticker page may show the correct logo and heading while the underlying data joins to the wrong share class. A support article may mention a product family when its instructions apply only to one model.
2. Source
The origin is known and appropriate for the claim. A primary filing, licensed provider, government publication, internal calculation, and editorial interpretation are not interchangeable.
The source hierarchy should depend on the attribute. A corporate filing may be authoritative for reported revenue. A market data provider may be authoritative for a current quote. A third party estimate may be useful for a forecast but should not replace the reported result after publication.
3. Freshness
The update time and validity window match the nature of the information. Frequently changing knowledge should not inherit the review cadence of evergreen content.
A company description reviewed six months ago may remain useful. A security price from six months ago requires a historical label. A tax threshold may remain valid for one year and become wrong on the first day of the next year.
4. Context
The object carries the qualifiers required for correct use, such as currency, unit, reporting period, jurisdiction, calculation type, market status, or forecast label.
Context is especially important when information is extracted from a page. A visually adjacent label can disappear while the number remains.
5. Consistency
Equivalent presentations use the same definition and compatible values. Differences are explainable rather than accidental.
Consistency does not mean every surface must display the same amount of information. A mobile card can round a value. An API can provide more precision. A regulated experience may show a longer disclosure. The meaning should remain compatible.
6. Ownership
A named team or role is accountable for source selection, update policy, exception handling, and correction.
Shared knowledge often falls between teams. Engineering owns the pipeline. Content owns the explanation. Product owns the interface. Data owns the provider relationship. Search owns discovery. A Knowledge Object still needs one accountable owner for the complete integrity policy.
7. Failure rules
The system defines what happens when required data is missing, delayed, conflicting, or outside its validity window.
Silence is a failure rule only when chosen intentionally. Displaying zero, carrying forward an old value, or using a partial result can create false confidence.
From quality checklist to Knowledge Contract
A checklist describes what a reviewer hopes to see. A contract defines what the system requires.
For important Knowledge Objects, teams can express integrity requirements as a Knowledge Contract. The contract can live in a schema, configuration file, content model, data test, governance document, or a combination of these.
A credible contract is explicit, testable, owned, versioned, observable, and capable of failing.
A contract becomes useful when it can fail validation.
If a required source disappears, the object should enter a known state. If the freshness threshold is exceeded, the presentation should stop implying that the value is current. If a calculation version changes, dependent outputs should be identified and reviewed.
What should a contract define?
| Contract field | Decision it forces |
|---|---|
| Object identity | Which entity and object type does the contract govern? |
| Required attributes | Which fields must exist before publication? |
| Source authority | Which sources are permitted, preferred, or prohibited? |
| Freshness threshold | How old can the information become before its state changes? |
| Validity window | During which period is the object applicable? |
| Calculation policy | Which formula, inputs, precision, and version apply? |
| Relationship rules | Which connections are required and which combinations are invalid? |
| Permitted presentations | Where can the object appear and which qualifiers must remain visible? |
| Failure behavior | Should the system suppress, label, fall back, alert, or block? |
| Owner | Who approves changes and responds to failures? |
| Observability | Which tests, logs, alerts, or reviews expose contract health? |
| Version | How are changes recorded and how do consumers migrate? |
Integrity is not the same as completeness
A Knowledge Object does not need every possible attribute. It needs the attributes required for its intended use.
A concise object with a clear source and timestamp can have higher integrity than a large object filled with uncertain fields. Adding more data increases the number of ways an object can become stale, contradictory, or difficult to own.
The right answer can vary by surface. A comparison tool may require normalized attributes. An educational page may require explanation and examples. An API may require exact types and error states. Each can draw from the same object without exposing every field.
Freshness is a state, not a timestamp
Many systems store a last updated date and treat freshness as solved. A timestamp is evidence, not a policy.
Freshness depends on the object type, user expectation, and consequence of delay.
| State | Meaning | Possible presentation |
|---|---|---|
| Current | Within the expected update window | Display normally with a timestamp where useful |
| Delayed | Valid but intentionally behind real time | Display a delay label |
| Historical | Correct for a past point or period | Display the period prominently |
| Forecast | Expected future value or event | Label source, horizon, and estimate status |
| Stale | Outside the accepted update window | Warn, suppress, or replace according to policy |
| Unknown | Freshness cannot be established | Do not imply current status |
This distinction matters because a fresh value can still be invalid, and an old value can remain valid as historical knowledge.
Provenance needs field level precision
A page level source list can be useful to readers, but it may not show which source supports which value.
This becomes important when one page combines official filings, live provider data, editorial analysis, and derived calculations.
Official filing
Reported financial results and legal disclosures.
Market data feed
Current price, market status, or trading data.
Editorial definition
Explanation, methodology, and user context.
Internal taxonomy
Entity types, categories, and relationships.
Derived object
Normalized inputs, calculation version, and published value.
Provenance should make the path reviewable. It does not require exposing licensed data or internal systems publicly.
Consistency requires deliberate exceptions
Perfect sameness is not always correct.
A mobile interface may round a number for space. An educational page may use an end of day example. An API may provide more precision than a webpage. A regulated experience may require a longer disclosure.
The integrity requirement is not identical presentation. It is explainable variation.
Semantic consistency
The object has the same meaning across every supported surface.
Value consistency
Values use compatible sources, periods, and methods.
Presentation consistency
Labels and qualifications do not contradict one another.
Intentional variation
Differences follow documented rules for the surface.
Failure behavior is part of product design
Information systems often design the success state and improvise the failure state. This leads to stale values, unexplained zeros, mismatched timestamps, or fallback copy that appears authoritative.
A Knowledge Contract should define failure behavior before the failure occurs.
| Failure | Weak response | Stronger response |
|---|---|---|
| Required input missing | Display zero or the previous value | Suppress the calculation or label the last valid value |
| Source conflict | Select one source silently | Apply an authority rule, log the conflict, and review material differences |
| Stale value | Keep the normal presentation | Change state, display time context, or withhold |
| Unknown entity | Attach data to the closest text match | Block publication until identity resolves |
| Calculation change | Replace values without a record | Version the method and document the effective date |
Integrity should be observable
Knowledge quality should not depend entirely on users reporting errors.
Teams need indicators that reveal when an object is drifting from its contract. Some tests can be automated. Others require sampled review.
- Percentage of objects with resolved identity
- Percentage with an approved source
- Percentage within the freshness threshold
- Objects with conflicting values across presentations
- Objects with no assigned owner
- Contract validation failure rate
- Time from failure detection to correction
- Derived values without a versioned calculation policy
These measures are internal product quality indicators. They should not be presented as evidence of how an external platform ranks or cites information.
When a formal contract is useful
Not every sentence needs a schema and alert. A personal essay, opinion, or low risk evergreen explanation can often be managed through editorial standards.
Formal contracts are most useful when knowledge is:
- Repeated across several surfaces
- Time sensitive
- Calculated or transformed
- Regulated or financially material
- Operationally important
- Consumed by several teams or systems
- Expensive to correct after distribution
The cost of the contract should match the cost of failure.
A practical integrity review
Teams can evaluate one important object with a short review.
- Identify it. Confirm type, stable identifier, aliases, and related entities.
- Trace it. Follow every important attribute back to its source and transformation.
- Time it. Define update cadence, validity, expiration, and historical handling.
- Assign it. Name an accountable owner and correction path.
- Break it. Simulate missing data, delayed data, conflicting data, and calculation changes.
- Observe it. Add tests or sampled reviews for the highest risk failures.
- Compare it. Verify that supported presentations preserve the same meaning.
Scope
Knowledge Integrity describes internal quality characteristics. It is not a list of ranking factors, retrieval signals, or guarantees used by Google, OpenAI, Anthropic, Perplexity, or any other external platform.
Its purpose is practical: help organizations publish information that is easier to verify, maintain, correct, and reuse.
Framework in one minute
- Integrity depends on identity, source, freshness, context, consistency, ownership, and failure rules.
- A Knowledge Contract turns quality expectations into explicit and testable behavior.
- Freshness should be modeled as a state with an action, not stored only as a timestamp.
- Failure behavior belongs in the product design, not in an emergency workaround.
- Formal controls are most valuable when the cost of incorrect or stale knowledge is high.