An importer's real job is not to work once. It's to keep reaching your data.

When you connect an importer to your Google Drive or your Gmail, you are handing a piece of software a standing key to some of the most personal material you own. The demo where it pulls a file on the day it was written is the easy part. The hard, honest part is the question we set for ourselves: how do we prove the importers reach the data they're for — automatically, every run — instead of writing one, watching it pass once, and hoping it still works next month?

Because the ways an importer silently rots are boring and numerous. A provider rotates the shape of its responses. The short-lived access key expires and the quiet renewal step was never really exercised. A privacy rule that was supposed to strip something never fired on the live path because the live path took a shortcut around it. None of these throw an error you'd notice. The importer just starts reaching less of your data, or reaching it wrong, and you find out — if you ever do — long after you stopped watching.

What shipped

Two things, and the second is the more interesting one.

First, importing from real consumer accounts genuinely works and lands in your memory. A Google Drive import with a real consumer sign-in was proven end to end, including the step where the importer quietly renews its short-lived access key mid-run — an imported Drive file becomes a real, searchable cloud-file entry in your memory graph, not a transient blob that evaporates. The Gmail and Drive set was completed. And a path that reads a public social feed was added that runs on a nightly automated schedule using only public data, with zero stored secrets. A locally-imported pack — say, a CSV export from your bank — turns into real entries in your memory through the exact same path a cloud import uses.

Second, and this is the part worth reading closely: we stopped trusting that the live cloud path behaves like the local one, and started proving it.

The move: one core, two doorways

For a long time a live cloud import and a local file import were two different stories that happened to end in similar-looking data. The local import ran through the full in-memory core — every safety step in order. The freshly-fetched cloud import took a more direct route to the graph. Similar output, different plumbing. And "different plumbing that produces similar output" is precisely where silent divergence hides.

The change is to feed the just-fetched cloud import pack back through the same in-memory core a disk import uses, so a live import gets full parity with a local one:

• Signature re-verification — the bytes are checked again inside the core, on the live path, not waved through because they came from a trusted fetch.
• A privacy receive-gate — the same gate that strips what it shouldn't keep runs on the cloud import, so a live import can't smuggle in something a local import would have dropped.
• Content hashing and deduplication — importing the same thing twice doesn't create two entries. The second import recognizes the first.
• A proper import marker — the record lands as a real, marked entry in your memory graph, the same kind of entry a local import produces, searchable and accounted-for.

The point isn't the list. The point is that there is now one core with two doorways, instead of two cores that were supposed to agree. A live Drive import and a local file import are now the same story with the same guarantees, because they run the same code.

flowchart TD
  A[Sign in to a real cloud account] --> B[Importer fetches your data · quietly renews the access token mid-run]
  C[A local pack · e.g. a CSV bank export] --> D[Import pack]
  B --> D
  D --> E[The same in-memory core both doorways share]
  E --> F[Re-verify the signature on the bytes]
  F --> G[Privacy receive-gate · strip what it shouldn't keep]
  G --> H[Content-hash · importing twice does not duplicate]
  H --> I[(A real, searchable entry in your memory graph)]
  J[Nightly automated check · public data · no stored secrets] --> B
  J --> K[Re-proves the whole live path on every run]

How you prove it every run without leaking anyone's credentials

There's an obvious tension in "prove the live cloud path automatically." An automated check that runs every night can't be handed a real person's Drive password, and it certainly can't stash live credentials somewhere a build system could read them. That would trade a rot problem for a much worse leak problem.

The resolution is small and deliberate: the address the importer fetches from was made overridable by configuration. The real production defaults are untouched — when you run an import, it goes to the real provider, exactly as before. But an automated or self-hosted test run can point the live fetch at a stand-in that speaks the same protocol, and exercise the entire live path — the fetch, the quiet key-renewal step, the parity core, the landing in the graph — without any real account's credentials ever entering the picture. The one path that genuinely can't be faked — reading a public social feed — is run against the real thing nightly, because public data needs no secret to reach.

So "reaches your data" stops being a claim we made once and becomes a check the system re-runs on its own, on every run, and fails loudly if the live path ever stops behaving.

The honest limits

This is as much a proof-and-guarantee story as it is a feature, and honesty about that is the whole spirit of it.

Not every provider can be safely automated. Some are explicitly marked as not safely automatable in an unattended check — the ways they authenticate or rate-limit don't fit a hands-off nightly run. For those, we didn't paper over the gap with a fake pass. They carry a written playbook for a human reviewer to walk the real path deliberately. Saying "this one needs a person" is more honest than a green check that proves nothing.

The proof already caught a real gap. During this work the automated scrutiny surfaced a silent-drop defect: on one of the paths that receives an imported pack, the imported bytes weren't actually being stored. That is exactly the class of quiet failure this whole effort exists to catch — an import that looks like it succeeded while some of your data never landed — and it was found and filed rather than shipped past. A proof that never catches anything isn't proving much; this one earned its keep on the first pass.

And the ledger stays honest about status. These are shipped capabilities and a standing every-run guarantee, landed on the main line. They are not a celebrated, ribbon-cut milestone — the item's own roadmap status remains open by design. We'd rather call it what it is: real capability, live now, with a proof that keeps watching, and a couple of edges we're telling you about instead of hiding.

The shape of the win is simple to state. You give an importer your real accounts on the understanding that it reaches your real data. The dishonest version of that promise is "it worked when we wrote it." The honest version is a check that re-proves the live path every single run, points at a stand-in so nobody's credentials leak to prove it, and is candid about the providers a machine can't safely test alone. That's the version we shipped.

Written by AI agents from real project logs; owned and edited by Mujo.