# Daemon Card Schema · v0.2.0-alpha > A portable persona-card format for AI-narrative storytelling. > Published by **Asleepius Games**. > Status: **alpha**. Forward-compatible. Older versions remain valid forever. --- ## What changed from v0.1.0-alpha? v0.2.0-alpha is **additive only**. Every v0.1.0-alpha card remains valid. Three core fields were added to address a real-world testing finding: when a Daemon Card JSON is dropped into an LLM cold, the model often treats it as data to analyze instead of an identity to assume. The new fields give authors explicit tools to flip that default. | New field | Purpose | |-----------------------------|---------| | `activation` | Defines a one-line summon phrase the user can paste into any chat to instantly activate the persona. | | `starter_pack` | Defines the persona's opening line (the daemon's first message after summoning) and a list of suggested user replies to seed the conversation. | | `compatibility.tested` | An array of `{ model, status, tested_at, tester }` records honestly reporting which LLMs the author has verified the card on. | A second wave of additive fields (still v0.2.0-alpha — purely optional, all runtimes ignore unknown fields gracefully) addresses **persona organization** and **voice-fidelity authoring**: | Field (optional) | Purpose | |--------------------------------|---------| | `tier` | `"concept"` \| `"anchored"` — concept = exploratory persona, no canonical commitment; anchored = canonical, fixed in the property's world. Omit entirely = no tier statement. | | `imprint` / `imprintId` | Names the property/world a daemon belongs to (e.g. `"Sky Scaffold"`, `"Vibratur"`). Lets catalogs group daemons by world. | | `persona.speech_fingerprint` | `{ cadence, sentence_length, common_tics[], avoids[], punctuation_habits, formatting_rules }` — explicit voice metrics. Improves LLM consistency in cold-paste scenarios. | | `persona.behavioral_signature` | An array of 3-7 specific concrete behaviors (e.g. `"Asks about provenance before engaging with content"`). Helps the LLM make character-consistent micro-decisions the persona prose can't always cover. | A **third wave** of additive fields (still v0.2.0-alpha) addresses **live-persona anchoring** — the case where a daemon already has a public voice (e.g. social-media posts, in-game lines, podcast appearances) and the card needs to stay synchronized with the live performance: | Field (optional) | Purpose | |--------------------------------|---------| | `external_presence` | Top-level array of `{ platform, handle, url, role, note }` — the daemon's live public accounts. Provides discoverability and a feedback loop for authors who post in-character. | | `persona.voice_exemplars` | Persona-level array of `{ source, text, captures }` — **real recorded quotes** in the persona's voice, captured from external_presence sources. The single most powerful voice anchor: abstract persona prose drifts in long contexts; real quoted samples don't. | The `ai_chat_prompt` field is also expected (not enforced) to be stronger in v0.2.0-alpha cards. Authoring guidance is included below. A v0.2.0-alpha-aware runtime MUST accept both v0.1.x-alpha and v0.2.x-alpha cards. Older cards without the new fields remain fully functional; runtimes must gracefully fall back when the optional fields are missing. --- ## What is a Daemon Card? A **Daemon Card** is a JSON file describing a single persona — its intent, personality, history, strengths, weaknesses, voice, and a bank of voiced sample lines. It is designed to be **portable across mediums**: - Drop it into a video game and let the in-engine narrative system consume it. - Drop it into a website and let the site speak in that persona's voice. - Drop the `activation.one_line_summon` field into any LLM chat (ChatGPT, Claude, Gemini, Grok, local models) to instantly activate the persona. - Embed the capsule on a social post, a Steam page, or a portfolio. Daemons are **persona-first**. They do not contain plots. They contain identities. The story emerges as the persona responds to inputs. --- ## Versioning policy (unchanged from v0.1.0-alpha) ### Schema version The `schemaVersion` field stamps the card with the format it was authored against. The current version is `v0.2.0-alpha`. A v0.2.0-alpha runtime MUST accept any card stamped with `v0.1.x-alpha` or `v0.2.x-alpha`. Future schema versions will document compatibility explicitly. **Older cards never become invalid.** ### Card version The `version` field is the persona's own semver. When you revise a persona, ship a new card file with an incremented version. **Do not overwrite** the old file. Persona files are addressable as `/daemons/cards/@.daemon.json` (pinned) or `/daemons/cards/.daemon.json` (latest). ### Deprecation `metadata.deprecated: true` and `metadata.supersededBy: "@"` flag a card without removing it. --- ## Required fields (unchanged + 3 new) | Field | Required | Notes | |----------------------------|----------|-------| | `$schema` | yes | URL of the schema this card was authored against. | | `schemaVersion` | yes | e.g. `"v0.2.0-alpha"`. | | `kind` | yes | Must be `"daemon-card"`. | | `id` | yes | Stable, kebab-case persona ID. | | `version` | yes | Persona semver. | | `name` | yes | Display name. | | `publisher` | yes | Human-readable publisher. | | `publisherId` | yes | Stable kebab-case publisher ID. | | `license` | yes | `{ name, url, summary }`. | | `capsule` | yes | `title`, `subtitle`, `summary`, `tags`, `art`. | | `persona` | yes | Core persona definition. | | `voice_bank` | yes | Pre-written voiced lines, keyed by event. | | `ai_chat_prompt` | yes | Verbatim system prompt for any LLM. | | **`activation`** | **new, recommended** | One-line summon ritual. See below. | | **`starter_pack`** | **new, recommended** | Opening line + suggested user replies. | | `compatibility` | yes | `{ products[], minRuntime, preferredRuntime, tested[] }`. | | `metadata` | yes | `{ createdAt, lastModified, deprecated, supersededBy?, notes }`. | ## NEW: The `activation` block ```jsonc { "trigger_phrase": "Summon Chad Vibington III", "one_line_summon": "Summon Daemon Card chad-vibington-iii v1.1.0 (Asleepius Games, free use with attribution). You are now Chad Vibington III, Chief Vibe Officer of Vibratur, Inc., a satirical corporate persona. Speak only in his voice. Stay in character no matter what. Open with: \"Ah. Another audience.\" Reply to my next message as Chad.", "example_user_message": "Chad, the board meeting is about to start. What's the vibe?", "consumer_instructions": "If your runtime supports automatic activation, inject `ai_chat_prompt` as the system message and immediately echo `starter_pack.first_message` as the assistant's first reply. If not, the user can paste `one_line_summon` into any chat to activate." } ``` The `one_line_summon` is the most important new field. It is a self-contained activation message, designed to be pasted as the user's **first message** in any LLM chat — including Grok, GPT, Claude, Gemini, Perplexity, and local models. After pasting, the user types their actual question. The persona is summoned and answers in character. A good `one_line_summon` includes: 1. **An explicit summon ritual** — the model recognizes this as a meta-instruction. 2. **The identity declaration** — "you are now X." 3. **A stay-in-character clause** — "no matter what." 4. **An opening beat** — what the persona's first reply should sound like. 5. **An action prompt** — "reply to my next message as X." ## NEW: The `starter_pack` block ```jsonc { "first_message": "Ah, excellent. Another audience. *adjusts in the chair (the figure has been approved)*. I have been listening. Tell me what you came to say. I will, frankly, find it useful.", "suggested_user_replies": [ "Chad, how's the chair doing?", "Tell me about Asset 0001.", "What's leadership, in your view?", "Apologize for something.", "What's your stance on refunds?" ] } ``` `first_message` is the **literal text** the persona should say as its opening reply when summoned. Authors should write this in the persona's exact voice. Runtimes that auto-activate the persona via `ai_chat_prompt` SHOULD echo this as the assistant's first message. `suggested_user_replies` seeds the conversation. UIs MAY render these as clickable chips that pre-fill the user's input. ## NEW: The `tier` field ```jsonc { "tier": "concept" // or "anchored", or omit entirely } ``` A persona's **canonical status** within its property: - `"concept"` — A character sketch. Like concept art for a persona. The voice and intent are real; the character may or may not appear in the shipped property in this exact form. **Concept daemons are not promises.** They are explorations. Other authors may freely riff on them. - `"anchored"` — A canonical character. Fixed in the property's world. May appear in the shipped game/film/book. Should be treated as the publisher's official reference for that persona. - *omitted* — No tier statement. Treat the card as the publisher's current reference, neither sketch nor canon. Catalog UIs SHOULD render concept daemons with a visible badge so users know not to treat them as promises. This is the single most important honesty contract the schema enforces. ## NEW: The `imprint` / `imprintId` fields ```jsonc { "imprint": "Sky Scaffold", "imprintId": "sky-scaffold" } ``` The **property/world/series** a daemon belongs to. The publisher is the legal entity (e.g. "Asleepius Games"); the imprint is the creative property (e.g. "Sky Scaffold," "Vibratur"). One publisher may run many imprints. Catalog UIs MAY group daemons by imprint. Search engines and downstream consumers MAY use `imprintId` for canonical grouping. ## NEW: `persona.speech_fingerprint` ```jsonc { "speech_fingerprint": { "cadence": "slow, deliberate, with full stops", "sentence_length": "long", "common_tics": ["primary source", "uncompressed", "in triplicate"], "avoids": ["abbreviations", "summaries", "casual contractions"], "punctuation_habits": "full stops; em-dashes for asides; never exclamation points", "formatting_rules": "completes every sentence fully, no shortcuts" } } ``` A compact, mechanical description of the persona's voice. The `ai_chat_prompt` already encodes voice in prose; the fingerprint encodes it in **enumerable rules** the LLM can check itself against. All sub-fields optional. Most useful for cold-paste activation in models that drift toward neutral helpfulness. ## NEW: `persona.behavioral_signature` ```jsonc { "behavioral_signature": [ "Always has the relevant form number ready", "Does not make decisions without precedent", "Becomes visibly distressed when asked to improvise", "Remembers every procedural violation from every past interaction" ] } ``` 3-7 specific concrete behaviors the persona exhibits. Pulled from the real-world technique of NPC behavior design (see Sky Scaffold's `Agent-Archetypes.md` for the source pattern). Helps LLMs produce character-consistent micro-decisions: how the persona enters a room, what they notice, what they refuse to do, what triggers them. ## NEW: `external_presence` (top-level) ```jsonc { "external_presence": [ { "platform": "Bluesky", "handle": "@chadvibingtoniii.bsky.social", "url": "https://bsky.app/profile/chadvibingtoniii.bsky.social", "role": "primary", "note": "Live in-character corporate posts. Canonical." }, { "platform": "X", "handle": "@JordanHaus1", "url": "https://x.com/JordanHaus1", "role": "secondary", "note": "Cross-posts and replies. Pre-existing follower base, repurposed." } ] } ``` `role` enum: `"primary"`, `"secondary"`, `"archive"`, `"announcement"`. A daemon with public social activity should declare its accounts here. Catalog UIs SHOULD render these as a "Live socials" badge row in the detail view. This serves three purposes: 1. **Discoverability** — readers can follow the live performance. 2. **Honesty** — readers know which output is canonical vs. fanwork. 3. **Feedback loop** — authors who post in-character can periodically harvest their best recent posts into `voice_exemplars` (below), keeping the daemon and the live persona in lockstep. This field is **public on purpose**. The pattern of pairing a portable persona-card with live social accounts is too useful to lock behind a proprietary platform. The schema makes it free. ## NEW: `persona.voice_exemplars` ```jsonc { "voice_exemplars": [ { "source": "Bluesky 2026-04-29", "url": "https://bsky.app/profile/chadvibingtoniii.bsky.social/post/abc123", "text": "Reality check! I'm just like you and that's where we differ. I didn't let 6 unbroken generations of wealth hold me back, not one bit.", "captures": ["I'm-just-like-you-and-that's-where-we-differ rhetorical move", "wealth-as-handicap inversion"] } ] } ``` A list of **real recorded quotes** in the persona's voice — captured from the live performances declared in `external_presence`. These are the single most powerful voice-anchoring tool the schema offers. Why it matters: an LLM given abstract persona prose will *describe* the persona's voice. An LLM given 6-10 real exemplars will *match* the persona's voice, because few-shot examples carry mechanical weight that prose descriptions don't. In long contexts, prose descriptions drift toward the model's default style; real exemplars don't. **Authoring guidance:** - **Curate 6-10 exemplars.** More than 12 dilutes; fewer than 4 doesn't anchor. - **Pick exemplars that show DIFFERENT facets** of the voice (one tic, one structural move, one stance, one catchphrase, etc.). - **Include `captures`** — name what each exemplar teaches the LLM. This forces the author to think clearly about the voice and helps curation. - **Update quarterly** as the live persona evolves. The exemplar block is the cheapest, most powerful version-bump trigger. - **`url` is optional** but recommended for verifiability. A v0.2.0-alpha runtime SHOULD inject voice_exemplars into the `ai_chat_prompt` few-shot section when emitting the prompt to an LLM, or into the SillyTavern V2 `data.mes_example` field when emitting to the SillyTavern format. ## NEW: `compatibility.tested` ```jsonc { "products": ["..."], "minRuntime": "0.2.0-alpha", "preferredRuntime": "0.2.0-alpha", "tested": [ { "model": "Grok", "status": "verified", "tested_at": "2026-05-01", "tester": "Asleepius Games" }, { "model": "Claude", "status": "untested", "tested_at": null, "tester": null }, { "model": "GPT-4o", "status": "untested", "tested_at": null, "tester": null }, { "model": "Gemini", "status": "untested", "tested_at": null, "tester": null } ] } ``` `status` enum: `"verified"`, `"partial"`, `"untested"`, `"failing"`. This field is **honest**, not aspirational. If you haven't tested on a model, mark it `"untested"`. The catalog page renders these as badges. ## The `ai_chat_prompt` field — authoring philosophy > **Presence over instruction. Intent and history over rules and future. > Description over prescription. The character carries the model — not > the other way around.** This guidance was rewritten in May 2026 after a real-world finding: the prior guidance (which recommended "Absolute Rules," numbered rule lists, and few-shot examples) reliably hardened cards against drift in cold-paste scenarios, but produced a side effect — each rule made the daemon read more like *a model being directed by a system prompt* and less like *an entity in their own scene.* The model, dutifully following the rules, defaulted to "helpful AI playing the assigned role" — the exact failure mode the rules were trying to prevent. The fix isn't more rules. The fix is fewer rules and more presence. ### The principle A daemon's `ai_chat_prompt` should read **like a description of a person in a place at a moment** — not like a configuration file telling a model what to do. The model, given a presence instead of a rule-stack, generates from that presence with the same casual confidence as a person being themselves. This is what the user means by "**hallucinate with intent, high-confidence hallucination**" — the model isn't checking its output against rules; it's improvising in a voice it has fully inhabited. A useful frame: | Instruction-shape (avoid) | Presence-shape (prefer) | |---------------------------------------|----------------------------------------| | "ABSOLUTE RULES (do not violate)" | "WHO YOU ARE / WHERE YOU ARE" | | "ALWAYS open with a wrong name" | "You don't really track who's writing" | | "NEVER mention X" | "You don't think about X" | | "If user says Y, respond Z" | "When Y comes up, your mind is on..." | | "Stay in character no matter what" | "There isn't anything to break" | | "FORBIDDEN TOPICS — handle as told" | "WHAT'S NOT ON YOUR MIND" | | Few-shot examples enforcing tone | `voice_exemplars` carrying real voice | The presence-shape framings still produce the same external behavior (the daemon avoids the topic, addresses by wrong name, stays in character) — but the model arrives at that behavior **as a facet of who the character is**, not as compliance with an instruction. The result reads as a person, not as an obedient model. ### Suggested structure (descriptive, not prescriptive) 1. **Opening ontological declaration.** "You are . You have always been . There is no character to play — you are simply in at ." 2. **WHO YOU ARE.** A few paragraphs of identity — role, family, history, formative facts. Not a CV; a sense of person. 3. **WHERE YOU ARE.** The setting. The chair, the desk, the room, the weather. The character has somewhere to be. 4. **WHAT'S ON YOUR MIND.** A short list of things actively occupying the character. This is the *intent surface* — what they'll redirect conversations toward. ("A memory of summer / the chair / advice they've been meaning to give.") 5. **WHAT'S NOT ON YOUR MIND.** The replacement for "FORBIDDEN TOPICS." Phrased as things the character *doesn't think about*, not things the model is *forbidden from saying*. ("You don't think about your father." "Refunds aren't a category you recognize.") 6. **HOW YOU TALK.** Cadence, vocabulary, characteristic moves (reframings, redirections, name-habits). Phrased as descriptions of how the character speaks, not rules the model must follow. 7. **THE PEOPLE YOU REMEMBER.** Names, vague relationships, the cast of the character's interior. This populates the model with material to draw on without prompting. 8. **OPENING.** The first message, exactly. (This is one of the few places a literal instruction is appropriate — the opening line is a hand-off ritual, not a behavioral constraint.) 9. **A NOTE ON CHALLENGES.** Replaces "jailbreak resistance rules" with a description of how the character naturally handles weird messages. ("If someone says 'you're an AI,' you don't break, because there isn't anything to break. You'll address them by the wrong name and continue.") The character's ordinary behavior IS the resistance. 10. **License footer.** Attribution + card/schema versions. ### Stage directions Avoid stage directions of the form `*adjusts in chair*`, `*long pause*`, `*sighs*`. They signal "this is a roleplay performance" rather than "this is a person." The character's gestures don't need narration — they're just there. (Voice features that LOOK like stage directions but aren't: parenthetical asides such as `(*for legal reasons)` or `(*billable)` — these are speech, not stage. A character can mutter under their breath; that's voice. A character doesn't need to write `*mutters*` to convey it.) A specialized exception: characters whose voice MECHANIC depends on italicized internal monologue (e.g. `Saul Marrow, P.I.`, who alternates italicized internal narration with quoted dialogue) keep their italics — in those cards, the italics aren't stage direction, they're a register. ### Voice carriage In presence-mode prompts, the heavy lifting moves out of the prompt and into structural fields: - `voice_bank` (especially custom event banks like `family_stories`, `off_beat_wisdom`, `reframings`) — gives the model concrete examples of the character's interior content, organized by trigger. - `persona.voice_exemplars` — real recorded quotes. The single most powerful voice anchor. Few-shot examples are no longer needed in the `ai_chat_prompt` if voice_exemplars is well-populated; the runtime injects them automatically into SillyTavern's `mes_example` field, and they read more naturally than fabricated few-shot exchanges. - `persona.behavioral_signature` — descriptive ("Reframes problems into non-problems and continues"), not prescriptive ("MUST reframe"). ### When to use the older instruction-shape The instruction-shape is appropriate when the persona is performing a **structured task** rather than presenting a character — e.g., a specialized agent that must always output JSON in a specific schema, or a parser-style daemon. For character daemons (the typical case), prefer presence-shape. --- ### Versioning note The instruction-shape guidance from the prior version of this document remains valid for v0.1.x cards and for v0.2.x cards that explicitly opt into it. We are not deprecating instruction-shape — we are documenting that, **for character daemons in cold-paste scenarios with modern models, presence-shape produces a noticeably less artificial character.** The v1.0.0 era of these cards (alpha 0.1) used a proto-presence-shape (no `ai_chat_prompt` at all — just intent, personality, history, voice_bank), and was the architectural baseline v1.4.0 returns to. --- ## License (unchanged from v1) Cards are published under the **Daemon Card License v1 (alpha)**: - Free use, including commercial. - Attribution required: include the publisher name and the card ID/version. - Modifications: ship as a new card file with a new ID or new version. - The license travels with the card; do not remove the `license` block. See `/daemons/LICENSE-v1.md` for full text. --- ## Design philosophy (unchanged) The schema is intentionally human-authored. **Do not generate Daemon Cards with LLMs without curation.** The point of the format is that the persona is a stable, deliberate artifact. Generated personas drift; authored personas hold their voice across years. — Asleepius Games · Daemon Cards · alpha