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.
- Policy questions
- New versions
- Review dates
- Document intake
- Onboarding answers
- Conflicting copies
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
- An agent finds the current version of the relevant policy.
- It answers with the passage and the version it read.
- If no current policy covers it, the question goes to the owner.
New versions
Starts: An owner uploads a revised policy
- Show what changed from the current version.
- A reviewer approves.
- The new version becomes current, and the old one is kept as superseded.
Review dates
Starts: A document reaches its review date
- Ask the owner to confirm or revise it.
- The request waits until they answer.
- Documents still unreviewed are listed for the team.
Document intake
Starts: A new runbook or spec is uploaded
- Link it to the product or process it describes.
- The owner confirms the link.
- Questions about that product now cite it.
Onboarding answers
Starts: A new joiner asks a question
- An agent answers from the current documents.
- Every answer cites the versions it read.
- Unanswered questions go to the team that owns the topic.
Conflicting copies
Starts: Two documents disagree on the same rule
- Show both passages and their versions.
- The owner chooses which one is current.
- The other is marked superseded.