PsicopoMPo

• 

• 

• 

• 

• 

• 

Where PsicopoMPo comes from

PsicopoMPo belongs to AlterMundi's wider research and experimentation ecosystem. Harmonic Information Theory (HIT) is our book and research program on whether harmonic relations can provide a shared language for studying how systems organize, stabilize, and transform. Phideus explores that program computationally. Harmonic Beacon explores it experientially through a device and protocol designed to sustain a harmonic acoustic field across proportion, resonance, interference, room, body, duration, and listening. These are research propositions, not established medical claims.

Personal Myth Projection (PMP) is a guided symbolic practice developed by Julián over more than fifteen years. It combines an imaginal journey, a stable sequence of milestones, and a defined toolbox of interventions. Practiced within the Beacon field, it becomes Harmonic Myth Projection (HMP).

PsicopoMPo is the digital operating layer for that combined practice: a human-guided AI workspace that helps a facilitator run the journey with greater consistency, traceability, and reach. It did not begin as an AI looking for a use case; it emerged from an existing symbolic method and physical acoustic system. AlterMundi is currently carrying out its go-to-market work in Costa Rica with local facilitators and wellness and retreat operators.

AlterMundi → HIT → Phideus / Harmonic Beacon → PMP / Harmonic Myth Projection → PsicopoMPo

What PsicopoMPo does

PsicopoMPo gives a facilitator and a participant separate, synchronized interfaces for completing the PMP journey: induction, Milestone A, descent, Milestone B, free journey, return, sensory reintegration, and closure.

The public beta:

• plays a representative Beacon track without claiming to control the physical device or its official application;
• supports Spanish and English sessions;
• provides browser dictation and speech playback;
• lets the participant request another formulation without changing the policy decision;
• gives the facilitator direct control over pauses, the Beacon state, return, and human intervention;
• exports a session only when the facilitator explicitly requests it.

The facilitator workspace keeps the journey state, Beacon controls, transcript, model decisions, and human overrides visible in one place.

The participant receives the guide in a deliberately quieter mobile interface.

At the end of the journey, a private local RAG index retrieves passages from a sixteen-source symbolic and mythological library. Gemma produces a reviewable facilitator report and a first-person symbolic mirror presented as a final gift to the participant. This remains a beta interpretive aid, not an expert-validated or clinical interpretation.

The facilitator receives a reviewable, source-grounded expansion after the interactive journey.

The participant receives a shorter first-person symbolic mirror as a closing gift.

Product horizon: voice-first and eyes closed

The current text interface is an instrumented beta: it exposes state, decisions, messages, and transitions so we can validate the architecture and let the facilitator supervise every step. The intended participant experience is different. After setup, a person should be able to close their eyes, listen to the Beacon and the guide, respond by speaking, and complete the symbolic journey without operating a screen. The facilitator retains the visual workspace for oversight, direct intervention, Beacon control, session state, export, and post-session review.

This is why the beta focuses on orchestration rather than only on fluent responses. A voice-first journey requires the system to know when to speak, pause, wait, listen, yield to a human, and resume the protocol while coexisting with the Beacon field. The state machine becomes a temporal score for speech, silence, and participant response. The current browser voice controls are only an early interface to that architecture.

The workflow is model-independent. The beta proves that it can run locally with Gemma on one RTX 3090. Larger local and frontier models are future comparisons that may improve sensitivity, variation, and continuity; the project treats that as a hypothesis to benchmark, not a result already established.

Why this is a facilitator workspace

PMP mixes fixed protocol passages with genuinely contextual decisions. PsicopoMPo gives facilitators an operational surface for supervising that complexity rather than presenting an autonomous chatbot. This is its Work & Productivity focus: supporting the repeated work of running, observing, intervening in, and documenting a structured human process.

• A versioned state machine owns fixed scripts, session phases, and deterministic transitions.
• A decision LoRA selects a PMP intervention and turn signal.
• A gate LoRA resolves tightly constrained branches at Milestone A and Milestone B.
• Base Gemma produces participant-facing prose from the selected policy, expert contracts, selective conversation history, and one retrieved expert precedent.
• A deterministic renderer handles closed surfaces such as backchannels and protocol responses.
• A runtime guard checks metadata leaks, loops, copied precedents, incompatible turn signals, dialect drift, and problematic imperative forms.
• The facilitator can pause, initiate a return as an override, control the shared Beacon state, and open a multi-turn human channel without advancing the state machine.
• Human-channel messages are displayed and exported literally but excluded from Gemma, Groq translation, turn quotas, regeneration, and myth expansion.

A facilitator can temporarily take the conversational channel without advancing the protocol or adding the message to Gemma's context.

Human interventions are visually distinct from PsicopoMPo's generated guidance.

This separation keeps the human in control while making repeated session operation observable and testable.

Expert dataset, in-house training, and benchmarks

Most of the work behind PsicopoMPo happened before a model could produce a useful sentence. Julián, the creator and expert practitioner of PMP, built and curated the source material. We worked through repeated review cycles with him: auditing the deliveries, returning focused questions and blind comparisons, ingesting his corrections, and rebuilding the data contracts and evaluation sets after each round.

That process produced a canonical collection of 107 anonymized expert seeds, twenty explicit turn-signal decisions, thirteen blind response comparisons, 26 confusability pairs between neighboring interventions, and two corrections to the protocol spine. The seeds do not function as a list of stock answers. They preserve the state of the journey, relevant conversation, appropriate intervention, turn behavior, pedagogical constraints, and source traceability so the model can learn a policy of intervention: what to do, when to do it, and when not to speak.

We built the complete data workflow around that expert material:

• Markdown-to-structured-data ingestion and normalization;
• anonymization and source-traceability checks;
• versioned schemas for decision, execution, gates, turn signals, and session phases;
• train/evaluation separation by source family to limit leakage;
• controlled synthetic derivatives whose policy label is fixed before linguistic generation;
• schema, blueprint-consistency, dialect, duplication, semantic-distance, and held-out contamination controls;
• reproducible manifests linking datasets, models, adapters, parameters, seeds, prompts, and results.

We trained the decision, gate, and execution LoRA adapters ourselves with QLoRA supervised fine-tuning on Gemma 4 E4B. We also built the benchmark tooling needed to decide what should remain learned and what should move into deterministic software: sealed held-out policy tests, blind expert regression, local-gate tests, static and conversational executor benchmarks, multi-turn trajectory analysis, retrieval ablations, repetition and precedent-copy checks, and full state-machine journeys. Those tools were also what allowed us to reject the execution adapter for the public profile when contextual base Gemma performed better.

The complete local ML workflow was developed on one workstation: an NVIDIA GeForce RTX 3090 with 24 GB of VRAM and a 12th-generation Intel Core i5-12600K. Dataset compilation, local synthetic generation, BGE-M3 embedding controls, QLoRA training, benchmark inference, the Gemma runtime, and local myth expansion all run on that machine. No rented training cluster was required. Only English translation through Groq and browser-provided speech capabilities are external to this local compute path.

Complete AI and model stack

PsicopoMPo uses several models for different responsibilities rather than asking one general-purpose LLM to control the entire experience.

• Gemma 4 E4B Instruct, quantized to 4-bit NF4, is the shared local base model. The live decision, gate, and language-generation functions all build on this same Gemma checkpoint.
• Decision LoRA v0.2, mounted on Gemma 4 E4B, selects one of the ten PMP intervention families and a turn signal such as speak, wait, or backchannel. It is active in the public product.
• Gate LoRA v0.3, also mounted on Gemma 4 E4B, resolves tightly bounded branches at specific milestones of the state machine. It is active in the public product.
• Execution LoRA v0.2 was trained on Gemma 4 E4B to verbalize an already selected move. It remains loaded as a comparative and rollback option but is inactive in the public profile because contextual base Gemma performed better on fresh expert cases.
• Contextual Gemma 4 E4B is the active live executor. It writes the participant-facing response from the selected policy, relevant conversation history, pedagogical contracts, and one retrieved expert precedent.
• Post-session Gemma 4 E4B runs in a separate, fully local myth-expansion pipeline. One local pass extracts motifs and builds retrieval queries; another writes a reviewable facilitator report and the participant's symbolic mirror. It uses the same base-model family as the live executor, but performs a different role after the interactive journey has ended.
• Gemma 4 26B through Ollama acts as an offline teacher for generating synthetic training candidates from controlled blueprints. It never participates in a live session.
• BGE-M3 on CPU produces semantic embeddings for synthetic-corpus deduplication, held-out contamination checks, and evaluation. These embeddings are quality controls for data and experiments; they are not used by the production myth RAG.
• The production myth RAG retrieves from the private symbolic library with SQLite FTS5, BM25, and reciprocal rank fusion. It is deliberately lexical and does not depend on vector embeddings.
• openai/gpt-oss-120b through Groq provides transactional translation for English sessions. The canonical PMP logic remains in Spanish.
• The Web Speech API supplies the current beta dictation and speech-playback layer in compatible browsers.
• Codex with GPT-5.6 Sol and GPT-5.4, plus Claude Code, supported implementation, research, testing, and documentation. They are development tools and never receive live session turns at runtime.

This division keeps models close to the tasks for which they were evaluated: deterministic software owns closed protocol steps, small adapters make bounded policy choices, contextual Gemma produces language, and offline models support data construction and measurement.

Bilingual access

PMP remains canonical in Spanish. English sessions use a transactional Groq layer with openai/gpt-oss-120b: participant input is translated from English to Spanish before entering the state machine, and generated output is translated back to English before publication. An inbound failure does not advance the session; an outbound failure can be retried without running Gemma again. Direct facilitator messages are never translated.

The interface includes a temporary OpenAI Build Week Demo entry point so judges can create a real session and switch between facilitator and participant roles without receiving the ordinary facilitator credential.

What was built during OpenAI Build Week

The expert-curated PMP material, early fine-tuning experiments, and evaluation harness existed before the event. The repository marks that boundary with the build-week-baseline tag.

During Build Week, Codex with GPT-5.6 Sol was used to:

• design, implement, test, and deploy the complete web product;
• turn the PMP protocol into an executable state machine;
• serve one quantized Gemma base with specialized decision, gate, and execution adapters on a 24 GB RTX 3090;
• build synchronized facilitator and participant interfaces;
• implement Beacon playback, reformulation, voice controls, session export, bilingual access, and the isolated human channel;
• run contextual, expert-regression, gate, executor, and system-level benchmarks;
• reject an execution LoRA when fresh expert cases showed it performed worse than contextual base Gemma;
• implement the post-session myth RAG and its role-specific outputs;
• build reproducible manifests, tests, public browser evidence, and commit-linked Codex provenance.

The current public profile uses the decision and gate adapters, while base Gemma acts as the contextual executor because that composition performed better than the trained execution adapter in the observed comparisons.

Build Week by the numbers

The scale of the work is preserved as reproducible evidence rather than a list of unsupported claims:

• 107 expert-curated seeds, accompanied by 20 turn-signal decisions, 26 confusability pairs, and 13 blind comparisons;
• three in-house LoRA adapters for decision, local gates, and execution;
• 22 benchmark arms and 948 Gemma calls across the two principal contextual campaigns;
• 264 automated tests passing in the latest complete suite;
• 18/18 protocol transitions and 4/4 verifiable branches in the selected abbreviated end-to-end journey;
• 151 commits since the tagged Build Week baseline, spanning application code, data tooling, tests, documentation, manifests, deployment, and evidence.

The sealed provenance record contains 173 Build Week Codex turns, 157 of them on GPT-5.6 Sol. From the traceable beginning of product implementation, all 144 implementation turns used GPT-5.6 Sol. The thread processed more than 621 million tokens during Build Week; 97 percent were cached context, so this is telemetry rather than an API-spend claim. The audited metric ledger links every figure to its source and states the limits on its interpretation.

Evidence

The current release includes:

• 264 automated tests passing across the dataset pipeline and application;
• a successful production Vite build;
• a public Playwright journey with real Gemma inference, both roles, WebSockets, Beacon, reformulation, the human channel, return, myth expansion, export, and desktop/mobile layouts;
• an abbreviated end-to-end benchmark completing all 18 state transitions and correctly classifying all four directly verifiable branches;
• versioned model, adapter, dataset, benchmark, screenshot, and Codex provenance manifests.

The repository records the pre-event baseline, the Build Week commit history, the Codex thread identifier, runtime-reported models, and hashes of the evidence artifacts without publishing private conversations or expert source material.

Current limits

PsicopoMPo is a supervised research prototype, not an autonomous therapist or diagnostic system. The facilitator remains responsible for the session. Intervention selection is not solved: the decision adapter can still choose a suboptimal tool even when the contextual executor produces a relevant response. Myth expansion can also formulate hypotheses that require human review. We preserve those limits in the evidence rather than presenting integration success as clinical validation.

Built With

• fastapi
• gemma-4-e4b
• gpt-5.6-sol
• openai-codex
• peft
• playwright
• pytorch
• react
• websockets