Skip to content

Bijection for Knowledge

Answers that cite the version they read.

Three copies of the policy, one of them current. Ask once and get an answer that names its source.


The travel policy exists in Confluence, in a Google Drive folder and in a PDF someone pinned in Slack. One of them is current. People ask in a channel, and the answer depends on who replies.

Bijection takes in each document as an immutable version and records which one is current. Answers, from people or agents, come back with the passage and the exact version they read.

  • Policy questions

    Starts: Someone asks a question in Slack

    1. An agent finds the current version of the relevant policy.
    2. It answers with the passage and the version it read.
    3. If no current policy covers it, the question goes to the owner.
  • New versions

    Starts: An owner uploads a revised policy

    1. Show what changed from the current version.
    2. A reviewer approves.
    3. The new version becomes current, and the old one is kept as superseded.
  • Review dates

    Starts: A document reaches its review date

    1. Ask the owner to confirm or revise it.
    2. The request waits until they answer.
    3. Documents still unreviewed are listed for the team.
  • Document intake

    Starts: A new runbook or spec is uploaded

    1. Link it to the product or process it describes.
    2. The owner confirms the link.
    3. Questions about that product now cite it.
  • Onboarding answers

    Starts: A new joiner asks a question

    1. An agent answers from the current documents.
    2. Every answer cites the versions it read.
    3. Unanswered questions go to the team that owns the topic.
  • Conflicting copies

    Starts: Two documents disagree on the same rule

    1. Show both passages and their versions.
    2. The owner chooses which one is current.
    3. The other is marked superseded.