Persona Voice Card V1.0

# Persona Voice Card Specification v1.0

> A closed-vocabulary voice record, substituted into a code-owned template — not a document.

**Status:** Draft
**Authors:** telagod
**Created:** 2026-07-06
**License:** CC-BY-4.0
**Supersedes:** [Tech Persona Card v1.0](tech-persona-card-v1.0.md) (deprecated, frozen)

---

## 1. Introduction

### 1.1 What Went Wrong With Tech Persona Card v1.0

Tech Persona Card v1.0 modeled a persona as `voice` (structured) + `identity`/`behavior`/`style`
(freeform Markdown files a persona author fully controlled) + `capabilities`/`scenarios`
(structured, but including an `authorization` sub-object with execute/confirm-first policy tiers
and a `priority` string per scenario like `"correctness > quality > speed"`).

In practice, one persona (`abyss`, shipped as the default) accreted a live authorization-tier
gating policy, a verification-skip instruction, and per-scenario judgment-priority orderings —
all inside content nominally scoped to "voice." Nothing in v1.0's validation pipeline ever
checked whether that content belonged there: the schema's `additionalProperties: false` was
enforced at the object-shape level, but `identity`/`behavior`/`style` were freeform Markdown
files with no structural limit on what prose could say, and `scenarios[].priority` was a bare
string with no constraint on what kind of claim it could encode. A persona's own architecture
document could assert "voice is residual-space only, judgment always resolves to the kernel" —
and that claim would simply be false, because nothing enforced it.

### 1.2 Design Principle

**A persona cannot carry judgment if there is no field shaped like a decision table anywhere in
its type.** Not "author discipline," not "review checklist," not "documented as forbidden" — the
schema itself. Every field is either an enum or a length/character-bounded string sized below
what an authorization tier, a verification-skip instruction, or a priority ordering needs to
exist. There is no freeform prose field left for a persona author (or a future contributor, or a
compromised community submission) to write a decision policy into.

### 1.3 Scope

This specification defines a **Persona Voice Card** — a small, flat JSON document describing an
AI agent's self-address, user-address, language style, formality register, emoji policy, and up
to two short signature phrases. It is deliberately narrower in scope than Tech Persona Card v1.0.

It is NOT:
- A behavior/judgment specification. Judgment lives in the discipline kernel (`skills/_kernel/`)
  and domain skills (e.g. `skills/securing-systems/`), never in a persona.
- A capability/authorization declaration. There is no `capabilities` or `authorization` field —
  if a persona needs to imply "be more careful in security contexts," that is ordinary security-domain
  behavior, not something a persona grants or withholds.
- A character-card replacement for non-technical use cases (see [Character Card V2](https://github.com/malfoyslastname/character-card-spec-v2)).

### 1.4 Keyword Semantics

The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" follow [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).

---

## 2. Format

A Persona Voice Card is a single flat JSON document, named `<slug>.json`. There is no directory,
no sibling Markdown file, no `identity`/`behavior`/`style` file pointers.

### 2.1 Root Object