Why P/G?
Why not just use an LLM with a prompt?
P/G specifies how the modeled relationship changes; a language model can express the resulting state.
The architectural choice
Why not use a local LLM and a database?
You can. Local hosting determines where language processing happens; a database stores the information you choose to retain. The remaining question is how an experience should change a relationship—and how that change should affect subsequent evaluation.
P/G supplies a specific model for that part: directed relationship state, event-driven updates, elapsed-time dynamics, and explicit connections to affect and valuation. These mechanisms can be inspected and tested separately from language generation.
You could also design another relational model. The meaningful comparison would then be between those models. Local execution, structured state, and code-defined updates are available in other systems too: see Ollama’s local-only operation and LangGraph’s state and reducers.
A computed example
A broken promise changes a represented relationship
Agent B already has a relationship toward A. B receives an observed event encoded as break_promise: A is the actor and B is the target. This synthetic example starts with authored state and uses the core’s engineering defaults. Its numbers are model outputs, not measurements of a person.
- Represent the event. The input supplies the event category, roles, confidence, and time. It does not ask a language model to assign a new trust score.
- Apply the relationship rules. The dictionary supplies role-specific priors. The core combines them with the prior identification state and norm rule, then applies response rates and bounds.
- Record the resulting state. Here is B’s directed relationship toward A before and after the event.
| Dimension | Before | After |
|---|---|---|
| Trust | 0.6000 | 0.2827 |
| Affiliation | 0.7000 | 0.5327 |
| Conflict | 0.0000 | 0.0900 |
Why the change matters afterward
The model’s identification coefficient toward A changes from 0.8617 to 0.6203. This coefficient controls how A’s represented property changes contribute to B’s effective property field.
Evaluate the same hypothetical improvement in A’s health, +0.05 model units, using each relationship state. Its primary affect contribution to B is 0.0302 with the earlier state and 0.0217 with the updated state. Both evaluations use copies; neither records the imagined improvement as an actual event.
An optional dialogue renderer could then express the state. Changing that wording does not, by itself, rewrite the recorded transition. Whether generated dialogue follows the state requires separate evaluation.
Inspect the inputs, rule, and replay record
The fixture uses dictionary version 0.2.1, the default norm pack and parameters, and core configuration M2. Confidence is 1.0; no property outcome is supplied. A’s represented health starts at 0.9. All inputs, parameters, full-precision outputs, and source fingerprints are included in the record.
For trust, the dictionary prior is −0.6. After propagation and the norm contribution, the update input is -0.634569. The negative response rate is 0.5: the core applies clip(0.6 + 0.5 × update input). The prior and update input are distinct from the final change in stored trust.
The health probe holds relationships fixed within each evaluation. Its contribution is the identification coefficient × the default health weight 0.7 × the represented change 0.05. It illustrates a mechanism, not a selected action or a general behavioral advantage.
Download the complete trace (JSON) · Download the replay script (Python)
Replay requires a matching local PGDynamics source checkout: run python -B replay-broken-promise.py --core /path/to/pgdynamics with the JSON beside the script. The script checks source fingerprints and reproduces the recorded results from two fresh starting states.
What the separation supports
Four concrete properties
Reproducible core updates
With the same starting state, structured events, elapsed time, and versioned configuration, the declared update can be replayed.
Inspectable state changes
A trace can connect an event, prior state, and applied rules to the resulting relationship change.
Explicit, testable mechanisms
Declared rules yield predictions that can be checked against alternatives and evidence. Correct implementation and psychological validity are separate questions.
No LLM call for the core update
The relationship calculation uses specified rules. It still performs computation; input processing and dialogue may have their own model costs.
Reproducibility begins at the structured input boundary: the same sentence need not be interpreted as the same event. A trace explains the model’s calculation; it does not establish that its interpretation is true.
Local computation
Local state. Controlled disclosure.
The local-first design does not require private relationship state or interaction history to be sent to a hosted language model for core updates. Input processing and language generation are separate components with their own data boundaries.
Complete application privacy depends on the mapper, renderer, storage, and external connections. Local LLMs can also process data locally. P/G’s contribution is the specified relationship dynamics and their separation from language processing.
Explore the architecture and data boundariesFit and evidence
When is the extra structure useful?
P/G requires explicit event representations, dimensions, rules, and parameters. That work is most justified when relationship dynamics need to be inspected, replayed, or evaluated independently of dialogue. Those choices can also omit context; this structure is not necessary for every conversational application.
The frozen core has undergone computational verification. Human correspondence remains untested. Comparative behavioral advantages require matched experiments; neither this example nor passing implementation tests establishes superiority over an LLM application or another relational model.
Read the research evidence and current status