Three questions that test company memory
Ask who owns it, what changed, and why it was decided. The effort required to answer reveals whether your company context actually works.
Most internal knowledge demos begin with an easy question.
“What is our refund policy?”
The system finds a document and returns a clean summary. That proves retrieval works. It does not prove the system understands the operation.
Use three harder questions instead:
- Who owns this?
- What changed?
- Why did we decide this?
The effort required to answer them reveals how much company context is still trapped between tools and people.
Who owns this?
Ownership sounds like a field in a project tool. In practice, several kinds of ownership may exist.
One person is assigned the task. Another owns the customer relationship. A manager approves the exception. A technical lead decides how the work is done.
When someone asks who owns a customer escalation, returning the task assignee may be misleading. The answer may require the CRM account owner, the support ticket, the latest meeting, and the decision that changed responsibility.
GitLab’s public handbook uses the idea of a Directly Responsible Individual for decisions. The useful part is not the acronym. It is the discipline of making one accountable person visible.
For every important work item, the system should distinguish who is doing the work, who owns the outcome, and who can approve a change.
What changed?
Most business software is good at showing the current state.
The opportunity is in negotiation. The project deadline is September 10. The ticket priority is high.
The current state does not explain what changed since the last review.
Did the customer add a requirement? Did a dependency fail? Did leadership move the deadline? Did the task return to active because the previous fix did not work?
Answering “what changed?” requires a time ordered view across systems. It may combine field history, messages, meeting notes, document edits, and reassignment events.
A useful answer is selective. It should surface the changes that affect the decision in front of the employee, not replay every notification.
Why did we decide this?
Decision reasoning disappears quickly.
The final project plan is saved. The discussion that shaped it remains in a meeting. Three months later, a new employee sees the plan and proposes the option the team already rejected.
A decision record does not need to be long. It should capture:
- What was decided.
- Who owned the decision.
- When it happened.
- The main reason.
- Important alternatives that were rejected.
- The work affected by the choice.
- Links to the original discussion or evidence.
GitLab’s developing decision log model includes structured decisions with status, author, date, and optional assignee. The larger lesson is useful for any company: treat a decision as an operating record, not a sentence that disappears inside a conversation.
Run the test on one active project
Choose a project that has changed several times.
Ask three employees the same questions. Then try to answer using the company’s existing systems without asking the project lead.
Measure:
- How many tools were opened?
- How long did the answer take?
- Did different employees reach different conclusions?
- Could they identify the original evidence?
- Did access rules change what each employee could see?
This gives you a practical baseline. It also shows which sources should be connected first.
Do not hide uncertainty
Sometimes the company did not record why a decision was made. A good system should say that.
It can show the current owner, the last change, and the available discussion without inventing a reason. It can ask the owner to confirm the missing context and then preserve the correction.
Trust improves when the system distinguishes evidence from inference.
Turn answers into operating habits
The long term fix is not only better search.
Make ownership explicit when work begins. Capture important changes as events. Record decisions during the meeting or approval where they happen. Link actions back to the decision.
The Business Brain can then assemble those records into a current answer with sources.
If your company can answer who owns it, what changed, and why it was decided, employees can continue the work.
If it can only find the document, the important part is still living somewhere else.
Questions people ask
How do you evaluate an internal knowledge system?
Test it with real multi source questions that require current ownership, recent changes, decision history, permissions, and citations. Document retrieval alone is not enough.
What should a decision record contain?
Record the decision, date, owner, participants, reasoning, alternatives considered, affected work, follow up actions, and links to the original evidence.
Why is ownership often unclear?
Ownership changes across projects and systems, and many tools store assignees without showing who is accountable for the decision or next action.