Skip to content

In development

Palo Bloom

Palo Bloom is Mpalo's experience-aware memory architecture. It is intended to help applications represent and retrieve experience across interaction, identity, and time. The architecture is not the same thing as the current customer runtime.

Current implementation

Mpalo currently operates an early text-memory runtime with durable submitted-text persistence, deterministic lexical retrieval, stored-text context rendering, deletion, and inspectable usage. The hosted path uses mpalo-local-mock and deterministic-lexical-v1. It does not execute a Palo Bloom model, produce customer-facing embeddings, or perform semantic vector search.

For the public product overview and broader direction of Palo, read Meet Palo.

Architecture direction

The research architecture explores a learned representation and decoding system closer to a modified variational autoencoder than to a wrapped conversational model. The intended system separates the representation of an event from the value later rendered for an application. It may also represent episodic structure, temporal relationships, and context across events.

Recall

The current runtime provides lexical retrieval. Learned semantic recall is a research question.

Traversal

The API can represent a future stage. A learned episodic traversal capability is not deployed.

Mapping

The API can report attribution for testing. A learned memory map is not deployed.

What the API can show

A memory write returns a retention state, representation status, provenance, and usage state. In the current hosted reference path, model-dependent representation and ranking are simulated, and the retention decision does not evaluate learned surprise or salience. A recall returns lexical candidates and may render selected stored text as context. It does not claim a semantic similarity score.

Response signalCurrent meaning
execution_mode: mockThe deterministic service fixture accepted the request.
provenance.execution.modelsimulated means only model-dependent work is substituted. not_invoked means no model stage ran.
representation.status: not_availableNo customer-facing embedding or learned representation was produced.
score_kind: mock_lexical_overlapCandidate ranking used lexical overlap rather than model confidence.
capability_status: contract_fixtureThe response shape is exercised for compatibility, not proof of the intended capability.

Storage, models, and data boundaries

Managed storage
The current reference path can retain submitted text after storage and consent checks. This is storage and retrieval, not training.
BYO storage
Mind can represent a custom connection. Runtime execution against customer storage is not deployed.
Downstream model
The application can use returned context with its own model. Mpalo does not provide that downstream response in this v1 path.
Managed external LLMs
Mpalo-managed external LLM connections are currently unavailable. Re-enabling them requires provider, legal, privacy, billing, and security controls.

The current reference runtime does not train or employ Palo Bloom and does not perform aggregate learning. It is a deterministic fixture for testing the API, SDK, CLI, usage ledger, and operational surfaces.

What must be proven next

Bloom moves from architecture direction to product capability only when a reproducible evaluation shows what the model executed and how it behaves. The evidence must cover representation version and dimensions, separate stored values, retrieval and rendering quality, latency, cost, tenant isolation, correction, deletion, failure behavior, and model artifact provenance. Learned behavior must be compared with lexical, random, untrained, and simpler baselines under the same context budget.