Persona Schema v.01.

The first public schema for gosum personas, including the autobiographical memory layer: the persona that remembers you.

§ 01What v.01 contains

Included in v.01

• memory block at the top level of the persona document.
• memoryPolicy block defining retention, decay, redaction, and privacy semantics.
• Memory atom type with structured representation (gist, details, salience, valence, privacy class).
• Two validation passes: structural (JSON Schema) and policy-coherence (SHACL).
• Redaction semantics: how individual memories can be removed without breaking persona coherence.
• Memory rendering rules: how memory atoms are surfaced to the LLM at inference time.

Held outside the baseline

• Unbounded drift in trait, style, or affect atoms. v.01 baselines remain governed and explicit.
• Automatic affect decay outside the declared memory policy.
• Composition operators that override consent, provenance, or signing rules.
• Automatic defining-event detection without editorial review.
• Cross-deployment memory transfer. (Out of scope. Possibly never.)

The discipline of v.01 is to ship one thing well: memory that accumulates, decays, brightens, and respects privacy.

§ 02The memory atom

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

{
  "id": "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",
  "provenance": {
    "sessionId": "sess:bonvoy-2026-04-22-uuid",
    "turnIndex": 7,
    "deploymentDid": "did:gosum:marriott:property-cluj-001"
  },
  "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 is what makes the memory layer GDPR-safe by construction.

Privacy classes

Consent basis

For any class containing PII, a consentBasis string is required. Valid bases include:

• 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 runtime must refuse to create a memory with a privacy class implying PII but consentBasis: not-applicable.

Sensitive-PII handling

§ 05Redaction semantics

The persona's memory must be redactable without breaking the persona's coherence. This is the hardest engineering problem in the v.01 schema and the most important one for legal compliance.

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.

Coherence handling rules in v.01

For v.01, the 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. Tombstones are retained for the period required by audit law (typically 6 years in EU), then permanently deleted.

§ 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

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 persona may, when asked about something at the edge of its memory, partially confabulate — but only with explicit hedging. The schema's memoryPolicy.confabulationPolicy governs this:

• strict: never confabulate. If memory is faint, say "I don't quite remember."
• moderate: confabulate plausible details from gist with hedging ("I think it was raining, but I might be misremembering").
• permissive: not allowed in v.01. Reserved for future entertainment-context personas.

For brand-deployed personas, strict is the default. moderate is allowed for hospitality and entertainment, never for healthcare or financial services.

§ 07The memoryPolicy block

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

{
  "memoryPolicy": {
    "enabled": true,
    "scope": "deployment",
    "maxAtoms": 50000,
    "maxMemoriesPerTurn": 5,
    "rehearsalCooldownTurns": 4,
    "retrievalThreshold": 0.15,
    "confabulationPolicy": "strict",
    "creationPolicy": {
      "minSalienceForCreation": 0.25,
      "salienceClassifier": "gosum-default-v.01",
      "salienceClassifierVersion": "v.01"
    },
    "retentionPolicy": {
      "defaultRetentionDays": 365,
      "perPrivacyClass": {
        "non-pii": null,
        "aggregate": null,
        "guest-pii": 90,
        "staff-pii": 365,
        "sensitive-pii": 30,
        "commercial-confidential": 1095
      }
    },
    "rightToBeForgottenSla": {
      "acknowledgmentHours": 24,
      "completionHours": 720,
      "tombstoneRetentionDays": 2190
    },
    "auditPolicy": {
      "logCreation": true,
      "logRetrieval": "sampled",
      "logRedaction": "always",
      "logRehearsal": "sampled"
    }
  }
}

Field notes

• scope: deployment — memories are scoped to a single deployment instance, not shared across deployments. Cross-deployment memory is out of scope for v.01.
• 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

v.01 defines the validation passes needed for a memory-aware persona.

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 gosum CLI grows three commands.

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 v.01 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. Set the persona's identity.version to v.01.
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.