Doc Chain Sync: One Source, Two Knowledge Destinations

Doc Chain Sync turns one changed Markdown file into controlled updates in both Notion and Google Drive. The local vault remains the source while downstream systems receive the formats and folder structure they need.

The supported impact is functional: one pipeline replaces two separate synchronization paths and skips unchanged files. I do not attach a time-saved, uptime, or adoption metric.

A local knowledge base can be ideal for authoring while collaboration and retrieval happen elsewhere. Copying documents by hand creates drift, and running full exports on every cycle wastes work while increasing the chance of duplicates.

The system needed to detect change, preserve useful metadata, update existing destinations, and recover cleanly without making either Notion or Google Drive the new source of truth.

I chose an incremental dispatcher with explicit state instead of a continuous event system. On each run, it scans selected folders, compares file state, routes changed documents to both destinations, and records successful synchronization.

That design is intentionally boring. A five-minute LaunchAgent schedule is enough for document workflows, easy to inspect, and easier to recover than a queue or webhook system that the use case did not require.

The Python dispatcher separates Notion, Google Drive, state, and logging concerns into small modules. The Notion client uses the standard library HTTP stack, while Google Drive synchronization delegates transfer behavior to rclone. A JSON state file records incremental progress.

Dry-run and force modes make changes inspectable. Folder caches avoid redundant destination creation calls during a run, and rotating logs provide an operational record without adding a service dependency.

Fresh local verification on July 31, 2026 passed 98 automated tests. Coverage exercises dispatch decisions, Notion create and update behavior, Google Drive synchronization, incremental state, dry runs, and smoke paths.

The repository is public and original, so the source and tests are directly inspectable from this case.

This case demonstrates system design, Python implementation, API integration, idempotent synchronization behavior, and automated verification. It does not claim production service levels, usage by other people, or measured productivity improvement.

The implementation expects users to supply their own destination credentials and local paths. No private vault content or credential value is part of the public project.