Continuity
Identity, persistent memory, conversations, and structured personal context.
A self-hosted personal AI system connecting information, tools, devices, and workflows. Built from the original Jarvis prototype into a platform with persistent context, academic tools, and owner-approved development.
JOS supplies the surrounding application: identity, persistent conversations and memory, structured personal data, tools, approval workflows, security, remote access, and system configuration. Model and provider flexibility remain an active development direction.
Identity, persistent memory, conversations, and structured personal context.
Calendar awareness, academic tools, integrations, file storage, and Codex development.
Owner approval, authentication, settings, and a consistent interface across devices.
The underlying model can change. JOS remains JOS.
Newest first. Approximate dates are kept as recorded; their order within a month or year is not exact.
I started a personality overhaul to make JOS more consistent and direct, with less generic assistant language. I wanted its responses to feel more familiar and better matched to the conversation.
I explored visual directions for JOS, including terminal-inspired type and simple symbols. I also considered a startup animation, but neither a final logo nor a finished animation was established.
I started extending personality settings into user-facing configuration. Controls for humor, directness, energy, and formality were still being developed.
I started designing a dedicated offline page for when Homebase is unreachable. It could show limited, non-sensitive connection information instead of a generic error, but it was not deployed.
I started a broader interface redesign, including dashboard spacing, cards, typography, and grouping. I also worked on collapsible sidebar categories to make the growing navigation easier to use. This redesign was still in progress.
I improved the organization of Codex tasks so their states were easier to scan. I also updated how individual scholarship opportunities showed details such as deadlines, eligibility, and status.
I added Codex Bridge to connect JOS to its development environment. I was still investigating why it could appear offline away from home even when Tailscale was active.
I worked on putting system configuration under System → Settings, starting with appearance and Codex options. More settings were planned, but the full settings system was still in development.
I built my portfolio and began designing a workflow for JOS to draft updates that could be applied to its repository. Public updates would still require my approval; this did not establish a working publishing connection.
I began exploring Apple Watch health data and Sleep Focus changes as a trigger for a JOS morning briefing. I also questioned whether this would be more useful than simply scheduling the briefing. It remained an experiment.
I revisited the briefing idea with more context about my day, upcoming exams, projects, and relevant news. This was planning work, not a completed briefing system.
I made owner authentication the default and protected the API routes and documentation. I also tightened session handling, added login and request limits, and separated Codex worker authentication.
I clarified that my LAN address, Tailscale address, and usejos.com all pointed to the same application. I did not need separate versions for each connection method.
I added a Scholarship section and planned how it could help discover and track opportunities. Ranking, eligibility checks, and automatic discovery were broader design goals, not all finished features.
I worked on making JOS accessible at usejos.com through Cloudflare Tunnel. The application continued running on Homebase.
I expanded the Courses page toward a dashboard with clearer course information and upcoming work. I focused on making assignments, deadlines, and course status easier to see.
I started exploring how JOS could use configurable AI models. Support for different providers, local models, or models for specific tasks was still experimental.
I looked into connecting Canvas for assignments, deadlines, and course information. My institution restricted student-created API tokens, so the direct integration was blocked.
I defined a workflow where JOS can suggest adding a capability but must ask me before changing its code. I wanted to keep control of which changes get made.
Google Calendar authorization needed repair on the headless Homebase server. I used SSH port forwarding for the browser callback, renewed access, and restarted the backend to restore it.
I connected the development workflow to Codex and added Codex Drafts to track proposed tasks. Code changes require my approval, followed by implementation, testing, and review.
I connected JOS to Google Calendar so it could use my actual schedule. This gave it access to events and deadlines instead of relying only on information I typed into chat.
I worked on a briefing concept that would include my schedule, free time, study priorities, and project suggestions. It was still a plan rather than a finished daily workflow.
Saving a syllabus did not automatically let JOS answer questions about grading, attendance, or course policies. I still needed to improve how it reads and retrieves the relevant parts of those documents.
I moved approval and destination-conversation settings out of the normal Codex Draft interface. This let that page focus on development tasks.
I improved the workflow for reviewing, approving, and rejecting extracted assignments. I kept the course name visible, added Reject All, and moved adding assignments to the calendar to the final step.
I set the rule that JOS could help draft and organize portfolio updates, but I would approve public changes. This described the publishing policy rather than a tested integration.
I added persistent syllabus storage on Homebase and linked uploads to courses in PostgreSQL. I confirmed that a CHM 111 syllabus was stored and tracked as uploaded.
After starting classes, I decided JOS should keep track of course information instead of making me explain it repeatedly. I focused on courses, syllabi, assignments, and deadlines.
I started replacing Jarvis references across the code, interface, prompts, and configuration. I also registered usejos.com and moved toward keeping the assistant’s identity in one configuration.
I changed the name from Jarvis to JOS, short for Just One System. I wanted a name that belonged to this project rather than being tied to Marvel.
The backend, model connection, identity layer, and web interface were coming together. I built and tested a service to create conversations and save and retrieve messages before connecting it to the main chat API.
I built a workflow for uploading syllabi and planned the extraction steps around reviewing the results before saving them. I wanted to approve course and assignment information rather than trust AI extraction automatically.
I started planning how JOS could connect school, business, projects, coding, files, and other tools. This was the direction for the project, not a set of finished integrations.
I connected saved conversations to the interface and checked that history stayed available after refreshing. I added conversation switching, New Chat, and navigation for desktop and mobile.
I continued working on the desktop and mobile interfaces so I could use JOS from more than one device. Voice access was still a future goal.
I added a dedicated identity and personality layer for JOS. This keeps its name, tone, and communication rules separate from the AI model underneath it.
I built the backend with Python and FastAPI and added PostgreSQL for persistent data. I introduced Alembic migrations so database changes could be tracked as the project grew.
I got the web interface to send a message to the AI model and display its response. I also designed a PostgreSQL-backed memory system for conversation context, tasks, and longer-term information; that design was separate from getting chat working.
I started developing the assistant on Homebase under the name Jarvis. My first goal was to get an AI-powered web chat working.
I wanted a self-hosted assistant that could remember context and help with my calendar, tasks, projects, and detailing business. I planned to use it from my computer and phone, with voice as a later goal.
I separated the design into identity, conversation, memory, planning, tools, and interface components. I wanted the AI model to be one part of the application rather than the whole application.
Logical application layers, not a network request sequence. The diagram distinguishes working capabilities from ongoing and future work.
Web and mobile-compatible surfaces for chat, dashboard, Courses, Scholarships, Codex, and System Settings. Voice is planned.
Defines name, tone, humor, communication style, and behavioral rules. The personality overhaul and additional controls are in development.
Language understanding, reasoning, responses, planning, and tool selection. The model sits behind the application boundary.
Persistent conversations and messages, with a layered memory design. Richer memory and document retrieval are still in development.
Persistent structured application data, with Alembic migrations and separate persistent storage for uploaded files.
Capabilities connected through the application services. Availability and maturity differ by integration.
A missing capability becomes a proposal, not silent self-modification. The owner’s approval gates implementation, and testing and review gate the resulting capability.
Python · FastAPI · REST APIs
PostgreSQL · Alembic · Persistent file storage
AI model APIs · Codex · Git · GitHub
Docker · Docker Compose · Homebase · Cloudflare · Cloudflare Tunnel · Tailscale
OAuth · Google Calendar API · Authentication · Web security
HTML · CSS · JavaScript · Responsive interfaces
Improve memory retrieval and syllabus parsing, indexing, and contextual answers.
Direct integration depends on institutional API access becoming available.
Add voice interaction and more APIs as new capabilities are reviewed and approved.
Explore configurable providers, task-specific models, and potential local AI models.
Build richer schedule-aware project, study, news, and article recommendations.
Extend capability generation and portfolio update automation while preserving owner approval.
Refine consistent personality, mobile UX, navigation, and additional System Settings.
Improve monitoring and the offline experience when Homebase is unavailable.
Explore branding and a startup-animation concept without treating either as final.
Coordinate more work while retaining explicit approval boundaries for consequential changes.