Using proof without breaking confidentiality

The expert’s dilemma

Your strongest credibility often comes from work you cannot talk about: a migration at a bank, a restructuring at a client, an incident you resolved. Staying silent wastes that experience. Sharing details can break a contract or a trust. The way through is to separate what the work proves from what the work was.

Two kinds of proof

• Public proof: talks, articles, open-source work, public case studies, products, certifications. You can cite it, link it and name it.
• Reference-only proof: confidential projects, internal metrics, client outcomes. It informs what you say and how confidently you say it, but its specifics never appear in public.

Write the list down and mark each item. Tractionim treats reference-only proof as material for judgment only: it is never quoted, and its specifics are kept out of anything it drafts.

Write the pattern, not the case

Instead of describing what happened at a named client, describe what you learned that generalises. "During the core banking migration at a top-five Dutch bank, we cut nightly batch time by 43 percent in Q3" identifies the client, the project and the period. "Incremental replacement works when you decouple at the integration boundary first, not at the user interface" carries the same authority and identifies no one.

Details that usually identify

• Names of employers, clients, systems and colleagues.
• Exact figures: budgets, user counts, percentages, dates.
• Distinctive combinations: industry plus country plus size can be enough.
• Screenshots, diagrams and internal terminology.
• Incidents that were reported in the news.

Set boundaries once

Decide in advance which topics are off limits, which client rules apply, and what always needs your review before publishing. When these are written down, each post becomes a simple check instead of a new judgment call. If you are unsure whether something identifies a client, treat it as reference only.

Build public proof deliberately

If most of your proof is private, make creating public proof part of the strategy: a talk, a write-up of a generalised method, a small open artefact, a clearly hypothetical worked example. Over time, public proof lets you speak with the authority your private work already earned.

A check before you publish

1. Could a colleague at the client or employer recognise the situation from this post?
2. Does it contain a name, number, date, screenshot or internal term from private work?
3. Would you be comfortable if the client read it tomorrow?
4. Is the claim still true and useful without the identifying detail?
5. Does it touch a topic on your boundaries list or one that needs review?

If any answer is uncomfortable, generalise further or keep the material as reference only.

When to ask for permission

Some outcomes are worth asking to share: a public case study, a joint talk, a quote. Ask in writing, say exactly what you want to publish, and keep the approval. Many clients agree when the story makes them look good and identifies nothing sensitive. Until you have that approval, the material stays reference only.

Formats that turn private work into public proof

• A method write-up: the steps you follow, illustrated with a clearly hypothetical example.
• A talk at a meetup or conference about the pattern, not the client.
• A small open artefact: a template, a checklist, a script others can use.
• An annotated decision: the trade-offs you weigh in a recurring situation.
• A teardown of public material in your field, using your private experience as judgment.