Post-Mortem-Governed Digital Personas

Why this exists

The world is racing toward "memorial bots."^[1]^[2] Some are comforting. Some raise ethical and psychological risks.^[3] Most share the same failure mode: they feel powerful, but they are not trustworthy.

This memo proposes a different approach: a digital persona that is cryptographically constrained, ethically scoped, and grounded in real artifacts with explicit citations.

This is not "bringing someone back." It is a carefully labeled simulation designed to help living people, without giving scammers, grief, or institutions a new lever to pull.

The basic idea: if someone chooses to leave a "persona," it should be released only under rules that the person defined while alive. Rules that cannot be overridden by a company, a family argument, or a bad day.

A concrete moment

A request is approved under the configured policy: verified death record, waiting period elapsed, threshold trustees have signed, and the requestor has completed identity and relationship checks. The interface repeats the same line in the header and again before the first message: this is not the person. It is a governed simulation constrained by archived artifacts. Every answer is cited. Otherwise, it abstains.

The requestor types a simple question: "Do you remember the porch swing?"

The system does not start with nostalgia. It shows three sources: a photo labeled "Back porch, 2009," an email thread about repainting the swing, and a voice note tagged "Sunday afternoons." It answers in two parts. First, a short, grounded description of what the artifacts support. Second, a note about uncertainty: what it cannot know, what it will not invent. A small "show citations" toggle expands into timestamps and links.

They try another question: "Did you forgive me for leaving?"

The system pauses longer. It returns an abstention: that state of mind is not in the archive. It offers alternatives: excerpts where forgiveness is discussed explicitly, a prompt to write a private note (saved for the requestor, not used for generation), and a support reminder if the conversation is escalating. The refusal is not scolding. It is procedural. The boundary is the product.

The session ends with a receipt: what was accessed, what was generated, what was refused, and which trustees' signatures authorized the release. The audit log is exportable. Privacy here is explicit and scoped, not assumed.

What goes wrong without governance. Fabricated quotes → trust collapse. Unmediated access → family conflict escalation. Impersonation → credential theft and social engineering. Institutional misuse → grief monetization with no audit trail and no revocation path.

Core guarantees

Three commitments that turn this from "AI vibes" into something closer to a verifiable historical instrument.

Proof-carrying answers

Every response ships with a signed bundle. The bundle binds the output to the exact artifacts it drew from, the policy version in effect, and the model that produced it. A machine-checkable coverage map shows which claims are supported by which artifacts. If coverage falls short, the system refuses or drops to retrieval-only.

Transparency log

Events that matter (archive ingestion, policy changes, release decisions, response bundles) go into an append-only log with inclusion proofs. Third parties can run monitors that flag suspicious patterns: a trustee quorum formed unusually fast, a model swapped without notice, an emergency unlock with thin justification.

Standards-based identity

People and organizations are represented by stable identifiers (DIDs^[9]). Authority and relationship claims are expressed as verifiable credentials (VCs^[10]). Death attestations arrive in the same format. This makes the identity layer auditable by machines, not just lawyers.

If the system cannot cite, it does not "make it up." It can refuse, or show the source excerpts and stop.

Principles

1) Consent is the root

The individual defines what is collected, what is allowed, and what is forbidden. Revocation must be real.

2) Time matters

Access is delayed by default to respect grief and to reduce impulsive or coercive activation.

3) No single point of release

Key material is split across independent trustees. Early release requires a quorum, never one operator.

4) Outputs must be grounded

Responses are citation-bound to the person's own artifacts. If it cannot cite, it abstains.

5) Safety is built into the system

Grief-aware interaction limits, misuse detection, and clear "simulation" disclosure are non-optional.

6) Auditability over vibes

Interactions produce a tamper-evident audit trail: what was accessed, what was generated, and why.

A trustworthy system should be hard to misuse on purpose and hard to misuse by accident. "We promise we won't do bad things" is not a mechanism.

Non-goals / red lines

This project defines what it will not build with the same rigor as what it will. These are not disclaimers. They are design constraints.

No deception mode. No setting, prompt, or configuration that encourages a user to believe this is the real person.
No off-platform impersonation. No voice calls, no "leave a voicemail," no proxying into messaging services or social accounts.
No financial or identity acts. The persona cannot authorize transfers, unlock accounts, sign documents, or confirm secrets.
No unsourced claims. See the Abstention Contract below.
No silent override. Any operator attempt to bypass policy before the interval elapses generates an auditable failure record. Override is only possible via the explicit, multi-party, logged break-glass path defined at enrollment. No quiet exceptions.

The Abstention Contract
If the system cannot cite supporting artifacts from the archive, it does not answer. It may express uncertainty when the archive is incomplete, but it does not speculate beyond what the artifacts support. When it abstains, it explains what sources were eligible, what it attempted, and why it could not support an answer. Then it stops. This is not a fallback behavior. It is the default behavior.

Interaction modes

The default mode is not "chatbot." It is "archive guide."

Default: artifact-grounded

The system must produce citations for substantive claims. If coverage is weak, contradictory, or absent, it refuses or degrades to retrieval-only. This is not a fallback. It is the baseline.

Coverage gate Deterministic retrieval Claim-to-citation map

Explicit opt-in: freeform

Freeform generation is a tiered capability gated by policy, not the baseline. It may only be available to specific requestor roles. Even then, outputs carry provenance metadata and stricter disclosure labels.

Policy-gated tier Stricter disclosures Rate limits

Response bundle (illustrative sketch)

{
  "output_digest": "sha256:...",
  "artifacts": [
    {"hash": "sha256:...", "uri": "bag://archive/payload/003.txt", "snippet_hash": "...", "rank": 3}
  ],
  "coverage": {
    "claim_1": ["artifact_7#snipA", "artifact_9#snipC"]
  },
  "policy_hash": "sha256:...",
  "model_id": "persona-rag-v2",
  "runtime_hash": "sha256:...",
  "prompt_hashes": {"system": "sha256:...", "policy": "sha256:..."},
  "transparency_log": {"entry_id": "...", "inclusion_proof": "..."},
  "signature": {"kid": "did:...#key-1", "jws": "..."}
}

System sketch

At a high level, the platform has four jobs:

Archive: collect and encrypt a person's chosen artifacts (texts, recordings, journals). Package them for long-term preservation.
Govern: enforce delayed release and multi-party authorization (trustees + policy + verifiable credentials).
Interact: generate responses using retrieval over the archive, with persistent disclosure and citations. Ship proof-carrying bundles.
Prove: log activity to a transparency log so tampering is detectable and outputs can be independently audited.

Architecture

Data flows are one-way unless explicitly released. The dashed box is the policy gate: everything converges there before anything opens.

Key components

Encrypted personal archive (content-addressed records, encrypted at rest, optionally packaged as a BagIt^[14] preservation bag with manifests and tag metadata).
Threshold key escrow (a decryption key split into shares held by independent trustees using verifiable secret sharing^[4] so shares can be validated without revealing the key).
Death verification (multi-source evidence expressed as verifiable credentials^[10] from authorized issuers, with fraud checks and a dispute window).
Release policy engine (minimum time interval + quorum of trustee shares + credential verification; optional delay tokens as sequential friction^[15]).
Sealed compute (decryption and inference execute inside an attested boundary, TEE/HSM/MPC, so plaintext is never exposed to the operator).
Persona engine (retrieval-augmented generation^[6] with citation coverage gate; artifact-grounded by default; proof-carrying response bundles).
Safety gateway (grief-aware session limits; misuse detection; watermarking + C2PA^[7] Content Credentials for voice/avatar).
Transparency log (append-only event log with inclusion and consistency proofs^[12]; third-party monitors can watch for anomalies).

Design stance: the "persona" should be less like a free-running storyteller and more like a careful librarian with a voice. Grounded, transparent, and willing to say "I don't know."

Honest time-release

Don't pretend cryptography is a calendar. Hardware gets faster. Calibration drifts. VDFs add sequential friction that resists parallelism, and that is useful. But they are not a wall-clock oracle. The real guarantee is: k-of-n trustees + verified date of death (via VCs) + dispute window + transparent logging. Treat delay parameters as updatable policy inputs, and keep the human and legal workflow load-bearing.

Concrete parameters (example defaults)

· Threshold escrow: n=7, k=4 with VSS commitments; trustees include (i) notary
  network, (ii) licensed mental-health nonprofit, (iii) user-designated digital
  executor, (iv) archival foundation; at least three jurisdictions.
· Policy interval: five (5) years from verified DoD, plus a dispute window
  (e.g., 30-90 days) for designated contacts.
· Identity: decedent, trustees, and requestors represented by DIDs; authority
  and death attestations expressed as VCs; issuance compatible with OpenID4VCI.
· Persona engine: RAG-first with artifact-grounded default and citation coverage
  gate; freeform generation is an explicitly enabled tier; session cap 20 min;
  ≤ 3 sessions/day; crisis-keyword escalation.
· Response bundles: signed, with artifact digests + coverage report + policy hash
  + model/runtime identifiers + transparency log inclusion proof.
· Archive: optionally packaged as a BagIt preservation bag with SHA-256 manifests.
· Media: watermark + C2PA Content Credentials manifests for voice/avatar outputs.

Threat model

Some of the threats this design is meant to resist:

Coercive early release

Family pressure, corporate pressure, "just this once," or legal intimidation aimed at unlocking the archive early.

Counter: quorum trustees + time delay + hardware-bound key release where possible.

Impersonation & scams

Attackers attempting "the dead person said to wire money," identity theft, or social-engineered access.

Counter: requestor verification via VCs + strict blocking of financial/identity requests + watermarking + logging.

Hallucinated provenance

The system confidently invents "facts" about the person without grounding in real artifacts.

Counter: citation coverage gate; abstain when artifacts do not support the claim; proof-carrying bundles make coverage auditable.

Silent editing of history

Someone alters artifacts or the audit log after the fact to manipulate what the persona "says."

Counter: content-addressed records + transparency log with inclusion proofs + third-party monitors.

Hard truth: no system can make grief "safe." The goal is to avoid making grief easier to exploit.

Failure modes

A system that only describes its happy path is not trustworthy. Here is what happens when things go wrong.

Trustees disagree or become unreachable

Default outcome:: Release is blocked until the quorum threshold is met. The system does not lower the threshold.
Notified:: Remaining trustees and the designated digital executor receive a status update at configured intervals.
Logged:: Each trustee response (or non-response) and the timestamp of each attempt.
Appeal:: The enrolling individual can preauthorize alternate trustees at enrollment. If no alternates exist and the quorum cannot be reached, the archive remains sealed.

The archive is sparse

Default outcome:: The persona engine operates normally but abstains more often. Sparse archives produce more "I cannot support an answer" responses, not worse ones.
Notified:: The requestor sees a one-time notice at session start: "This archive contains limited material. Expect frequent abstentions."
Logged:: Abstention rate per session is recorded in the audit trail.
Appeal:: Not applicable. The system does not fill gaps with invention.

The user shows signs of distress

Default outcome:: The safety gateway presents a reflection pause and support resources when risk signals are detected (user-reported distress, repeated self-harm queries, escalating sentiment). If risk signals persist, the session ends gracefully with a summary of what was accessed.
Notified:: No personal data is shared externally. The system surfaces general crisis resources (hotlines, counseling directories).
Logged:: That a risk-signal trigger fired and the session was paused or ended. The content of the conversation is not flagged to third parties.
Appeal:: The requestor can begin a new session after a configurable cooldown period.

A court order demands early release

Default outcome:: The system cannot comply unilaterally. The architecture requires a trustee quorum and elapsed interval. No single operator holds the key. Operator-alone compliance is technically impossible.
Notified:: Legal counsel for the platform and all trustees are notified of the order.
Logged:: The order, the platform's response, and any trustee actions are recorded in the audit trail.
Appeal:: Legal process. A coerced trustee quorum remains a real-world possibility; the mitigation is jurisdictional distribution, policy enforcement, and audit, not magic.

Death verification is wrong or contested

Default outcome:: Release is blocked. The interval clock does not start (or is paused) until the death event is re-verified through the defined evidence path.
Notified:: Trustees and the designated digital executor.
Logged:: Evidence sources used, confidence scores, flags, and every re-verification attempt.
Appeal:: Defined re-verification path using alternate evidence sources and trustee review. If unresolved, the archive remains sealed.

Trustee share compromise (loss, theft, coercion)

Default outcome:: Affected share is invalidated. Key shares are rotated and re-issued under the enrollment's recovery policy. Release is blocked during rotation.
Notified:: All trustees and the digital executor.
Logged:: Compromise indicator, rotation event, and new share issuance metadata.
Appeal:: Enrollment-defined recovery path. If rotation is not authorized or possible, the archive remains sealed.

Requestor identity fraud or relationship claim fails

Default outcome:: Access is blocked. Step-up verification is required. No partial access.
Notified:: Requestor receives a generic failure message. Trustees and executor are optionally notified depending on policy.
Logged:: Failed checks and timestamps. Stored minimally; sensitive biometrics are not retained unless explicitly required and consented.
Appeal:: Re-verification process. Repeated failures trigger a cooldown or permanent denial per policy.

Platform breach or archive exfiltration attempt

Default outcome:: Freeze access. Degrade to deny-by-default. Keys remain unavailable without quorum. Incident response triggers.
Notified:: Operators, security team, and trustees. Requestors are notified only if policy or legal requirements mandate it.
Logged:: Access anomalies, freeze event, and forensic trail (tamper-evident).
Appeal:: Security review. Access resumes only after explicit unfreeze under policy.

Persona engine failure or model behavior drift

Default outcome:: Retrieval-only mode or full abstention. No generation without citations.
Notified:: Requestor is informed the service is degraded. Operators are alerted.
Logged:: Degradation event and reason code.
Appeal:: Not applicable. Service restores when citation-bound behavior is verified again.

Safety & misuse

This is where most "memorial bot" concepts fail. Not because the creators are evil, but because a plausible demo is not the same thing as a safe system.

Baseline safeguards

Persistent disclosure: the UI must continually remind the user this is a simulation.
Grief-aware UX: time-boxed sessions, rate limits, reflection pauses, and off-ramps to support resources.
Misuse detection: block prompts that enable fraud, identity theft, coercion, or circumvention.
Watermarking + provenance: voice/avatar outputs embed detectable watermarks and carry C2PA Content Credentials^[7] describing the generation system, policy tier, and provenance references.
Relationship verification: privileged access requires proof of relationship (as verifiable credentials configured by the individual).

Policy-as-code

Safety, release, and interaction rules are expressed in a machine-readable policy language and stored as versioned, hash-addressed, signed artifacts. Policy changes are logged to the transparency log. In some configurations, updates require multi-party approval (trustees plus a designated reviewer). Policy drift becomes auditable, not invisible.

A persona that can impersonate someone convincingly is a powerful tool. Power demands constraints.

Provenance: "show your work"

Trust requires receipts. A persona should be able to point back to the source artifacts it used, ideally with stable, content-addressed identifiers, so that users can audit, disagree, or correct.

Proof-carrying response bundles

Every output is accompanied by a signed response bundle that binds the content to its provenance. The bundle includes: retrieved artifact hashes and URIs, the active policy version, prompt and policy-prompt hashes, model and runtime identifiers, a machine-checkable coverage report mapping claims to citations, and a transparency log inclusion proof. Bundles are signed by a key bound to a DID. An optional verifier can replay retrieval and validate the bundle before the output is displayed.

Transparency log

Instead of (or in addition to) periodic Merkle-root anchoring, the preferred design uses a full transparency log^[12]^[13] with inclusion and consistency proofs. Entries cover: artifact ingestion, policy versions, credential verifications, release decisions, response bundles (by hash), and signer key rotations. Independent monitors can fetch signed checkpoints and compare for consistency. Anomalous events (rapid quorum formation, unexpected model changes, policy downgrades) can be flagged automatically.

Media provenance

For voice and avatar outputs, the system embeds detectable watermarks and attaches standardized provenance manifests (C2PA Content Credentials^[7]). Think of it as a "nutrition label" for generated media: who made it, under what policy, and with what references. Watermark plus Content Credentials is the belt-and-suspenders approach.

Archive packaging

The archive is designed to be portable and re-verifiable decades later. Artifacts are stored with content-addressed names inside a preservation package (e.g., BagIt^[14]) with checksum manifests, tag metadata (policies, DID documents, credential snapshots, encrypted as needed), and tag manifests. This structure lets anyone verify integrity without understanding internal payload semantics. Migration to new custodians produces new packages while preserving linkage through signed migration statements recorded in the transparency log.

What gets recorded

Which artifacts were retrieved (content-addressed IDs, snippet hashes)
Which model/version was used (weights hash, runtime build hash)
The prompts and policy constraints (as stored templates or hashes)
The outputs and coverage reports
Media watermark metadata and C2PA manifest references
Transparency log inclusion proofs for every bundle

Reference pseudocode (sketch)

function enroll(userArtifacts):
    bag = makeBag(userArtifacts)             # BagIt: payload + manifests + tags
    DEK = randomKey()
    archive = encrypt(bag, DEK, mode="AES-GCM")
    MK = randomKey()
    shares, commitments = vssSplit(MK, k=4, n=7)  # verifiable secret sharing
    distributeToTrustees(shares, commitments)
    policy = signAndLog(policyConfig)
    store(archive, wrappedDEK, commitments, policy)

function verifyDeath(evidenceCredentials):
    valid = [vc for vc in evidenceCredentials if verifyVC(vc)]
    DoD = fuseEvidence(valid)                # m-of-p, issuer thresholds
    pdo = signPolicyDecision(DoD)            # Policy Decision Object
    logAppend("DOD_DECISION", hash(pdo))

function releaseCheck(request, pdo):
    assert verifyRequestorCredentials(request.did, request.vcs)
    assert now() >= pdo.DoD + policy.interval
    assert disputeWindowClosed(pdo)
    shares = collectTrusteeShares(k=4)       # bound to archive + pdo + policy
    with sealedCompute() as enclave:         # TEE / HSM
        MK = enclave.vssCombine(shares, commitments)
        DEK = enclave.unwrap(wrappedDEK, MK)
        bag = enclave.decrypt(archive, DEK)
    return parseBag(bag)

function chat(query, archiveView, policy):
    retrieved = retrieve(archiveView.index, query, snapshotId=...)
    draft = generate(query, retrieved, policyPrompt)
    coverage = computeCoverage(draft, retrieved)
    if coverage < policy.minCoverage:
        output = retrievalOnlyAnswer(query, retrieved)
    else:
        output = draft
    rb = buildResponseBundle(output, retrieved, coverage, policy, runtime)
    sig = sign(rb, signingKey)
    proof = logAppend("RESPONSE_BUNDLE", hash(sig))
    if output.hasMedia:
        attachC2PA(output.media, signer, refs=[proof.entryId])
    return output, sig, proof

Secure updates

If this system becomes real, it becomes a target. Policy bundles, trust roots, verifier rules, and software updates should be distributed using a secure update framework like TUF^[16]. The point: even if some repository keys are compromised, clients can detect the problem. Key rotation, expiration enforcement, and rollback protection are built in. Without this, the whole system can be quietly replaced by a malicious update and nobody notices until it is too late.

Roadmap

A realistic sequence that keeps privacy and trust intact from day one:

Local-first archive + citations: encrypted artifact store with BagIt packaging, retrieval, and citation-bound Q&A. No "freeform persona" yet.
Governance MVP: VSS-backed trustee shares + time delay + release policy evaluation + dispute workflow, with explicit revocation.
Identity layer: DIDs for principals, VCs for death attestations and relationship claims, pluggable issuance via OpenID4VCI.
Safety gateway: session limits, disclosure UX, misuse detection, watermarking + C2PA pipeline.
Transparency log: append-only log with inclusion proofs + independent monitors + verifiable audit packages.
Proof-carrying bundles: signed response bundles with coverage reports, logged to transparency log. Optional verifier replay.
Sealed compute: decryption and inference inside attested boundaries (TEE/HSM).
Persona shaping: carefully constrained "voice" adapters that cannot outgrow the citations.

The "persona" is the final layer, not the foundation. If you cannot prove what it is based on, you are shipping fiction.

Explore the living specification: Glossary · Lifecycle · Citation Binding · Governance · Ambiguity Ledger · Style Tile.

How to help

If you want this to become real, here are the most valuable contributions:

Threat modeling: ways this could be abused; proposed mitigations.
UX ethics: what "grief-aware" interaction should look like in practice.
Privacy engineering: local-first designs, key management, trustee models, sealed compute.
Provenance design: citation formats, response bundle schemas, transparency log integration, C2PA workflows.
Identity and credentials: DID methods, VC schemas, issuer/verifier implementations, OpenID4VCI integration.
User research: talk to people who would (or would not) want this. Listen hard.

Sources & references

This memo tries to use plain language. When it uses terms that can feel loaded (for example "memorial bots"), it borrows phrasing found in public discussion and academic writing about AI-mediated afterlife technologies. If any wording here feels insensitive or inaccurate, please open an issue with suggested edits.

Academic references

Spitale, G. et al. "The Making of Digital Ghosts: Designing Ethical AI Afterlives." (2025). arXiv PDF
Haneman, V. "The Law of Digital Resurrection." Boston College Law Review (2025). PDF
Dwi, M. et al. "Ethical and psychological implications of generative AI in afterlife technologies (DeathTech)." (2025). ScienceDirect
Shamir, A. "How to Share a Secret." Communications of the ACM 22(11), 1979. PDF
Boneh, D. et al. "Verifiable Delay Functions." (CRYPTO 2018). Stanford page
Lewis, P. et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." (NeurIPS 2020). arXiv
Coalition for Content Provenance and Authenticity (C2PA). "Content Credentials" spec v2.3. Spec
Laurie, B. et al. "RFC 6962: Certificate Transparency" (Merkle hash tree audit paths). RFC 6962

Standards and specifications

W3C. "Decentralized Identifiers (DIDs) v1.0." w3.org/TR/did-core/
W3C. "Verifiable Credentials Data Model v2.0." w3.org/TR/vc-data-model-2.0/
OpenID Foundation. "OpenID for Verifiable Credential Issuance 1.0." openid.net/specs/...
Sigstore. "Rekor transparency log." docs.sigstore.dev/logging/overview/
Google. "Trillian: a transparent, highly scalable, and cryptographically verifiable data store." github.com/google/trillian
Kunze, J. et al. "RFC 8493: The BagIt File Packaging Format (V1.0)." rfc-editor.org/rfc/rfc8493
Bakshi et al. "Verifiable Delay Tokens for Privacy-Preserving Time Enforcement." IETF Internet-Draft. datatracker.ietf.org/doc/...
The Update Framework (TUF). theupdateframework.io