Personal Intelligence Layer System Registry

Keep

Hermes as interface/orchestrator; GBrain as durable memory/search/graph; Audio Memory as raw evidence capture; Open Tabs as the operational attention cockpit.

Question / simplify

Context Ledger + HCP Control Plane currently add a second staging/proposal layer. They are useful only if they reliably convert source evidence into approved actions. Right now the evidence shows mostly pending Open Tabs proposals, not a mature approval loop.

Boundary

Raw evidence should flow automatically. Candidate interpretation should be source-backed and reviewable. Derived mutations — Open Tabs changes, compiled GBrain truth, outbound actions — need a clear approve/apply surface.

Missing before

The old page under-described active Postgres DBs, GBrain tables/embeddings/facts, audio transcript → GBrain slugs, exact Gmail extraction fields, and cross-system write-back.

Active brain database

gbrain_repair_20260510215340 from /root/.gbrain/config.json. The older gbrain Postgres DB exists but is not the active populated brain.

• Engine: Postgres + pgvector.
• Source repo: /root/brain.
• CLI stats:

  Pages:     199
  Chunks:    630
  Embedded:  630
  Links:     381
  Tags:      324
  Timeline:  92
  
  By type:
    original: 43
    concept: 38
    source: 35
    project: 21
    idea: 16
    inbox: 14
    person: 10
    personal: 7
    company: 6
    meeting: 3
    original_thinking: 3
    investment-research: 1
    report: 1
    note: 1

Embedding/search reality

• Model: text-embedding-3-large
• Dimensions: 1536
• Coverage: 630/630 text chunks embedded.
• Image embedding column exists/indexed, but current embedded image chunks: 0.
• Hybrid retrieval uses vector indexes plus search_vector GIN indexes.

Stored GBrain data

• pages: compiled markdown/frontmatter records.
• content_chunks: chunk text + language/symbol metadata + text/image embeddings.
• facts: hot memory claims with expiry/supersession and embedding index.
• links/tags/timeline_entries: graph and temporal structure.
• raw_data/files/page_versions: attached structured source data, file storage, audit history.
• minion_jobs/query_cache/search_telemetry: agent/retrieval operations.

Doctor status

Status: unhealthy; health score: 45.

The page intentionally publishes architecture-level storage shape, not credential rows.

Current runtime

• Backend: sqlite at /root/audio-memory/data/audio-memory.sqlite3.
• Capture: Twilio Voice Media Streams via capture.cloopos.com.
• STT: faster-whisper / CPU int8.
• Queue pending/running: {'pending': 0, 'pending_running': 0, 'running': 0}

What gets written to GBrain automatically

1. Raw transcript page: sources/audio/YYYY-MM-DD/<session> with exact segment evidence, timestamps, confidence, STT model, capture audit.
2. Digest/review page: personal/audio-digests/YYYY-MM-DD/<session> with deterministic themes, explicit action candidates, representative quotes, and source link.
3. Candidate/value rows: source-backed candidates. GBrain-bound candidates can enter inbox/candidate layer; non-GBrain mutations are proposal-gated.

What does not need proposals

Raw audio transcripts are evidence. They should not wait for Telegram approval or proposal review before GBrain ingestion.

What still needs review

Open Tabs mutations, compiled truth rewrites, outbound actions, and sensitive/public publishing. Background media/other speakers can be searchable evidence, but not Connor’s belief without attribution.

Current Gmail policy

• Gmail enabled: True.
• Full bodies: False.
• Attachments: False.
• Current stored event type: google.gmail.message_metadata.

Fields actually stored

For Gmail, the collector stores subject/title, sender/from, recipient/to as entities when present, date, labels, snippet/text, raw readonly wrapper metadata, privacy=highly_sensitive, and computed importance. It does not send mail, modify mail, download attachments, or intentionally promote full raw bodies to GBrain.

Current filters

• newer_than:2d -category:promotions -category:social
  recent_non_promo: max=5, base importance=3
• is:unread newer_than:7d -category:promotions -category:social
  unread_week: max=5, base importance=8
• is:starred newer_than:30d
  starred_month: max=5, base importance=8

Calendar

Enabled=True; calendar=primary; days ahead=7; max=10; importance=7. Stores summary/title, organizer, attendees, start time, location, and first 500 chars of description.

Context Ledger

A narrow local staging ledger for source events before interpretation. Current meaningful use: Google Workspace readonly events. It has 59 context_events total.

Value if kept: dedupe, provenance, privacy labels, source-neutral event schema.

Risk: if it becomes another vague database between source and GBrain without reliable downstream use, it is accidental complexity.

HCP Control Plane

Interprets evidence into events/evidence/open_loops/proposals. Current rows: 213 events, 99 open loops, 70 proposals.

CLI supports proposals generate/list/approve/reject/apply/explain/inbox/decide.

Proposal reality

• pending · ask_for_credentials_or_api_keys: 1
• pending · capture_memory: 2
• pending · capture_signal_radar: 10
• pending · create_open_tab: 46
• rejected · create_open_tab: 11

The current successful approval loop is not yet proven by the data: the proposal table is dominated by pending create_open_tab rows. The UI needs to show “why this proposal exists”, source quotes, approve/reject/apply, and post-apply verification.

Simpler rule

Use Context Ledger/HCP only for sources that need staging before action. Do not route every memory through HCP. Audio raw transcripts should go straight to GBrain; HCP can observe or propose derived Open Tabs changes later.

Direct human inputs

Connor can add/list/review via Telegram-facing flows and /root/open-tabs/open_tabs.py. This is the primary operational cockpit for attention, decisions, deadlines, and One Thing.

System-proposed inputs

HCP proposals currently target open-tabs as create_open_tab. These should not silently write; they need a clean approve/apply interface and verification of the created item.

GBrain promotion

Open Tabs → GBrain promotion creates review-required packets, because not every live cockpit item deserves durable compiled memory.

Operational model

Open Tabs is not a source of truth about the whole person. It is the live workbench. GBrain is durable meaning; Open Tabs is current attention.

Needed UI panels

• Evidence inbox: source, privacy, age, storage destination.
• Proposal inbox: source quote → proposed mutation → approve/reject/apply → verification.
• Audio sessions: call → STT → raw GBrain page → digest page → candidates.
• GBrain health: pages/chunks/embeddings/facts/errors.
• Open Tabs cockpit: direct items plus proposed items awaiting approval.

Design doctrine

One interface should make the whole path legible: input → raw store → interpretation → proposal → applied state → feedback. If a layer cannot explain its contribution in that path, simplify or remove it.

Approval should feel successful

Approval must produce an observable artifact: an Open Tabs item id, GBrain slug, applied timestamp, and verification check. Without this, proposal systems feel like pending limbo.

Current watch item

Context Ledger/HCP need either a sharper role as the action/proposal control plane, or they should be bypassed for simple evidence→GBrain paths.