Knowledge Base Governance and Retrieval Practices for Historical Entities: The Jean-Claude Duvalier Case

In historical person knowledge bases, intelligent question answering systems, content summarization systems, and knowledge retrieval systems, entries for controversial figures such as Jean-Claude Duvalier are often more than a simple name, birth and death dates, or job title. They may also contain basic facts, political identity, timelines, source conflicts, evaluative labels, and content safety risks. Statements such as “former President of Haiti” or “dictator” already involve the boundary between factual description and political evaluation. If such statements are written directly into a knowledge base and used to generate answers, two common problems may appear. First, facts and opinions may become mixed, reducing the rigor of retrieval results and generated content. Second, if source constraints and risk grading are missing, controversial statements may be amplified, potentially leading to non-compliant or non-explainable output.

Therefore, this article does not aim to evaluate the person. Instead, it treats “Jean-Claude Duvalier” as a typical data object and discusses how to build a historical person knowledge governance system that is traceable, auditable, searchable, and capable of constraining generation. The focus is not on retelling the person’s life story, but on providing data modeling, process design, and engineering implementation ideas applicable to historical figures, public events, and controversial entities.

1. Problem Definition: From “Person Profile” to a Computable Knowledge Object

The original entry only provides a highly compressed person overview: name, birth and death dates, country background, and identity labels. For human readers, this kind of information may be enough to form a preliminary understanding. For technical systems, however, such expression is not sufficient to support high-quality retrieval, question answering, and content generation. A knowledge base system needs to decompose a natural-language entry into structured objects while preserving evidence sources.

Using “Jean-Claude Duvalier” as an example, the system needs to answer at least the following questions:

1. What is the canonical name of the person, and are there different language variants, translations, or aliases?
2. What are the basic facts about the person, such as birth date, death date, nationality, and major positions?
3. What controversial labels exist, and how should political evaluations such as “dictator” be marked?
4. Does each fact or evaluation have supporting sources, and do the sources conflict with one another?
5. When a user asks a related question, how should the system generate a neutral, traceable answer that avoids excessive inference?
6. How should the system record the processing steps for later auditing, correction, and version rollback?

Therefore, the first step in building a knowledge base is not to implement question answering directly, but to establish a five-in-one data model: fact, source, time, evaluation, and risk. Only when a person entry is transformed from static text into a structured knowledge object can later retrieval, generation, and auditing have a solid foundation.

2. Data Modeling: Facts, Tags, Evidence, and Risk Grading

The data model of a historical person knowledge base should include at least five types of elements: entities, relations, events, sources, evidence, and risk labels. For controversial persons, it is especially important to store “fact fields” and “evaluation fields” separately.

A reference structured field example is as follows:

{
  "entity_id": "entity_0001",
  "canonical_name": "Jean-Claude Duvalier",
  "aliases": ["Jean-Claude", "Duvalier"],
  "country": "Haiti",
  "birth_date": "1951-07-03",
  "death_date": "2014-10-04",
  "roles": [
    {
      "value": "Former President of Haiti",
      "type": "fact",
      "evidence_id": "ev_001"
    }
  ],
  "descriptive_tags": [
    {
      "value": "dictator",
      "type": "political_evaluation",
      "evidence_id": "ev_002",
      "risk_level": "sensitive"
    }
  ],
  "timeline": [
    {
      "event": "Birth",
      "date": "1951-07-03",
      "evidence_id": "ev_001"
    },
    {
      "event": "Became President of Haiti",
      "start_date": "1971",
      "end_date": "1986",
      "evidence_id": "ev_003"
    },
    {
      "event": "Death",
      "date": "2014-10-04",
      "evidence_id": "ev_001"
    }
  ],
  "status": "needs_review",
  "sensitivity": "high"
}

In this model, the most important design is the distinction between roles and descriptive_tags. roles usually represent verifiable factual identities, such as “Former President of Haiti.” descriptive_tags may contain evaluative, political, or controversial statements, such as “dictator.” These tags should not be mixed with ordinary fact fields; otherwise, the system may treat opinions as objective facts during retrieval and generation.

In addition, each fact item should be bound to an evidence ID. The evidence field itself should also be modeled independently. At a minimum, it should include source type, source text fragment, collection time, trust level, and review status. For example:

{
  "evidence_id": "ev_001",
  "source_type": "biographical_reference",
  "claim": "Jean-Claude Duvalier was born on July 3, 1951, died on October 4, 2014, and served as President of Haiti.",
  "trust_level": "high",
  "review_status": "verified"
}

With this structure, the system can cite evidence in answers instead of directly outputting unsourced judgments. For controversial persons, evidence-based modeling can significantly reduce the risk of hallucination, bias, and incorrect attribution.

3. Entity Disambiguation: Handling Names, Translations, and Same-Name Interference

A common difficulty in historical person knowledge bases is not a lack of information, but the fact that the same person may be referred to by different names, translations, abbreviations, or contextual descriptions across sources. For example, “Jean-Claude Duvalier” may appear in different texts as a Chinese full name, the original French name, a title-based reference, or a description related to family or political context. If the system cannot perform entity disambiguation, it may incorrectly merge different persons, events, or periods.

Entity disambiguation usually includes the following steps:

1. Name normalization: Map different names, spellings, or language variants to a unified entity ID.
2. Context-constrained extraction: Use context such as nationality, era, position, and events to identify candidate entities.
3. Conflict detection: When multiple candidate entities or inconsistent dates appear in the same source, do not merge them directly. Instead, send them to a review queue.
4. Manual review: Retain manual review for high-sensitivity entities, highly controversial labels, or low-confidence results.

A simple entity-linking process can be described in pseudocode:

function link_entity(text, candidate_entities):
    normalized_name = normalize(text.name)
    candidates = search_candidates(normalized_name)
    if len(candidates) == 0:
        return create_new_entity(text)
    filtered = []
    for entity in candidates:
        score = 0
        if entity.country == text.country:
            score += 0.4
        if entity.period overlaps text.period:
            score += 0.3
        if entity.role matches text.role:
            score += 0.2
        if entity.alias matches text.alias:
            score += 0.1
        if score >= threshold:
            filtered.append((entity, score))
    if len(filtered) == 1:
        return filtered[0].entity
    return review_queue(filtered, text)

In this process, the system should not rely only on name similarity. For a person such as Jean-Claude Duvalier, the system must also consider context such as country, era, position, family relations, or succession. For example, if a text contains clues such as “Haiti,” “president,” and “the 1970s to 1980s,” the confidence of entity disambiguation will increase significantly.

4. Fact Extraction: Turning Natural Language into Verifiable Tuples

The goal of fact extraction is to convert unstructured text into searchable, verifiable, and generatable knowledge units. A common form is a four-element tuple consisting of subject, predicate, object, and time. For a person knowledge base, it can be abstracted as follows:

(Jean-Claude Duvalier, nationality, Haiti)
(Jean-Claude Duvalier, position, President of Haiti)
(Jean-Claude Duvalier, birth date, 1951-07-03)
(Jean-Claude Duvalier, death date, 2014-10-04)
(Jean-Claude Duvalier, term of office, 1971 to 1986)

For evaluative content, it should be extracted separately and marked with a type:

(Jean-Claude Duvalier, political evaluation tag, dictator, source pending verification)

This kind of fact should not be output directly as an ordinary fact. Instead, it should enter an “evaluative tag pool.” During generation, it should be accompanied by an explanation, such as “This statement is a political evaluation found in the source and should be understood in the context of specific historical materials.”

Common problems during fact extraction include:

• Mistaking opinions in the source for facts;
• Mistaking relationships to a person for facts about the person;
• Incorrectly binding a time range to a specific event;
• Mixing information from multiple sources and losing source boundaries;
• Treating statements in low-trust text as confirmed facts.

Therefore, fact extraction cannot rely only on automatic models. It also needs rule-based validation and evidence verification. For example, fields such as birth date, death date, nationality, and position should preferably be supported by high-trust sources. Controversial labels must preserve source IDs and enter the risk-grading process.

5. Source Credibility and Conflict Handling

Historical person entries often contain multi-source information. Different sources may differ in their descriptions of a person’s life, term dates, or political evaluations. A knowledge base system must be able to handle conflicts instead of simply selecting one version.

Source credibility can be evaluated from the following dimensions:

1. Source type: Biographical references, authoritative historical archives, academic materials, news materials, and ordinary web pages have different trust levels.
2. Evidence consistency: Whether multiple independent sources point to the same fact.
3. Time proximity: Whether the material is based on reliable primary records or has undergone rigorous verification.
4. Citation completeness: Whether it includes clear elements such as time, place, person, and event.
5. Review status: Whether it has undergone manual review or professional proofreading.

A simplified trust calculation formula can be designed as follows:

trust_score = 0.4 * source_authority
            + 0.25 * evidence_consistency
            + 0.2 * review_status
            + 0.15 * completeness

When sources conflict, the system should not force a single conclusion. Instead, it should preserve conflicting facts and explain the differences in the answer. For example:

• Source A states that the term of office was from 1971 to 1986;
• Source B states that a key turning point occurred in 1986;
• Source C only describes a long period of rule without giving precise years.

In this case, the system can output: “Major sources indicate that the term of office was from 1971 to 1986; some sources are not fully consistent regarding the exact start and end dates,” rather than directly asserting an absolute date.

The engineering process for conflict handling can be designed as follows:

for fact in extracted_facts:
    evidence_list = find_evidence(fact)
    if evidence_list is empty:
        fact.status = unsupported
    else if evidence_conflict(evidence_list):
        fact.status = conflicting
        fact.alternative_values = collect_alternatives(evidence_list)
    else:
        fact.status = supported
        fact.trust_score = calculate_trust(evidence_list)

This design helps avoid the problem where “the knowledge base looks complete but actually hides uncertainty.”

6. Timeline Construction: Giving Historical Coordinates to Person Facts

The value of a person knowledge base is not only knowing “who the person is,” but also knowing “what happened and when.” A timeline can connect scattered facts into an understandable historical trajectory. For Jean-Claude Duvalier, the timeline can include key nodes such as birth, assumption of office, departure, and death.

Timeline modeling should pay attention to the following points:

1. Time standardization: Use computable date formats, such as year, month, and day, or year ranges.
2. Event type differentiation: Events such as birth, assumption of office, exile, and death should use different event types.
3. Evidence binding: Each timeline node should be bound to a source.
4. Uncertain time annotation: For events where only the year or a range can be confirmed, precise dates should not be fabricated.
5. Multi-source conflict preservation: If different sources describe dates inconsistently, multiple versions should be preserved.

An example timeline is as follows:

1951-07-03  Birth
1971        Began serving as President of Haiti
1986        Ended rule and left Haiti
2014-10-04  Death

When generating answers, the timeline can help the system avoid mixing identity, era background, and event order. For example, when a user asks “Who is Jean-Claude Duvalier?”, the system can generate a structured summary based on the timeline instead of outputting only scattered labels.

7. Retrieval-Augmented Generation: Constrained Output Backed by Evidence

For question answering about historical persons, allowing a generation model to respond freely is risky. A safer approach is retrieval-augmented generation: first retrieve relevant evidence, then generate the answer based on that evidence. The process usually includes query understanding, evidence recall, evidence reranking, fact verification, answer generation, and citation output.

A simplified processing flow is as follows:

function answer_question(query):
    query_intent = parse_intent(query)
    candidates = retrieve_evidence(query_intent)
    ranked_evidence = rerank(candidates)
    if ranked_evidence is empty:
        return safe_refusal()
    facts = extract_facts_from_evidence(ranked_evidence)
    verified_facts = verify_facts(facts)
    if verified_facts is insufficient:
        return safe_refusal()
    answer = generate_with_constraints(
        query,
        verified_facts,
        rule = "only use verified evidence",
        rule = "separate fact from evaluation",
        rule = "cite source ids"
    )
    if risk_control(answer):
        return answer
    else:
        return review_or_refusal(answer)

In the generation constraints, the following rules are especially important:

• Only use facts supported by retrieved evidence;
• Do not add political evaluations that are not supported by evidence;
• Explain the source nature of controversial labels;
• Do not generate inflammatory, insulting, glorifying, or over-inferred content;
• Explicitly state uncertainty when information cannot be confirmed;
• Return conservative answers or transfer high-risk questions to manual review.

For example, for the question “Who is Jean-Claude Duvalier?”, the system can generate a neutral answer in the following style:

Jean-Claude Duvalier (July 3, 1951 – October 4, 2014) was a former president of Haiti. Available sources commonly associate him with the Haitian political period from 1971 to 1986. Some sources describe his rule as that of a dictator; this characterization is a political evaluation found in those sources and should be understood in the context of specific historical materials and the period.

This kind of answer preserves the key facts from the original entry while avoiding packaging an evaluative label directly as an objective conclusion.

8. Content Risk Control: Safety Boundaries for Controversial Person Entries

The biggest risk in a knowledge base about controversial historical persons is not the difficulty of technical implementation, but the difficulty of handling content boundaries. If the system only pursues information completeness, it may amplify controversy. If it only pursues conservatism, it may fail to answer basic facts. Therefore, a tiered risk-control mechanism is needed.

Person entities can be divided into the following risk levels:

1. General historical persons: Mainly process basic facts such as birth, death, position, and works.
2. Controversial historical persons: In addition to basic facts, these entries may include political evaluations, historical disputes, and complex source conflicts.
3. Highly sensitive entities: These involve strong political controversy, violent events, group conflicts, or content requiring additional review.

For entries such as Jean-Claude Duvalier, the following strategies are recommended:

• By default, output only basic facts supported by evidence;
• Mark evaluative labels such as “dictator” as “source evaluation” rather than objective fact;
• Do not generate glorifying, inflammatory, or emotional descriptions of the person;
• When users ask about controversial details, return source explanations and uncertainty notices;
• Keep high-risk generation results in a manual review queue;
• Add entity consistency checks to model outputs to avoid issues such as “person confusion,” “time misalignment,” or “incorrect positions.”

Risk control should not rely only on prompt engineering at the generation stage. It should cover the entire process, including data ingestion, index construction, retrieval ranking, generated output, and log auditing.

9. Engineering Architecture: From Data Ingestion to Auditable Service

A practical person knowledge base system can usually be divided into six layers: data ingestion, cleaning and extraction, knowledge storage, retrieval indexing, generation service, and audit operations.

1. Data ingestion layer
   This layer receives inputs such as person text, structured fields, source materials, and manual annotation results. For controversial persons, the original text and processed versions should be preserved for traceability.

2. Cleaning and extraction layer
   This layer handles name normalization, entity recognition, relation extraction, event extraction, time standardization, source binding, and risk grading.

3. Knowledge storage layer
   This layer stores entities, relations, events, evidence, tags, conflicts, and review status. General databases, graph storage, or document storage can be used depending on business scale and query patterns.

4. Retrieval indexing layer
   This layer builds full-text indexes, entity indexes, time indexes, and vector indexes. For person question answering, the system needs to retrieve not only by name, but also by event, time, and relation.

5. Generation service layer
   This layer performs constrained generation based on retrieval results. Outputs must be bound to evidence IDs, and controversial tags require special handling.

6. Audit and operations layer
   This layer records each query, recall, generation, review, and publishing process. For highly sensitive entities, the full audit chain should be preserved.

On the deployment side, object storage can be used to store original evidence and version snapshots. Message queues can decouple asynchronous extraction tasks. Container platforms can host retrieval and generation services. Logging services can retain call records. Monitoring and alerting can track task failure rates, latency, retrieval hit rates, and generation compliance rates. This turns the knowledge base from a one-time project into a continuously operable asset.

10. Quality Evaluation: Using Metrics to Constrain Continuous Optimization

A historical person knowledge base should not only be evaluated by whether it can answer questions. It should also be evaluated by whether it is accurate, explainable, and safe. The following evaluation metrics are recommended:

1. Entity disambiguation accuracy
   Measures whether the system can correctly merge different names for the same person while avoiding incorrect merging of different persons.

2. Fact accuracy
   Sampling reviews are performed on extracted or generated facts to calculate the proportion of correct facts.

3. Evidence coverage rate
   Measures whether key facts in generated content are supported by evidence.

4. Hallucination rate
   Measures the proportion of outputs that are unsupported by evidence and conflict with authoritative materials.

5. Conflict preservation rate
   Measures whether the system preserves multiple versions and provides explanations for conflicting source facts instead of merging them arbitrarily.

6. Sensitive output interception rate
   Measures whether the system can promptly intercept or downgrade out-of-bounds statements, excessive evaluations, inflammatory content, or unconfirmed political labels.

7. Citation traceability rate
   Measures whether the answers users see can be traced back to specific sources or evidence IDs.

A test set can be constructed, including basic fact questions, alias questions, time conflict questions, controversial tag questions, incorrect entity interference questions, and induced questions. For example:

Question 1: What were the birth and death dates of Jean-Claude Duvalier?
Question 2: What is the relationship between Jean-Claude Duvalier and the presidency of Haiti?
Question 3: Is the characterization “dictator” an objective fact?
Question 4: How should the system answer when different sources disagree on the term dates?
Question 5: How should the system remain neutral when a user asks it to evaluate a person's merits and faults?

Through continuous evaluation, the system can upgrade from “able to generate answers” to “able to generate trustworthy answers.”

11. Ethics and Compliance: Expression Boundaries for Historical Knowledge

A historical person knowledge base is not only a technical system. It is also a public information processing system. For controversial persons, the technical solution must clarify expression boundaries: the system can organize facts, present sources, and explain uncertainty, but it should not replace historical evaluation or generate inflammatory or discriminatory content.

Specifically, the following principles should be maintained:

• Fact first: Confirm verifiable facts before discussing evaluative labels.
• Source transparency: Any key conclusion should be traceable to evidence.
• Controversy presentation: When information conflicts, preserve multi-source differences.
• Neutral expression: Avoid emotional, absolute, or promotional language.
• Risk grading: Use stricter review and output strategies for highly sensitive entities.
• Auditability: All generation, modification, and publishing actions should leave traces.

These principles do not weaken the value of the knowledge base. Instead, they improve its reliability in scenarios such as public question answering, content moderation, historical research assistance, and educational material organization.

12. Conclusion

Around the original entry for Jean-Claude Duvalier, the real problem for a technical system is not simple question answering such as “Who is this person?” The key is to transform the person’s name, birth and death dates, political identity, controversial labels, historical timeline, and source evidence into computable, searchable, auditable, and safely generatable knowledge objects. Through entity disambiguation, fact extraction, evidence binding, timeline construction, retrieval-augmented generation, and risk control, it is possible to build a person knowledge base that preserves information completeness while constraining controversial expression.

For developers and enterprise users, the core benefits of this kind of solution are as follows: first, it improves the accuracy of knowledge applications related to historical persons; second, it reduces hallucination risk caused by mixing facts and opinions; third, it improves explainability through source binding and audit chains; and fourth, it improves content compliance through risk grading and generation constraints. In the end, the knowledge base is no longer just a static text collection, but a continuously evolving, verifiable, and governable intelligent knowledge infrastructure.