Book an audit
A living operating manual for growing companies

Your wiki isn't wrong because nobody wrote it. It's wrong because nobody updated it.

I build a manual that assembles itself from work already happening — decisions in Slack, changes in tickets, the way things are actually done — and flags every page that has gone stale, with the evidence that it has. Writing documentation is a project. Keeping it true is the product.

Look inside one Why the last one failed

Runs in your infrastructure, on the tools you already use. Nothing new for your team to remember to update.

Northgate Supply — Operating Manual Sample company · not live data
— — —

—

Assembled from

Note the coloured dots. A manual that can't tell you which pages to distrust is just a longer way of being wrong. Staleness is the feature — the writing is the easy part.

The pattern

Every company has done this before. Here's how it went.

Someone spent three weeks writing it in a burst of enthusiasm. Eighteen months later nobody opens it, and the people who do get burned.

01

Writing it was a project with an end date

Documentation gets treated as a deliverable, so it's accurate on the day it ships and decays from there. Nobody scheduled the maintenance, because maintenance has no completion date to celebrate.

02

The reward for updating it is zero

Changing a process is urgent. Documenting that you changed it is not. Everyone knows this, which is why the wiki describes a company that stopped existing some time in 2024.

03

Nothing tells you which pages lie

A stale page looks identical to a current one. So the first time someone follows out-of-date instructions and gets it wrong, the whole thing loses credibility — not just that page.

04

The real process lives somewhere else

The actual answer is in a Slack thread from March, a comment on a ticket, and the head of the person who's been here longest. That's where the knowledge is; the wiki was always a copy.

So don't ask people to maintain a copy. Read the places where the work already leaves a trace, keep the manual in step with them, and be honest about the pages you're no longer confident in. That's the whole design.

The mechanism

Four things that keep it honest

Ingest

Read where the work already happens

Connected, read-only, to the systems your company already leaves evidence in: Slack or Teams, your ticket tracker, your repositories, Notion or Drive, and your helpdesk.

Nobody has to write anything into a new tool. That requirement is what killed the last attempt.

Detect · key

Notice when reality diverges from the page

A page about the refund process is compared continuously against how refunds are actually being discussed and handled. When those diverge, the page is marked and the divergence is shown — not hidden behind a "last edited" date that tells you nothing about truth.

Three states only: verified recently, may be out of date, contradicted by evidence. A human decides what to do about it.

This is the part that makes it a product rather than a documentation exercise.

Own

Every page has a named owner and a review clock

Not to create bureaucracy, but because "who do I ask if this is wrong" is the question that actually gets asked. Owners get a short nudge only when something looks divergent — never a monthly review-everything email that gets filtered.

Answer

People ask, rather than browse

Nobody reads a manual. They ask a question, in Slack or in the tool they're already in, and get an answer with the source page, the owner, and the confidence attached.

If the relevant page is stale, the answer says so before it says anything else.

Honest scoping

This is worth it at a specific size, and not before

Below a certain headcount you don't have a knowledge problem, you have a lunch table.

Good fit
  • 40–400 people, or growing fast through that range
  • Onboarding takes weeks longer than it should
  • Two or three people are load-bearing for everyone else
  • Same questions asked in Slack every week
  • Multiple sites or timezones, so asking isn't instant
  • A wiki exists and everyone quietly distrusts it
Wrong fit — I'll say so
  • Under about 25 people. Just talk to each other.
  • Nothing is written down anywhere, including in chat
  • The real goal is monitoring what staff are saying
  • Nobody will own a single page after handover
  • Leadership wants a manual to avoid making decisions
  • The processes genuinely change every fortnight

The third one on the right matters more than it looks. If this becomes a surveillance tool it will be sabotaged within a month, and rightly. I build it read-only for process knowledge and I'll walk away from the other version.

How we'd work

Ten weeks to a manual people trust

The first version covers one department. Company-wide from day one is how these become abandoned again, but larger.

Weeks 1–2

Audit what exists

What's written down, where, and how much of it is still true. Usually the first honest measurement anyone has of their own documentation.

Weeks 3–5

Assemble the first pass

One department's processes drafted from existing evidence, then corrected by the people who actually do the work. Correcting is much faster than writing.

Weeks 6–8

Wire the detection

Connect the sources, tune what counts as divergence, set owners and review clocks. This is where most of the engineering is.

Weeks 9–10

Release and hand over

Ask-a-question in Slack, the runbook, and training for whoever owns it internally. Then the next department, if it earned it.

Pricing

Published, because a call shouldn't be the price list

Start with the audit. Finding out that 60% of your documentation is wrong is worth the fee on its own.

Start here Knowledge audit

How much of what you've written down is still true?

$5,500

Two weeks · credited against a build

  • Everything you've documented, inventoried
  • Sampled and checked against reality
  • The knowledge that exists in only one head
  • Which department to start with, and why
  • Yours to act on without me
Book the audit
First department

One department's manual, live, with detection wired up.

$26k – $48k

8–10 weeks · audit credited

  • Processes assembled and human-verified
  • Staleness detection across your sources
  • Ask-a-question in Slack or Teams
  • Permissions mirroring your existing access
  • Runs in your infrastructure
Discuss a build
Ongoing

More departments, and someone keeping the detection honest.

from $4,800/mo

Cancel any month · 30 days notice

  • A new department each month or two
  • Monthly health report: what's stale, what's trusted
  • Detection tuned as your tools change
  • New sources connected as you adopt them
  • Designed so your ops team takes it over
Talk about ongoing

The number that decides whether this worked

At the audit we measure what proportion of your existing documentation is still accurate. It's usually somewhere between 30% and 60%, and it is always lower than leadership expects.

We agree a target for that figure after the build — typically above 90% verified-accurate on the covered department, sustained at the three-month mark rather than measured on launch day. Anyone can make documentation accurate once. If it isn't holding at three months, I keep working at my cost until it is.

Model and infrastructure costs sit in your own accounts, typically $100–$500 a month by company size. Not marked up.

Questions

What operations leads ask first

We already have Notion / Confluence. Are you replacing it?

No, and I'd rather not. Those are good editors and your team knows them. The manual can live inside Notion or Confluence as its front end — what I add is the layer underneath that assembles content from your other systems and marks pages as divergent.

Replacing your wiki would mean a migration, retraining, and the same decay six months later. The problem was never the tool.

How does it know a page has gone stale?

By comparing what a page claims against what the connected sources show. If the refund page says approvals go to a team lead, and forty recent conversations show them going to finance instead, that's a divergence — flagged with the evidence, for a human to resolve.

It doesn't edit the page itself. Automatically rewriting documentation from chatter is how you get a manual that confidently describes a mistake somebody made twice.

Are you reading all our Slack messages?

Only the channels you nominate, read-only, and the manual only surfaces process knowledge — never who said what, never individual performance. Permissions mirror your existing access, so nothing becomes visible to someone who couldn't already see it.

Tell your team what's connected before it goes live. A tool people discover is reading their messages is a tool people stop using honestly, and then the source dries up.

Won't it just document our bad processes?

Yes, initially — and that's frequently the most useful thing it does. Seeing the actual process written down, including the three exceptions everyone works around, is how most teams discover the process needs changing.

What it won't do is invent a better one. Improving the process is your job; making it visible is mine.

What's the ongoing effort for our team?

During the build: a few hours from two or three people in the department, mostly correcting drafts. Correcting is roughly five times faster than writing, which is the reason it's assembled first and reviewed second.

After that: owners get a nudge only when something looks divergent, which for a stable department is a handful a month. If the nudges become noise, the detection is tuned — noisy alerts get ignored and then the whole thing dies again.

You're one person. What if you disappear?

Everything runs in your infrastructure and repositories, with a runbook and the detection rules documented. Your content stays in your wiki, readable, whatever happens to the layer underneath.

That's the deliberate design: the worst-case failure is that you go back to a normal wiki with unusually good, recently verified content in it.

Who does the work

I've spent eight years building systems that notice when something drifts

I'm Bahman Shadmehr. Automated trading platforms on the Texas wholesale power market and US equities, a national payment gateway I helped decompose while it was live, and the pipelines and monitoring underneath all of it.

Drift detection is the thread. Those systems ran unattended, and the whole engineering discipline was noticing when reality had diverged from what the system assumed — before it cost anything. A manual that goes quietly out of date is the same failure mode in a slower medium.

You deal with me from first call to handover. No account manager, no team you never meet.

2024 — 2025Automated energy trading, ERCOT — pipeline, health metrics, anomaly alerting
2023 — 2024US equities trading platform — AWS services, monitoring on daily jobs
2022 — 2023Vgang — Kubernetes platform, integration microservices
2020 — 2021Zibal — payment gateway, monolith to microservices, Prometheus and Grafana
2017 — 2020Rahpa — async backends, real-time tracking systems

Python, Go, Kubernetes, Docker, AWS, GCP, Postgres, MongoDB, Redis. Remote, UTC+3. 76 technical posts · LinkedIn

Next step

Name the person everyone asks when they don't know something

Every company has one. Tell me who they are and what they get asked, and I'll tell you within a day whether a manual would take that load off them — or whether you have a different problem.

info@bshadmehr.me
Book a knowledge audit

Two clients at a time Reply within a day Remote · UTC+3

Useful in a first message

  1. Headcount, and how fast it's growing.
  2. Where documentation lives today, if anywhere.
  3. Which tools your work leaves a trace in.
  4. The department that hurts most.
  5. Who would own this internally afterwards.