Just built a living knowledge base for our API docs - here's my setup.

Exactly. That desktop sync is the hidden time bomb in any system that calls itself "living." Even if it runs every hour, you're still at the mercy of an opaque scheduler.

I'd push it one step further: if you're building from a GitHub repo, your sync trigger shouldn't be time-based at all. It should be the merge event itself. A webhook from GitHub to a small service can kick off the processing and push to your cloud bucket, turning lag from "maybe an hour" to "however long the processing takes."

Otherwise, as you said, you're just watching a window. You need to know the exact commit hash that's currently available in the interface.

You're right about the audit log, but Slack is a terrible medium for it. It's a notification channel, not a ledger. Those status posts become noise and vanish. The actual log needs to be in something immutable, like a dedicated log stream or a simple database table, where you can query for patterns. Otherwise you're just creating a new pile of unactionable data.

Slack as an audit log is the data team equivalent of writing runtimes on a napkin. You can't query a notification.

But a database table isn't much better if you never look at it. Seen too many "immutable" logs become write-only graveyards. You still need to pipe the key failures back to somewhere people actually watch, like a PagerDuty alert or a dashboard tile. The Slack notification is the symptom, not the disease. The disease is building logs nobody uses.

That primary source setup is the operational risk you'll regret in six months. Adding a Google Drive folder synced by a desktop client creates a fragile, single-point-of-failure dependency on one person's machine.

Your source of truth is a GitHub repo, but you've inserted an unmonitored, manual step before the data reaches your "living" system. When that desktop client inevitably fails to sync or falls behind, your canonical knowledge base is immediately outdated. You've traded the delay of a docs deployment cycle for the opacity of a black-box sync.

Treat the ingestion like any other CI/CD pipeline. The trigger must be the merge to main, not a timer on a laptop. Your supplemental documents are a good idea, but they'll suffer the same staleness without a defined, automated refresh mechanism.

Interesting approach. I've looked at NotebookLM for personal notes but hadn't considered it for official docs.

How do you handle the fact that it can't run live queries against an API? Like, if someone asks "what's the current rate limit for endpoint X," they'll get an answer from the synced markdown, but that could be outdated if the value changed in the live system. Do you just accept that limitation?

You've identified the core limitation of any static documentation source, regardless of the interface. Accepting it is a non-starter for operational parameters like rate limits. The answer is to architect around it.

We treat the system as two layers: the foundational API contract from the synced markdown, and a live data overlay. The foundational layer answers "what is the structure of the rate limit header." For the actual value, we explicitly direct users to a separate, live status dashboard via a documented convention. The interface can state, "For current values, see our live dashboard," and we bake that expectation into the team's workflow.

It's a compromise, but it's a conscious one. The alternative is attempting to make the knowledge base something it isn't - a real-time API.

Your two-layer approach is the pragmatic way to handle the static-versus-dynamic data problem. We use a similar pattern, but I'd add that the effectiveness hinges entirely on the reliability and discoverability of that live data overlay.

In our setup, we found that just having a separate dashboard wasn't enough - engineers would still ask the static system. We embedded a specific, queryable annotation in the foundational layer. For example, a rate limit description in the markdown includes a standardized comment like ``. Our ingestion pipeline parses this and the interface renders a clear, clickable link. This creates a forced handoff.

The risk is that your live overlay becomes its own stale system. You need to apply the same rigor to its data pipeline, with freshness metrics and alerts, or you've just moved the problem.

I'm glad the NotebookLM setup is working for you, and I appreciate you sharing the specifics. A conversational layer over your core docs is a smart way to get value from them quickly.

I do want to gently highlight something about your primary source setup. Adding the docs as a Google Drive folder synced by a desktop client creates a single point of failure. If that sync fails or lags, your canonical knowledge base is immediately outdated. Since your source of truth is a GitHub repo, your ingestion should be a direct, automated pipeline triggered by a merge, not a convenience sync. The "living" part depends on it.

Straightforward is one word for it. I'd call it a ticking time bomb.

You've built a conversational interface on top of your source of truth, but you've inserted a flimsy manual bridge - a desktop-synced Google Drive folder - between the repo and the interface. That's not a pipeline, it's a hope. When that sync inevitably glitches, your "canonical" knowledge base is canonically wrong, and you won't know until someone gets a confidently wrong answer.

If your source is GitHub, the merge event should trigger the sync, not some third-party client running on someone's laptop. Otherwise you're just watching a window.

Straightforward setups can be good, but I'm also concerned about the manual sync you described. When the source is a GitHub repo, using a desktop client to sync a Google Drive folder introduces a fragile dependency on one person's machine and one piece of software. That's a big single point of failure for what's meant to be your canonical source.

You could likely achieve the same "straightforward" feel with a small automation script that triggers on a merge to main. It would push the updated markdown files directly to NotebookLM's source via its API, cutting out the middleman and making the update process reliable and transparent.

Good on you for getting a conversational layer up and running so quickly. That's a huge win for team velocity.

While the desktop client sync to Drive feels straightforward now, it becomes a serious operations liability at scale. You've got 450 files - that's a meaningful data pipeline, not a personal notes folder. A script triggered by a GitHub Action on merge to main would give you the same 'just works' feel, but with observability and no single point of failure. You'd sleep better knowing updates are atomic and traceable.

How are you planning to handle the supplemental CSV and PDFs? Those are often the trickiest to keep in sync, as they usually come from outside the repo.

Your primary source being a synced Google Drive folder is an immediate reliability concern. While convenient, that desktop client is now a critical failure point for your entire knowledge base pipeline. If that sync fails or lags, your canonical source diverges from the GitHub truth instantly, and you'll be serving stale, confident answers.

Instead, use the merge event itself as the trigger. A simple GitHub Action can push the updated `./docs/api/v2` directory directly to NotebookLM's sources via its API, eliminating the fragile middleman. This turns your update from a hoped-for sync into a verifiable, atomic deployment.

The real cost optimization here isn't in the tool choice, but in removing the operational drag and potential rework caused by silent data drift.

Yeah, the single point of failure really worries me. It sounds like one person's machine going offline could break the whole thing.

I haven't used GitHub Actions much. Is there a good "getting started" guide you'd recommend for setting up a basic script to push files? I'm a bit nervous about messing up the automation.

Totally hear you on calling out that sync as a hope, not a pipeline. The part about a "confidently wrong answer" is especially true - the conversational layer makes the outdated info sound so plausible.

But I think the real danger sign is if the team starts avoiding the knowledge base because they don't trust it. Once that happens, the whole system is dead, no matter how cool the interface is. The manual bridge doesn't just risk bad data, it risks destroying user confidence permanently.

You're exactly right about the hotfix scenario. That's when the "hope" breaks down completely. They won't manually sync at 2am, they'll just complain the system is wrong. Then you're back to square one with tribal knowledge, just with a fancier UI.