davegoldblatt

Verified Riemann Zeta in Lean: https://github.com/davegoldblatt/openai-zeta-proof-check

You're not off base. There's no per-claim evidence trail. The Claude pipeline scored claims using model judgment and stored verdicts without the reasoning or sources behind them. Your Tesla example is a good one. There is real evidence for that causal claim (NHTSA investigations, documented crashes where Autopilot naming was cited as a factor), but the dataset doesn't show you any of it. Right now it's just "Claude said so." What the dataset is currently good for: extraction, clustering, timeline structure, and surfacing drift patterns across claim families. When 120 hallucination claims come back 57% supported and 63 bubble claims come back 41% contradicted, the distribution tells you something even if any single verdict is arguable. What it's not good for: claim-by-claim adjudication auditability. You're right that without provenance, this is closer to a structured first draft than a final verdict. Your approach of storing browsed pages and snippets per-claim is what auditable looks like.

Fair critique. The methodology doc covers this: both pipelines agree on the high-confidence clusters (security vulnerabilities, bubble predictions) even though they disagree on edge cases. The repo is public specifically so people can spot-check. If you find a claim where the scoring is wrong, I'd genuinely like to know.

lol

Opened a design issue for this if anyone wants to follow along or weigh in: https://github.com/davegoldblatt/total-recall/issues/2

Nice, just looked at dory. Cool to see different takes on the same problem. The write gate and the manual curation approach converge on the same insight: the model shouldn't necessarily decide what's permanently important.

Thx! Also, interesting approach on your end. The screen-context angle solves a different problem than what I was going after, but I agree they're complementary. Curated project memory and broad ambient capture serve different retrieval patterns. Good luck with YC!

The global vs. project-specific split is the right question and has real tradeoffs. You're right that preferences, identity, and coding style don't change between repos. Right now Total Recall is project-scoped, so if you're using it across multiple projects you'd be maintaining separate memory for each, which of course is redundant for that kind of context.

The tension is that some things genuinely are project-specific (decisions, architecture, people involved) and mixing those into a global tier makes retrieval noisier and may degrade performance to the point where its useless. I think the answer is probably both: a global layer for durable personal context and project-scoped registers for everything else. Haven't built that yet but it's the obvious next step. Am going to add this to my next sprint.

Also, your point about using Claude Code for thinking and writing beyond just coding resonates too. The more you use it outside of repo-scoped work, the more project-level memory feels like the wrong boundary. Will report back when ive come up with a potential solution.

Agree on human pruning piece for the most part. The system is built on the assumption that the model shouldn't necessarily be trusted to decide what's permanently important.

Remove-gates are a good extension of the same philosophy. Right now /recall-maintain lets you manually review and clean up, but it doesn't proactively surface "hey, you haven't referenced this in two weeks, still relevant?" That would be the natural counterpart to the write gate: system surfaces candidates, human decides.

Am going to think on this, but will likely add. Appreciate you!

Just pushed a rewritten README with a quickstart and usage walkthrough. Appreciate the nudge

Two good questions.

Concurrent sessions: it's a real edge case but the blast radius is small. Daily logs are append-only by convention, so two sessions writing at the same time would mean interleaved or lost entries at worst. Registers and CLAUDE.local.md are theoretically higher risk since they get modified rather than appended to, but promotion is user-initiated via /recall-promote, so you'd have to be promoting in both sessions at the same time to hit it. The race window exists (edit tool does read-then-write, not atomic append) but I haven't hit it in practice.

Cleanest fix if it ever matters: per-session log files (YYYY-MM-DD-session-abc.md) so there's no conflict on capture, and recall-promote just reads all of them. Not worth adding file locking or restructuring for a problem that hasn't bitten anyone yet.

Write gate consistency: in my experience the model errs conservative (misses things) rather than permissive (saves junk). For me I actually prefer that direction since saving too much degrades the whole system over time, while missing something important is easy to fix. You just say "remember this" and it bypasses the gate. That explicit override (item 5 on the gate) has been more reliable than trying to tune the automatic criteria to be more permissive.

Also, let me know if this lands:

How It Works Think of it like a kitchen with four storage areas:

Counter (CLAUDE.local.md): The stuff you reach for every day. Loads automatically, every session. Kept small on purpose, around a page of text.

Pantry (memory/registers/): Organized by category. Your preferences, key decisions, project details, people you work with. Claude checks here when it needs something specific.

Daily notebook (memory/daily/): Timestamped scratch notes from each day. Everything gets written here first. You decide later what's worth keeping permanently.

Storage closet (memory/archive/): Old stuff that's done or outdated. Still searchable, but never loaded automatically.

The key idea: notes hit the daily notebook first, then you promote the keepers. Claude doesn't get to decide on its own what's important enough to remember permanently. You do.

just updated, thanks for the feedback!

roger that! good point on the readme, was aiming for velocity of shipping. will re work

great to hear! lmk if you have any feedback

thanks! lmk if you have any feedback

done https://github.com/davegoldblatt/total-recall/commit/152ab12

Good catch. I agree the safe default is to ignore memory/ since it can contain personal notes, people context, and daily logs. I’m updating the installer to add memory/ to .gitignore by default (along with CLAUDE.local.md and .claude/settings.local.json).

For teams that do want shared context, I’ll document a “team mode” gitignore pattern that commits only selected registers (e.g. decisions/projects) while keeping daily logs + preferences/people local.

built this because I got tired of re-teaching Claude Code the same context every session. Preferences, decisions, “we already tried X,” “don’t touch this file,” etc. After a few days it starts to feel like onboarding the same coworker every morning.

Most “agent memory” tools auto-save everything. That feels good briefly, then memory turns into a junk drawer and retrieval gets noisy. Total Recall takes the opposite approach: a write gate. Before anything gets promoted, it asks one question: “Will this change future behavior?” If not, it doesn’t get saved.

How it works:

Daily log first (raw notes)

Promote durable stuff into registers (decisions, preferences, people, projects)

Small working memory loads every session (kept intentionally lean)

Hooks fail open. SessionStart can surface open loops + recent context. PreCompact writes to disk (not model-visible stdout)

The holy shit moment is simple: tell Claude one important preference or decision once, come back tomorrow, and it behaves correctly without you repeating yourself.

Would love feedback from heavy Claude Code users:

Does the write gate feel right or too strict?

Does this actually reduce repetition over multiple days?

Any workflow/privacy footguns I’m missing?

WOAH, this solves a huge problem. I'm in the early stages of building my newsletter, and the biggest problem is getting subscribers. Having a way to actively get current subscribers to be invested in getting me new subscribers is awesome :)

You're welcome! Hope it's useful :D