document_id	SOCIAL_INTERACTION.README
master_version	0.3.0
readme_sync_version	0.3.0
status	DERIVED
source_of_truth	SOCIAL_INTERACTION_MASTER.md
trace_head	SOCIAL_INTERACTION.TRACE.0003
last_updated	2026-08-13

Social Interaction System

The Social Interaction System is a setting-neutral domain architecture built on Periodic Semantic Grammar. Functional Behavior represents why a result matters; DPA represents whether the social move is an Ask, Deal, or Pressure; BASED represents how behavioral-emotional force is organized; Social Expression produces observable evidence; Interpretation represents what a receiver infers; and Interaction Delta records what changes. PSG supplies the bounded, versioned, validatable, and traceable semantic grammar connecting those jobs.

Authority

SOCIAL_INTERACTION_MASTER.md is the canonical living downstream design source. This README is a synchronized orientation derived from Master version 0.3.0 and is not an independent design authority.

Direct current project-owner instruction and ratified PSG upstream contracts outrank the Master. Context packages provide provenance; audits report findings; exports are delivery copies only.

Parent architecture:

• Repository: fargo161/periodic-semantic-grammar
• Baseline: 6d1efe5f486082b6372d0ccaeefb85e0c32b13c6
• Relationship: PSG is the upstream parent grammar; this repository owns downstream social-interaction semantics.
• Source linkage: architectural reference only; PSG is not copied, vendored, forked here, or included as a submodule.

See ARCHITECTURE_DEPENDENCY.md for the repository boundary.

Current architecture

CHARACTER STATE + ANTECEDENTS + WORLD / RELATIONSHIP STATE
        ↓
FUNCTIONAL BEHAVIOR
  WHY: Escape | Attention | Access | Sensory / Autonomic
        ↓
DPA
  WHAT MESSAGE-ACTION: Ask | Deal | Pressure
        ↓
BASED
  HOW FORCE IS ORGANIZED: ordered, weighted two-Cue Vibe
        ↓
MESSAGE CONSTRUCTION + SOCIAL EXPRESSION
  WHAT BECOMES PERCEPTIBLE
        ↓
RECEIVER INTERPRETATION
  WHAT THE RECEIVER INFERS
        ↓
RESPONSE + PSG-VALIDATED INTERACTION DELTA
  WHAT CHANGES
        ↓
UPDATED STATE + TRACE + NEXT ANTECEDENT

PSG surrounds the loop with identity, versions, relations, direction, weights, boundaries, references, schemas, bindings, validation, derivation, non-materialization, TRACE, transfer, resolution, and explanation.

Generation is intentionally asymmetric:

NPC: hidden state -> intended presentation -> rich Textual Paralanguage -> observable message
PLAYER: constructed message -> Player Packaging Evidence -> observable message
BOTH: observable evidence -> receiver-relative interpretation

The player controls communication by constructing messages, not by selecting emotions.

The next one-room behavior-lab pass has a bounded PROTOTYPE-CANONICAL tactical contract:

STATIC 3-AP BEAT
  -> MESSAGE | MOVE | SCAN | INTERACT | DISTRACT
  -> actor-specific reception, attention, visibility, and attribution
  -> object and room-state consequences
  -> NPC action and fail progression
  -> new static tableau + causal history

These mechanics govern that prototype only. They are not universal Social Interaction or PSG laws.

Module maturity

Module	Current posture	Established	Still incomplete
PSG upstream	completed v0 proof baseline	deterministic core contracts	production infrastructure and final ontology
Master documentation	CANONICAL, FOUNDATION	authority, boundaries, maturity, v0.3 bounded prototype contract	future semantic and implementation evidence
Functional Behavior	four PROPOSED Functions	identities, absolute-pressure source, cross-Function laws	scales, arithmetic, charging, testing
DPA	route identities established	Ask, Deal, Pressure and safeguards	tactics, gating, fit, contest rules
BASED	Cue foundation complete	B/A/S/E/D identities, asymmetric contracts, 20 codes	ratios, 50:50, full Vibe semantics, calibration
Social Expression	provisional interface	evidence-generation, NPC-side rich paralanguage direction, no-codebook laws	final rig, operation grammar, generator, masking and leakage
Player Communication	canonical owner preference	construct messages rather than select emotions	exact builder UI and free-text policy
Player Packaging Evidence	working/provisional	descriptive observable packaging layer	canonical name, schema, provenance, normalization, testing
Antecedents and Interpretation	conceptual contracts	participant-specific context and inference boundaries	update and inference mechanics
Interaction Delta	conceptual schema	structured, independently traceable consequence	arithmetic and minimum runtime set
Activation	interface only	distinct, replaceable state	formula, bounds, persistence
Regulatory Flexibility	conceptual	distinct adaptation domain	formula, bounds, persistence
Integrated Runtime	conceptual spine	system loop and resolver obligations	resolver, authoring, UI, content pipeline
One-room behavior lab	PROTOTYPE-CANONICAL rework	static Beat, shared AP, tactical actions, reception, tableaux, NPC agency, fail trajectories	tested tuning, complete implementation, universal applicability

Canonical terminology

Functional Behavior

Term	Canonical meaning
Function	One primitive motivational or result-pressure domain.
Escape	Disengagement pressure.
Attention	Acknowledgment pressure.
Access	Affordance-availability pressure.
Sensory / Autonomic	Internal-condition modulation pressure.
Function Profile	The four current absolute Function pressures and their state layers.
Function Wheel	A DERIVED relative visualization, not stored truth.
Dominant Function	Highest absolute pressure; a lower pressure may still impose a hard boundary.
Activation	Separate hidden drive state; not total pressure by definition.
Regulatory Flexibility	Separate adaptation, substitution, compromise, and delay capacity.

Tangible is DEPRECATED as the Function name and retained only as legacy/narrower subtype context under Access.

BASED

Code	Cue	Primitive force
B	Belligerence	oppositional
A	Aggression	advancing
S	Sociability	affiliative
E	Empathy	perspective-modeling
D	Deception	epistemic-control

Cue means one primitive BASED force. Vibe means one ordered two-Cue BASED relation. The first Cue is declared dominant; the second modifies it. Direction changes identity:

BA != AB
BE != EB
SD != DS

Cue is canonical inside BASED. Observable evidence may be grouped as a Cue Package, but those visible signals are not additional BASED Cues.

The 20 current Vibe codes and names are registered in Master Section 7.10. Codes are structurally primary; names do not define complete mechanics.

DPA and expression

• DPA routes are Ask, Deal, and Pressure. They are choices, not a required escalation ladder.
• Players construct messages through route, content, framing, support, acknowledgment, qualification, directness, hedging, closure, refusal space, promise, condition, and consequence; exact controls remain unresolved.
• Rich Textual Paralanguage generation is primarily NPC-side.
• Player Packaging Evidence is a working descriptive layer, not an emotion or intent classifier.
• Literal content, intended meaning, intended presentation, expression, and receiver interpretation remain separate.
• Observable social evidence is not hidden truth.

Stable boundaries

• Function is not visible behavior, DPA, or BASED.
• DPA is not motive or moral valence.
• BASED is not Function, expression, personality diagnosis, or truth.
• Expression is evidence, not interpretation or truth.
• Interpretation does not overwrite objective or actor state.
• Function satisfaction does not imply constructive implementation or benefit.
• Compliance does not imply agreement.
• Acknowledgment does not imply understanding, agreement, or validation.
• Activation is not the sum of Function pressures by definition.
• Regulatory Flexibility is not Sensory / Autonomic pressure.
• Domain-specific rules stay downstream unless separately authorized as a genuinely general PSG proposal.
• BASED primordial self-pair refusal and exact 50:50 handling belong to downstream BASED validation, not generic PSG core.
• Prototype FunctionalElementId values are not equivalent to the four primitive Functions.
• Three AP, action costs, direct-message limits, room anchors, and Mara/Drew fail trajectories are prototype-scoped.
• Prototype-canonical does not mean universal or production-stable.

Current unresolved work

High-priority unresolved areas include:

• pressure scales, bounds, ties, zero states, deltas, decay, awareness, and expression arithmetic;
• Activation and Regulatory Flexibility calculation and persistence;
• exact BASED ratio thresholds and exact 50:50 behavior;
• complete ratio-sensitive semantics for all 20 Vibes;
• Empathy / Deception instrumental boundary;
• BASED academic charging, calibration, impact, persistence, consequence, control, and recovery values;
• DPA tactic taxonomy, route gating, fit, and contest rules;
• facial-rig grammar, textual transformation, masking, leakage, and character expression profiles;
• final Textual Paralanguage operations, channels, scales, realization rules, NPC generator, and baseline styles;
• canonical name and schema for Player Packaging Evidence;
• message-builder UI, free-text policy, provenance, ambiguity handling, normalization, and testing;
• prototype FunctionalElementId relationship to the four Functions;
• VALIDITY versus VALIDATION;
• research-to-reference-pool promotion and audit-history authority;
• initiative, movement graph, hearing ranges, whisper thresholds, and attention representation;
• room-event probabilities, distraction strength, attribution logic, and Scan granularity;
• NPC planning, fail thresholds, trigger combinations, and object-lockdown sequence;
• group-message slot handling, MISHEARD, partial-overhear fragments, and Beat-summary wording;
• interpretation, common-ground, memory, relationship, and outcome mechanics;
• integrated resolver, authoring workflow, UI, testing, and content pipeline.

The full registry and disciplined next sequence are in Master Section 19. UNRESOLVED is not permission to invent an answer.

Recent change

Trace head SOCIAL_INTERACTION.TRACE.0003, dated 2026-08-13:

• revised the Master and synchronized README to version 0.3.0 from the prototype-rework handoff;
• registered the one-room behavior lab's bounded PROTOTYPE-CANONICAL tactical contract;
• established static three-AP Beats and the player/NPC action grammars for the next prototype pass;
• added direct-message limits, actor-specific reception, overhearing, movement, Scan, shared attention, distraction, room events, and object state;
• added static expression tableaux, bounded NPC agency, visible Mara/Drew fail trajectories, and causal-history requirements;
• preserved initiative, revalidation, whisper, tuning, and implementation details at WORKING or UNRESOLVED maturity;
• kept every prototype constant local rather than promoting it into universal architecture;
• made no change to PSG core and implemented no runtime.

Preserved earlier transitions:

• the earlier BASED freeze was explicitly lifted;
• Access superseded Tangible as the canonical Function name;
• absolute Function pressures superseded normalized percentages as stored truth;
• the Function Wheel became a derived view;
• Sensory / Autonomic and Regulatory Flexibility were split into distinct concepts.

Start reading

For a human:

1. System Thesis
2. Authority, Maturity, and Supersession
3. Functional Behavior
4. DPA
5. BASED
6. Social Expression
7. Interaction Delta
8. Current Maturity Map
9. Unresolved Work Registry

For an LLM:

1. Read the Document Contract.
2. Preserve the Validation and Boundary Rules.
3. Use the Machine Orientation.
4. Follow the Update Protocol.
5. Inspect Decision Ledger and Provenance before reinterpreting source decisions.

Repository documentation:

• Architecture dependency
• Context intake rules
• Profile location
• Decision records
• Audits

Update and synchronization rule

The Master is edited first. Any change to canonical terminology, module identity, maturity, authority, major architecture, supersession, cross-system contracts, implementation milestones, or unresolved-work status must update this README in the same change.

Both files must keep these values synchronized:

master_version: 0.3.0
readme_sync_version: 0.3.0
trace_head: SOCIAL_INTERACTION.TRACE.0003

Minor prose, formatting, spelling, or link corrections do not require README changes when they alter no semantics. The change record must still state why the README is unaffected.

See Master Section 20 for the full protocol and drift checklist.

Do not assume

• Do not assume the Cues or Functions are numerically calibrated, academically charged, empirically tested, or STABLE.
• Do not assume the current Vibe names provide full semantic definitions.
• Do not assume exact 50:50 Vibes materialize; current status is UNKNOWN.
• Do not assume a forced Ask → Deal → Pressure sequence.
• Do not replace player message construction with an emotion or generic tone picker.
• Do not infer emotion, BASED, Function, motive, intent, or truth from Player Packaging Evidence.
• Do not treat punctuation, tilde, ellipsis, all caps, or keysmash as a fixed emotion codebook.
• Do not treat the one-room behavior lab or its FunctionalElementId vocabulary as canonical architecture.
• Do not generalize its 3-AP economy, direct-recipient rules, room anchors, reception vocabulary, or NPC fail trajectories.
• Do not infer Deception from privacy, uncertainty, nervousness, omission, or gaze alone.
• Do not infer internal state from one facial, textual, postural, or timing signal.
• Do not treat Access as a general Goal or revert it to Tangible.
• Do not treat the relative Function Wheel as stored truth.
• Do not equate Sensory / Autonomic with Regulatory Flexibility.
• Do not resolve the Empathy / Deception instrumental boundary.
• Do not treat a successful tactic, Function satisfaction, compliance, agreement, or constructiveness as the same result.
• Do not add social-interaction special cases to PSG core without a separate authorized UPSTREAM_PSG_PROPOSAL.

What comes next

The immediate prototype direction is to preserve the stabilized prior build as a reference, implement the smallest Mara/Drew room around shared 3-AP Beats, remove direct Function/Vibe/emotion selection, add compositional messages, movement, Scan, attention, reception, distraction, room events, NPC agency, static tableaux, fail trajectories, and causal history, then test repeatedly before generalizing.

This repository currently contains documentation architecture only. Runtime code is not implemented.