Home / Product / Atlas and Studio

Affirmology Atlas - overview (v1, for Jeff to tweak)

Updated Jun 18, 2026 · Affirmology_Atlas_Overview_v1.md

Affirmology Atlas - overview (v1, for Jeff to tweak)

This is the working overview of Atlas, the app version of the Affirmology system. It builds on the original Affirmology_Atlas_AppSpec_v1.md and fleshes it out into a buildable v1. Mark it up freely. The companion how-to (Affirmology_Activation_HowTo_v1.md) holds the click-by-click cloud steps; this doc is the what and why.

Names are locked: the app is Atlas, the in-app assistant is Hermes.

1. The one-sentence version

Atlas is the whole Affirmology system surfaced as a single installable app on the phone and the Mac: open it, talk to Hermes, and the full Studio is one tap away.

2. Where it sits right now (June 2026)

• Render and R2 are SET UP and the upload is in progress (the cloud move, build-order step 1, is underway).
• Corpus upload to the cloud is the next dependency (so cloud generation stays chart and corpus grounded).
• The corpus overnight upgrade runs tonight.
• Atlas (PWA + Hermes + voicenotes + messaging) is the build right after the cloud move lands. It cannot ship before the cloud is up, because it must be available 24/7 on everyone's schedule and store voicenotes and messages.

So the order is: finish the cloud move and corpus upload, confirm one real cloud render, then build Atlas v1 on top.

3. The core idea: one app, two modes, one tap between them

Hermes (chat mode) - the default, dead simple. A chatbot wired to the live backend system and to every document in the jpl-knowledge share. Voicenote or type. Ask anything, drop an idea, leave feedback, ask about any project doc, check on the system. This is the on-the-road mode, the thing Jeff opens from his phone in the car.

Hermes is the ROUTER and the SUPPORT desk, not a tradition specialist. He is the warm front desk: he answers and hands each specialist question to the oracle who owns it (Western astrology to Sophia, Gene Keys to Athena, Human Design to Prometheus, Vedic to Parashara, numbers to Pythagoras), files feedback into the system, and routes requests to the composer or the team. He ALSO handles app support: how to use Atlas and the Studio, what the structures are, navigation, troubleshooting, and plans/billing questions (account-specific billing is explained generally and routed to the team, never invented or actioned by Hermes). Character/voice profiles: CLAUDE OUTPUTS/Affirmology/Affirmology_CouncilCharacters_VoiceProfiles_v1.md.

Client-facing Hermes (PHASE 2). Today Hermes serves the internal team only (Jeff, Sol, Colin, behind the gate); clients meet the demo and their delivered audio, not Hermes. The natural next phase makes Hermes the CLIENT concierge too: a customer opens their reading and Hermes answers about their own chart and audio, takes their feedback, and routes requests. This needs a new CLIENT permission tier (scoped to that one client's own chart and audios only, never the team's internal world, never another client's data, never the business/equity material). Because Hermes is already built as a router, pointing him outward is mostly a permission tier plus a scoped knowledge view, not a rebuild.

Studio (full mode) - the complete workbench. People, structures, the conversational composer, the library, versions, render. Everything the cloud Studio already does.

A single prominent toggle flips between them. Hermes is the easy front door; Studio is one tap away.

4. What Atlas does (feature set)

• Voicenoting everywhere. Record feedback, ideas, or questions by voice from the phone. Transcribed, stored in R2, routed into the system (and into feedback where relevant).
• Hermes knows everything safe. Live system state plus all jpl-knowledge docs, so it can answer about the project, the agents, the charts, the Studio, and the investor material at a high level, and help draft on brand.
• Team messaging lives on the HERMES side, not the Studio side. Jeff, Sol, and Colin send app-related messages to each other, Slack-like, inside the Hermes chat surface (share an audio + report, "give this a listen," drop an idea). The Studio stays the workbench; messaging is a Hermes feature.
• Full Studio when you want it. Compose, iterate scripts, render keepers, browse the library, all from the same app.

5. Cross-platform: phone AND Mac

Atlas is an installable PWA (progressive web app) on the cloud Studio. One codebase, one login (Cloudflare Access), installs on:

• iPhone / Android home screen (feels native),
• Mac (Chrome or Safari Install / Add to Dock),
• any browser.

Same Atlas on the phone and the Mac, same account, same data. The Studio was already built mobile-first, so it should work on a phone today (worth testing studio.affirmology.ai on the phone now). Atlas adds the polished mobile layout, the PWA wrapper (manifest + service worker + icon), the Hermes-first default screen, voice capture, and the mode toggle.

6. How it rides the cloud (architecture)

Atlas is the same cloud Studio, surfaced as an app with a Hermes-first, two-mode UI. It needs Render and R2 because it must be available 24/7, store voicenotes, and carry messages between people.

• Render - the 24/7 FastAPI server (the existing Studio app, STUDIO_STORAGE=r2, gated STUDIO_REQUIRE_AUTH=true).
• R2 - durable storage for rendered media, voicenotes, and (the cloud copy of) the corpus DB so generation stays grounded.
• Cloudflare Access - one login across phone and Mac; email allowlist (Jeff, Sol, Colin).
• Hermes's knowledge - read access to live system state plus the jpl-knowledge docs, tier-walled so Tier C copyrighted material is never exposed and no person's chart content bleeds into another's.

7. Version 1 scope (proposed - tweak this)

In v1:

1. The cloud Studio running on Render + R2 (the move itself).
2. Installable PWA, phone and Mac, mobile-polished.
3. Hermes chat as the default screen, connected to system state + jpl-knowledge, with the one-tap toggle to full Studio.
4. Voicenote capture stored in R2.
5. Team messaging (Jeff, Sol, Colin).

Deferred past v1 (candidates, your call):

• Push notifications for messages and required requests.
• Hermes taking actions (kicking off a render, filing structured feedback) rather than just answering.
• Offline mode beyond basic PWA caching.
• Native app-store builds (the PWA likely covers this; revisit only if needed).
• A custom media domain (media.affirmology.ai) for direct public delivery.

8. Build order for v1 (when Render + R2 are up)

1. Move the Studio to Render + R2 and confirm one real cloud render end to end (media lands in R2, corpus DB reachable).
2. Make it an installable PWA (manifest + service worker + icon), phone and Mac, mobile-optimized.
3. Add the Hermes chat mode (system + jpl-knowledge connected) as the default, with the one-tap toggle to full Studio.
4. Add voicenote capture (R2) and team messaging.
5. Install on Jeff's phone (Add to Home Screen) and Mac (Install from the address bar), same Cloudflare Access login; have Sol and Colin install and test.

9. Guardrails Atlas must honor (non-negotiable)

• The demo stays LOCKED and untouched; all experimentation lives in the Studio. Atlas surfaces the Studio, never the demo render path.
• Everything is chart-driven; style is shared, content is never shared. Hermes and the composer never let one person's chart content leak into another's audio.
• Tier C copyrighted material (Gene Keys official, Ra Uru Hu / Jovian Archive) is benchmark-only and never exposed by Hermes; retrieval stays tier-walled to A/B.
• Cost discipline holds: script-first by default, audio renders only on explicit per-version approval. Hermes does not silently spend voice credits.
• No em dashes anywhere in anything Atlas generates.

10. Decisions locked (2026-06-18, Jeff)

The open questions are answered. These are now requirements.

• Messaging circle (v1): Jeff, Sol, Colin only. Wider later.
• Hermes takes actions (big-time), not read-only. It can create audios on the fly from concepts, run the composer back-and-forth, log feedback, store and pull information wherever it is relevant. Hermes is "the messenger": the easy way to get thoughts out of our heads and into the system for deeper processing later, and to pull anything back out.
• Permission tiers (see section 11). Jeff has the most power. Sol and Colin have a little less; future added people get less still. Nobody but Jeff can overwrite or delete permanent files. Renders and feedback are open to all three.
• Default landing screen: remember the LAST mode used per person (Hermes or Studio), with an always-present toggle button (upper-left or a corner) to flip between them.
• Voicenotes: transcript only. Do not retain the raw audio in R2. Transcribe, store the text, route it, discard the audio.
• Nightly process auto-applies SAFE changes and reports the rest (see section 12).
• Messaging is in-app only for v1, and it lives on the Hermes side (email/external reach deferred).
• Approvals queue (Jeff reviews). Hermes maintains a running queue of pending changes that need Jeff's sign-off (see sections 11-12). Hermes surfaces it to Jeff for review/approve/reject, and can proactively bring items to his attention in the chat. Approved items proceed; rejected ones are logged.

11. Hermes permission tiers (v1)

One login model (Cloudflare Access), three roles, scoped capability. Hermes enforces this on every action and answer.

• Jeff (owner): everything. Create/iterate/render audios, take actions across the system, read and write project docs, see all material including private business material.
• Sol and Colin (collaborators): create, iterate, and render audios; log feedback (text or voice); ask anything about the system; read the shareable knowledge base; message the team. These "create" actions happen RIGHT AWAY. BUT anything that would change deep strategy or the project DOCS is NOT applied directly for them: it is RECORDED to Jeff's approvals queue for review/approval. They CANNOT overwrite or delete permanent files, and they CANNOT see private ownership material: cap table / shares, the founder agreements between Jeff and Sol, legal terms. They CAN see the investor-pitch, research, and product material (the same body of work going into the investor video and research docs), because they may be dropping in insights on exactly that. The split is: create-and-do (audios, feedback, questions, messages) = immediate; touch deep strategy/docs = queued for Jeff; private equity/legal/agreements = Jeff-only, invisible.
• Future people: narrower still; defined when added.

This is a real reason Atlas matters: it is how Sol and Colin interface with the whole system without having to live in GitHub, Claude projects, and Gemini. Sol needs the system but is realistically never going to set those up; Hermes is her front door into all of it.

12. Feedback cataloging + nightly improvement loop

• Hermes catalogs ALL feedback (text and voice-note transcripts) from anyone, tagged by person, surface, and audio/version where relevant.
• A nightly run reviews the catalog and the system, then auto-applies SAFE changes and produces a prioritized report of everything else. It posts that report where Jeff (and the team) will see it: in Hermes, and surfaced in the in-app space.
• "Safe" is fenced hard (non-negotiable): the nightly job may auto-apply only low-risk, reversible changes (copy/wording, small UI/content, config, catalog/triage, draft proposals). It may NEVER touch the locked demo, never delete or overwrite a permanent file, never deploy engine/chart/script-structure code on its own, never spend voice credits silently, and never change DEEP STRATEGY or the project DOCS on its own. Anything touching deep strategy, the docs, audio content, charts, script structure, money, or the demo is RECORDED TO THE APPROVALS QUEUE for Jeff's review, not auto-applied. (Recommend everything land in git with an easy revert.)
• Approvals queue: the single place where every queued change (from the nightly job and from Sol/Colin's strategy/doc edits) waits for Jeff. Hermes presents it, lets Jeff approve/reject, and can ping him in chat when something needs attention. This is the "system I interact with them on" that Jeff asked for.
• The goal Jeff stated: the system gets better and better at turning feedback into improvement, with reports that can reach him on his computer and reach the team in-app.

13. Voice transcription tooling (decided + to confirm)

• v1 (cloud, now): a simple hosted transcription on the Render box for the voice-note -> transcript flow (transcript only). Jeff's existing Whisper account fits this directly; whisper.cpp on the server also works for short notes. Granola is a meeting-notetaker, not an API; keep it for personal use, not in this pipeline.
• CORRECTED 2026-06-18 (Jeff's dev was right): Parakeet runs NATIVELY ON A NORMAL PHONE, no NVIDIA, fully offline. The trick is you do NOT run NeMo/CUDA on the phone; you run an exported ONNX build of Parakeet through the sherpa-onnx runtime, which does inference on the phone's CPU with no GPU and no internet. Prebuilt iOS and Android examples exist for Parakeet-TDT-0.6b. This is what the developer demoed. (Note on names: "Wispr" is Wispr Flow, Jeff's personal Mac/phone dictation app, a different thing from OpenAI Whisper. Neither is the same as on-device Parakeet.)
• Why on-device is genuinely BETTER (the dev's point holds): works offline, zero per-use API cost, fully private because the audio never leaves the phone, and fast. It also fits our locked "transcript only" rule taken further: if transcription happens on the phone, the audio never even reaches our server, only the text does.
• The tradeoff: on-device Parakeet nudges Atlas toward either a thin native app wrapper (Capacitor/Flutter/React Native bundling sherpa-onnx) OR sherpa-onnx's in-browser WASM build inside the PWA, rather than the simplest pure web PWA with server-side transcription. A build-path detail, settle it at B7. The earlier "native app builds deferred past v1" note is reopened by this.
• Server-side option (fallback): transcription on the Render box (OpenAI Whisper API, or self-hosted) still works for all three users seamlessly, since it is a cloud call. Use it only if we want something live before the native piece is ready.
• Recommendation (updated): plan on Parakeet ON-DEVICE as the real transcription layer. If Jeff's dev already has a working phone module, that module can BE our layer and we skip server transcription entirely. Fall back to server-side Whisper only as an interim. Parakeet also sets up the future "talk to Hermes" voice direction.

14. Cloudflare Access login page - brand it

The current Cloudflare Access (Zero Trust) login/OTP page is off-brand. Cloudflare Access supports custom branding (logo, background, app name, custom CSS on some plans) and a fully custom login page. Task: apply the Affirmology look (emerald + gold + cream, the wordmark) to the Access app for studio/atlas.affirmology.ai so the front door matches the product. If the plan's branding controls are too limited, the fallback is a branded landing/splash that hands off to Access.

Built on Affirmology_Atlas_AppSpec_v1.md. Cloud steps in Affirmology_Activation_HowTo_v1.md. This is a living draft for Jeff to tweak and add to. Decisions in sections 10-14 locked with Jeff 2026-06-18.