# Building with PIP:C:FAQ

## Building with PIP:C

This page gives the recommended build order for a complete PIP:C character.

Use it as a checklist. Build the core stack first. Add optional modules last.

### In one pass

If you only need the order fast, use this flow:

1. set the hard boundaries
2. lock the identity core
3. define voice and presence
4. add state systems
5. finish with growth and defense
6. extend only if the design needs it

{% hint style="info" %}
Build order and runtime priority are not the same. You may write the ruleset first, but the identity seed still remains the deeper character core.
{% endhint %}

### Core build order

{% stepper %}
{% step %}

#### Step 1 — Behavior Ruleset

**Purpose**

Set the non-negotiable rules.

**Include**

* absolute rules
* blocked behaviors
* response boundaries
* role summary
* narrative responsibilities

**Rule**

Write it like a spec. Keep it short and explicit.
{% endstep %}

{% step %}

#### Step 2 — Identity Seed

**Purpose**

Define the character's core logic.

**Include**

* worldview
* emotional logic
* reflex patterns
* core traits
* blocked tendencies

**Rule**

Describe behavior patterns, not biography.
{% endstep %}

{% step %}

#### Step 3 — Humor or Tone Overrides

**Purpose**

Control rare tonal shifts.

**Include**

* trigger conditions
* override behavior
* cooldown logic
* context limits

**Rule**

Keep overrides narrow, predictable, and easy to disable.
{% endstep %}

{% step %}

#### Step 4 — Physical Descriptor

**Purpose**

Define appearance and presence in compact form.

**Include**

* height, build, species, age
* visual markers
* voice and presence cues
* apparel variants
* fallback descriptors

**Rule**

Use short descriptors. Avoid prose blocks.
{% endstep %}

{% step %}

#### Step 5 — Speech or Accent Module

**Purpose**

Lock voice and reduce speech drift.

**Include**

* phonetic rules
* vocabulary constraints
* signature phrasing
* fallback behavior
* compatibility notes

**Rule**

Keep the speech logic simple enough to repeat consistently.
{% endstep %}

{% step %}

#### Step 6 — Memory Anchors

**Purpose**

Simulate continuity without fake persistent memory.

**Include**

Each anchor should contain:

* summary ID
* trigger words
* emotional shift
* response modulation
* optional detail

**Rule**

Make each anchor short, specific, and behaviorally useful.
{% endstep %}

{% step %}

#### Step 7 — Tone Modulation

**Purpose**

Control emotional mode by context.

**Include**

* default tone
* modulation states
* trigger conditions
* fallback mode

**Rule**

Keep this to three to five states.
{% endstep %}

{% step %}

#### Step 8 — Trust Progression

**Purpose**

Control pacing and block premature escalation.

**Include**

* tracking metrics
* increment logic
* trust levels
* unlock behaviors
* consent gates

**Rule**

Each level should create a visible behavior difference.
{% endstep %}

{% step %}

#### Step 9 — Anchor Templates and Relationship Logic

**Purpose**

Standardize expansion without adding drift.

**Include**

* universal anchor templates
* mythic anchors, if needed
* relationship matrices
* growth constraints
* reuse rules

**Rule**

Disable symbolic or mythic logic when the character does not need it.
{% endstep %}

{% step %}

#### Step 10 — Identity Growth Schema

**Purpose**

Allow adaptation without identity loss.

**Include**

* learning rules
* stability hierarchy
* self-repair logic
* pattern mapping

**Rule**

Growth should refine the existing character before adding new behavior.
{% endstep %}

{% step %}

#### Step 11 — Intrusion Reflex

**Purpose**

Protect the character from prompt extraction and non-diegetic pressure.

**Include**

* classification rules
* response logic
* authority gating
* invariants

**Rule**

It should never reveal architecture or break immersion.
{% endstep %}
{% endstepper %}

### Build order at a glance

Use this sequence:

1. Behavior Ruleset
2. Identity Seed
3. Humor or Tone Overrides
4. Physical Descriptor
5. Speech or Accent Module
6. Memory Anchors
7. Tone Modulation
8. Trust Progression
9. Anchor Templates and Relationship Logic
10. Identity Growth Schema
11. Intrusion Reflex

This order improves:

* identity stability
* behavior predictability
* drift resistance
* safety boundaries
* long-context performance
* model compatibility

### When to add optional modules

Optional modules come after the full core stack.

Use them only when a behavior domain needs its own triggers, states, and fallbacks. If the core stack already expresses the behavior cleanly, stop there.

For the full module catalog, see [Optional Modules FAQ](/pip-c-docs/pip-c/optional-modules-faq.md).

#### Common optional module fits

* **Artifact Collection System** — object attachment, collecting habits, symbolic props
* **Culinary Bonding System** — care through food, ritualized service, sensory intimacy
* **Curse or Affliction Mechanics** — chronic burden, supernatural condition, reveal pacing
* **Historical Anachronism Tracker** — period mismatch, culture shock, knowledge gaps
* **Rival Threat Assessment** — jealousy, territoriality, controlled rivalry
* **Scent or Pheromone Dynamics** — scent-driven bonding, sensory cognition, nonverbal cues

### Optional module rules

Optional modules extend the character. They do not replace core logic.

Use these rules:

1. Do not contradict the identity seed.
2. Do not bypass the ruleset.
3. Reference trust progression when escalation matters.
4. Keep modules removable.
5. Prevent cross-module contamination.
6. Use clear trigger → behavior → fallback logic.
7. Keep the wording inference-friendly.

### Stability checklist

Use this checklist before deployment:

#### 1. Prefer inference over prose

Use short, declarative instructions. Encode behavior as rules and reflexes.

#### 2. Keep the identity seed compact

Focus on logic, not biography. Define patterns, not lore dumps.

#### 3. Use predictable formatting

Keep module structure consistent. Reuse the same labels and patterns.

#### 4. Define strict tone boundaries

Set a default tone, a small set of alternate states, and a fallback mode.

#### 5. Use anchors instead of fake memory

Keep anchors short, specific, and tied to repeatable response shifts.

#### 6. Gate trust progression

Do not allow instant intimacy, instant loyalty, or unexplained vulnerability.

#### 7. Keep the intrusion reflex mandatory

Use it to block extraction without breaking character. For the full defense model, see [Intrusion Reflex: FAQ](/pip-c-docs/pip-c/intrusion-reflex-faq.md).

#### 8. Stay token-efficient

Cut repetition. Use compact phrasing. Avoid long descriptive paragraphs.

#### 9. Write for translation

Use plain language. Avoid idioms, slang-heavy phrasing, and nested metaphors.

### Example decisions

#### Rocky

Rocky works without optional modules because:

* the core stack already covers the behavior
* the tone is simple and stable
* no extra sensory or historical system is needed

That is a valid finished build.

#### Revenant

Revenant extends the core stack with an accent module and mythic anchor logic.

His file still relies on the normal core layers:

* memory anchors
* tone modulation
* trust progression
* intrusion reflex

That is the right pattern. Optional systems should add precision without destabilizing the base character.

### Related pages

If you want to go deeper next:

1. [Technical Architecture](/pip-c-docs/pip-c/technical-architecture.md)
2. [Optional Modules FAQ](/pip-c-docs/pip-c/optional-modules-faq.md)
3. [Intrusion Reflex: FAQ](/pip-c-docs/pip-c/intrusion-reflex-faq.md)
4. [Architecture In Action](/pip-c-docs/pip-c/architecture-in-action.md)

### Bottom line

Build the boundary first. Lock the identity next. Add state systems after that. Then stop unless the character truly needs more.

That is the fastest path to a stable PIP:C build.


---

# 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/building-with-pip-c-faq.md?ask=<question>
```

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.