Home / Audio / Scripts and Tracks

C18 - Hermes-rendered Sacred Audio (the priority) - build brief (v1, 2026-06-20)

Updated Jun 20, 2026 · Affirmology_HermesRenderedSacredAudio_C18_BuildBrief_v1.md

C18 - Hermes-rendered Sacred Audio (the priority) - build brief (v1, 2026-06-20)

Jeff 2026-06-20, HIGH priority "100%, exactly what I want": Hermes builds a full SACRED AUDIO + PDF for him from inside the chat, delivers them in the conversation, and then prompts whether to make a record that is SEARCHABLE BY ALL STUDIO USERS. This completes the action layer (C16 push, C17 draft) with the render trigger Code deferred. Uses the EXISTING proven Sacred Audio pipeline (ElevenLabs, structure-driven, QC gate, PDF). No new TTS engine, no Fish, no new cost analysis. THE DEMO IS UNTOUCHED.

What already exists (build on it, do not rebuild)

• send_to_studio (C17) creates a Studio DRAFT entry (person, structure, length, music_bed, draft_script), source "hermes". LIVE.
• POST /api/studio/draft/{id}/render triggers the normal chart-driven render path on that entry. LIVE (currently only reachable from the Studio UI / API, Hermes cannot trigger it).
• The render pipeline already produces the audio + PDF, runs audio_qc.py, and stores media. The deliveries/inbox (C16) can carry a payload into a chat.

What to build

1. Hermes triggers the render and delivers the result in chat

• New Hermes tool render_sacred_audio {person, structure?, length?, music_bed?, source_script?, deliver_to?}. It (a) creates the Studio entry (reuse send_to_studio internals), (b) calls the existing render path for that entry, (c) returns immediately with the entry_id and a "your Sacred Audio is rendering" message (renders take minutes, do NOT block the chat turn).
• deliver_to (optional, default = the requester): who receives the Cast. CRITICAL SEMANTICS (Jeff 2026-06-20): when deliver_to is ANOTHER member, the audio is REGENERATED in the chosen structure using the RECIPIENT'S chart, then delivered to them. It is NOT a forward of the requester's own audio. (If Sol's chart audio were sent to Jeff as-is, Jeff would hear Sol's content thinking it is about him, confusing. So "Cast to Jeff" = render the chosen structure for Jeff's chart, deliver to Jeff.) Implementation: a Cast to person X sets person = X for the render. EXCEPTION: TEAMWORK / RELATIONSHIP structures (built on BOTH charts, e.g. synastry, joint business) are the one shared audio relevant to both, delivered to either/both with NO per-recipient regeneration. Lands in the recipient's chat as "Jeff Cast you a Sacred Audio." User-initiated, circle-only, server-side permission.
• DELIVERY ON COMPLETION: when the render finishes, drop a delivery into the requester's chat/inbox (reuse the C16 deliveries mechanism) of kind "audio" with the audio URL + the PDF URL, so the finished Sacred Audio + PDF appear inline in the conversation. If a delivery-on-complete hook is too much for v1, the acceptable fallback is a check_my_render tool (or Hermes re-checking GET /api/studio/draft/{id}) that returns the media URLs once status is done, plus the front-end showing the audio player + a PDF link.
• Tool description: only fires on an explicit user request ("make me the audio", "render this as a Sacred Audio"). User-initiated only.

2. After delivery, prompt to share to the searchable Studio library

• Once the audio is delivered, Hermes asks: "Want me to make this a shared record, searchable by everyone in the Studio?"
• If yes -> set a visibility = "shared" (or shared = 1) flag on the library entry (the studio.db entry / data/studio.db). Default for all entries stays PRIVATE; sharing is opt-in and additive.
• SHARED LIBRARY VIEW: studio.html gets a "Shared Library" list/search showing all visibility = "shared" entries (title, person, structure, date, play + PDF). Add a simple text search over title/person/structure. Optionally expose a Hermes search_studio_library(query) tool so chat can find shared records too.
• New endpoints as needed: POST /api/studio/entry/{id}/share (set/unset shared, permission-checked) and GET /api/studio/library?shared=1&q=... (list/search shared entries).

Permissions + privacy (important)

• "All Studio users" = all AUTHENTICATED Studio users, which today is the trusted Cloudflare Access allowlist (Jeff, Sol, Colin, testers), not the public internet. State this in the share prompt so it is honest ("searchable by everyone with Studio access").
• Sharing is USER-INITIATED and OPT-IN per record; nothing is shared automatically. Enforce server-side, keyed on as_person.
• PERMISSION MODEL (Jeff 2026-06-20, FINAL): within the circle (jeff/sol/colin), Hermes is as OPEN as the Studio already is. The Studio's People Library already lets any authenticated member render any seeded member's chart, so a stricter boundary in Hermes would be inconsistent and pointless. So: any circle member can render from any circle member's chart and Cast/deliver it to any circle member (themselves or others), and share/unshare any circle record.
• HARD STOPS (the only ones): reject anyone outside the circle (not jeff/sol/colin); no permanent delete of anyone's records; the demo stays locked.
• FUTURE (note, not now): when the product opens to PAYING MEMBERS / clients beyond the founder circle, real per-user privacy isolation is needed (a member must not render or see another member's chart or records). That tenant-isolation is a separate future build. The founder circle is fully trusted and open today.

Naming

The customer-facing label for "Hermes renders a Sacred Audio for you" is CAST (chosen by Jeff 2026-06-20): "Hermes will Cast your Sacred Audio." Internal tool name stays render_sacred_audio; the UI button reads "Cast."

VOCABULARY (Jeff 2026-06-20): the audio container types are called STRUCTURES (the existing code term, now adopted customer-facing too). Users pick a Structure, can build Custom Structures, and Hermes Casts a Sacred Audio from one. Use "Structure(s)" consistently in the Cast flow and the shared-library labels; no rename needed.

Guardrails

• DEMO LOCKED: C18 uses the Studio render path, never the demo. The demo render settings are untouched.
• EXISTING PIPELINE: reuse the proven render + QC + PDF; do not change render settings or the oracle/script quality.
• USER-INITIATED + ADDITIVE + TIER-CHECKED server-side. No em dashes. Chart-driven preserved.
• Vendored engine: if any change touches engine code, sync affirmology-studio/affirmology-agent/; if it is api/ + web/ only, no vendor sync needed.

Acceptance test

1. In Jeff's chat: "Make me the Sacred Audio for this." Hermes creates the entry, kicks off the render, and says it is rendering.
2. When the render completes, the finished audio (player) + PDF link appear in Jeff's chat (via delivery or a check tool). QC passed; it is a real chart-driven Sacred Audio.
3. Hermes asks whether to share to the Studio library. Saying yes makes the entry appear in studio.html's Shared Library and be found by a title/person search; saying no keeps it private.
4. Permissions: Sol can render + share her own; cannot share/unshare Jeff's; un-share returns it to private.