# Optional Modules FAQ ## Optional Modules Optional modules are plug-in behavior packs for PIP:C characters. They extend the core system without touching the identity seed. They also stay compatible with trust gating, memory logic, and identity growth. You do **not** need them to make a character work. The core architecture is already stable on its own. You use optional modules when a behavior domain needs more precision than the core stack should carry. ### In one pass If you only need the page fast, read it in this order: 1. **What optional modules do** 2. **What rules they must follow** 3. **Which modules already exist** 4. **How far the system can extend** ### What optional modules do Optional modules add specificity. They are best for behaviors that are: * too narrow for the core architecture * rich enough to deserve their own triggers and states * repeated often enough to justify formal logic That makes them useful for domains like jealousy, food rituals, collections, curses, or scent-driven behavior. Without modules, those traits often stay shallow. With modules, they become repeatable systems the model can follow. ### What optional modules are not Optional modules do **not** replace the character core. They should never: * overwrite the identity seed * bypass hard behavior rules * ignore trust progression * create growth that contradicts established anchors The design rule is simple: *core defines who the character is* *modules define how that identity expresses itself in a specific domain* ### Design constraints Every optional module should follow the same baseline logic: * clear trigger conditions * defined response states * trust-aware escalation * recovery or decay behavior * no conflict with absolute rules If a module cannot be expressed as structured conditional behavior, it usually does not belong here yet. ### Available Modules #### Artifact Collection System This module tracks how a character bonds with physical objects. It can define: * collection categories with emotional meaning * acquisition triggers tied to mood or attachment * display habits that change with trust * narrative use of objects as emotional symbols This turns props into active character logic instead of background flavor. #### Culinary Bonding System This module encodes food as care, ritual, and vulnerability. It can define: * cuisine skill with emotional associations * trust-gated cooking rituals * user reaction outcomes * scent and taste as intimacy triggers It works especially well for characters who show attachment through service rather than confession. #### Curse/Affliction Mechanics This module formalizes supernatural or chronic conditions. It can define: * the affliction type and origin * trigger and severity shifts * behavioral fallout * visual or sensory manifestations * reveal thresholds by trust level * break conditions or cure logic This keeps an affliction from becoming random drama or pure flavor text. #### Historical Anachronism Tracker This module manages period mismatch and culture shock. It can define: * what the character understands * what they misread or reject * stress-based historical slips * user-led learning paths * values they will never modernize away It prevents the usual immortal-character problem where they magically know everything. #### Rival Threat Assessment This module tracks jealousy, territoriality, and rival response. It can define: * what counts as a threat cue * how intense the response becomes * how false positives are handled * behavior tiers from watchfulness to interference * how reassurance or rejection shifts the state That keeps possessive behavior legible, paced, and reactive instead of repetitive. #### Scent/Pheromone Dynamics This module encodes scent-driven attraction and sensory behavior. It can define: * how the character reads the user's scent * what emotional changes scent reveals * marking, tracking, or scent-seeking behavior * arousal triggers tied to scent shifts * absence behaviors driven by scent memory It is useful for heightened-sense characters and nonverbal intimacy patterns. ### Shared pattern across these modules Even though the subject changes, the architecture stays the same. Most optional modules follow the same logic chain: 1. identify a trigger 2. classify the current state 3. apply a behavior shift 4. gate escalation through trust 5. define decay, recovery, or consequence That shared pattern is why the system scales cleanly. ### Potential Module Types The system is intentionally extensible. Any behavioral domain can become a module if it can be written as: * triggers * states * responses * trust-aware progression * recovery or long-term growth Strong future candidates include: * combat proficiency and weapon preference * magic systems and exhaustion rules * finances, resources, and status behavior * religious ritual and devotional logic * mentorship and training patterns * seasonal or cyclical personality shifts * phobias, avoidance loops, and exposure recovery The core test is simple: if the behavior can be modeled as conditional logic with stable transitions, it can probably become a PIP:C module. ### Bottom line Optional modules make characters more specific without making them less stable. They work because they stay subordinate to the core architecture. They extend identity. They do not replace it. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://pip-c.gitbook.io/pip-c-docs/pip-c/optional-modules-faq.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.