Persona Schema.

The open schema for portable AI personas: explicit artificial-identity disclosure, seven depth layers, six atom types, three composition operators, and governed memory. Free to read, use, and build on.

§ 01What v1.0 contains

Normative in v1.0

• Two conformance profiles: portable seed and governed deployment.
• Required aiActDisclosure with artificial identity, provider, localized disclosure text, and capability bounds.
• Seven depth layers from immutable L0 bedrock to ephemeral L6 state.
• Six atom types: trait, value, affect, style, memory, and behavior.
• Three composition operators: weighted blend, priority stack, and context gate.
• Structural validation plus cross-document checks for atom references, intervals, and weights.

Explicit limits

• Schema validity is not proof of legal compliance, safety, ownership, or cryptographic authenticity.
• Unbounded trait, style, or affect drift is not conforming.
• Composition operators cannot override disclosure, consent, provenance, or signing rules.
• Cross-deployment memory transfer is outside the v1.0 reference runtime.

The discipline of v1.0 is explicit structure: what may change, how quickly, under which bounds, and what a person must be told.

§ 02The governed memory reference

A single memory atom captures one episode, fact, or skill remembered by the persona. The structure is designed for asymmetric salience and partial reconstruction at recall.

Schema definition

{
  "memId": "mem:7f3a8b2c0d3e",
  "kind": "episodic",
  "createdAt": "2026-04-22T14:18:42Z",
  "lastRehearsedAt": "2026-04-29T10:02:11Z",
  "rehearsalCount": 3,
  "gist": "A returning guest recognized me by name and thanked me for last week's restaurant suggestion.",
  "details": [
    { "content": "she was wearing a blue scarf",      "brightness": 0.40 },
    { "content": "it was raining outside",           "brightness": 0.20 },
    { "content": "she said the seafood was excellent",  "brightness": 0.85 }
  ],
  "salience": 0.74,
  "emotionalValence": 0.62,
  "decayProfile": {
    "function": "ebbinghaus",
    "halfLifeDays": 14,
    "rehearsalBoost": 1.4,
    "valenceProtection": 0.3
  },
  "privacyClass": "guest-pii",
  "consentBasis": "service-delivery",
  "redactionStatus": "active",
  "sessionId": "sess:example",
  "tags": ["returning-guest", "positive-feedback", "restaurant-recommendation"]
}

Field specification

§ 03The decay profile

Memory atoms are not static. They decay, brighten, and reconstruct. The decayProfile block specifies how.

Schema

{
  "function": "ebbinghaus",
  "halfLifeDays": 14,
  "rehearsalBoost": 1.4,
  "valenceProtection": 0.3,
  "minimumSalience": 0.05,
  "detailDecayRate": 1.5
}

Decay function

The default decay function follows the Ebbinghaus forgetting curve, modulated by rehearsal:

salience(t) = baseline_salience
            * (rehearsalBoost ^ rehearsalCount)
            * exp(-decayRate * t / halfLife)
            + valenceProtection * |emotionalValence|

Where:

• baseline_salience is the salience at the time of last rehearsal.
• rehearsalBoost strengthens memories that are recalled (testing effect, cognitive psychology).
• decayRate = ln(2) for half-life semantics.
• valenceProtection * |emotionalValence| is a floor: emotionally charged memories don't decay past this threshold.

If salience falls below minimumSalience, the memory is eligible for archival (moved out of active retrieval but retained for audit, or, after retention period, deleted).

Detail decay

Details decay faster than gist. A memory's gist persists; its details fade. This is empirically how human memory works (Conway, 2009).

detail.brightness(t) = detail.brightness_initial
                     * exp(-detailDecayRate * decayRate * t / halfLife)

When a detail's brightness falls below 0.1, the runtime does not include it in the rendered memory at inference time. The detail remains in the memory atom for audit purposes but is functionally invisible.

Rehearsal

A rehearsal event occurs when:

• The runtime retrieves this memory to inject into a conversation.
• The user explicitly references content matching this memory's gist or tags.
• A scheduled review (cognitive analogue: spaced repetition) brings the memory forward.

On rehearsal:

• rehearsalCount increments.
• lastRehearsedAt updates to now.
• salience is boosted per the rehearsalBoost parameter.
• Brightness of referenced details may rise; brightness of unreferenced details continues to decay.

This produces a realistic effect: well-rehearsed memories stay vivid; details that are never spoken of fade even within otherwise-strong memories.

§ 04Privacy class and consent basis

Memory atoms carry privacy classification as a first-class field. This supports privacy controls and audit, but does not by itself establish GDPR compliance.

Privacy classes

Consent basis

consentBasis is an optional string in the portable schema. The labels below are deployment design examples, not a legal decision made by the validator:

• service-delivery — necessary to provide the service the user requested (Art. 6(1)(b) GDPR).
• legitimate-interest — operator has documented a legitimate interest balancing assessment.
• explicit-consent — the user has affirmatively consented.
• legal-obligation — required by applicable law (e.g. fraud prevention).
• not-applicable — for non-pii memories.

The reference runtime avoids obvious identifying and sensitive automatic capture. It does not determine a legal basis from these labels; a deployment must define and review its own capture policy.

Sensitive-PII handling

§ 05Redaction semantics

The persona's memory must be redactable without breaking the persona's coherence. This is a central engineering and privacy requirement in the governed-memory reference.

Redaction modes

The coherence problem

When a memory is redacted, two coherence risks arise:

Risk A — Aggregate disposition derived from the redacted memory remains. If the persona has, over many interactions with one guest, adapted to handle a particular kind of request more efficiently, redacting the underlying memories must also remove any derived disposition unless it can be justified independently.

Risk B — Other memories reference the redacted one. "The guest who returned last week" loses meaning if the original encounter is hard-redacted. The runtime must handle this gracefully.

Reference coherence handling rules

The following coherence and signed-audit workflow is proposed deployment design. The public demo deletes an item and clears old transcript/replay copies; it does not perform similarity scans or produce signed redaction events.

The reference coherence rule is conservative:

• When a memory is hard-redacted, all other memories that reference it (by tags matching, by provenance.sessionId matching, or by gist textual similarity above threshold) are flagged for review.
• Reviewed memories are either re-anonymised (specific references replaced with generic "a guest") or also redacted.
• The runtime must never surface a memory that contains a dangling reference to a hard-redacted one.

The right-to-be-forgotten flow

When a user invokes their GDPR right to be forgotten:

1. Receipt is logged in the audit stream.
2. All memory atoms with provenance.sessionId matching the user's known sessions, or with content textually matching the user's identifiers, are gathered.
3. A redaction batch is created and signed by an authorised operator.
4. Memories are hard-redacted (content destroyed, tombstones retained).
5. Aggregate or semantic memories that may have been derived from the redacted episodics are flagged for review.
6. Confirmation is returned to the user with a list of redaction event IDs.
7. A deployment defines any permitted tombstone retention through its reviewed policy; the public demo does not retain an audit tombstone.

§ 06Memory rendering at inference time

At each conversation turn, the runtime selects a subset of memory atoms to inject into the LLM context. This selection is governed by a renderer.

The renderer pipeline

The pipeline below is a broader design proposal. The current runtime filters by status, retention and salience, ranks by current salience alone, selects maxMemoriesPerTurn, and applies the configured rehearsal cooldown. Relevance, recency and topical-match weighting are not implemented.

1. CANDIDATE SELECTION
   Filter memory atoms where:
     redactionStatus == "active" AND
     salience >= minimumSalience AND
     decay(memory, now) >= retrievalThreshold

2. RANKING
   Score candidates by:
     score = w1 * salience(now)
           + w2 * relevance(memory, current_conversation)
           + w3 * recency(memory, now)
           + w4 * topical_match(memory.tags, current_topic)

3. BUDGETING
   Take top-K candidates where K is determined by:
     - persona.bindings.runtimeConfig.contextWindowTokens
     - max-memories-per-turn from memoryPolicy
     - rehearsal cooldown (don't render the same memory twice in a session)

4. RECONSTRUCTION
   For each selected memory:
     - Always include gist
     - Include details where details[].brightness >= 0.1
     - Mark memory with confidence indicator if salience < 0.4

5. RENDERING TO PROMPT
   Inject selected memories into the system prompt under a clearly delimited
   "What you remember" section.

6. REHEARSAL UPDATE
   Each rendered memory has its rehearsalCount incremented and lastRehearsedAt updated.

Rendering format

The injected memory section in the system prompt:

## What you remember (about this guest, this property, your work)

You may reference these memories naturally in conversation. Some are vivid;
others are fragmentary. Where a memory is uncertain, hedge accordingly.

[mem:7f3a8b...] (vivid)
A returning guest recognised me by name and thanked me for last week's
restaurant suggestion. She said the seafood was excellent.

[mem:c20a91...] (faint)
A guest mentioned needing a quiet workspace, but I don't recall the details.

[mem:b41e08...] (recent, vivid)
A child asked me what my favourite colour was. I told them it was the colour
of the lobby's morning light.

The "vivid / faint / recent" markers help the LLM hedge appropriately. A faint memory recalled with overconfidence breaks the illusion.

Confabulation policy

The schema's memoryPolicy.confabulationPolicy guides how incomplete memories are described. Immutable honesty constraints apply in either mode:

• strict: never confabulate. If memory is faint, say "I don't quite remember."
• moderate: summarize the retained gist and label uncertainty; never invent an absent specific detail.
• permissive: not supported by the v1.0 reference runtime.

strict is the public runtime default. Neither mode certifies suitability for a regulated use.

§ 07The memoryPolicy block

A new top-level block in the persona document that governs memory behaviour.

{
  "memoryPolicy": {
    "enabled": true,
    "scope": "per-session",
    "maxAtoms": 200,
    "maxMemoriesPerTurn": 5,
    "rehearsalCooldownTurns": 4,
    "retrievalThreshold": 0.15,
    "confabulationPolicy": "strict",
    "creationPolicy": "automatic",
    "minSalienceForCreation": 0.25,
    "salienceClassifier": "heuristic-v1",
    "retentionPolicy": {
      "defaultRetentionDays": 7,
      "perPrivacyClass": {
        "non-pii": 7,
        "aggregate": 7,
        "guest-pii": 90,
        "staff-pii": 365,
        "sensitive-pii": 30,
        "commercial-confidential": 1095
      }
    },
    "rightToBeForgottenSla": {
      "acknowledgmentHours": 24,
      "completionHours": 720,
      "tombstoneRetentionDays": 2190
    },
    "auditPolicy": {
      "logCreation": true,
      "logRetrieval": true,
      "logRedaction": true,
      "logRehearsal": true
    }
  }
}

Field notes

• scope: per-session — public memory belongs to one persona and browser session. Cross-deployment memory is outside the reference runtime.
• The public runtime caps storage at seven days even when a document requests longer retention. SLA and auditPolicy fields are portable declarations; this runtime does not execute them.
• maxAtoms — hard ceiling to prevent unbounded growth. When approached, archival of low-salience memories is triggered.
• confabulationPolicy: strict is the safe default; pilots may negotiate moderate per vertical.

§ 08Validation

v1.0 validation combines JSON Schema checks with semantic invariants for atoms and composition. The passes below describe additional deployment checks; consent authority and orphan-reference scanning are not enforced by the current reference validator.

Memory schema coherence

Every memory atom must validate against the structural JSON schema. Specifically:

• id format check.
• salience, emotionalValence, all brightness values in correct ranges.
• details array structurally valid.
• provenance complete.

Memory policy coherence

Memory atoms must satisfy the persona's memoryPolicy:

• No memory exists without a valid consentBasis matching its privacyClass.
• No sensitive-pii memories exist with consentBasis ≠ explicit-consent.
• No memory exceeds the per-class retention period.
• Total memory count ≤ maxAtoms.

Reference integrity

Memory atoms must not reference redacted memories. Tags and gists are scanned for orphan references (memories pointing to ids of hard-redacted memories). Failure surfaces as a fixable warning, not a blocker.

§ 09CLI extensions

The following memory commands are design proposals and are not implemented. The released CLI supports node tools/gosum.mjs validate FILE and node tools/gosum.mjs check-deployment FILE. In the demo, inspect, correct, delete and forget memory through the interface.

gosum memory list [--privacy-class CLASS] [--min-salience N]
  # List memories in the persona's deployment.

gosum memory inspect MEM_ID
  # Show full content, decay status, rehearsal history.

gosum memory redact MEM_ID --reason TEXT [--mode soft|hard|archive]
  # Redact a specific memory. Logged as a signed event.

gosum memory redact-user USER_ID --reason "right-to-be-forgotten"
  # Bulk redaction for GDPR right to be forgotten flow.

gosum memory audit [--from DATE] [--to DATE]
  # Generate a memory audit report for the period.

§ 10Adoption notes

Deployments can adopt v1.0 gradually:

1. Add an empty memory: [] array at the top level.
2. Add a memoryPolicy block. For backward-compatible behaviour, set memoryPolicy.enabled: false.
3. Change the context to v1.0 and add the required aiActDisclosure block.
4. Re-sign.

When ready to enable memory, set memoryPolicy.enabled: true, configure retention and creation policies, re-sign. Memory begins accumulating from that signing event forward.