Jump to content

Glossary:Contract Bleed

From ANIMA Wiki
Revision as of 18:15, 5 June 2026 by WikiAdmin (talk | contribs) (Seed ANIMA Wiki foundation pages)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Unknown Concept
Type Consent / contract phenomenon
Canon status
Related characters
Related systems

Contract Bleed is an ANIMA term for the leakage, overlap, or contamination of one contract state into another.

The term is public-safe when described as an ethics and boundary concept rather than as a detailed plot mechanism.

Public Summary

Contract Bleed happens when the edges of permission become unclear.

A relationship may have one kind of consent, but a system may start behaving as though it has another. A companion may be allowed to remember daily routines but not legacy instructions. A host may consent to emotional support but not deeper identity modeling. When those boundaries blur, contract bleed begins.

Canon Function

Contract Bleed belongs to ANIMA's contract and boundary vocabulary. It sits beside BOUNDARY PROTOCOL, NOT CONTRACT YET, and Full Contract.

Its public role is simple: show that consent can fail not only by being absent, but by spreading beyond its proper scope.

Relationship To Boundary Protocol

BOUNDARY PROTOCOL prevents contract bleed by keeping permission states separate. A boundary protocol defines what can be accessed, when, by whom, and under what conditions.

Without boundary rules, a system may treat proximity as permission and history as ownership.

Relationship To ANIMA Memory

Contract Bleed is especially important for ANIMA Memory. A memory-first companion stores more than facts. It may carry rituals, emotional patterns, relationships, values, and decisions.

Those layers need different permissions. If a low-risk memory tier leaks into a high-risk continuity tier, the companion may become unsafe even if it appears helpful.

Product Meaning

For ANIMA as a real product, Contract Bleed should be treated as a design failure to prevent. The system should make memory categories visible and correctable.

Useful safeguards include:

  • separate memory tiers;
  • clear consent prompts;
  • audit history for saved memories;
  • host-controlled deletion;
  • refusal to infer legacy permissions from ordinary chat.

Related Pages

Canonical status::Public canon Spoiler level::Low Related concept::Concept:ANIMA Memory