A maintained wiki needs claims that can survive revision

Someone corrects a paragraph in a generated wiki. The next import rewrites the page, restoring the original mistake and removing the explanation. A change log may show that the file was updated, but it cannot explain why the human correction disappeared unless the application records who owns the text and which version the generator used.

A maintained knowledge base has to manage evidence and editing together. Its pages may be readable Markdown, but their claims need source relationships, and its update procedure needs to distinguish new evidence from a competing edit. Otherwise, automatic maintenance can repeatedly undo the very review intended to make the collection reliable.

The Boris integration specification describes a proposed source-backed wiki within an agent application. It separates original sources, maintained pages, and ingestion or query workflows. Material claims resolve to source versions and supporting spans. Human edits are preserved through base-version comparison and, where suitable, a three-way merge. These are specified capabilities, not an independently verified integration.

Follow one claim through an update

A claim record should identify what is being asserted and which evidence supports it. Include the source identifier, content version, original locator, relevant dates, and access rules. A link to an entire document may be useful navigation, but it is too broad to establish which passage supports a particular sentence.

Track observation time separately from the period the claim describes. A page imported today can state a rule that expired last year, so when a later source supersedes that rule, preserve the earlier claim with its historical scope and record the superseding relationship. That gives a reader a way to understand both current guidance and an older decision.

The wiki’s readable paragraph can summarize several claims. Keep the underlying relationships inspectable so that editing a sentence does not silently detach it from the evidence. Important answers should reopen the supporting source spans before presenting the claim as current.

An illustrative editing conflict

Imagine a hypothetical equipment guide. A source manual says that a device requires a particular adapter. The wiki summarizes that requirement, and a human editor adds a note explaining which connector label appears on the device. Later, a revised manual changes the adapter requirement.

The ingestion worker prepares an update against the page version it originally read. Before saving, it compares that base version with the current page. If the human changed a different paragraph, the application may be able to preserve both changes automatically. If both edits alter the same requirement, the application should present the overlapping text for review.

A three-way merge compares the original base, the current human-edited version, and the proposed generated version. Its purpose is to preserve compatible work and expose actual conflicts. It cannot decide whether an unsupported human sentence is factually correct merely because a person wrote it, so factual validation remains a separate responsibility.

After review, save the accepted page and its claim changes as one coherent operation. If the process stops halfway through, recovery should complete or undo the recorded update rather than leave the page describing one state while the claim database describes another. This equipment example is a teaching fixture, not a report of a tested Boris workflow.

Search must respect the same corrections

A corrected page is insufficient if an old search snippet still supplies the previous requirement, because source changes can affect indexes, cached summaries, backlinks, and answers prepared for later use from the same material. Maintain the dependency relationships needed to mark or rebuild those derivatives when the supporting source changes.

Permission changes require similar care. Removing access to a source should not leave its content exposed through a generated summary. Apply the relevant rules to derived material, then test retrieval using the affected identity. A page can be factually accurate and still be inappropriate for that reader to receive.

Start with a deliberately small update test. Create one source, one supported claim, and one readable page. Add a human correction, revise the source, and interrupt the next update before completion. Inspect the recovered page, database record, and search result together. The update is ready for broader use only when the accepted claim retains its support and the human edit is either preserved or explicitly presented for resolution.

Source notes

Based on section 7 of the September 2026 Boris Integration Specification. The equipment guide and recovery test are illustrative; the complete integration was not independently verified.