What must change before a sales demo uses real data? — SalesWiki, Part 4 of 5

The public demo uses invented accounts. You can trace an answer to its sources and see how a correction enters review.

If you are responsible for sales or marketing operations, the practical question is what it would take to test one real decision without exposing customer data or mistaking a convincing demo for proof that it helps.

In Part 3, I chose one repeated decision to test: which account needs attention today, and why? This article looks at how to run the synthetic demo, where real data belongs, and what a private pilot would need to prove. The demo itself does not show that the workflow helps a real team.

The boundary is simple: the public repository holds the platform, its demo holds synthetic cards, and real customer data belongs in a separate private vault.

Contour	Location	Data rule
Platform	Public SalesWiki repository	Code, schemas, templates and docs
Demo	demo/ inside the repository	Synthetic cards only
Pilot	A separate private vault outside the repository	Real accounts, deals, contacts and transcripts

The public preview can run locally or for one operator, and Docker can run its checks. It is not a shared hosted service yet.

Inspect the synthetic demo

The public Knowledge Workbench
is the quickest way to see the synthetic workflow. Select Tour in the top
bar. Its seven-step quick tour takes about two minutes: it checks dated evidence
when a signal is stale, shows how roles get different views of shared evidence,
and follows an answer to its sources. The stale step asks the user to check the
evidence; the demo does not know why a review was late. The tour does not submit
a proposal or change a card.

To run the demo locally, clone the
public repository and run
python3 scripts/first_run.py. The README
covers the full setup, including Obsidian and clients that connect to the demo.
This verifies the synthetic setup; it does not show whether the workflow helps
a real team.

Keep the data boundary in place

The health check blocks a pilot/ folder or a card marked dataset: pilot
inside the public repository. The gateway reads from a separately configured
private vault. This keeps pilot data outside the public demo; it is a repository
safeguard, not a complete access-control system.

Start a private pilot carefully

Do not copy real customer records or call transcripts into this repository.
Create a separate access-controlled vault with no public remote. Keep
personal-data bodies out of Git. Use external restricted references where
needed.

The repository includes a pilot runbook at:

docs/engineering/permissioned-knowledge-pilot-runbook.md

The smallest useful pilot tests one repeated decision. The runbook starts with
a possible sales question: which lead needs a follow-up today, and why? Part 3
used a related account-follow-up question. Before a real pilot begins, the team
should choose one exact decision and keep it fixed. The runbook describes a
plan; it is not evidence that a real team has tested the workflow. A later
marketing pilot can use the same method once its decision and success criteria
are clear.

A useful pilot should prove more than document retrieval. Continue only if real
work validates all four points:

1. The cited answer helps people make the chosen decision with less searching than their current workflow.
2. At least one correction is clearer or safer after a proposal, review and controlled update.
3. Keeping the data and access rules under the team's control solves a real need.
4. Users can explain why they chose the action and what evidence would change it.

If the pilot mainly proves that people want document search or summarization, an
existing product may be the cheaper answer.

Before the first real account enters the pilot, write down the test plan: the
decision, the allowed evidence, the current workflow, and what would make the
team stop or change direction. Count an answer without a source, restricted
information reaching the wrong person, or an action the user cannot explain as
a failed case. Do not change the allowed sources, access rules and answer
format all at once; otherwise the team will not know what caused an improvement
or a failure.

I would also record what happens when a fact needs review. A stale flag tells
us that a review window passed; by itself, it does not tell us whether a source
changed, a sync failed, or no one owned the task. In the private pilot log, I
would note when the check was due, noticed, assigned and resolved; the review
result; the likely cause (or unknown); and whether it could have changed the
decision. I would keep customer text and contact details out of that log, using
only a private record handle and a restricted source link.

That distinction follows public data-quality guidance: assess quality against
the intended use, track recurring issues, and investigate causes before choosing
a fix. The Government Data Quality Framework
describes that loop, and its issues framework
puts impact and priority into the response. This is a method for the pilot to
test; it is not a claim that SalesWiki currently diagnoses stale records.

For an early pilot, I would use the roles and team boundaries already in place.
The account owner sees the next check. Someone responsible for sales operations
or knowledge quality can review process patterns within their existing access.
Department leads see team-level summaries. I would not add a separate audit
role until a multi-user pilot shows a need for independent review. If that need
appears, the role should be read-only and show review-event details, not
customer records.

What production deployment still needs

Before shared production use, add:

• a sign-in system that verifies the user on every request;
• securely stored connector credentials with limited access;
• backup and restore drills;
• operational logs, monitoring and limits on request volume;
• incident response;
• external storage that can delete personal data.

In the public Docker Compose preview, the demo can read files but cannot change
them; only its named runtime volume is writable. A production setup would need
a separate worker with controlled write access to the private vault. Docker
does not provide user identity or access control by itself.

A practical evaluation checklist

After trying the demo, you should be able to answer these questions:

• Can a person trace the answer to a dated source and see what is missing?
• Do people see only the information allowed for their role and task?
• Does missing or conflicting evidence lead to a check instead of a guess?
• Does a correction wait for review before the card changes?
• Can the team tell whether an old fact came from a changed source, a missed sync, an unowned check, or an unknown cause?
• Will real pilot data stay outside the public repository?

If those properties match your requirements, clone the
SalesWiki repository and run
the demo. Then choose one repeated sales or marketing decision and compare the
cited workflow with the way the team handles it today. That comparison, including
where SalesWiki gets in the way, is the evidence the next version needs.

Continue the series

Previous: What should a sales knowledge base help someone decide?

Next: When does an integration help a sales decision?