CACrown ArchivesThe cinema collection
Menu
Research dossier · General Reference

Byzantine fault

Fault in a computer system that presents different symptoms to different observers

Cross-disciplinary reference desk with index cards, atlas, dictionary and catalogue
General referenceInterpretive dossier study · Crown Archives visual atlas
Record originEnglish Wikipedia
Text licenseCC BY-SA 4.0
Source revisionJul 2, 2026
Entity authoritySource title only
Source-derived summary

A Byzantine fault is a condition of a system, particularly a distributed computing system, where a fault occurs such that different symptoms are presented to different observers, including imperfect information on whether a system component has failed. The term takes its name from an allegory, the "Byzantine generals problem", developed to describe a situation in which, to avoid catastrophic failure of a system, the system's actors must agree on a strategy, but some of these actors are unreliable in a way which causes other (good) actors to disagree on the strategy and they may be unaware of the disagreement.

Editorial summary

Begin with the source’s own compact description: “Byzantine fault” is fault in a computer system that presents different symptoms to different observers. The dossier treats that line as a proposition to test through Byzantine, fault and Fault, not as a finished interpretation.

Editorial reviewA dependable orientation record for establishing vocabulary, names and a first evidence trail. The current 99-word lead offers orientation but no explicit four-digit date, so chronology should not be assumed. The selected authority fields contribute no independent date. For this dossier, Byzantine, fault and Fault is the immediate research focus.
Editorial analysis

Why this record matters

The phrase “fault in a computer system that presents different symptoms to different observers” supplies a clear boundary for inquiry. It also exposes the unanswered questions: who defined that boundary, when it became stable and which sources sit outside it.

Evidence profile

Vocabulary and entity names are the principal evidence signals here, because they determine the precision of every later search. The source revision retrieved here is dated Jul 2, 2026.

Critical limits

Overview language is designed for orientation and should not be treated as a substitute for the evidence cited beneath it. The source lead contains qualifying language; that uncertainty should survive quotation, summary and reuse. Authority statements aid reconciliation but still require their own references, qualifiers and ranks to be checked.

How to read it

Use the entry as an orientation point, then follow its citations and revision history. Names, dates and institutional relationships should be checked against the original record.

Best used for
  • Subject orientation
  • Search vocabulary
  • Locating named sources
Verify next

The closest primary source, responsible institution and strongest cited specialist reference.

Three-step research path

  1. Establish the record: confirm the title “Byzantine fault”, its source revision and the description used here.
  2. Expand the search: follow Byzantine fault primary sources, Byzantine fault archive and Byzantine research across catalogues and specialist indexes.
  3. Test the account: compare the strongest cited source with the responsible institution’s current record and note any disagreement.

Questions for further research

  1. Which source most directly establishes the central claim about “Byzantine fault”?
  2. Which institution is responsible for the underlying evidence?
  3. Which cited source is closest to the event, object or claim?
Subject index

Search terms from this dossier

Source & attribution

This entry incorporates text from Byzantine fault” on English Wikipedia. Contributors are listed in the page history. Text is available under the Creative Commons Attribution-ShareAlike 4.0 License. Selected authority identifiers and statements are retrieved from Wikidata under CC0; their references and qualifiers remain part of the verification path.