SkeletonKey is a local-first personal record and self-sousveillance framework. It brings environmental awareness, connected information, timelines, field memory, and practical action into one system you can inspect, adapt, and control.
Source-available · Local-first by design · Optional AI · Built to be extended
Maps, routes, weather, location, events, field notes.
Documents, people, places, timelines, relationships, context.
Plans, tasks, goals, alerts, and recorded outcomes.
SkeletonKey connects capabilities that are often separated across unrelated apps and services. Each part has a job; together, they help preserve context from the first observation through to the action it informs.
Offline maps, local geographic search, routing, elevation, location tracking, and environmental feeds support awareness in the field. Capabilities depend on the configured services and available local data.
Maintain connected records of events, places, people, documents, timelines, narratives, finances, plans, and relationships. Imported information and evolving interpretations can remain part of a shared context.
Field logs, alerts, tasks, goals, and plans help connect what happened and what you know to what you choose to do next. The system supports decisions; it does not replace your judgment.
These screenshots are from the project’s running desktop and phone applications. Open any image to view it at full size.
Images are served directly from the project repository. The README describes them as captured from the running app using a synthetic demo record.
SkeletonKey grew from a practical problem: making sense of a complicated situation meant keeping track of documents, institutions, case references, money, tasks, and timelines spread across different places.
A separate case-management tool helped connect tasks to evidence and goals. Integrating that work with a broader timeline and knowledge system revealed a larger possibility: one persistent record could connect the circumstances around a person with the information they gather and the actions they take.
The project has since expanded into environmental awareness, offline tools, field memory, and optional agents that can work with the same record under explicit permissions.
The system should increase your ability to understand and direct your own life — without making that ability dependent on the system itself. SkeletonKey's guiding idea
SkeletonKey is a collection of connected components. Optional integrations extend the system; they are not all required for the core record to be useful.
A desktop and browser-accessible record for events, locations, people, sources, narratives, money, tasks, and connected context, with import and export support.
Local map data, a geographic gazetteer, routing, and elevation tools can provide core geographic capabilities without a live map API or API key, once the required data is installed.
The Android beacon can send configured position and sensor information, provide on-device speech features, and receive messages from the local system. It requires setup and a reachable configured server.
A proactive watch can check defined conditions such as lost signal, prolonged stops, movement anomalies, geofences, or dusk. Alerts depend on configuration and available signals.
A tiered field log moves from raw events to daily digests and more compact narratives, helping retain useful continuity while distinguishing detailed records from summaries.
Model Context Protocol (MCP) tools allow compatible agents to retrieve information and, where explicitly permitted, propose or perform changes. Model quality and capabilities vary. Cloud inference sends selected context to the provider.
These principles are meant to shape implementation decisions, not merely describe the project's intentions.
Prioritize local storage, inspectability, portability, and the ability to export or delete personal records.
The underlying record and tools should remain useful without an AI agent. AI adds a way to interact with the system; it is not the source of truth.
Maps, weather sources, models, and integrations should be replaceable without needlessly losing records, relationships, or workflows.
Keep source material, summaries, hypotheses, and recorded actions distinguishable. Preserve uncertainty instead of presenting inference as fact.
Access, writes, external data flows, and optional extensions should have visible boundaries and meaningful approval controls.
Users should be able to stop the beacon, disable optional services, disconnect agents, and remove their record.
The system is designed to maintain continuity between what enters the record, how it is understood, and what happens next.
Record an event, import a document, add a field note, or use a configured map, beacon, or environmental service.
Relate the information to existing people, places, timelines, sources, and plans. Keep the origin and confidence of interpretations visible.
Use the connected record to make a decision, create a task, or configure an alert. Track the outcome without confusing a suggestion with a completed action.
SkeletonKey combines local capabilities with optional networked services. The actual privacy and availability characteristics depend on which components you enable and how you configure them.
The core record, MCP tools, and offline map stack are designed to run locally. Offline geographic use requires the relevant map and routing data to be installed.
Weather or hazard feeds, a phone beacon connection, messaging bridges, and other integrations can require network access. Their data flows should be reviewed before use.
When a cloud model is used, the context sent to it leaves the local machine. Use local inference when local-only processing is required, understanding that model performance may differ.
SkeletonKey is an evolving source-available project. Explore the code, read the technical documentation, inspect the boundaries, and decide which components fit your needs.