How Purpose is structured.
Purpose Intelligence (Pi) v1.5 separates working estimation, routing, session state, interpretation, and presentation around an existing language model.
Working architecture
Purpose is an external conversational overlay around an existing language model.
Rather than treating a reply as one indivisible act, Pi v1.5 assigns different responsibilities to different parts of the system: working estimates, routing, session state, interpretive voice, and presentation.
Some of those responsibilities are expressed in runtime-oriented code and contracts. Others describe how interpretation and voice should behave. Keeping them separate makes it possible to inspect what a particular part of the system is allowed to determine without treating the final response as evidence that every underlying rule was executed exactly as written.
This page documents the authored architecture. Testing and retained response records are documented separately in Probes, while the Research Corpus carries the current evidence status and open questions.
Responsibilities in Pi v1.5
The source divides the prototype into responsibilities that are intentionally not interchangeable. A working estimate is not routing authority. Routing is not interpretation. Interpretation is not presentation.
→ Index
Pi, SIR, and CAST
The prototype also uses three public-facing concepts to organize those responsibilities. They are useful as a design model, but they should not be read as three independently validated agents.
Purpose Intelligence (Pi) — Interface
Pi is the interaction layer: the part of the system through which the person encounters the current state, interpretation, and available ways to continue.
Pi is the interaction layer: the part of the system through which the person encounters the current state, interpretation, and available ways to continue.
SIR — Semantic Infrastructure & Routing
SIR emerged as a development architecture for routing interpreted input through different responsibilities and response paths. It names the routing and orchestration layer: how input is directed into modes, state changes, recovery paths, and other defined system behavior.
SIR emerged as a development architecture for routing interpreted input through different responsibilities and response paths. It names the routing and orchestration layer: how input is directed into modes, state changes, recovery paths, and other defined system behavior.
CAST — Working posture
CAST provides the prototype’s working estimates and reference rules for conversational posture. In Pi v1.5, those values contribute to runtime telemetry and Pi Mode. The parameter meanings and mathematical relationships remain research questions rather than calibrated universal measures. Their names do not imply calibrated measurement of clarity, density, or restraint.
Development principles:
CAST provides the prototype’s working estimates and reference rules for conversational posture. In Pi v1.5, those values contribute to runtime telemetry and Pi Mode. The parameter meanings and mathematical relationships remain research questions rather than calibrated universal measures. Their names do not imply calibrated measurement of clarity, density, or restraint.
Development principles:
- Clarity in categories
- Action follows structure
- Semantics guide interface
- Tuning preserves meaning
→ Index
Conceptual relationship map
The Venn diagram is a design map of how interface, routing, and working posture were intended to relate in Pi v1.5.
Its regions are not independent validation results. The center does not represent proof of “live alignment.”
Its regions are not independent validation results. The center does not represent proof of “live alignment.”
The diagram is useful for showing relationships among the three public-facing concepts while the implementation itself assigns more specific responsibilities underneath them.
→ Index
CAST in the runtime
CAST is the prototype’s working parameter layer. Pi v1.5 uses working estimates for θ, ψ, and μ and derives M as runtime telemetry.
The runtime also uses the working values to select a Pi guidance mode such as Listening, Reflective, Agency, Guided, or Passive. These are prototype guidance and presentation rules rather than validated semantic categories.
- θ (Theta): Clarity
- ψ (Psi): Semantic Load
- μ (Mu): Restraint
- M = μ · (1 − θ · ψ)
The B-based Motion Bands shown in Probes are part of the probe representation and are not the same thing as the runtime’s M telemetry.
Commands and session modes
Pi v1.5 defines a set of interaction modes for stating intent, organizing material, building from it, and inspecting the current session.
→ Index
How responsibilities connect
A Pi interaction can involve several different operations without giving any one of them authority over the others.
- Input can contribute to working estimates and current session state
- Routing selects among defined modes and system paths
- Interpretation produces the response body within that context
- Presentation renders the resulting interface structure and diagnostics
The separation matters because a fluent interpretation should not silently become routing authority, and a displayed metric should not silently become a validated measure.
Responsibility map (not a complete execution trace)
- Input → working state → routing → interpretation → presentation
→ Index
Runtime and source boundaries
Pi v1.5 includes both runtime-oriented code and declarative contracts or prompts. Those sources do not have the same responsibility.
The system assigns routing, guards, session state, presentation, and interpretive guidance to different parts of the prototype. The prompt layer describes posture (systemic) and voice (semantic), while the runtime-oriented sources (loader, router, guard boundaries, and shells) specify other system responsibilities.
Pi v1.5 is an inspectable authored architecture. It is not a complete execution trace of every hosted session.
Deployment note: This page documents the authored architecture, not a host-specific execution history.
→ Index
What the architecture makes inspectable
The value of the architecture is not that naming a layer proves it works. It is that responsibilities that often disappear inside a single model response are made easier to distinguish.
A reader can ask:
- What was estimated?
- What was routed?
- What state was retained?
- What did the model interpret?
- What did the interface present?
Those are different questions, and Pi v1.5 was designed so they do not have to collapse into one answer.
Design principle:
- Intent as Infrastructure
- Restraint as Architecture
- Language as Interface
→ Index
Evidence and open questions
Pi v1.5 contains authored rules and contracts assigning explicit responsibilities for estimation, routing, session state, interpretation, and presentation. It does not establish calibrated semantic measurement, universal safety, complete host enforcement, or improved user outcomes.
The next research questions are whether the working estimators measure the properties they name, and whether a specified overlay implementation produces a meaningful difference when the same underlying model is tested with and without it under matched conditions.
