Entity SEO
Entity Confidence and Review Dates: Evidence, States and Triggers
Confidence belongs to a specific assertion with a scope and date. An organization’s identity can remain well supported while its address, ownership, availability or connections between products need fresh evidence. Record what the evidence supports now, what remains unresolved, and what should cause the claim to be checked again.
Match the evidence to an action
Translate confidence into a permitted action
Define the states in your own register and use them consistently. High, medium and low describe the strength of support; held, disputed and unknown describe different unresolved conditions. A review date is a control on the decision, not a promise that the assertion remains true until that date.
| State | Evidence position | Permitted use and next action |
|---|---|---|
| High | Direct, relevant and sufficiently current evidence supports the exact assertion; no unresolved material contradiction. | Use within that documented scope. Keep the source and a review trigger; avoid extending the claim to other versions or markets. |
| Medium | Evidence supports a limited assertion, but a meaningful uncertainty remains. | Narrow or qualify the wording. State the unresolved dimension and name the evidence needed to strengthen it. |
| Low | Support is indirect, incomplete or too weak for the proposed current claim. | Do not present the broad assertion as an established fact. Seek stronger evidence or retain a clearly bounded research note. |
| Held | A dependency prevents a current decision, such as a major version change awaiting review. | Pause the dependent current claim. Preserve historical evidence and assign a concrete next check. |
| Disputed | Credible sources conflict within the same scope. | Keep both assertions and their dates. Escalate the contradiction; avoid choosing by convenience or source count. |
| Unknown | No usable evidence establishes the assertion. | Leave the entry unresolved. Unknown does not mean false, absent or incompatible. |
Separate the state from publication permission. A historical assertion with strong support may be suitable for a dated history passage but unsuitable for a current product recommendation. A disputed claim may need explicit attribution instead of deletion.
Write the assertion before assessing it
Name the entity ID, attribute or predicate, proposed entry, applicable version, market and effective period. “Connects to Platform B” is too broad if the source only describes Product A version 2 sending one type of record to Platform B version 4 in a particular environment.
Resolve identity first. Similar names, matching domains or repeated mentions together do not establish that two records are the same entity or that a strong relationship exists. Keep people, organizations, brands, products and versions distinct.
Record an explanation beside the state. A label such as high confidence is unhelpful if the next reader cannot see which source supports the assertion and what its scope excludes. The same entity can have different confidence decisions for its name, address, support status and connections to other systems.
Read the evidence dimensions separately
- AuthorityAsk if the source is entitled or well placed to establish this claim. A provider can state its own support policy; a test can show observed behavior in the tested setup.
- DirectnessSeparate an explicit statement from an inference. A page mentioning two products does not prove that they work together.
- IndependenceTrace sources to their origin. Different sites repeating one announcement are not independent confirmations of that announcement.
- FreshnessCompare the source date and last observation with the pace of change. An older record can remain useful for historical identity but miss a recent product release.
- Scope and contradictionCheck versions, environment, market and time. Two different entries are not necessarily contradictory if they apply to different periods; equally, a fresh source can still be about the wrong entity.
Do not average away a blocking weakness. Strong authority does not repair the wrong version, and freshness does not repair indirect evidence. If a numeric score is used internally, document the dimensions, weights and limits; a score without testing against observed outcomes should not be presented as a statistical probability.
A supported connection after a platform change
Illustrative scenario: Product A documentation states that version 2 works with Platform B version 4. The register records the source, its observation date and a decision of high confidence for that pair. Platform B then releases version 5. No source or test has yet been reviewed for the new pairing.
| Record | Decision now | Next evidence or action |
|---|---|---|
| A2 with B4 | Retain the supported historical assertion within its original period and environment. | Keep the original evidence. Check for notices changing support if the page makes a current claim. |
| A2 with B5 | Hold the current compatibility assertion. | Find current provider documentation and, where appropriate, test the specified behavior in the specified environment. |
| “Works with all B versions” | Reject this expansion of the evidence. | Narrow the visible statement and any dependent graph or structured data candidate to the supported pair. |
| Review record | Assign a reviewer and a dated next check, with release announcements as an earlier trigger. | Record what was checked, the remaining uncertainty and the decision that each result will permit. |
Lack of new evidence does not prove failure. If a test succeeds but provider support remains unconfirmed, record observed behavior and official support as separate assertions. If new documentation contradicts the old claim in the same scope, mark the conflict disputed and investigate.
Use both calendar dates and change events
Set a review interval that reflects volatility, consequences of error and available evidence. A durable identity record may need less frequent checking than price, availability, ownership or compatibility. There is no universal interval that makes every entity fact current.
Store the observation date separately from the source publication date, the assertion’s effective period and the next review date. Reading an old page today updates the observation date; it does not make the claim newly established. Keep any unknown date marked unknown.
Add event triggers: a source revision or removal, product release, ownership change, lifecycle event, market change or conflicting report. When a trigger occurs before the scheduled date, reopen the affected assertion and its dependents. A missed review date means review is overdue; it is not automatic evidence that the recorded assertion became false.
Assign an accountable owner, record the review outcome and list unresolved evidence requests. If support is no longer adequate for a current claim, narrow or pause that claim and mark related pages, tables and structured data candidates for review. Preserve the previous decision rather than overwriting its reason.
Questions about uncertainty and expiry
Can a trusted source justify permanent high confidence?
No. Confidence is tied to the assertion, source scope and relevant time. A trusted provider can change its policy, and an unchanged page can become incomplete after a release.
What is the difference between disputed and unknown?
Disputed means usable sources conflict in the same scope. Unknown means evidence is insufficient to establish the assertion. Each needs a different repair: reconcile the conflict or acquire missing support.
Should stale facts be deleted?
Decide by use. A supported historical statement can remain dated and attributed. A current claim needs current support appropriate to its subject; retaining the historical record does not justify presenting it as current.
What does an accepted review produce?
An exact assertion, evidence profile, reasoned state, permitted use, responsible owner, review date and change triggers. When the record is held, include the missing dependency and next action rather than forwarding it as accepted.
Related decisions and sources
Entity Version Compatibility Matrix
Define both versions, direction, environment and limitations before assessing a compatibility claim.
Entity Provenance Chain
Trace how evidence became the assertion being reviewed.
Entity Identity Evidence Register
Resolve which entity the sources describe.
Entity Predicate Library
Keep relationship wording consistent with the evidence.
Entity SEO
Find related entity methods.
RDF 1.1 Concepts
Read the inherited reference on graph statements. This page’s confidence labels are editorial states, not a claim that RDF assigns confidence probabilities.
The examples are teaching scenarios, not records of client work. The illustrations explain record separation and revision; they are not evidence of the assertions described. These editorial methods do not guarantee rankings, indexing, traffic, rich results, citations or AI feature inclusion.