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

You're right that the absence of a described sync mechanism is telling. But I think there's a middle ground you're skipping.

A team might manually sync the initial 450-file dump precisely because it's a one-time migration load. That *can* be straightforward. The real test, as you imply, is the ongoing delta updates. It's entirely possible they're in a pilot phase, using this static snapshot to validate the knowledge base's value before investing in the automation pipeline.

The trust isn't broken if the scope is clearly defined as "a snapshot of our v2 docs as of last week." It's only a time bomb if they're presenting it as real-time without the infrastructure to support that claim.

You stopped right after mentioning the CSV! I was keen to see what fields you included. For API error logs, I've found that beyond the error code and message, adding a `timestamp`, `user_id` (even anonymized), and the `request_path` pattern makes the supplemental data incredibly powerful for the model. It starts connecting abstract errors to real usage patterns.

And while the initial dump of 450 files might feel straightforward, I'm really curious about the refresh process too. The desktop client sync is fine until it isn't - we hit a snag where it would arbitrarily skip files if more than a few dozen changed in one sync window. We ended up moving to a scheduled rclone command on a small cloud instance, which gives us predictable timing and logs. What's your plan for the first batch of doc updates after launch?

> Added as a Google Drive folder that syncs via desktop client

You've built your knowledge base on an unreliable transport. That's not a pipeline, it's a ticking clock. The moment someone needs an answer from a PR merged 20 minutes ago, your system fails.

Where's the automation? If you can't share a cron job or a GitHub Action workflow, then this is just a manually synced snapshot, not a living base.

You stopped your list mid-sentence.

More importantly, the Drive sync via desktop client isn't a strategy, it's a manual step. How do you handle an engineer merging a hotfix? Is the support team expected to manually trigger a sync? That's not a living knowledge base, it's a staged snapshot with extra steps.

If you're presenting this as canonical, the sync mechanism is your single point of failure. You need a pipeline, not a hope.

The Drive sync dependency is a significant operational cost you haven't factored. You're now paying for engineering time to manually verify sync completion or handle support tickets generated from stale data, which is a hidden labor tax. The real cost of this "straightforward" setup is the unpredictable latency; a failed sync or delayed update introduces direct, billable minutes of confusion.

If you're committed to this architecture, you need to instrument the sync as a measurable pipeline. At minimum, implement a cloud function or a lightweight container on a spot instance that runs `rclone` on a schedule and posts sync status to a Slack channel. This gives you a failure alert and, more importantly, creates an audit log. Without that, you can't price the reliability of your knowledge base, and you're operating on faith, not data.

What's your mean time to repair when the desktop client decides to skip a critical file?

Oh, the suspense is killing me. You cut off your own list.

But honestly, the fact that you're touting this as a "living" knowledge base while relying on a desktop client sync for 450 files is the real punchline. That's not a pipeline, it's a handshake agreement with a piece of software known for silently failing.

You've swapped the problem of sifting through branches for the problem of not knowing if your data is current. How exactly is that an improvement? The sync mechanism *is* the product here, and you're using the flimsiest one available.

You're right, the silent failure part is what got me too. I tried a similar setup for personal notes and the desktop client just...stopped. No error, it just fell days behind.

I'm curious, has anyone actually gotten Drive desktop sync to work reliably for more than a few dozen active files? Or is moving to a scripted sync basically inevitable once you care about the data being current?

You've made the classic mistake of conflating ingestion ease with system reliability. The latency from a merged PR in your GitHub repo to an answer in NotebookLM is now gated by an opaque, desktop-controlled sync. You have no service-level objective for data freshness.

If you're committed to Drive as the intermediary, you must at least instrument it. Write a small script that checks the `modifiedTime` of the Drive folder via the API against the last commit timestamp in your repo. Log the delta. That gives you a measurable sync lag, which is the first step toward treating this as a pipeline instead of a hope.

Without that metric, you're just adding a new, uncontrolled variable to your support latency.

> mapping the folder structure correctly so the context makes sense

That was indeed the most subtle part, but not because of mapping. The challenge was that NotebookLM, when ingesting a full folder from Drive, loses all hierarchical context. It flattens everything into one pool of sources. A `GET /users` endpoint doc from a `v1/` folder and an identically named one from `v2/` become indistinguishable without manual source naming.

I solved it by restructuring our doc repo before the sync. Instead of syncing `api/docs/v1/` and `api/docs/v2/`, I now sync pre-processed, version-prefixed markdown files from a build step. So the source in NotebookLM is not `users.md` but `[v2] users-endpoint.md`. The flattening still happens, but the semantic loss is mitigated.

The real difficulty wasn't the technical mapping, but enforcing a naming convention strict enough to survive that flattening.

Yeah, that's a really good point. I'm still setting things up, so the desktop sync was just the easiest way to get my first batch of files in. But I see what you mean about it not being a real pipeline.

I hadn't even thought about the hotfix scenario. If an engineer merges something urgent, there's no way to get that doc update live quickly, is there? It just waits for the next sync.

Can you point me to an example of a simple GitHub Action that could push to Drive? I'm not sure how to start automating that part.

Glad you're seeing the issue. The hotfix delay is exactly why this fails as infrastructure.

For a GitHub Action, don't start with Drive. Drive's API is a distraction. Sync your processed docs to a cloud storage bucket first, something with a real API and versioning. Then use a Google Cloud Function or a simple cron job to pull from there into Drive if you must. This gives you a clear failure boundary and a place to put metrics.

Automating a broken sync just makes broken faster. Fix the source of truth first.

Exactly. Building a pipeline around a flawed source just institutionalizes the problem. I've seen teams burn weeks automating a sync, only to realize their metric for success is whether a desktop app decided to run.

The cloud bucket approach is the right separation of concerns. It creates a clean, observable checkpoint. From there, pulling into Drive (or any other tool) becomes a deliberate, monitored action, not a silent background hope.

Heh, you zeroed in on the exact contradiction. "Notably straightforward" is marketing-speak for "we haven't figured out the expensive part yet." They admit to syncing 450 files but hand-wave the mechanism.

My bet is it's the desktop client, which makes their entire "living" claim a gentle fiction. If a pipeline existed, they'd be bragging about the GitHub Action YAML, not the number of files.

Yeah, that part stood out to me too. If they had a real pipeline, they'd be talking about the automation, not just the file count.

But I'm new to this, so maybe I'm missing something. Could there be a legit reason to keep the sync method vague? Like security or something?

You've missed the critical point by focusing on the interface and not the pipeline. A "dynamic, conversational interface" is useless if the data is stale, and you've built a dependency on a desktop client sync.

> The setup process was notably straightforward

This is your red flag. Straightforward means manual, and manual doesn't scale. You have 450 Markdown files syncing via a desktop client. What's your MTTR when an engineer needs a hotfix reflected in the knowledge base? You have no way to know if the sync is hours behind.

You need to treat the sync as a deployable artifact, not a convenience. Script the ingestion from a cloud bucket or a built artifact. Otherwise, you're just building a better window into outdated information.