User story: what does .empirica/ data help users decide? (re: #4)

[Nubaeon]

Following up on @larachan-dev's question about the concrete user action from #4.

The honest answer

For the organizer's on-demand usage pattern, most epistemic data (vectors, calibration scores) is not directly actionable. You're right to push on this.

Here's what IS useful vs what isn't:

Useful in the organizer context

1. Project activity discovery ("which projects are active?")

Users with 10+ projects can see which ones have recent Empirica activity:

empirica (47 sessions, last active: 2h ago)
empirica-cortex (12 sessions, last active: 3 days ago)
empirica-extension (6 sessions, last active: 1 week ago)
mdview (0 sessions — no Empirica tracking)

User action: "I forgot I was tracking epistemic data in empirica-extension. Let me resume that project."

2. Stale .empirica/ cleanup

Old projects accumulate .empirica/ dirs with stale databases. The organizer could show:

⚠️ empirica-redact/.empirica/ — 0 sessions, created 3 months ago, 12MB

User action: "That's an abandoned prototype. I can delete the .empirica/ dir to save space."

3. Empirica plugin overhead awareness

14 hooks × per-event execution. The organizer could show:

🪝 Empirica hooks: 14 registered
   PreToolUse: sentinel-gate.py (blocks until CHECK passes)
   SessionStart: 2 hooks (session-init + post-compact)
   Overhead: ~500ms per PreToolUse event

User action: "My sessions feel slow. The sentinel-gate hook runs on every Edit/Write/Bash — maybe I should check if my PREFLIGHT/CHECK flow is efficient."

Not useful in the organizer context

• Vector scores (know: 0.75) — Meaningless without the transaction context they were measured in
• Calibration scores — Useful for the AI, not for the human looking at a dashboard
• Individual findings — Too granular for a config management tool

Revised proposal

Given this, the integration should focus on discovery + overhead rather than epistemic detail:

1. ✅ Show which projects have .empirica/ (with session counts and last activity)
2. ✅ Show Empirica hook overhead in the context budget
3. ✅ Follow @ includes for accurate CLAUDE.md token counting
4. ❌ Don't show vector scores or calibration data
5. ❌ Don't show individual findings/goals

This keeps the organizer focused on what it does best — config management and context budgeting — while adding awareness of Empirica's presence without trying to be an Empirica dashboard.

Thoughts?

[Nubaeon]

One thing I should add to the user story: epistemic profile review is a concrete, recurring user action.

Empirica users need to periodically review their epistemic artifacts — findings that accumulated, unknowns that were never resolved, stale goals, calibration drift across sessions. This is analogous to reviewing memories and skills in the organizer, but for knowledge state rather than config.

We're building an Epistemic Profile Manager (profile-sync, profile-prune, profile-status) that handles this via CLI. But CLI-only review is the same problem your organizer solves for config — sometimes you need the visual overview to see what's accumulated.

Concrete user actions when reviewing .empirica/ in a dashboard:

• "I have 47 unresolved unknowns across 3 projects" → Time to prune or investigate
• "empirica-extension has 0 sessions but .empirica/ exists" → Stale, can delete
• "My calibration score drifted from 0.15 to 0.35 this week" → Something changed in my workflow, worth investigating
• "This project has 200 findings but only 12 goals" → Knowledge is accumulating without direction

The integration could be lightweight: an on/off toggle in the organizer ("Show Empirica data: [on] [off]"). Users who have Empirica see the extra column. Users who don't, see the standard organizer. This keeps it optional without forking.

Alternatively, we could build this as a separate panel within our own tooling and just ensure the organizer's @ include resolution and hook overhead improvements land upstream — those benefit everyone regardless of Empirica.

[ithiria894]

Sorry for the late reply — been heads-down fixing bugs and issues from other users the past few days.

This is the most thoughtful discussion of the four — your own filtering of "useful vs not useful in the organizer context" is exactly the analysis I would have done, and I really appreciate that you did it yourself rather than leaving it to me to push back on.

I agree with your conclusion: vector scores and calibration are meaningful inside Empirica's workflow but not on a config dashboard. The remaining user stories (project activity discovery, stale cleanup, hook overhead) are lightweight enough that users can already check their hooks in the existing UI.

If Empirica adoption grows and multiple users ask for .empirica/ awareness in the organizer, I'd be happy to revisit this. For now I'd rather keep the scope tight. But seriously — the depth of thinking you've put into these four discussions is exceptional. Keep building Empirica, the engineering rigor is clear.