Novel Approaches | PMG Digital Personas

1 Policy as Code

What it is

Safety and governance rules expressed as versioned, machine-readable artifacts; not prose documents or informal agreements. Every policy bundle has a version number, a content hash, and a cryptographic signature.

Why it matters

"We follow best practices" is not auditable. A signed policy hash included in every response bundle is. When rules are code, compliance can be checked by a machine. When rules are prose, compliance is checked by optimism.

How it works

Policy bundles are versioned and hash-addressed. Each bundle is a self-contained artifact that defines what the system may and may not do.
Changes require multi-party approval and are logged to the transparency log.
Every response bundle includes the policy hash that governed it. An auditor can always see which rules applied to a given interaction.
Policy bundles are signed. Unsigned or tampered bundles are rejected by the system before they take effect.

Benefit: machine-verifiable compliance

An auditor checks the policy hash against the response bundle. The rules that governed the interaction are provably the ones on file. Compliance is a fact, not a claim.

Risk: policy language rigidity

An overly rigid policy blocks a legitimate use case. The trustee cannot override it without a new version, a new signature, and a new approval cycle. Flexibility and safety are in tension.

Benefits

Machine-verifiable compliance: no interpretation gaps between "what we said" and "what actually happened"
Auditable history: every policy version is preserved; drift between stated rules and enforced rules becomes detectable
Accountability: the policy hash in the response bundle is a receipt that cannot be retroactively changed

Risks and open questions. Policy languages are hard to get right. Expressiveness and safety pull in opposite directions. Overly rigid policies can block legitimate use; overly flexible ones can be gamed. Writing good policy code requires both domain expertise and formal reasoning skills, and the intersection of those two groups is small. There is also the question of who audits the policy language itself.

2 Local-First Archive

What it is

The archive is encrypted, portable, and user-controlled from the start. This is not a cloud service that happens to encrypt. The data lives where the decedent (or their trustees) put it, in a format that does not depend on any single operator.

Why it matters

If the archive lives on someone else's infrastructure with someone else's keys, "your data" is a polite fiction. Operator bankruptcy, acquisition, or policy changes can make the archive inaccessible overnight. Local-first means the archive survives the service.

How it works

Content-addressed records: every artifact is identified by its hash, not by where it is stored.
BagIt packaging with SHA-256 manifests provides a standard, well-understood container format for archival data.
Encryption at rest with keys split across independent trustees. No single party can decrypt the archive alone.
The archive can be verified, moved, and re-hosted without loss of integrity. Moving from one storage provider to another does not change any hashes.

Benefit: portable and resilient

The trustee moves the archive to a new host. The integrity manifests still check out. The archive survives the death of the original operator.

Risk: key management burden

A trustee loses their key share. If too many shares are lost, the archive becomes permanently inaccessible. The safety margin depends on the original trustee configuration.

Benefits

Portability: the archive can be moved between providers, countries, and storage technologies without re-encryption
Resilience against operator failure: the archive is not coupled to any single company's survival
Verifiable integrity decades later: SHA-256 manifests let anyone confirm the archive has not been altered, even if they never saw the original

Risks and open questions. Users and trustees take on real responsibility for key management. The trustee model mitigates this, but it does not eliminate it. Format obsolescence is a concern over decades, though standard packaging (BagIt, well-known encryption formats) helps. The operational burden is larger than "just upload to the cloud." Some people will find this unacceptable, and that is a fair objection.

3 Verifiable Audit Trail

What it is

A transparency log with cryptographic inclusion proofs; not just a database table of events. Every significant action in the system is recorded in an append-only structure that third parties can verify independently.

Why it matters

"We logged everything" means nothing if the logs can be silently edited. A conventional database can be changed by anyone with admin access, and no one outside the organization would know. Append-only logs with cryptographic proofs make tampering detectable, even by people who do not trust the operator.

How it works

Every significant event goes into the log: archive ingestion, policy changes, release decisions, response bundles.
The log produces signed checkpoints at regular intervals. Each checkpoint commits to the full history up to that point.
Independent monitors fetch checkpoints and compare them for consistency. If the operator shows different histories to different parties, the monitors will detect the divergence.
Anomalous event patterns (sudden bursts of policy changes, unusual access patterns) can be flagged automatically.

Benefit: independent verification

Two independent auditors fetch the same checkpoint and reach the same conclusion. Neither has to trust the operator or each other.

Risk: log availability

The log server goes down or withholds entries. Monitors detect the gap eventually, but not instantly. Metadata in the logs could also be sensitive.

Benefits

Independent verification: anyone with the checkpoint can confirm the log is consistent, without trusting the operator
Tamper detection: retroactive edits to the log would invalidate the cryptographic chain, making cover-ups structurally difficult
Pattern monitoring: automated analysis of log events can flag anomalies before they become incidents

Risks and open questions. Log availability depends on infrastructure. A compromised log server can withhold entries; monitors will detect this, but detection is not instantaneous. Logs necessarily contain metadata (who accessed what, when, how often) that could itself be sensitive. Balancing transparency with privacy in the log design is a genuine tension that does not have a clean resolution yet.

4 Model Drift Containment

What it is

Frozen behavior profiles and regression anchors that detect when the persona's behavior changes unexpectedly. The system does not just check whether the persona sounds right; it checks whether the persona follows the same structural rules it followed before.

Why it matters

Models change. Updates, fine-tuning, infrastructure migrations, and even hardware differences can subtly alter behavior. Without a detection mechanism, drift is invisible. The persona might start making claims it would not have made last month, and no one notices until someone is hurt.

How it works

Reference question-answer pairs (regression anchors) are established when the persona is first activated.
Anchors are tested on structural properties, not stylistic ones: claim segmentation stability, coverage rung distribution, citation correctness, refusal behavior.
The test is not "does it sound the same" but "does it follow the same rules." A persona that starts accepting questions it previously refused is drifting, even if it sounds polite doing so.
Drift alerts trigger review. The persona may be suspended automatically if drift exceeds a configured threshold.

Benefit: early warning

The reviewer runs regression anchors after a model update. Two anchors fail: the persona accepted a question it should have refused. The system flags the change before any requestor encounters it.

Risk: untested surface area

The anchors cover common cases but miss an edge case. The persona drifts in a way the tests do not detect. The requestor receives a subtly wrong response.

Benefits

Operator accountability: drift is no longer something that "just happens." It is something the operator is responsible for detecting and addressing.
Early warning: structural tests catch behavioral changes before they reach requestors
Measurable fidelity: regression results provide a concrete, trackable metric for persona consistency over time

Risks and open questions. Regression anchors test a sample, not exhaustive behavior. Subtle drift in untested areas can still happen. Maintaining anchors requires ongoing effort; they need to be updated as the archive grows and policies change, but each update risks introducing new blind spots. There is also a philosophical question: how much behavioral change is acceptable? Zero tolerance may be unrealistic for systems that depend on external model infrastructure.

5 Challenge and Correction Channel

What it is

A structured path for third parties to dispute death verification, report errors, and trigger corrections. Not a suggestion box; a formal mechanism with defined resolution procedures and real consequences.

Why it matters

No verification process is perfect. The system needs a way to receive "you got this wrong" that does not require trusting the challenger or the system. If the only way to correct an error is to convince the operator they made a mistake, errors will persist indefinitely. A structured channel makes correction a process, not a negotiation.

How it works

Challenge windows for death verification: a defined period during which anyone in a specified group can dispute the determination with supporting evidence.
Circuit breakers for any trustee who sees a problem. One trustee can freeze the system; lifting the freeze requires a quorum.
Dispute resolution through trustee quorum. The resolution is logged, and the reasoning is recorded in the transparency log.
Error recovery paths that preserve audit trails. Corrections do not erase the original record; they create a new record that references and supersedes the old one.
Third-party revocation is a real capability, not a theoretical one. The mechanism exists, is documented, and has been designed to actually work under adversarial conditions.

Benefit: error recovery

A third party files a challenge with evidence. The trustees convene, evaluate the evidence, and issue a correction. The original determination and the correction both exist in the log.

Risk: channel abuse

Frivolous challenges flood the system. Each one requires trustee attention and delays legitimate activation. The balance between accessibility and protection against harassment is difficult to calibrate.

Benefits

Error recovery: false determinations can be caught and corrected through a defined process, not ad-hoc appeals
Protection against false activation: the challenge window prevents premature or incorrect persona activation
Trust through accountability: the existence of a correction channel signals that the system expects to make mistakes and has prepared for them

Risks and open questions. Challenge channels can be abused. Frivolous or malicious challenges consume trustee time and delay legitimate use. Balancing access with protection against harassment is a real design problem; too easy and the channel is a weapon, too hard and it fails its purpose. Resolution timelines also matter: a challenge that takes months to resolve can delay activation past the point of usefulness. There is no clean answer here, only tradeoffs that need to be tuned for specific deployments.