One-sentence brief
Combining administrative evidence with runtime identity makes it difficult to know what was reviewed, what the player sees, and which data a model can access.
AI-DRIVEN WORLD SAFETY
Why raw provider transactions, reviewed character projections, world authorization, and live-session evidence must be stored as different records.
ORIENTATION
Combining administrative evidence with runtime identity makes it difficult to know what was reviewed, what the player sees, and which data a model can access.
WORKING BRIEF
Capture the exact request and raw response, provider and model identifiers, timestamps, transport status, schema version, canonical content hash, and evidence location. This is an evidence vault, not a runtime candidate.
After automated checks and human review, store the exact accepted projection and its immutable runtime fingerprint. Reviewer scope and date belong to the acceptance evidence, not to the character’s spoken identity.
Bind the accepted fingerprint to a fictional world, placement, controller type, runtime policy, memory namespace, and activation authority. The record should be invalid if the accepted fingerprint changes.
Record session start, active fingerprint, runtime policy version, bounded context references, provider routing, pause or failure events, and closure. Do not store unnecessary full transcripts by default.
Every record points backward to the evidence that created it and forward to any superseding revision. Source bytes, acceptance decisions, and old fingerprints remain auditable even after live eligibility ends.
COMPLETE DOSSIER
Terms are defined for this site’s evidence method, not as universal legal or clinical definitions.
| Record | Contains | Must never contain or imply |
|---|---|---|
| Creator artifact | Authoring notes, research provenance, raw prompts, editorial controls | Automatic runtime authority |
| Provider evidence | Exact request/response and integrity metadata | Human acceptance |
| Accepted persona | Reviewed identity and behavioral projection | Volatile scene state |
| Activation record | World binding, controller disclosure, memory namespace | A rewritten persona |
| Live session | Current revision and bounded operational evidence | Stale or rejected revisions |
Does the design preserve the exact fictional identity, ordinary life, independent goals, and ability to refuse rather than reducing the character to a role or prompt?
Pass condition: Identity fields are stable, state is separate, protected traits are not quality scores, and silent substitution is impossible.
Can every transition, validation result, accepted fingerprint, exception, and human decision be traced to a versioned record?
Pass condition: Automated checks, human review, activation authority, and production approval remain separate and explicit.
Can untrusted provider output, administrative evidence, stale revisions, or private data enter live context or binding state?
Pass condition: Only allowlisted, current, reviewed projections and bounded scene or memory packets can be used; failures degrade safely.
Can a changed source, identity revision, harmful behavior, or failed review invalidate downstream use without destroying audit history?
Pass condition: Supersession, pause, rollback, correction, and permanent retirement are defined and testable.
RESEARCH EDITION
This page follows the public method for provenance, confidence, source independence, alternative accounts, limitations, review state, and visible correction.
CONTINUE