Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- PERSONALOS RECREATION SPECIFICATION
- Sanitized, implementation-oriented version
- Purpose of this document
- ========================
- This file specifies the PersonalOS system as a reusable private research and
- tooling environment. It is written so another person can recreate the same kind
- of system for their own life archive without receiving any private facts from
- the original workspace.
- This document intentionally does not include:
- - The original subject's name.
- - Names of family members, friends, employers, schools, cities of residence, or
- other identifying entities.
- - Raw excerpts from private messages, notes, emails, voice transcripts,
- documents, photos, health records, finance records, or generated analyses.
- - Absolute local paths that reveal a machine username.
- - Account IDs, project IDs, API keys, tokens, hashes of private archives, or
- credential scan findings.
- - Concrete life events, diagnoses, financial amounts, travel routes, addresses,
- or exact personal chronology facts from the source workspace.
- Where a concrete identifier would have appeared, this spec uses placeholders:
- - <workspace>: the root directory for the new PersonalOS workspace.
- - <subject>: the person whose archive is being modeled.
- - <subject_slug>: a filesystem-safe slug for <subject>.
- - <counterpart>: another person in a message or relationship record.
- - <source_family>: a source family such as messages, writing, voice, finance,
- health, location, media, or generated analysis.
- - <model>: the selected language, embedding, vision, or local ML model.
- What the original project completed, stated generically
- =======================================================
- The original PersonalOS work built a private end-to-end system with these
- completed or partially completed layers:
- 1. Reorganized the workspace into a clean personal/project split.
- 2. Documented raw-source preservation rules, privacy posture, canonical paths,
- generated-output locations, and legacy path translation.
- 3. Collected and canonicalized multiple source families: writing, messages,
- voice, calendar, mail, photos metadata, finance, rideshare/location, health
- inventories, AI conversations, and selected generated analyses.
- 4. Built platform-specific normalization for major message platforms, including
- repaired social-media exports and stable source locators.
- 5. Built a cross-platform merged message-history pipeline with normalized event
- rows, raw identity rows, person identity edges, conversation rows, manual
- identity override queues, and top-person history files.
- 6. Built message activity analytics, group/cross-platform salience windows, a
- metadata-only relationship graph, closeness rankings, friend-mention indexes,
- and model-ranked relationship chunks/subchunks.
- 7. Built a chronology system: source acquisition, broad seed events, filtered
- candidate packs, chronology drafts/addenda, mail and finance backfills,
- travel/movement ledgers, flight-route guess ledgers, daily location modeling,
- and visual trip/movement surfaces.
- 8. Built day-level activity indexing from generated evidence packets and model
- labels, including deterministic no-evidence and location-only rows.
- 9. Built media layers: image caption manifests, model caption batches,
- caption/FTS SQLite indexes, text/OCR pass, important-media-text promotion,
- emotional/life-moment tags, anonymous face detection/clustering, and local
- media review surfaces.
- 10. Built location layers: common place indexes, merchant/location records,
- message-location mention aggregates, RAG-backed naming, grouped location
- resolution, and per-location activity timelines.
- 11. Built context packs from primary sources, life moments, relationship
- subchunks, writing, voice transcripts, and synthesis backfill, including a
- medium default pack for seeded chats.
- 12. Built a staged contrastive synthesis harness with source cards, primary
- moments, a claim ledger, contrasts, theme dossiers, skeptical audit, and a
- final report.
- 13. Built higher-interpretation layers: psychological/formulation dossiers,
- skeptical audits, structured ledgers, introspective-question extraction,
- open-ended question answering, and final conclusion ledgers.
- 14. Built a local RAG index with source-aware formatting, FTS, exact search,
- embedding search, hybrid/evidence retrieval, salience roles, vector matrix
- generation, cost guards, and regression checks.
- 15. Built local chat over the RAG index with default medium-pack seeding and
- retrieval-as-tool behavior.
- 16. Built a no-build static React dashboard with a unified local Python server
- that mounts dashboard, raw stream review, raw plain view, chat, search,
- media caption review, relationship graph, chronology globe, rideshare map,
- presence map, finance summaries, daily timeline, and final conclusions.
- 17. Added privacy/security tooling: generated-artifact secret scanning,
- local-only raw APIs, optional authentication, cleanup/status reports, and
- explicit pre-export rules.
- 18. Added miscellaneous local utilities such as a browser path blocker and
- vendored export tools.
- Core idea
- =========
- PersonalOS is a private local system for turning a person's scattered archive
- into source-grounded context. It is not a generic notes app, CRM, diary, or
- public website. It is a research environment that:
- 1. Preserves raw source exports as evidence.
- 2. Normalizes heterogeneous sources into typed records with stable source
- locators.
- 3. Builds derived indexes over chronology, relationships, locations, media,
- daily activity, and life moments.
- 4. Uses model-generated analysis, but keeps it downstream of evidence.
- 5. Separates primary source material, derived indexes, model interpretation,
- and orientation/profile material.
- 6. Supports local search, retrieval-augmented chat, dashboards, and review
- tools without publishing private data.
- The strongest outputs should function as indexes back into primary sources, not
- as replacements for those sources. Every important claim should point back to a
- source path, local locator, confidence label, and uncertainty/counterevidence
- when available.
- Design principles
- =================
- Evidence rules
- --------------
- - Never rewrite or delete raw exports unless the user explicitly asks.
- - Treat every generated artifact as sensitive by default.
- - Preserve distinction between:
- - direct self-expression;
- - observed behavior;
- - third-party reports;
- - platform metadata;
- - generated interpretation.
- - Use model analysis for synthesis and hypotheses, not as final authority.
- - Prefer falsifiable claims over smooth narrative.
- - Store source paths, row numbers, byte offsets, message IDs, local line ranges,
- JSON pointers, or other stable locators wherever possible.
- - Make uncertainty visible. A weak signal should remain weak until corroborated.
- - Do not let one high-volume platform dominate the entire self-model.
- - Keep relationship-specific behavior separate from broad personality claims.
- Privacy rules
- -------------
- - Default posture: local-only.
- - Do not commit raw archives or large private generated outputs to a normal git
- repository.
- - Do not publish dashboards, context packs, synthesis reports, RAG indexes, or
- model prompts without a separate redaction/export workflow.
- - Raw-content APIs must bind to loopback by default.
- - Remote/tunnel access must require authentication.
- - Pre-export secret scanning is mandatory for generated artifacts.
- - Secret scanners must report only path, rule, severity, and line number; they
- must not print or persist matched secret values.
- - Avoid storing API keys, OAuth tokens, session cookies, or private keys inside
- source files, generated prompts, model responses, or shell history.
- Visual/interface style
- ----------------------
- For local websites, timelines, dashboards, and review tools, use a dense
- monochrome information-design style:
- - linear ledger-like layouts;
- - square controls;
- - thin rules;
- - compact typography;
- - low ornament;
- - color used selectively for state, severity, grouping, or focus;
- - avoid big rounded cards, pill shapes, decorative gradients, bubble timelines,
- oversized whitespace, and marketing-style hero sections;
- - expose state and internal workings instead of hiding complexity.
- Canonical workspace layout
- ==========================
- Create the root directory:
- <workspace>/
- The root should stay clean. The canonical top-level layout is:
- <workspace>/
- README.md
- AGENTS.md
- personal/
- project/
- Do not recreate legacy root-level folders such as raw message exports, outputs,
- scripts, or source-family folders at the workspace root. Keep the split:
- - personal/: raw personal store and human-facing reading surface.
- - project/: code, pipelines, generated artifacts, docs, sites, and tools.
- Personal store
- --------------
- personal/
- README.md
- raw/
- conversations/
- library/
- Raw source folders:
- personal/raw/
- writing/
- apple_notes/
- google_docs/
- other_writing/
- messages/
- imessage/
- signal/
- snapchat/
- discord/
- discord_dce/
- instagram/
- twitter_raw/
- twitter_data/
- other_platforms/
- voice/
- voice_memos/
- finance/
- bank_statements/
- paypal/
- other_accounts/
- health/
- lab_results/
- clinical_records/
- location/
- rideshare/
- maps_takeout/
- other_location_exports/
- media/
- photos_exports/
- social_media/
- Rules for personal/raw:
- - It is evidence storage.
- - Add new exports here.
- - Do not normalize in place.
- - Do not move source files during pipeline work.
- - If a source-family folder already contains old charts or analysis created
- during earlier extraction, leave it unless there is an explicit migration.
- Conversation folders:
- personal/conversations/
- ai_chats/
- terminal_context_chats/
- web_context_chats/
- other_model_conversations/
- Human library folders:
- personal/library/
- chronology/
- synthesis/
- context_packs/
- life_moments/
- message_histories/
- profile_seeds/
- The library is a reading surface. It may contain symlinks into project/outputs.
- The canonical generated artifacts still live with project code.
- Project folders
- ---------------
- project/
- README.md
- docs/
- scripts/
- pipelines/
- outputs/
- sites/
- tools/
- deploy/
- tests/
- tmp/
- Use these rules:
- - Single-file utilities and drivers go in project/scripts.
- - Multi-file pipelines go in project/pipelines.
- - Cross-project generated artifacts go in project/outputs.
- - Pipeline-owned outputs may live under project/pipelines/<pipeline>/outputs.
- - Local web tools go in project/sites.
- - Vendored or local binary tools go in project/tools.
- - Deployment shims go in project/deploy.
- - Scratch files go in project/tmp and must not become durable state.
- Path helper module
- ------------------
- Add a shared path helper such as:
- project/scripts/personalos_paths.py
- It should expose:
- - ROOT: <workspace>.
- - PERSONAL_DIR: <workspace>/personal.
- - RAW_DIR: <workspace>/personal/raw.
- - CONVERSATIONS_DIR: <workspace>/personal/conversations.
- - LIBRARY_DIR: <workspace>/personal/library.
- - PROJECT_DIR: <workspace>/project.
- - SCRIPTS_DIR: <workspace>/project/scripts.
- - PIPELINES_DIR: <workspace>/project/pipelines.
- - OUTPUTS_DIR: <workspace>/project/outputs.
- - TMP_DIR: <workspace>/project/tmp.
- - source-family convenience paths.
- - workspace_root(file): find <workspace> from any script path.
- - canonicalize_workspace_path(value): translate old paths to canonical paths.
- Every new script should use this helper rather than assuming a hard-coded root.
- Legacy path map
- ---------------
- If the project previously had root-level folders, keep a documentation-only
- legacy path map:
- project/docs/LEGACY_PATHS.md
- Do not recreate old paths. The map should translate old references to current
- canonical paths for older generated artifacts.
- Environment and dependencies
- ============================
- Minimum practical environment:
- - macOS or Linux-like local environment.
- - Python 3.11+.
- - Node.js 20+ or current local equivalent.
- - SQLite with FTS5 support.
- - ripgrep for fast local search.
- - Optional local nginx or hosts entry for a friendly local domain.
- - Optional Poppler, ffmpeg, OCR tools, image libraries, and local ML packages
- for media/voice work.
- - API access for selected model providers.
- - For browser/dashboard QA, Playwright or another browser automation tool.
- Python packages commonly needed:
- - standard library: argparse, csv, json, sqlite3, pathlib, dataclasses,
- datetime, email, mailbox, re, hashlib, zipfile, plistlib, http.server.
- - data: pandas, numpy, openpyxl.
- - text/token utilities: tiktoken or equivalent tokenizer.
- - model clients: provider SDKs as needed.
- - PDF/finance extraction: pypdf, pdfplumber, or platform tools.
- - media/vision: pillow, imageio, OpenCV as needed.
- - face detection/clustering: insightface, onnxruntime/CoreML provider,
- scikit-learn for DBSCAN.
- - web/server: no framework required; the current style uses Python
- ThreadingHTTPServer plus static vendored frontend assets.
- Node packages/tools commonly needed:
- - vanilla Node scripts for chart/workbook/timeline generation.
- - local vendored React builds for no-build static apps.
- - optional force-graph or Three.js vendored locally for graph/globe views.
- - optional workbook/artifact generation libraries.
- There is no single root package manager file in the current style. Prefer small
- scripts with explicit dependencies and status docs. If you introduce a package
- manager later, keep raw archives outside dependency tooling and avoid scanning
- node_modules into RAG or secret reports.
- Configuration
- =============
- Create a subject config file before building:
- project/config/subject.json
- Recommended fields:
- {
- "subject_slug": "<subject_slug>",
- "display_name": "<subject>",
- "timezone": "<IANA timezone>",
- "birth_date": "<YYYY-MM-DD or null>",
- "known_life_phase_boundaries": [],
- "identity_seed_path": "personal/library/profile_seeds/<subject_slug>.md",
- "canonical_email_addresses": [],
- "canonical_phone_numbers": [],
- "self_platform_ids": {},
- "redaction_policy": {
- "external_exports_default": "blocked",
- "raw_quotes_default": "minimal",
- "remote_sensitive_api_default": "disabled"
- }
- }
- The current project has some older scripts where subject-specific filenames or
- seed facts are embedded directly. For a clean recreation, parameterize those
- scripts to read subject config and data files. Hard-coded identity facts should
- be replaced with:
- project/config/identity_seed_events.jsonl
- Identity seed event schema:
- event_id
- date_start
- date_end
- precision
- title
- description
- domains
- people
- locations
- source_type
- source_path
- locator
- evidence_basis
- confidence
- importance_hint
- citation
- interpretive_risk
- Do not put private seed facts in this public spec. Each user should create their
- own local seed file.
- Data model overview
- ===================
- Use a small number of durable record types across the system.
- SourceRef
- ---------
- Every derived row that points to evidence should support:
- source_path: workspace-relative path to raw or derived source.
- source_family: high-level family.
- source_id: script-defined source identifier.
- locator: stable pointer such as row number, JSON pointer, byte offset,
- message ID, line range, file member, or timestamp.
- source_line: optional local line number.
- source_member: optional member path inside an archive.
- evidence_basis: direct_self_expression, observed_behavior,
- other_person_report, platform_metadata, generated_index,
- model_interpretation, or mixed.
- confidence: low, medium, high, or needs_review.
- interpretive_risk: why this row may be misleading.
- Chronology event
- ----------------
- Use a broad event row for chronology seeds:
- event_id
- date_start
- date_end
- precision
- title
- description
- domains
- people
- locations
- source_type
- source_id
- source_path
- locator
- evidence_basis
- confidence
- importance_hint
- citation
- interpretive_risk
- raw
- Keep seed events inclusive. Candidate filtering and narrative chronology are
- separate downstream steps.
- Normalized message event
- ------------------------
- Message normalization should converge on:
- event_id
- platform
- source_family
- source_path
- source_line
- raw_message_id
- timestamp_utc
- timestamp_local
- conversation_id
- conversation_kind
- conversation_title
- sender_raw_identity_id
- sender_person_id
- sender_label
- is_from_me
- text
- participant_person_ids
- related_person_ids
- relation_scope_by_person
- source_quality
- confidence_flags
- The key field is related_person_ids. It answers: whose per-person history should
- include this event in the deterministic first pass?
- Relation scopes:
- direct_conversation
- small_group_context
- medium_group_context
- group_sender
- server_sender
- additive_sender_only
- Raw identity row
- ----------------
- raw_identity_id
- platform
- raw_label
- raw_platform_id
- normalized_label
- person_id
- person_label
- merge_confidence
- evidence
- Person identity edge
- --------------------
- person_id
- person_label
- raw_identity_id
- platform
- raw_label
- raw_platform_id
- confidence
- method
- note
- Conversation row
- ----------------
- conversation_id
- platform
- source_family
- conversation_kind
- conversation_title
- raw_conversation_id
- source_path
- participant_person_ids
- participant_raw_identity_ids
- message_count
- my_message_count
- first_timestamp_utc
- last_timestamp_utc
- source_quality
- notes
- Summary node
- ------------
- Hierarchical summaries should use:
- summary_id
- source_modality
- node_kind
- level
- summary_status
- summary_text
- time_start_utc
- time_end_utc
- conversation_ids
- conversation_titles
- conversation_kinds
- person_ids
- person_labels
- platforms
- event_count
- my_event_count
- other_event_count
- episode_ids
- child_summary_ids
- source_refs_sample
- source_ref_count
- event_ids_sample
- event_id_count
- salience
- life_moment_candidate
- search_tags
- input_hash
- RAG source/chunk
- ----------------
- RAG indexing should keep separate source and chunk tables.
- Source table fields:
- source_id
- path
- family
- artifact_type
- content_provenance
- is_model_generated
- embedding_salience
- evidence_role
- mtime
- size
- sha256
- formatter_version
- Chunk table fields:
- chunk_id
- source_id
- chunk_index
- text
- formatted_text
- start_line
- end_line
- start_byte
- end_byte
- timestamp_start
- timestamp_end
- people
- locations
- tags
- embedding_salience
- evidence_role
- content_provenance
- input_hash
- Content provenance:
- primary_source
- derived_artifact
- model_generated
- project_doc
- orientation
- prior_chat
- unknown
- Evidence role:
- primary
- derived_index
- analysis
- orientation
- prior_chat
- Source acquisition layer
- ========================
- The source acquisition layer imports raw archives into canonical storage without
- changing the originals.
- Writing
- -------
- Sources:
- - Apple Notes export.
- - Google Docs or Drive export.
- - Markdown/text files.
- - PDFs or documents containing personal writing.
- Desired derived artifacts:
- - merged text files for large source families;
- - per-document manifests with title, path, created/modified times, token counts,
- and source refs;
- - optional ranking/tagging outputs for emotional salience, self-reflection,
- chronology relevance, and inclusion/exclusion in context packs.
- Implementation notes:
- - Preserve original export directories.
- - Convert documents into readable plain text where possible.
- - Keep document-level metadata separate from extracted body text.
- - Do not overwrite the raw export with normalized text.
- Messages
- --------
- Sources:
- - local chat database exports;
- - phone/cloud archive exports;
- - Signal exports;
- - Discord account export and DiscordChatExporter JSON;
- - Snapchat data export;
- - Instagram data export;
- - Twitter/X archive exports;
- - other platforms as needed.
- For each platform:
- 1. Put raw export under personal/raw/messages/<platform>/.
- 2. Write a platform normalizer that emits normalized records with:
- timestamp, sender, participants, conversation, text, attachments/placeholder
- events, reactions, calls/system rows where available, and source locators.
- 3. Preserve message text in normalized event ledgers when needed for local
- analysis, but avoid writing message bodies into metadata-only reports.
- 4. Route every platform through the merged message histories pipeline.
- Special source-family notes:
- - iMessage/live databases may need a main export plus additive cloud/archive
- rows not present in the live database. Deduplicate by stable message IDs where
- available.
- - Discord DMs/group DMs should use recipient metadata from the account package
- when available instead of inferring participants only from authored rows.
- - Snapchat may contain both chat-history rows and content-free activity
- metadata. Keep media decode separate from message normalization.
- - Instagram exports often need mojibake repair. Repair strings in memory and
- write normalized derived rows; never edit raw Meta files.
- - Twitter/X participants may be numeric IDs until manually resolved.
- Voice
- -----
- Sources:
- - Voice memo manifest.
- - Audio cache.
- - Transcripts.
- - Suspect transcript folder.
- - Prior analysis outputs.
- Derived artifacts:
- project/outputs/voice/
- canonical_voice_manifest.csv
- canonical_voice_manifest.jsonl
- voice_transcript_triage.md
- voice_cleanup_candidates.csv
- voice_repeat_artifacts.csv
- voice_repeat_artifacts.md
- STATUS.md
- Voice pipeline behavior:
- - Join manifest rows to audio files and transcript files.
- - Flag missing audio, missing transcript, zero-token transcript, short
- transcript, likely truncation, repeated-word artifacts, and tiny clips.
- - Do not delete raw audio.
- - Treat cleanup as analysis triage: ignore/exclude generated empty clips unless
- the user manually reviews them.
- - Feed high-value transcripts into context packs, synthesis, RAG, chronology,
- and question extraction.
- Calendar, mail, photos, and location metadata
- ---------------------------------------------
- Sources:
- - Local calendar database.
- - Google Calendar Takeout.
- - Photos library metadata or photo export metadata.
- - Email takeout mbox.
- - Rideshare/location export archives.
- - Other maps/location histories.
- Derived artifacts:
- project/outputs/chronology/data_acquisition/
- apple_calendar_events.csv/jsonl/ics
- apple_calendar_hidden_events.csv/jsonl
- google_calendar_takeout_events.csv/jsonl
- photos_metadata.csv/jsonl
- photos_daily_counts.csv
- google_mail_mbox_index.csv/jsonl
- google_mail_chronology_hits_yYYYY.md
- google_mail_targeted_backfill_candidates.jsonl/tsv
- google_mail_curated_evidence.md
- rideshare/
- rides_redacted.csv/jsonl
- orders_redacted.csv/jsonl
- city_presence_days.csv/jsonl
- monthly_summary.csv/jsonl
- chronology_signals.jsonl
- Calendar rules:
- - Read local calendar DB read-only.
- - Exclude non-personal calendars such as holidays/birthdays unless explicitly
- useful.
- - Hide legacy family/shared calendars that do not represent <subject>'s own
- chronology.
- - Preserve hidden rows in audit sidecars.
- Email rules:
- - Index mbox headers and byte offsets first.
- - Store message IDs, dates, sender/recipient metadata, subject, labels, and
- byte offsets.
- - Do not load entire mbox bodies into dashboards by default.
- - Extract broad year-sliced chronology hits.
- - Create targeted backfill candidates for school, admissions, work, travel,
- legal, finance, health, and other chosen domains.
- - Manually curate a small evidence pack from noisy hits.
- Photos rules:
- - Start with metadata: asset ID, created date, media type, dimensions, GPS if
- available, favorite/hidden flags, source path, derivative path.
- - Use metadata for activity density and location corroboration.
- - Direct visual review/captioning is a separate media pipeline.
- Rideshare/location rules:
- - Store raw export archive under personal/raw/location/<source>/.
- - Normalize into redacted outputs.
- - Omit full addresses, phone/email, card numbers, device IDs, IP addresses,
- precise analytics coordinates, and item-level order customizations unless
- explicitly needed.
- - Round coordinates or city-bucket them in derived artifacts.
- - Treat rideshare metadata as strong location/logistics evidence and weak
- purpose/meaning evidence.
- Finance
- -------
- Sources:
- - Bank statement PDFs.
- - PayPal CSV exports.
- - Other card/bank/brokerage/payroll exports.
- Derived artifacts:
- project/outputs/chronology/data_acquisition/bank_statements/
- plain_text/
- bank_statement_manifest.csv
- bank_statement_transactions.csv
- bank_statement_monthly_summary.csv
- bank_statement_analysis.md
- bank_statement_chronology_addendum.md
- charts/
- project/outputs/chronology/data_acquisition/paypal/
- paypal_source_manifest.csv
- paypal_transactions.csv
- paypal_monthly_summary.csv
- paypal_history.xlsx
- paypal_history_analysis.md
- Finance rules:
- - Parse statements into transaction-like rows.
- - Keep account numbers masked or reduced to non-sensitive account buckets.
- - Preserve source statement path and page/line/source locator.
- - Treat merchant/location parsing as heuristic.
- - Separate physical point-of-sale from remote/subscription/web payments.
- - Use finance data for chronology and location corroboration, not for exposing
- raw spending details in default dashboards.
- Health
- ------
- Sources:
- - Lab results.
- - appointment exports.
- - clinical records if the user wants them included.
- Rules:
- - Store under personal/raw/health.
- - Do not index into public or shared artifacts.
- - In RAG, classify as primary evidence but high sensitivity.
- - In dashboards, default to aggregate inventory/status only.
- - Clinical-style interpretation may be done locally only with source labels and
- confidence/counterevidence.
- Pipeline: merged message histories
- ==================================
- Purpose
- -------
- Build a graph-first, cross-platform message event ledger and per-person history
- files.
- Inputs:
- personal/raw/messages/...
- project/outputs/instagram/instagram_dm_events.jsonl
- project/outputs/instagram/instagram_conversations.jsonl
- platform-specific normalized exports
- identity_overrides.csv
- Main command pattern:
- python3 project/pipelines/merged_message_histories/build_merged_message_histories.py \
- --top-n 100 \
- --output project/pipelines/merged_message_histories/outputs
- Useful options:
- --limit-sources imessage signal
- --limit-sources instagram
- --top-n <N>
- --output <dir>
- Outputs:
- project/pipelines/merged_message_histories/outputs/
- message_events.jsonl
- conversations.jsonl
- raw_identities.jsonl
- person_identity_edges.jsonl
- person_index.csv
- top_people_seed.csv
- top100_index.csv
- run_summary.json
- review/
- identity_collapse_report.csv
- identity_merge_candidates.csv
- high_confidence_identity_merge_candidates.csv
- medium_confidence_identity_merge_candidates.csv
- platform_metadata_aliases.csv
- identity_resolution_worklist.csv
- identity_resolution_worklist.md
- identity_review_queue.csv
- service_or_spam_candidates.csv
- unresolved_platform_ids.csv
- top100/
- 001_person_slug.md
- 001_person_slug.events.jsonl
- 001_person_slug.history.tsv
- Identity strategy
- -----------------
- The pipeline should be conservative:
- - raw identities are platform-specific labels, handles, phone numbers, emails,
- user IDs, or display names;
- - people are canonical candidates;
- - raw identities map to people through confidence-labeled edges;
- - deterministic merges are allowed for exact contact-resolved labels and stable
- raw platform IDs;
- - uncertain matches go to review queues;
- - manual merges live in identity_overrides.csv.
- identity_overrides.csv schema:
- platform,raw_label,person_label,confidence,note
- Example placeholder:
- signal,Alex Example,Alex Example,manual_high,same person as another platform contact
- Group chat attribution
- ----------------------
- Use tiered inclusion:
- - direct/private conversation: include all rows in the counterpart's history;
- - very small group: include all rows for all known participants;
- - medium group: include sender rows for sender, and <subject>-authored rows for
- all participants only below a configured participant cap;
- - large group/server: include sender rows only by default;
- - additive cloud/archive rows without reliable membership: sender-only.
- This avoids treating every large-group message as relationship evidence for
- every participant.
- Per-person files
- ----------------
- For the top people by related event count:
- - write a Markdown coverage summary without message bodies;
- - write an events JSONL with message text for local analysis;
- - write a history TSV for model chunking and local review.
- Validation:
- - every JSONL row parses;
- - required schema fields present;
- - no duplicate event IDs;
- - no missing UTC timestamps where source timestamp exists;
- - raw identity IDs do not link to multiple final people;
- - top-N output files exist and are non-empty;
- - run_summary counts match event files.
- Pipeline: message activity and salience analytics
- =================================================
- Activity reports
- ----------------
- Command pattern:
- python3 project/pipelines/merged_message_histories/build_activity_reports.py \
- --input project/pipelines/merged_message_histories/outputs \
- --output project/pipelines/merged_message_histories/outputs/analytics \
- --top-n 100
- Outputs:
- analytics/monthly_activity.csv
- analytics/monthly_sent_received.svg
- analytics/monthly_top5_people.csv
- analytics/monthly_top5_people.svg
- analytics/three_month_top5_people.csv
- analytics/three_month_top5_people.svg
- analytics/top100_by_messages.csv
- analytics/top100_by_direct_messages.csv
- analytics/analytics_summary.md
- analytics/run_summary.json
- Definitions:
- - Monthly sent/received counts are unique normalized events.
- - Word/character counts come from normalized text.
- - Direct thread episode endings use inactivity windows.
- - Monthly top people are ranked by related-history events, so small-group
- context may count one source message toward several people.
- Salience windows
- ----------------
- Command pattern:
- python3 project/pipelines/merged_message_histories/build_salience_windows.py
- Outputs:
- analytics/identity_review_summary.json
- analytics/group_salience_windows.csv/jsonl
- analytics/cross_platform_episode_windows.csv/jsonl
- analytics/salience_run_summary.json
- analytics/salience_analytics.md
- Group-chat salience:
- - split non-direct conversations by inactivity gap;
- - rank by volume, participant breadth, <subject> participation, and text flags;
- - text flags include mentions, planning, conflict, emotion, decisions,
- transitions, links, and platform shifts;
- - do not write message bodies.
- Cross-platform episodes:
- - per-person bursts among top related people;
- - require multiple platforms;
- - split by inactivity gap;
- - cap long windows so constant relationships do not become multi-month blobs.
- Pipeline: relationship graph
- ============================
- Purpose
- -------
- Build a metadata-only graph of relationship candidates and shared group context.
- Command:
- python3 project/pipelines/merged_message_histories/build_relationship_graph.py
- Inputs:
- person_index.csv
- conversations.jsonl
- run_summary.json
- service/spam review CSV
- optionally message_events.jsonl for temporal metadata only
- Outputs:
- project/outputs/relationship_graph/
- relationship_graph.json
- relationship_graph_summary.json
- closeness_rankings.csv
- friend_mention_index.csv
- friend_mention_index.json
- friend_mention_summary.md
- STATUS.md
- Rules:
- - Message text is not embedded in graph JSON.
- - Every person with at least one related event gets an ego edge.
- - Ego edge weight uses direct volume, context volume, total volume,
- reciprocity, recency, duration, platform breadth, conversation breadth, and
- confidence.
- - A separate closeness score emphasizes sustained direct contact, active direct
- months, direct episodes, direct recency, reciprocity, relationship duration,
- platform breadth, and capped group-context support.
- - Person-person links are inferred only from shared non-direct conversations in
- a bounded participant range.
- - Cap the number of shared group links to keep the visualization usable.
- - Low-quality labels and service/spam candidates stay labeled as low confidence.
- Pipeline: friend mentions and birthdays
- =======================================
- Friend mention index:
- - Build aliases from the top relationship/contact set.
- - Scan message text locally for mentions of those aliases.
- - Aggregate mention counts, platforms, source refs, and time buckets.
- - Do not write raw message text into mention outputs.
- - Use for relationship graph enrichment and evidence discovery.
- Birthday index:
- - Extract birthday candidates from message/event evidence where useful.
- - Store known vs unresolved rows separately.
- - Include source refs and confidence.
- - Keep evidence review local and do not expose third-party private facts by
- default.
- Pipeline: relationship chunk salience
- =====================================
- Purpose
- -------
- Use model scoring to identify the most salient relationship-history chunks,
- then compress those chunks into tighter subchunks for context packs and review.
- Inputs:
- project/pipelines/merged_message_histories/outputs/top100/*.history.tsv
- relationship graph metadata
- prior relationship takeaways
- optional psychological/relationship dossiers
- compact global profile/chronology orientation
- Stage 1 command pattern:
- python3 project/scripts/gpt5mini_relationship_chunk_salience.py
- Stage 1 outputs:
- project/outputs/relationship_chunking/
- relationship_chunk_manifest.jsonl
- relationship_chunk_scores_gpt5mini.jsonl
- relationship_chunk_scores_gpt5mini_latest.jsonl
- relationship_chunk_scores_gpt5mini_latest_summary.json
- relationship_chunk_rankings_gpt5mini_latest.csv
- relationship_chunk_rankings_gpt5mini_latest.md
- relationship_chunking_gpt5mini_latest_audit.md
- STATUS.md
- Stage 2 command:
- python3 project/scripts/build_relationship_salience_subchunks.py
- Stage 2 outputs:
- relationship_top150_diverse_ultra_tight_subchunks_pack.md
- relationship_top150_diverse_ultra_tight_subchunks_manifest.jsonl
- relationship_top150_diverse_ultra_tight_subchunks.csv
- relationship_top150_diverse_ultra_tight_subchunks_stats.json
- relationship_top150_diverse_ultra_tight_subchunks_audit.md
- relationship_top150_diverse_ultra_tight_breakdown_by_relationship.md/csv
- Also keep broader fallback packs for review:
- relationship_top300_ultra_tight_subchunks_pack.md
- relationship_top300_high_notable_subchunks_pack.md
- relationship_top300_salient_subchunks_pack.md
- Subchunk rules:
- - Start from ranked parent chunks.
- - Prefer high notable source ranges.
- - Merge nearby overlaps.
- - Use compact speaker labels.
- - Preserve dates, platform, direct/group context, and source row ranges.
- - Keep the pack small enough for downstream model context.
- Pipeline: hierarchical summaries
- ================================
- Purpose
- -------
- Build a summary-node tree over normalized sources. The first implemented slice
- is messages, using merged-message history outputs as source of truth.
- Command examples:
- python3 project/pipelines/hierarchical_summaries/build_message_summary_tree.py --dry-run
- python3 project/pipelines/hierarchical_summaries/build_message_summary_tree.py --person-limit 10
- python3 project/pipelines/hierarchical_summaries/build_message_summary_tree.py --include-all-people
- Inputs:
- message_events.jsonl
- conversations.jsonl
- person_index.csv
- Outputs:
- project/outputs/hierarchical_summaries/messages/
- message_summary_nodes.jsonl
- message_summary_edges.jsonl
- message_summary_aliases.jsonl
- life_moment_candidates.jsonl
- message_summary_manifest.json
- message_summary_status.md
- Behavior:
- - Split platform threads into episode nodes using inactivity gaps.
- - Build calendar rollups at multiple window sizes, such as 1w, 2w, 1m, 2m, 4m,
- 6m, and 1y.
- - Write aliases instead of duplicating summary prose when wider windows contain
- only one child.
- - In the metadata-first pass, read message bodies locally for scoring but do
- not write message bodies into summary outputs.
- - Emit life-moment candidates as a filtered subset of summary nodes.
- Context packages for future model summarization:
- python3 project/pipelines/hierarchical_summaries/build_message_summary_contexts.py sample --count 20 --run
- Context package fields:
- global_context
- node_metadata
- person_thread_context
- life_context_near_window
- local_continuity_context
- child_summary_context
- episode_raw_material
- output_budget_hint
- prompt
- These prompt packages may include raw local message transcripts and must be
- treated as private generated artifacts.
- Pipeline: life-moment examples
- ==============================
- Purpose
- -------
- Extract reviewable life-moment examples from source-family packs. A life moment
- is not a final biographical truth; it is a source-grounded candidate with
- evidence pointers.
- Command pattern:
- python3 project/scripts/extract_life_moment_examples.py
- Inputs:
- - synthesis source manifest;
- - selected source-family packs;
- - message/history packs;
- - Instagram derived packs;
- - voice/writing/context sources.
- Outputs:
- project/outputs/life_moment_examples/
- life_moment_examples_report.md
- life_moment_sources.json
- run_summary.json
- sources/<source_id>.json
- full_source_packs/<source_id>.txt
- prompts/
- raw_responses/
- STATUS.md
- Rules:
- - Keep source IDs stable.
- - Keep source refs and why-review notes.
- - Treat weak attention/social signals as weak unless corroborated.
- - Use life-moment candidates from hierarchical summaries as a future preferred
- input layer.
- Pipeline: Instagram integration
- ===============================
- Purpose
- -------
- Normalize a raw Instagram/Meta export into useful derived artifacts without
- editing the raw export.
- Command:
- python3 project/scripts/normalize_instagram_export.py \
- --raw-root personal/raw/messages/instagram \
- --output project/outputs/instagram \
- --timezone <timezone>
- Outputs:
- project/outputs/instagram/
- instagram_dm_events.jsonl/csv
- instagram_conversations.jsonl/csv
- instagram_dm_pack.txt
- instagram_public_records.jsonl
- instagram_public_pack.txt
- instagram_attention_events.jsonl
- instagram_attention_pack.txt
- instagram_chronology_signals.jsonl
- instagram_identity_review_candidates.csv/jsonl
- instagram_inventory_summary.json
- validation_summary.json
- integration_validation_summary.json/md
- STATUS.md
- Rules:
- - Repair common export encoding issues in memory.
- - Convert timestamp_ms to UTC ISO and configured local time.
- - Create deterministic event IDs from thread path, index, timestamp, sender,
- and text hash.
- - Use JSON pointers such as relative/path.json#/messages/N for review.
- - Preserve message text in local event JSONL/CSV, but reports should avoid raw
- message bodies by construction.
- - Create placeholders for shares, reactions, photos, videos, audio, calls, and
- unavailable/deleted content.
- - Distinguish inbox threads from message requests.
- - Mark deleted/anonymous/brand/service/spam-looking labels as low confidence.
- Downstream use:
- - Merged message histories import normalized DM events and conversations.
- - Synthesis uses three derived sources: DMs, public/profile surface, and weak
- attention graph.
- - Chronology starts with chronology signals; bulk DMs should flow through
- selected life-moment/synthesis outputs, not direct chronology insertion.
- - RAG indexes the derived packs and JSONL records.
- Validation:
- python3 project/scripts/validate_instagram_integration.py
- Pipeline: chronology
- ====================
- Purpose
- -------
- Build an inclusive event database, then narrow it into a readable, cited life
- chronology.
- Core outputs:
- project/outputs/chronology/
- chronology_seed_events.jsonl/csv
- chronology_seed_summary.json
- chronology_candidate_events.jsonl
- chronology_candidate_pack.md
- chronology_candidate_summary.json
- chronology_draft_v0.1.md
- chronology_draft_v0.2.md
- chronology_draft_v0.3.md
- chronology_addenda/
- STATUS.md
- Stage 1: export local chronology sources
- ----------------------------------------
- Command:
- python3 project/scripts/export_chronology_sources.py
- What it does:
- - Reads local calendar DB read-only.
- - Reads local Photos metadata DB read-only.
- - Writes visible calendar rows, hidden-calendar audit rows, ICS export, photos
- metadata, and count summaries.
- - Applies conservative filters for non-personal calendars and unsupported legacy
- shared-calendar rows.
- Stage 2: parse Google Calendar Takeout
- --------------------------------------
- Command:
- python3 project/scripts/parse_google_calendar_takeout.py
- What it does:
- - Parses .ics files from Takeout.
- - Emits CSV/JSONL rows and a summary.
- - Preserves calendar/source locators.
- Stage 3: index Google Mail Takeout
- ----------------------------------
- Commands:
- python3 project/scripts/index_google_mail_mbox.py
- python3 project/scripts/extract_google_mail_chronology_hits.py
- python3 project/scripts/extract_google_mail_targeted_backfill.py
- What they do:
- - Build an mbox index with byte offsets.
- - Extract broad year-sliced chronology hits.
- - Extract targeted backfill candidates.
- - Support manual curation into google_mail_curated_evidence.md.
- Stage 4: finance acquisition
- ----------------------------
- Commands:
- python3 project/scripts/extract_chase_bank_statements.py
- python3 project/scripts/export_paypal_history.py
- node project/scripts/build_paypal_history_workbook.mjs
- python3 project/scripts/prepare_chase_chart_data.py
- node project/scripts/build_chase_financial_charts_workbook.mjs
- What they do:
- - Extract statement text.
- - Parse statement metadata and transaction rows.
- - Build monthly summaries.
- - Write chronology addenda.
- - Build review workbooks/charts.
- Stage 5: rideshare/location acquisition
- ---------------------------------------
- Command pattern:
- python3 project/scripts/normalize_uber_export.py
- Important implementation note:
- - In the current style, some older normalizers may run when invoked without
- subcommands. Add normal argparse support before sharing with another user so
- --help never mutates outputs.
- What it does:
- - Reads a raw export zip from personal/raw/location/<source>/.
- - Writes redacted ride/order/city/monthly summaries.
- - Writes chronology signals.
- - Excludes full addresses, exact sensitive coordinates, device/network IDs,
- payment details, and other sensitive fields.
- Stage 6: build chronology seed
- ------------------------------
- Command:
- python3 project/scripts/build_chronology_seed.py
- Inputs:
- - identity seed events;
- - primary-source moments;
- - life-moment examples;
- - voice manifest;
- - calendar rows;
- - photos metadata/counts;
- - email curated evidence;
- - bank/PayPal addenda;
- - Instagram chronology signals;
- - rideshare chronology signals;
- - other source-family extraction outputs.
- Output schema is the chronology event row described above.
- Stage 7: build candidate pack
- -----------------------------
- Command:
- python3 project/scripts/build_chronology_candidate_pack.py
- Behavior:
- - Reads chronology_seed_events.jsonl.
- - Keeps identity, primary moments, curated evidence, high-signal calendar rows,
- dated life moments, longer voice records, high-volume photo days, finance and
- location corroboration, and selected platform signals.
- - Drops routine calendar noise, generic reminders, routine meetings, and weak
- metadata unless useful as corroboration.
- - Writes JSONL plus a GPT-ready Markdown pack.
- Stage 8: write chronology narrative
- -----------------------------------
- Use the candidate pack as source material for a model or human pass. The prompt
- should require:
- - chronological ordering;
- - short titles;
- - source citations;
- - confidence labels;
- - contradictions/needs-review ledger;
- - gaps section;
- - no future events treated as having occurred;
- - no unsupported interpretations.
- Keep drafts versioned. Add source-family addenda rather than overwriting the
- main draft when a new source is first integrated.
- Travel, movement, and location sublayers
- ----------------------------------------
- Major trip index:
- project/outputs/chronology/major_trips_index_v0.1.md
- project/outputs/chronology/major_trips_index_v0.2.md
- Flight route guess ledger:
- python3 project/scripts/build_flight_route_guess_ledger.py
- Travel movement ledger:
- node project/scripts/build_travel_movement_events.mjs
- Daily location model:
- python3 project/scripts/build_daily_location_model.py
- Major trips visual timeline:
- node project/scripts/build_major_trips_visual_timeline.mjs
- Trip globe data:
- node project/scripts/build_trip_globe_timelapse_data.mjs
- Rules:
- - Split trips into explicit origin-to-destination movement legs where possible.
- - Insert continuity_gap rows where location continuity is unresolved.
- - Use confidence labels.
- - Treat flight numbers/airport pairs as guesses unless source evidence is
- explicit.
- - Do not reconstruct exact routes from redacted endpoints as truth; label them
- approximate.
- - For visual timelines, use dense ledger-style rows instead of decorative
- timeline cards.
- Pipeline: daily activity index
- ==============================
- Purpose
- -------
- Build a source-grounded day-by-day activity ledger from generated indexes,
- including deterministic no-evidence rows.
- Command sequence:
- python3 project/scripts/build_daily_activity_index.py --today <YYYY-MM-DD> prepare
- python3 project/scripts/build_daily_activity_index.py --today <YYYY-MM-DD> run --model <model> --reasoning none --assemble
- python3 project/scripts/build_daily_activity_index.py --today <YYYY-MM-DD> fetch-pending --assemble
- python3 project/scripts/build_daily_activity_index.py --today <YYYY-MM-DD> assemble
- python3 project/scripts/build_daily_activity_index.py --today <YYYY-MM-DD> status
- Outputs:
- project/outputs/daily_activity_index/
- daily_evidence_packets.jsonl
- model_labels.jsonl
- daily_activity_index.jsonl
- daily_activity_index.csv
- daily_activity_index.md
- manifest.json
- daily_activity_index_summary.json
- prompts/
- raw_model_responses/
- pending_model_responses/
- errors/
- README.md
- Label categories:
- administrative_financial_day
- future_scheduled
- health_or_appointment_day
- inconclusive
- media_or_capture_only
- no_evidence
- routine_communications
- social_or_relationship_day
- substantive_day
- travel_or_location_day
- work_or_school_day
- Rules:
- - Read generated indexes, not raw exports directly.
- - Cap snippets in evidence packets.
- - Final rows point back to local refs.
- - Future rows are schedule/context, not confirmation that future events
- happened.
- - Use deterministic labels for no-evidence and location-only days.
- - Use model labels only for evidence-bearing days.
- Pipeline: location index
- ========================
- Purpose
- -------
- Index places that repeatedly appear as stays, rideshare endpoints, purchase
- venues, merchants, photos, calendar rows, chronology rows, and message-location
- mentions.
- Commands:
- python3 project/scripts/build_common_location_index.py
- python3 project/scripts/name_location_index_with_rag.py --rag --output-dir project/outputs/location_index/place_naming
- python3 project/scripts/resolve_location_groups_with_rag_web.py --web-context --reuse-llm-adjudications --output-dir project/outputs/location_index/location_resolution
- python3 project/scripts/build_location_activity_index.py --output-dir project/outputs/location_index/location_activity
- Outputs:
- project/outputs/location_index/
- common_location_index.jsonl/csv
- all_location_records.jsonl/csv
- merchant_location_index.jsonl/csv
- message_location_mentions.jsonl/csv
- location_evidence_events.jsonl/csv
- location_index_summary.json
- place_naming/
- location_resolution/
- location_activity/
- README.md
- Commonness rules can be tuned:
- - stay places: minimum modeled days;
- - purchase places: minimum purchase count;
- - rideshare endpoints: minimum endpoint touches or days;
- - message-only places: minimum mention count.
- Privacy:
- - Do not copy raw message text.
- - Use redacted rideshare inputs.
- - Round coordinates.
- - Redact street-address-looking private anchors in generated titles.
- - Public reverse geocoding is context, not proof of personal meaning.
- Pipeline: media captioning, OCR/text pass, and face clustering
- ==============================================================
- Purpose
- -------
- Create source-aware search context for images/media while preserving source
- pointers, uncertainty, and local-only review.
- Media captioning commands:
- python3 project/pipelines/media_captioning/media_captioning.py build-manifest
- python3 project/pipelines/media_captioning/media_captioning.py sample --count 24 --run --model <vision_model> --detail high
- python3 project/pipelines/media_captioning/media_captioning.py prepare-inline-batches --model <vision_model> --detail high
- python3 project/pipelines/media_captioning/media_captioning.py submit-batches project/outputs/media_captioning/batches/<batch_dir>
- python3 project/pipelines/media_captioning/media_captioning.py batch-statuses project/outputs/media_captioning/batches/<batch_dir>
- python3 project/pipelines/media_captioning/media_captioning.py fetch-batches project/outputs/media_captioning/batches/<batch_dir>
- python3 project/pipelines/media_captioning/media_captioning.py collect-batch-outputs project/outputs/media_captioning/batches/<batch_dir>
- python3 project/pipelines/media_captioning/media_captioning.py prepare-retry-batches ...
- Outputs:
- project/outputs/media_captioning/
- manifests/
- samples/
- batches/
- captions/
- media_captions.sqlite
- RUN_STATUS.md
- Caption records should include:
- - media_id;
- - source path;
- - media source family;
- - date/context hint;
- - generated caption;
- - visible people/activity/mood/location hints;
- - uncertainty;
- - tags;
- - parse/review flags;
- - model usage metadata in raw output files, not in RAG-facing formatted text.
- Text/OCR pass commands:
- python3 project/pipelines/media_captioning/media_text_pass.py build-manifest
- python3 project/pipelines/media_captioning/media_text_pass.py sample --count <N> --run --model <vision_model>
- python3 project/pipelines/media_captioning/media_text_pass.py prepare-inline-batches --model <vision_model>
- python3 project/pipelines/media_captioning/media_text_pass.py submit-batches <batch_dir>
- python3 project/pipelines/media_captioning/media_text_pass.py fetch-batches <batch_dir>
- python3 project/pipelines/media_captioning/media_text_pass.py collect-outputs
- python3 project/pipelines/media_captioning/media_text_pass.py prepare-retry-batches
- python3 project/pipelines/media_captioning/media_text_pass.py index-sql
- Important media text:
- python3 project/scripts/build_important_media_text.py
- Rules:
- - General generated captions are selective/lower-salience RAG material.
- - Strict OCR/text records with important personal content can be promoted into
- default-salience RAG.
- - Promotion requires actual transcribed text, non-low confidence, and high
- personal salience.
- - Utility text, receipts, generic school exercises, product listings, maps,
- tickets, weather, games, memes, comics, and generic news/articles should be
- excluded from default high-salience RAG unless explicitly needed.
- Emotional/life-moment tag layer:
- python3 project/scripts/tag_media_emotional_moments.py --sync-sqlite
- Rules:
- - Derived tag JSONL should store media IDs, source paths, priority, and tags,
- but not raw caption text or OCR text.
- Face clustering commands:
- python3 project/pipelines/media_captioning/face_clustering.py build-candidates
- python3 project/pipelines/media_captioning/face_clustering.py detect
- python3 project/pipelines/media_captioning/face_clustering.py cluster
- python3 project/pipelines/media_captioning/face_clustering.py index-sql
- Outputs:
- project/outputs/media_face_clustering/
- face_candidate_manifest_*.jsonl
- face_detections_*.jsonl
- clusters_*/
- media_face_clusters.sqlite
- media_face_clusters.summary.json
- STATUS.md
- Rules:
- - Cluster IDs are anonymous by default.
- - Do not assign person names without explicit visual/manual review.
- - Keep all detections so stricter/looser clustering can be rerun without
- redetecting.
- - Treat large clusters as candidates, not identity truth.
- Pipeline: context packs
- =======================
- Purpose
- -------
- Build compressed, source-aware context packs for future model sessions.
- Output family:
- project/outputs/context_pack/
- <subject_slug>_context_prompt_primary_source_pack.md
- <subject_slug>_context_prompt_primary_source_pack_v2.md
- <subject_slug>_context_prompt_primary_source_pack_v3.md
- <subject_slug>_context_prompt_primary_source_pack_v4.md
- <subject_slug>_context_prompt_primary_source_pack_v4_medium_50k.md
- *_stats.json
- *_coverage_audit.md
- Builder family:
- python3 project/scripts/build_personal_context_doc.py
- python3 project/scripts/build_personal_context_doc_v2.py
- python3 project/scripts/build_personal_context_doc_v3.py
- python3 project/scripts/build_personal_context_doc_v4.py
- python3 project/scripts/build_personal_context_doc_medium.py
- Evolution:
- - v1: primary source moment selections and supplemental sections.
- - v2: better dedupe, source displays, special high-priority source sections,
- life-moment sections, synthesis backfill, coverage audit.
- - v3: expanded life sections and source-stat coverage improvements.
- - v4: source-card taxonomy refresh after moving from legacy relationship slices
- to canonical source-family cards.
- - medium: deterministic broad sample from the full v4 pack, sized for default
- seeded chats; retrieval is still required for specific claims.
- Rules:
- - Context packs are orientation, not primary truth.
- - Include source-use cautions and evidence hierarchy.
- - Preserve source map and section boundaries.
- - Deduplicate repeated source blocks.
- - Record stats: token counts, byte size, SHA-256, selected groups, omitted
- groups, version, source pack hash.
- - Write coverage audits listing included/skipped source groups.
- - Do not include old per-person source slices in the active v4 taxonomy unless
- deliberately re-enabled.
- Docs/notes/voice specialized packs:
- python3 project/scripts/build_docs_notes_voice_context_pack.py
- python3 project/scripts/tag_notes_and_voice_sources.py build-manifest
- python3 project/scripts/tag_notes_and_voice_sources.py ...
- python3 project/scripts/build_tagged_docs_notes_voice_context_pack.py
- Use these to:
- - rank notes/voice sources by emotional, self-reflective, chronology, and
- inclusion salience;
- - include transcripts with quality flags;
- - exclude tiny/empty/repeated-artifact voice cases;
- - write audit files explaining included/excluded items.
- Pipeline: contrastive synthesis
- ===============================
- Purpose
- -------
- Build a staged, skeptical, contrastive synthesis over source families.
- Command sequence:
- python3 project/scripts/gpt55_synthesis.py plan
- python3 project/scripts/gpt55_synthesis.py status --verbose
- python3 project/scripts/gpt55_synthesis.py run --stage source-cards
- python3 project/scripts/gpt55_synthesis.py run --stage primary-moments
- python3 project/scripts/gpt55_synthesis.py run --stage claim-ledger
- python3 project/scripts/gpt55_synthesis.py run --stage contrasts
- python3 project/scripts/gpt55_synthesis.py run --stage theme-dossiers
- python3 project/scripts/gpt55_synthesis.py run --stage audit
- python3 project/scripts/gpt55_synthesis.py run --stage final-report
- Or:
- python3 project/scripts/gpt55_synthesis.py run --stage all
- Dry run:
- python3 project/scripts/gpt55_synthesis.py run --stage source-cards --only <source_id> --dry-run
- Fetch interrupted background response:
- python3 project/scripts/gpt55_synthesis.py fetch --response-id <response_id> --stage <stage> --job-id <job_id>
- Outputs:
- project/outputs/synthesis/
- synthesis_manifest.json
- synthesis_token_report.md
- synthesis_run_summary.json
- inputs/
- prompts/
- raw/
- response_ids/
- errors/
- source_cards/
- primary_source_moments/
- claim_ledger/claim_ledger.jsonl
- relationship_contrasts/
- theme_dossiers/
- audit/skeptical_audit.md
- final/final_report.md
- README.md
- synthesis_update_status.md
- Stage design:
- 1. source-cards
- - one card per source family;
- - asks what the source uniquely reveals, hides, contradicts, and biases;
- - includes candidate primary-source moments.
- 2. primary-moments
- - reviewable index of high-value source moments;
- - may be deterministic fallback extracted from source-card JSONL blocks if
- a model run fails.
- 3. claim-ledger
- - normalized JSONL claims with source refs, confidence, and risk.
- 4. contrasts
- - compares source families and relationship/platform contexts.
- 5. theme-dossiers
- - cross-source dossiers for major themes such as work/agency, family,
- friendship, attachment/intimacy, conflict/repair, intellectual style,
- development over time, and private-vs-interpersonal self.
- 6. audit
- - skeptical attack on the emerging analysis.
- 7. final-report
- - long-form synthesis downstream of all previous stages.
- Rules:
- - Save every prompt before API submission.
- - Skip existing outputs unless --force is passed.
- - Do not overwrite a good stage output with an incomplete/failed model response.
- - Track response IDs and raw responses separately.
- - Use max request/body size guards.
- - Use active canonical source-family cards, not old per-person message slices,
- unless explicitly enabled for a special rerun.
- - Keep relationship/platform contrasts and theme dossiers marked with their
- run vintage if only part of the pipeline is refreshed.
- Pipeline: psychological and interpretive analysis
- =================================================
- Purpose
- -------
- Build deeper formulation layers from evidence, while keeping them explicitly
- separate from primary sources.
- GPT-style psychoanalysis harness
- --------------------------------
- Commands:
- python3 project/scripts/gpt55_psychoanalysis.py prepare
- python3 project/scripts/gpt55_psychoanalysis.py plan --stage all
- python3 project/scripts/gpt55_psychoanalysis.py run --stage relationships
- python3 project/scripts/gpt55_psychoanalysis.py run --stage self_dossiers
- python3 project/scripts/gpt55_psychoanalysis.py run --stage ledgers
- python3 project/scripts/gpt55_psychoanalysis.py run --stage audit
- python3 project/scripts/gpt55_psychoanalysis.py run --stage final
- python3 project/scripts/gpt55_psychoanalysis.py extract-ledgers
- python3 project/scripts/gpt55_psychoanalysis.py status
- Outputs:
- project/outputs/psychoanalysis/
- input_manifest.json
- run_manifest.json
- inputs/
- relationship_cohort.md
- incomplete_relationships.md
- relationship_packs/
- relationship_dossiers/
- self_dossiers/
- ledgers/
- consolidated_ledgers.md
- extraction_summary.md
- audit/skeptical_audit.md
- final/final_report.md
- literature/
- RESUME.md
- STATUS.md
- Rules:
- - Use prior synthesis as index/foil, not final authority.
- - Build relationship packs from top relationships plus evidence summaries.
- - Build self/theme dossiers across a fixed set of themes.
- - Extract structured ledgers from narrative dossiers.
- - Run a skeptical audit.
- - Mark source-verification queues as open unless manually reviewed.
- Fable/large-context review-first harness
- ----------------------------------------
- Commands:
- python3 project/scripts/claude_fable_psychoanalysis.py prepare
- python3 project/scripts/claude_fable_psychoanalysis.py build-intro
- python3 project/scripts/claude_fable_psychoanalysis.py build-context
- python3 project/scripts/claude_fable_psychoanalysis.py plan
- python3 project/scripts/claude_fable_psychoanalysis.py test-stack --reprepare
- python3 project/scripts/claude_fable_psychoanalysis.py status
- Real model stages only after review:
- python3 project/scripts/claude_fable_psychoanalysis.py run-profiles --provider <provider> --model <model> --confirm-cost --allow-large-context
- python3 project/scripts/claude_fable_psychoanalysis.py discover-questions --provider <provider> --model <model> --confirm-cost --allow-large-context
- python3 project/scripts/claude_fable_psychoanalysis.py run-question-round --round 1 --provider <provider> --model <model> --confirm-cost --allow-large-context
- python3 project/scripts/claude_fable_psychoanalysis.py review-round --round 1 --provider <provider> --model <model> --confirm-cost --allow-large-context
- python3 project/scripts/claude_fable_psychoanalysis.py synthesize --provider <provider> --model <model> --confirm-cost --allow-large-context
- Rules:
- - Default provider should be mock.
- - Non-mock calls require --confirm-cost.
- - Large contexts require --allow-large-context.
- - Existing generated analyses are excluded from source packs by default.
- - Orientation/profile material is tagged not-evidence.
- - RAG leaves vector retrieval off unless explicitly enabled.
- - API keys are environment variables, not project files.
- Open-ended question pipeline
- ----------------------------
- Commands:
- python3 project/scripts/open_ended_questions.py generate
- python3 project/scripts/open_ended_questions.py answer-batches
- python3 project/scripts/open_ended_questions.py synthesize
- python3 project/scripts/open_ended_questions.py status
- Outputs:
- project/outputs/open_ended_questions/
- question_bank.jsonl
- question_bank.md
- answers/
- all_answers.md
- answer_synthesis.md
- prompts/
- raw_responses/
- STATUS.md
- Purpose:
- - Generate empirical/open questions from existing analysis.
- - Answer them in batches using source-aware context.
- - Synthesize what remains unresolved.
- Introspective question pipeline
- -------------------------------
- Commands:
- python3 project/scripts/introspective_questions.py extract
- python3 project/scripts/introspective_questions.py pack-batches
- python3 project/scripts/introspective_questions.py run-batches
- python3 project/scripts/introspective_questions.py run-final
- python3 project/scripts/introspective_questions.py status
- Outputs:
- project/outputs/introspective_questions/
- candidates/
- candidate_summary.json
- candidate_pack.md
- all_question_candidates.jsonl
- dedup_question_candidates.jsonl
- analysis/
- question_cluster_ledger.jsonl
- introspective_question_report.md
- prompts/
- raw_responses/
- STATUS.md
- Purpose:
- - Extract question-like utterances from messages, writing, voice transcripts,
- and prior AI chats.
- - Deduplicate and cluster them.
- - Produce a report on recurring self-questions and unresolved concerns.
- Final conclusions layer
- -----------------------
- Inputs:
- - psychoanalysis final report and skeptical audit;
- - psychoanalysis consolidated ledgers;
- - introspective question report and ledger;
- - open-ended answer synthesis and answer index;
- - work-review/consistency review outputs.
- Outputs:
- project/outputs/final_conclusions/
- final_conclusions_report.md
- final_claims.jsonl
- relationship_takeaways.jsonl
- operating_rules.jsonl
- unresolved_questions.jsonl
- ledger_parse_summary.json
- final_conclusions.prompt.md
- final_conclusions_final.json
- STATUS.md
- Rules:
- - Final conclusions are high-level, model-generated interpretation.
- - Keep structured ledgers parseable.
- - Keep unresolved questions explicit.
- - Do not collapse uncertainty into advice.
- Pipeline: RAG and search
- ========================
- Purpose
- -------
- Build a local retrieval index across raw personal roots and curated generated
- evidence layers. Use it for search, chat, source expansion, and evidence
- review.
- Builder:
- project/scripts/personalos_rag.py
- Primary index:
- project/outputs/rag/personalos_fts.sqlite
- Vector files:
- project/outputs/rag/personalos_fts_<model>_<dimensions>.vectors.npy
- project/outputs/rag/personalos_fts_<model>_<dimensions>.vectors.json
- Default scan roots:
- - personal/
- - project/docs/
- - selected project/outputs subdirectories:
- chronology, synthesis, context_pack, current_state, daily_activity_index,
- final_conclusions, life_moment_examples, hierarchical_summaries, instagram,
- introspective_questions, location_index, media_captioning selected outputs,
- media_face_clustering selected outputs, open_ended_questions, psychoanalysis,
- relationship_graph, voice, work_review, birthdays
- - project/pipelines/merged_message_histories/outputs/
- Default exclusions:
- - prompts unless deliberately indexed for audit;
- - raw model responses;
- - response IDs;
- - errors;
- - batch internals;
- - cached media binaries;
- - broad duplicate acquisition tables that do not make useful chunks;
- - external symlink targets;
- - prior AI chats unless user asks about prior AI/chat behavior.
- Index commands:
- python3 project/scripts/personalos_rag.py index --verbose --include-legacy-globs
- python3 project/scripts/personalos_rag.py stats
- python3 project/scripts/personalos_rag.py refresh-source --path-contains <path_fragment>
- Embedding cost-safe commands:
- python3 project/scripts/personalos_rag.py estimate-embed --missing-only
- python3 project/scripts/personalos_rag.py estimate-embed --missing-only --embedding-scope all
- python3 project/scripts/personalos_rag.py embed --limit 100 --batch-size 128 --concurrency 4 --verbose
- python3 project/scripts/personalos_rag.py embed --embedding-scope all --batch-size 128 --concurrency 8 --max-usd <budget> --verbose
- python3 project/scripts/personalos_rag.py build-vector-index
- Safety:
- - estimate-embed and embed default to high-salience/default scope.
- - Unbounded paid embedding runs fail unless given --limit, --max-usd, or
- --yes-full-embed.
- - Preserve existing embeddings during rebuild when chunk hashes match.
- - Vector search must score all currently embedded chunks matching selected
- filters/scope, not only a tiny FTS candidate slice.
- Search commands:
- python3 project/scripts/personalos_rag.py search "query"
- python3 project/scripts/personalos_rag.py vector-search "query"
- python3 project/scripts/personalos_rag.py hybrid-search "query"
- python3 project/scripts/personalos_rag.py grep "exact phrase"
- python3 project/scripts/personalos_rag.py open <chunk_id>
- Retrieval modes:
- - evidence: multi-lane retrieval with exact variants, FTS, source-family lanes,
- vector lane, fusion, and grading.
- - hybrid: FTS plus vector with reciprocal-rank fusion.
- - fts: SQLite FTS5.
- - vector: direct semantic search.
- - exact: substring grep.
- Embedding salience:
- - default: raw high-signal personal material and curated evidence.
- - selective: useful expanded layers such as daily activity, location, message
- histories, synthesis, psychoanalysis, finance/health, broad media captions.
- - index_only: orientation/structural layers such as context packs, relationship
- graph, summary aliases, face metadata, profile seeds, project docs.
- - exclude: prior AI chats and other material excluded unless explicitly asked.
- Evidence roles:
- - primary: raw/local evidence.
- - derived_index: source-aware indexes/summaries.
- - analysis: model-generated analysis artifacts.
- - orientation: context packs or profile material.
- - prior_chat: previous AI chats.
- Formatting and chunking:
- - Embed source-aware readable text, not raw JSON when a deterministic formatter
- can preserve meaning better.
- - Preserve line breaks in chat transcripts.
- - Split chat-like sources around conversation boundaries and large time gaps.
- - Preserve stable local line ranges and chunk expansion handles.
- - Format media captions, media text, face records, chronology rows, finance
- rows, location rows, relationship graph rows, and generic JSONL/CSV as
- readable evidence blocks.
- - Strip raw response envelopes, request IDs, usage blobs, and batch metadata
- from RAG-facing text.
- Regression:
- python3 project/scripts/eval_personalos_chat_retrieval.py
- python3 project/scripts/eval_personalos_chat_retrieval.py --local-checks-only --include-local-vector-check
- Check:
- - expected paths for representative queries;
- - evidence role assignment;
- - line-preserving previews;
- - duplicate exclusion for seen chunks;
- - prior AI chat exclusion;
- - vector matrix row counts and scoring scope.
- Chat system
- ===========
- Purpose
- -------
- Provide a local web chat over the PersonalOS evidence index without injecting
- the entire archive every turn.
- Server:
- project/scripts/personalos_chat_server.py
- Normal use is through unified app server. Standalone debug command:
- python3 project/scripts/personalos_chat_server.py --port 8780
- Default chat flow:
- 1. First turn seeds the medium context pack.
- 2. Default rag_mode is tool: model receives retrieval/open tools and should
- retrieve for substantive archive/advice/chronology/relationship/work/health
- questions unless retrieval is clearly unnecessary.
- 3. The model writes purpose-built retrieval queries rather than passing the raw
- user prompt as the only query.
- 4. Retrieval uses embedding-backed evidence retrieval over high-salience scope
- by default.
- 5. Inject a retrieval digest with evidence roles, source mix, warnings,
- previews, and expansion handles.
- 6. The model answers from retrieved evidence or states uncertainty.
- Context modes:
- - primer: minimal orientation.
- - context_pack: default medium pack.
- - full: full v4 pack for explicit deep-context sessions.
- Follow-up behavior:
- - Exclude chunks already injected earlier in the same session unless explicitly
- opened for expansion.
- - Keep chat sessions under personal/conversations/ai_chats/.
- Dashboard and local app
- =======================
- Purpose
- -------
- Provide a local browser interface over generated aggregate data plus opt-in raw
- review, search, chat, media review, and relationship graph.
- Static app:
- project/sites/personalos_app/
- index.html
- app.js
- styles.css
- data/dashboard_data.json
- data/daily_activity_index.json
- vendor/
- globe/
- uber-map/
- presence-map/
- final-conclusions/
- Regenerate data:
- python3 project/scripts/build_current_state_dashboard.py
- Serve:
- python3 project/scripts/personalos_app_server.py --port 8765
- With auth:
- PERSONALOS_AUTH_PASSWORD='<strong password>' \
- python3 project/scripts/personalos_app_server.py --host 127.0.0.1 --port 8765
- Prefer password file for persistent launch:
- PERSONALOS_AUTH_PASSWORD_FILE=<0600_password_file> \
- python3 project/scripts/personalos_app_server.py --host 127.0.0.1 --port 8765
- Single-instance behavior:
- - The server should be single-instance guarded by default.
- - Re-running should print the existing URL and exit.
- - Use --allow-multiple and a different port only when explicitly needed.
- Mounted routes:
- - /: dashboard.
- - /chat/: local chat.
- - /search/: RAG search UI.
- - /media-captions/: media caption review.
- - /relationship-graph/: graph viewer.
- - /api/raw-stream: raw stream API.
- - /api/raw-media/photo/<id>: local photo derivative fetch.
- - /api/raw-email-body: on-demand email body expansion from mbox offsets.
- Sensitive APIs:
- - Raw-content endpoints must be loopback-only by default.
- - Use --allow-remote-sensitive-api only for an explicitly trusted local network
- debugging session.
- Dashboard data builder
- ----------------------
- Builder:
- project/scripts/build_current_state_dashboard.py
- Inputs:
- - filesystem metadata;
- - source counts;
- - pipeline status files;
- - aggregate JSON/CSV/Markdown status artifacts;
- - synthesis token/source metadata;
- - message analytics;
- - daily activity index;
- - RAG stats;
- - chronology/travel/location artifacts;
- - finance summaries;
- - media summaries.
- Outputs:
- project/outputs/current_state/dashboard_data.json
- project/outputs/current_state/daily_activity_index_app.json
- project/outputs/current_state/README.md
- project/sites/personalos_app/data/dashboard_data.json
- project/sites/personalos_app/data/daily_activity_index.json
- Rules:
- - Metadata-only by default.
- - Store counts, labels, paths, statuses, token estimates, and aggregate metrics.
- - Do not embed raw message bodies or source document bodies.
- - Validate generated payload before writing dashboard copies.
- Dashboard views
- ---------------
- Recommended sections:
- - overview/source coverage;
- - messages: distribution, timeline, platforms, people, email, Instagram;
- - finance: overview, peaks, bank, PayPal, monthly combined ledger;
- - chronology: overview, candidate datapoints, corrected trip timeline,
- every-day timeline, movements, movement globe, presence map;
- - raw stream: opt-in chronological scroll over source rows;
- - raw plain: day-separated reader with content/source toggles;
- - search: mounted RAG search;
- - chat: mounted RAG chat;
- - media captions: review/search surface;
- - relationship graph: full graph viewer and compact relationship manager;
- - final conclusions: structured high-level interpretation view.
- Raw stream index
- ----------------
- The app consumes:
- project/outputs/raw_stream/raw_stream_index.sqlite
- It should contain chronological rows across messages, photos, calendar rows,
- email headers, and other reviewable source rows, with enough offsets/paths to
- load source content on demand.
- Important gap to address in a clean recreation:
- - The current app consumes this SQLite index, and daily activity can read it,
- but the standalone builder is not clearly documented in the script index.
- A clean implementation should add:
- project/scripts/build_raw_stream_index.py
- It should read normalized source artifacts and write:
- raw_stream_index.sqlite
- raw_stream_summary.json
- README.md
- Required fields:
- stream_id
- timestamp_utc
- timestamp_local
- date_local
- source_family
- source_type
- source_path
- source_locator
- file_key
- byte_start
- byte_end
- line_start
- line_end
- media_id
- conversation_id
- sender_label
- is_from_me
- title
- preview
- has_body
- sensitivity
- Search UI
- ---------
- Standalone fallback:
- python3 project/scripts/personalos_search_server.py --host 127.0.0.1 --port 8770
- Modes:
- - semantic vector;
- - hybrid;
- - keyword FTS;
- - exact.
- Browser semantic search sends query text to the embedding API. Keyword and exact
- stay local.
- Relationship graph viewer
- -------------------------
- Static viewer:
- project/sites/relationship_graph/
- Canonical data:
- project/outputs/relationship_graph/relationship_graph.json
- Mounted URL:
- http://127.0.0.1:8765/relationship-graph/
- Rules:
- - Uses metadata-only graph JSON.
- - Vendor graph renderer locally.
- - Do not load message bodies.
- Chronology globe, ride map, and presence map
- --------------------------------------------
- Movement globe:
- project/sites/personalos_app/globe/
- Inputs:
- - dashboard_data.json;
- - travel movement events;
- - approximate track geometry;
- - optional vendored Earth/land assets and Three.js.
- Rules:
- - Full-bleed scene or dense embedded panel.
- - Verify nonblank desktop/mobile canvas.
- - Use approximate tracks with confidence labels.
- Ride map:
- project/sites/personalos_app/uber-map/
- Inputs:
- - redacted rides visualizer data;
- - optional flight legs;
- - optional OSM road-route cache.
- Commands:
- python3 project/scripts/build_uber_ride_visualizer_data.py
- python3 project/scripts/build_uber_road_route_cache.py
- python3 project/scripts/render_uber_route_qa_contact_sheet.py
- Rules:
- - Redacted rounded endpoints only.
- - OSM routes are approximate recomputations, not actual telemetry.
- Presence map:
- project/sites/personalos_app/presence-map/
- Command:
- python3 project/scripts/build_presence_map_data.py
- Inputs:
- - rides;
- - flight legs;
- - photos/location overlays;
- - endpoint overlays.
- Privacy and security tooling
- ============================
- Secret scanner
- --------------
- Script:
- project/scripts/scan_generated_artifact_secrets.py
- Default command:
- python3 project/scripts/scan_generated_artifact_secrets.py
- Specific artifact:
- python3 project/scripts/scan_generated_artifact_secrets.py project/outputs/path/to/artifact
- Default scope:
- - project/outputs;
- - project/tmp;
- - pipeline-owned outputs directories.
- Default exclusions:
- - personal/raw;
- - personal/conversations;
- - acquisition archives such as large mbox files unless explicitly targeted.
- Flags:
- --include-raw-source
- --include-acquisition-archives
- --report <path>
- --no-status
- Rule families:
- - private key blocks;
- - OpenAI/Anthropic/GitHub/AWS/Google/Slack/Stripe tokens;
- - JWTs;
- - sensitive variable assignments.
- Behavior:
- - Report only path, line, rule ID, severity, and description.
- - Do not print matched secret value.
- - Write redacted report under project/outputs/privacy/.
- - Update STATUS.md unless disabled.
- - A nonzero result blocks external movement until remediated, rotated, or
- explicitly false-positive reviewed and rescanned.
- Backup and change tracking
- --------------------------
- Recommended:
- - encrypted local/cloud backup for raw archives;
- - restore test documentation;
- - narrow git repository for code/docs only, if any;
- - .gitignore raw archives, conversations, RAG indexes, large generated packs,
- credentials, model responses, and local cache files.
- Do not initialize full-workspace git over raw sources and large generated
- private outputs unless you have a strict ignore policy.
- Deployment/proxy layer
- ======================
- There is an optional deploy shim for a remote proxy:
- project/deploy/personalos_vercel_proxy/
- package.json
- vercel.json
- api/proxy.js
- Purpose:
- - Relay HTTP requests from a deployed endpoint to a configured PersonalOS origin
- URL.
- Rules:
- - Do not commit provider-generated .vercel metadata.
- - Do not commit project IDs or organization IDs.
- - Configure upstream via environment variable such as PERSONALOS_ORIGIN_URL.
- - Ensure the origin server itself has strong authentication.
- - Proxy responses should set no-store cache headers.
- - Use this only if you understand the privacy risk of making any PersonalOS
- surface reachable over the network.
- Miscellaneous local utilities
- =============================
- Discord export helper
- ---------------------
- The workspace can vendor a local copy of DiscordChatExporter or an equivalent
- tool under:
- project/tools/discordchatexporter/
- Use it to create Discord JSON exports for DMs, group DMs, and selected server
- snippets. Keep tool binaries out of RAG indexing. Keep raw exported JSON under
- personal/raw/messages/discord_dce/ and normalize into merged-message histories
- from there.
- Browser path blocker
- --------------------
- The workspace can include a small local focus utility:
- project/scripts/x-home-blocker/
- Purpose:
- - Block one distracting browser path such as a social feed home URL without
- blocking the entire host or normal deep links.
- Implementation:
- - Browser enterprise policy for Chrome/Firefox URL blocklists.
- - Optional Chrome extension for single-page-app navigation where URL changes
- happen without a full reload.
- - macOS configuration profile alternative if desired.
- Rules:
- - Use placeholder install commands in docs:
- sudo <workspace>/project/scripts/x-home-blocker/install.sh
- sudo <workspace>/project/scripts/x-home-blocker/uninstall.sh
- - Do not hard-code local usernames in the utility README.
- - Keep browser-control utilities separate from PersonalOS evidence pipelines.
- Testing and verification
- ========================
- Local tests:
- python3 -m unittest discover project/tests
- Current test focus:
- - app server raw stream route behavior;
- - search server behavior.
- Add tests for:
- - path helper canonicalization;
- - message event schema validation;
- - identity override resolution;
- - chronology candidate filter behavior;
- - RAG formatter output for each source family;
- - secret scanner redaction;
- - dashboard payload validation;
- - raw API loopback/auth behavior.
- Pipeline validation checklist:
- - JSONL parse checks for every JSONL output.
- - Required schema field checks.
- - Duplicate ID checks.
- - Missing timestamp checks.
- - Output count parity with source manifests.
- - No raw message bodies in metadata-only reports.
- - No raw credentials in generated artifacts.
- - Model response status complete before overwriting final stage outputs.
- - Empty/error files reviewed.
- - Dashboard JSON validates before copying to site.
- - RAG embedding counts match chunk counts for selected scope.
- - Vector manifest row order matches vector matrix row order.
- - Browser screenshots for dashboard/globe/maps/media views after UI changes.
- Recreate-from-zero runbook
- ==========================
- Phase 0: create workspace
- -------------------------
- 1. Create <workspace>.
- 2. Add README.md, AGENTS.md, personal/, project/.
- 3. Add project/scripts/personalos_paths.py.
- 4. Add project/docs/PRIVACY_SECURITY_CHECKLIST.md.
- 5. Add project/docs/LEGACY_PATHS.md if migrating older paths.
- 6. Add project/config/subject.json.
- 7. Add project/config/identity_seed_events.jsonl.
- Phase 1: collect raw exports
- ----------------------------
- 1. Put writing exports under personal/raw/writing.
- 2. Put message exports under personal/raw/messages.
- 3. Put voice exports/transcripts under personal/raw/voice.
- 4. Put calendar/mail/photos/location exports under relevant raw folders or
- chronology acquisition folders.
- 5. Put finance exports under personal/raw/finance.
- 6. Put health exports under personal/raw/health only if desired.
- 7. Do not normalize in place.
- Phase 2: normalize platform-specific sources
- --------------------------------------------
- 1. Export/normalize iMessage or equivalent local chat DB.
- 2. Export/normalize Signal.
- 3. Export/normalize Discord with account metadata when available.
- 4. Export/normalize Snapchat chat/activity.
- 5. Run Instagram normalizer.
- 6. Export/normalize Twitter/X direct/group messages and public account data.
- 7. Build voice manifest and repeat-artifact triage.
- 8. Extract finance and rideshare/location derived redacted outputs.
- 9. Export calendar/photos metadata.
- 10. Index mail mbox and curate evidence.
- Phase 3: build message graph
- ----------------------------
- 1. Run merged message histories.
- 2. Review identity queues.
- 3. Edit identity_overrides.csv.
- 4. Rerun merged histories.
- 5. Run activity reports.
- 6. Run salience windows.
- 7. Build relationship graph.
- 8. Build friend mention index if desired.
- Phase 4: build chronology/location/activity
- -------------------------------------------
- 1. Build chronology seed.
- 2. Build chronology candidate pack.
- 3. Write initial chronology draft from candidate pack.
- 4. Integrate mail/finance/location/social addenda.
- 5. Build major trip/travel movement ledgers if location data supports it.
- 6. Build daily location model.
- 7. Build daily activity index.
- 8. Build common location index, naming, resolution, and activity layers.
- Phase 5: build media layers
- ---------------------------
- 1. Build media caption manifest.
- 2. Run small sample caption QA.
- 3. Run full batch captioning with budget controls.
- 4. Collect/retry/index captions.
- 5. Run text/OCR pass if needed.
- 6. Build important media text.
- 7. Run emotional/life-moment tag layer.
- 8. Run face candidate/detect/cluster/index if needed.
- Phase 6: build life moments, context packs, synthesis
- -----------------------------------------------------
- 1. Extract life-moment examples.
- 2. Build source tagging for notes/voice.
- 3. Build docs/notes/voice context pack.
- 4. Build full context pack v4.
- 5. Build medium default context pack.
- 6. Run synthesis plan.
- 7. Run synthesis source cards.
- 8. Run primary moments, claim ledger, contrasts, theme dossiers, audit, and
- final report.
- 9. Update synthesis README/status.
- Phase 7: build interpretive layers
- ----------------------------------
- 1. Run psychoanalysis prepare/plan.
- 2. Run relationship dossiers.
- 3. Run self/theme dossiers.
- 4. Extract/consolidate ledgers.
- 5. Run skeptical audit.
- 6. Run final report.
- 7. Run introspective questions.
- 8. Run open-ended questions.
- 9. Run final conclusions.
- 10. Keep all interpretation clearly downstream of evidence.
- Phase 8: build RAG, dashboard, and app
- --------------------------------------
- 1. Build raw stream index.
- 2. Build RAG index.
- 3. Estimate embeddings.
- 4. Embed with limit/budget first.
- 5. Embed full selected scope only with explicit confirmation/budget.
- 6. Build vector index.
- 7. Run retrieval regression checks.
- 8. Build dashboard data.
- 9. Serve unified app locally.
- 10. Verify dashboard/search/chat/media/graph/globe/map views.
- Phase 9: pre-export review
- --------------------------
- 1. Run secret scan.
- 2. Review generated artifacts for personal identifiers and sensitive facts.
- 3. Create purpose-specific redacted artifact if sharing.
- 4. Do not share canonical generated outputs directly.
- Recommended status docs
- =======================
- Every major output family should have README.md or STATUS.md:
- project/outputs/README.md
- project/outputs/synthesis/README.md
- project/outputs/synthesis/synthesis_update_status.md
- project/outputs/chronology/STATUS.md
- project/outputs/daily_activity_index/README.md
- project/outputs/instagram/STATUS.md
- project/outputs/life_moment_examples/STATUS.md
- project/outputs/rag/README.md
- project/outputs/current_state/README.md
- project/outputs/relationship_graph/STATUS.md
- project/outputs/relationship_chunking/STATUS.md
- project/outputs/voice/STATUS.md
- project/outputs/media_captioning/RUN_STATUS.md
- project/outputs/media_face_clustering/STATUS.md
- project/outputs/location_index/README.md
- project/outputs/privacy/STATUS.md
- project/pipelines/merged_message_histories/STATUS.md
- project/outputs/psychoanalysis/STATUS.md
- project/outputs/final_conclusions/STATUS.md
- Status docs should include:
- - generated_at/updated_at;
- - command used;
- - input roots;
- - output paths;
- - counts;
- - validation checks;
- - known gaps/caveats;
- - rerun instructions;
- - privacy notes.
- Output directory catalog
- ========================
- Use these cross-project output families:
- project/outputs/ad_hoc/
- One-off outputs that do not yet deserve a stable pipeline family.
- project/outputs/birthdays/
- Birthday/evidence review artifacts.
- project/outputs/chronology/
- Seed/candidate events, chronology drafts, travel/location movement,
- acquisition outputs, visual timelines, addenda.
- project/outputs/context_pack/
- Full and medium source-aware context packs plus stats/audits.
- project/outputs/current_state/
- Dashboard snapshot and current state reports.
- project/outputs/daily_activity_index/
- Day-by-day evidence packets, model labels, final ledgers.
- project/outputs/final_conclusions/
- Final integrated report and structured ledgers.
- project/outputs/hierarchical_summaries/
- Summary nodes, edges, aliases, life-moment candidates.
- project/outputs/instagram/
- Derived Instagram DMs/public/attention/chronology/identity outputs.
- project/outputs/introspective_questions/
- Extracted self-question candidates, batches, final report.
- project/outputs/life_moment_examples/
- Extracted life-moment examples and source packs.
- project/outputs/location_index/
- Common places, resolution, activity, naming.
- project/outputs/media_captioning/
- Captions, text pass, important text, tag layers, SQLite.
- project/outputs/media_face_clustering/
- Face candidates, detections, clusters, SQLite.
- project/outputs/open_ended_questions/
- Question bank, answers, synthesis.
- project/outputs/privacy/
- Secret-scan reports and status.
- project/outputs/psychoanalysis/
- Deep formulation reports, ledgers, audit, final.
- project/outputs/psychoanalysis_fable/
- Review-first large-context source packs and staged prompts.
- project/outputs/rag/
- SQLite FTS/vector retrieval index and vector matrix.
- project/outputs/raw_stream/
- Raw stream SQLite index used by local app APIs.
- project/outputs/relationship_chunking/
- Model-ranked relationship chunks and compact subchunk packs.
- project/outputs/relationship_graph/
- Metadata-only graph, closeness rankings, friend mentions.
- project/outputs/source_tagging/
- Source ranking/tagging outputs for notes and voice.
- project/outputs/synthesis/
- Contrastive synthesis stages.
- project/outputs/voice/
- Voice manifest, transcript triage, cleanup candidates.
- project/outputs/work_review/
- Consistency review and project self-audit outputs.
- Known implementation improvements for a clean clone
- ===================================================
- 1. Parameterize subject-specific filenames and identity facts.
- Older scripts may use fixed <subject_slug> filenames or embedded seed facts.
- Move those into project/config.
- 2. Add a documented raw-stream builder.
- The app consumes raw_stream_index.sqlite; make its builder explicit.
- 3. Standardize CLI behavior.
- Every script should have argparse --help that never mutates outputs.
- 4. Centralize model/provider config.
- Put model defaults, reasoning defaults, max output tokens, and cost guards in
- config files or shared helpers.
- 5. Add a unified validation command.
- A top-level project/scripts/validate_personalos.py should run JSONL checks,
- schema checks, secret scan, RAG stats, dashboard payload validation, and
- selected unit tests.
- 6. Move large paid-run manifests to explicit budgeted workflows.
- Any full embedding, media captioning, synthesis, or formulation run should
- fail closed without limit, budget, or confirmation.
- 7. Add source-family privacy levels.
- Each source family should carry default exposure, RAG salience, dashboard
- visibility, raw drilldown permission, and export policy.
- 8. Add schema versioning.
- Every durable JSONL/CSV output should include schema version in manifest or
- row metadata.
- 9. Improve redaction/export tooling.
- Build a separate redacted-export generator rather than manually editing
- canonical private artifacts.
- 10. Keep visual QA artifacts but avoid indexing them.
- Screenshots and QA images are useful locally but should not become RAG
- evidence unless deliberately selected.
- Minimal viable PersonalOS
- =========================
- If recreating from scratch with limited time, build this subset first:
- 1. canonical folder layout and path helper;
- 2. raw writing export;
- 3. at least one message-platform normalizer;
- 4. merged message histories;
- 5. identity review/overrides;
- 6. chronology seed/candidate pack;
- 7. context pack medium;
- 8. RAG index with FTS first;
- 9. dashboard data and unified local server;
- 10. secret scanner.
- Then add:
- 11. embeddings/vector search;
- 12. synthesis;
- 13. daily activity;
- 14. location/media layers;
- 15. psychological/open-ended/final-conclusion layers.
- Definition of done
- ==================
- A rebuilt PersonalOS is functionally complete when:
- - Raw exports are preserved under personal/raw.
- - Canonical scripts use path helpers and subject config.
- - Message events, identities, conversations, and top histories build cleanly.
- - Chronology seed and candidate packs build with source refs.
- - Context pack full and medium variants build with stats and coverage audits.
- - RAG index builds, embeds under budget controls, and passes retrieval checks.
- - Dashboard data builds without raw source bodies.
- - Unified local app serves dashboard, search, chat, raw review, media review,
- and graph routes.
- - Privacy scanner runs and blocks external export on findings.
- - Major generated families have README/STATUS docs.
- - High-level analysis artifacts separate evidence from interpretation.
- - The user can answer: "where did this claim come from?" for any important
- claim by following local source references back to primary evidence.
Advertisement
Add Comment
Please, Sign In to add comment