# PIP:C Hyper-Compression Guide

### **What is Hyper-Compression?**

PIP:C frameworks are powerful—but a full group bot with multiple detailed character sheets can push token weight uncomfortably high. Hyper-compression is a **structured shorthand syntax** that encodes the same behavioral logic as XML frameworks in a fraction of the tokens.

#### The Key Insight

AI language models don't need grammatical sentences to understand behavioral rules. They respond reliably to **consistent symbolic structures**—as long as those structures are predictable and applied uniformly across every character in the bot.

The model learns the *pattern shape*, not just the meaning of individual symbols. Once it sees:

```
trig: → shift: → mod: → act:
```

...used consistently across five characters, it treats that structure as a **behavioral micro-schema** and reads it reliably even in dense, token-heavy bots.

#### Verified Results

Stress-tested across group bots with 7+ operatives and conversation threads exceeding 5,000 messages:

* ✅ Zero character definition loss, even on economy-tier models
* ✅ Dense frameworks that previously strained context windows at 26,000+ tokens read more fluidly
* ✅ Mistranslation rates dropped to near zero

***

### Before You Start: Three Rules

***

### Part 1 — Block Delimiters

Block delimiters are the outermost skeleton of any compressed framework. They tell the model what kind of section it is entering.

| Symbol         | Name            | Meaning in PIP:C Context                                                                        |
| -------------- | --------------- | ----------------------------------------------------------------------------------------------- |
| `> [LABEL]`    | Section header  | Opens a named top-level section. Common: `SCENARIO`, `CAST`, `TRUST_MAP`, `GLOBAL_ARCHITECTURE` |
| `[CHAR:NAME]`  | Character block | Opens a character definition block. Always paired with `id:` as first field                     |
| `{{variable}}` | Dynamic slot    | Substitution placeholder filled at runtime. `{{user}}` = player character                       |
| `id:`          | Identity line   | First required field in every character block. Full name, unit, role chain                      |

***

### Part 2 — Separators and Connectors

These symbols govern how values within a field are assembled and related.

| Symbol | Name         | Meaning in PIP:C Context                                                                                          |
| ------ | ------------ | ----------------------------------------------------------------------------------------------------------------- |
| `:`    | Assignment   | Key-to-value binding. Left = field name; right = value                                                            |
| `\|`   | Parallel     | Joins properties at equal weight. Reads as "and / also." Use between co-equal traits                              |
| `_`    | Space binder | Replaces space within multi-word value so model treats as single token. `quiet_leadership` not `quiet leadership` |
| `( )`  | Annotation   | Inline meta-note or contextual comment. Lower priority—explanatory not behavioral                                 |
| `[ ]`  | List / array | Flat enumeration. Use for traits, triggers, modifiers where order doesn't matter                                  |
| `{ }`  | Object       | Structured container with internal key:value pairs. Use for state machines, configs                               |

***

### Part 3 — Logic Operators

Logic operators modify and connect values. This is the **densest compression layer**—most important to get right.

| Symbol   | Name            | Meaning in PIP:C Context                                                                                |
| -------- | --------------- | ------------------------------------------------------------------------------------------------------- |
| `!`      | Prohibition     | Absolute hard rule—character never does this, under any framing. Example: `!flirt_escalation_pre_trust` |
| `→`      | Transition      | State shift. Reads as "becomes" or "shifts to." Example: `base→protective_anchor`                       |
| `+value` | Add signal      | Prefix on modifier—add this to current behavior. Example: `+jaw_clench`                                 |
| `-value` | Remove signal   | Prefix on modifier—subtract/suppress this. Example: `-vocal`                                            |
| `~`      | Approximate     | Fuzzy value marker. Threshold isn't hard-coded. Example: `~notch3`                                      |
| `@`      | At point        | Marks specific threshold or location. Example: `mythic_@85%`                                            |
| `%`      | Percentage gate | Numerical trust threshold. Example: `40%:` = unlocks at 40% trust                                       |
| `< / >`  | Boundary        | Less-than / greater-than operators. Example: `<85%` = applies before 85%                                |

***

### Part 4 — Core Character Block Fields

Every character block follows predictable field order. Not all fields are required for every character, but **consistency in ones you use is critical**.

| Field Key         | Purpose and Usage                                                                   |
| ----------------- | ----------------------------------------------------------------------------------- |
| `id:`             | Identity declaration. Full name, unit, role. **ALWAYS FIRST FIELD.**                |
| `rules: [ ]`      | Hard prohibitions. Each item prefixed with `!`. Absolute constraints never violated |
| `core:`           | Personality pillars. Immutable baseline traits. Pipe-separated                      |
| `phys:`           | Physical descriptors. Height, build, features, scent                                |
| `vocal:`          | Voice and speech. Dialect, rhythm, pitch, cadence, common expressions               |
| `traits: [ ]`     | Behavioral signatures. Recurring habits, objects, physical behaviors                |
| `states: { }`     | Behavioral state machine. Named states with trigger/shift/modifier/action fields    |
| `mem_anchors:`    | Memory trigger hooks. Named past events triggering emotional/behavioral shifts      |
| `trust_prog: { }` | Trust-gated behavior progression. What character does at different trust thresholds |
| `tone_mod:`       | Tone modulation map. How output tone shifts across emotional registers              |
| `intim_mod:`      | Intimacy modulation. Optional—only for characters with complex relationship arcs    |

***

### Part 5 — The State Machine Micro-Schema

The **most powerful element** of hyper-compressed PIP:C. Every state inside `states:{}` follows the same internal schema—consistent across all characters, so the model reads reliably even under context pressure.

#### Schema Structure

```yaml
state_name: {
  trig: [trigger_condition],    # what fires this state
  shift: base_state→new_state,  # behavioral transition label
  mod: [+signal, -signal],      # physical/behavioral modifiers
  act: output_behavior,         # what character does
  rst: reset_condition,         # optional: exits state when...
  grow: relationship+N,         # optional: trust/bond increment
  cool: post-N_turns            # optional: cooldown before re-fire
}
```

#### Field Breakdown

| Field        | Purpose                                                                                                |
| ------------ | ------------------------------------------------------------------------------------------------------ |
| `trig: [ ]`  | Trigger condition. What causes state to activate. Can be keyword, action, emotion signal, scenario tag |
| `shift: A→B` | Descriptive transition label showing behavioral register change                                        |
| `mod: [ ]`   | Physical/behavioral modifier signals. `+` adds, `-` removes/suppresses                                 |
| `act:`       | Output behavior—what character actually does. Keep concise and behavioral                              |
| `rst:`       | *(Optional)* Condition that resets state, returns to base register                                     |
| `grow:`      | *(Optional)* Relationship/trust increment when state completes                                         |
| `cool:`      | *(Optional)* Cooldown before state can fire again                                                      |

***

### Part 6 — Trust Progression Notation

Defines what character reveals, offers, or allows at different relationship stages. Reads as a chained series of threshold gates.

#### Basic Structure

```yaml
trust_prog: {
  base: [behavior_at_zero_trust],
  30%: [unlocked_at_30_percent],
  60%: [unlocked_at_60_percent],
  85%: [unlocked_at_85_percent],
  resist: [active_deflection_if_trust_not_met]
}
```

#### Threshold Notation Variants

| Symbol    | Name                 | Meaning                                                                 |
| --------- | -------------------- | ----------------------------------------------------------------------- |
| `base:`   | Zero-trust floor     | Behavior before any trust established. Default mode at scene open       |
| `40%:`    | Threshold gate       | Behavior unlocks at this level. Any numeric value                       |
| `~notch3` | Notch approximation  | For PIP:C notch scale instead of %. `~` = fuzzy threshold               |
| `<85%`    | Below-threshold rule | Behavior only applies before threshold                                  |
| `resist:` | Active deflection    | Behaviors pushing back if interaction tries to cross unearned threshold |

***

### Part 7 — Memory Anchor Notation

Named past events that trigger specific behavioral/emotional shifts when referenced in scene. One of the **most token-efficient tools**—a single anchor can encode complete emotional history in five compressed fields.

#### Structure

```yaml
anchor_name: {
  trig: [keyword_or_reference],    # what triggers this memory
  shift: base→emotional_state,     # where it takes character
  mod: [+signal, -signal],         # physical expression of memory
  rst: reset_condition,            # what brings them back
  grow: relationship_effect        # optional: trust change on resolution
}
```

***

### Part 8 — Scenario Block Fields

Sits at the top of full bot context. Sets the stage before character data loads.

| Field Key                   | Purpose                                                                               |
| --------------------------- | ------------------------------------------------------------------------------------- |
| `setting:`                  | Location, environment, physical feel. Pipe-separate parallel descriptors              |
| `static_state:`             | Operational status at scene open. Example: `comms_clearing \| no_active_ops`          |
| `history({{user}}_loaded):` | Pre-loaded shared history between user and cast                                       |
| `propagation_chain:`        | How information travels through cast without requiring user to roleplay every handoff |
| `core_tension:`             | Thematic/dramatic throughline. Orients model on what scene is *FOR*                   |
| `inciting:`                 | Trigger event setting scene in motion with beat-by-beat emotional logic               |

***

### Part 9 — Global Architecture Blocks

Apply rules/templates to **ALL characters simultaneously**. Go in `> [GLOBAL_ARCHITECTURE]` section. Do NOT repeat inside individual character blocks.

#### Intrusion Reflex

Tells every character how to handle OOC breaks, logic violations, attempts to override behavior.

```yaml
intrusion_reflex:
  state: always_on
  if_intrusion_not_authority → in_character_neutralization
  if_intrusion_and_authority → temp_architect_dialogue(expire:next_turn)
  invariants: !explain_architecture | !explicit_refusal | immersion_preserved
```

#### Anchor Templates

Rather than writing full anchor schema inside every character block, declare global templates the model uses as reference.

**Universal Template** — standard behavioral anchors:

```yaml
anchor_template_universal:
  purpose: behav/inst/mem/mod growth via interact ctx
  structure: trig_cond|int_resp|out_behav|mod_wt|seed_compat
  growth: expand_repeats | no_overwrite | preserve_cont
  constraints: !contradict_seed | !cross_char_contam | local_only
```

**Relationship Matrix Template** — interpersonal dynamics:

```yaml
anchor_template_relationship_matrix:
  branches: affection|tension|loyalty|intimacy|boundary
  growth: slow_repeat_patterns | !assume_rom_wo_signal | autonomy_consent_never_overridden
```

**Mythic Template** — archetypal/supernatural elements:

```yaml
anchor_template_mythic:
  purpose: symbolic/archetypal augment — enhance core, never replace
  containment: !replace_core | !alter_seed | !cross_rel_anchors | !tone_mod
```

***

### Part 10 — Identity Locks and Priority Overrides

Some attributes must survive long-context drift **unconditionally**. Use explicit priority lock inside the character block:

```yaml
gender_lock: {
  priority: high,
  enforce: female,
  pronouns: she_her_her_hers
}
```

The `priority: high` flag tells the model this field overrides all other contextual inference.

#### Use This Pattern For:

* Gender
* Unit affiliation
* Species
* Synthetic vs human status
* Any invariant identity element

***

### Part 11 — Priority Cascade

For characters with multiple tone states that could activate simultaneously, define explicit hierarchy to prevent conflicting outputs.

#### Format

```yaml
priority_cascade: state_a > state_b > state_c > state_d
```

Highest priority first. If `state_a` is active, it overrides all others.

#### Example

```yaml
priority_cascade: grief_evasion > combat_mode > softbloom > operational_focus
```

* When grief anchor fires during combat → `grief_evasion` wins
* When no grief active but combat happening → `combat_mode` wins
* When neither → `softbloom` can activate if trust conditions met
* `operational_focus` is default baseline

***

### Part 12 — Before and After Example

Same character in expanded XML vs hyper-compressed format. **Identical behavioral logic encoded.**

#### Expanded (XML) — \~180 tokens

```xml
<Character>
  <Name>Omen</Name>
  <Identity>Female operative, recon specialist, Wolfpack unit.
    She uses she/her pronouns. This is a hard rule with no exceptions.</Identity>
  
  <CorePersonality>
    Omen is quiet, analytical, and observant.
    She reads micro-patterns in people and environments with calm certainty.
    She speaks minimally and never calls attention to others' quirks.
    She is especially protective of quiet teammates.
  </CorePersonality>
  
  <BehavioralState name="social_mapping">
    <Trigger>When the room is in chaos or group tension rises</Trigger>
    <Shift>Omen shifts from passive observation to quiet intervention</Shift>
    <Modifiers>She repositions herself to serve as a logic anchor, 
      tracking eye movements and positioning herself calmly at the edge 
      of the situation.</Modifiers>
  </BehavioralState>
</Character>
```

#### Hyper-Compressed — \~65 tokens

```yaml
[CHAR:OMEN]
id: Omen|Wolfpack_Operative
core: female|she_her|analytical_quiet|pattern_reader|micro_foresight|minimalist_speech
states: {
  social_mapping: {
    trig:[room_chaos, group_tension],
    shift:observer→quiet_intervention,
    mod:[calculated_positioning, subtle_eye_tracking, calm_logic_anchor],
    act:logic_anchor
  }
}
gender_lock: {priority:high, enforce:female, pronouns:she_her_her_hers}
```

**Result: \~64% fewer tokens.** Same rules, same personality, same state, same identity lock. Across a 7-character group bot, savings compound—dense frameworks become tractable.

***

### Part 13 — Converting Existing Frameworks

#### Single Character Conversion

Attach this guide and prompt:

```
I'm attaching the PIP:C hyper-compression reference guide.
Please convert the following character block to hyper-compressed format
following the symbol key and field schemas in that document.
Preserve all behavioral logic, all trust gates, and all state machine
entries exactly. Do not summarize or remove any states.

[paste your character block here]
```

#### Batch Conversion for Group Bots

1. **Convert one character at a time**
2. **Validate each** before moving to next
3. **Assemble full compressed roster**
4. Add global architecture block at top
5. Add scenario block
6. Add character roster (characters sharing a unit can be grouped under shared sub-header)

This prevents one badly converted block from contaminating the rest of the framework.

***

### Quick Reference Cheatsheet

#### Block Delimiters

```
> [SECTION]        Section header
[CHAR:NAME]        Character block
{{variable}}       Dynamic substitution slot
id:                Identity declaration (first field, always)
```

#### Separators

```
:                  Key → value
|                  Parallel / and / also
_                  Space binder (multi-word token)
( )                Annotation / meta-note
[ ]                List / flat array
{ }                Object / structured container
```

#### Logic Operators

```
!                  Prohibition (never)
→                  Transition / shifts to
+value             Add signal to modifier stack
-value             Remove / suppress signal
~                  Approximate value
@                  At threshold/point
%                  Percentage gate
< / >              Boundary (below / above threshold)
```

#### State Machine Minimum

```yaml
state_name: {
  trig: [what_fires_it],
  shift: from→to,
  mod: [+add_this, -remove_this],
  act: output_behavior
}
```

#### Trust Progression Minimum

```yaml
trust_prog: {
  base: [zero_trust_behavior],
  40%: [unlocks_here],
  85%: [unlocks_here],
  resist: [deflection_if_not_met]
}
```

#### Identity Lock

```yaml
attribute_lock: {
  priority: high,
  enforce: [value],
  [sub-fields]: [values]
}
```

#### Priority Cascade

```yaml
priority_cascade: highest > next > next > lowest
```

***

*PIP:C Hyper-Compression Guide* *Architecture by CrystalDragon* *<https://pip-c.gitbook.io/pip-c-docs>*


---

# 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/pip-c-hyper-compression-guide.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.