Reference

Data boundaries and provenance

A memory request has more than one kind of state. This page explains the boundary between submitted input, retained memory, derived representation, operational records, usage, billing, and model execution so that a successful response is not mistaken for a claim the service cannot prove.

Current runtime.

The hosted customer path is a production-shaped deterministic mock. It authenticates, checks storage and consent, persists eligible text, performs tenant-scoped lexical retrieval, records usage and test-environment billing, and exposes redacted observability. Only model-dependent computation is substituted. It does not execute a learned Palo Bloom model or perform aggregate learning.

Input, identity, and scope

The API accepts text memory events or recall cues together with a namespace, idempotency key, event time, and bounded metadata. The server derives tenant and user scope from the verified credential. Client-supplied identity fields cannot widen that scope.

Boundary	Current behavior	What it does not prove
Authenticated caller	API key or supported session boundary is verified before the route proceeds.	That the caller is the person described by a memory event.
Memory subject	Not separately modeled in the v1 event contract.	Consent or authority from a person represented in submitted text.
Namespace	Separates application data within the verified tenant scope.	A security boundary by itself. Credentials and server scope remain authoritative.
Idempotency	Replays can return the original accepted result without a second memory or charge.	That a different request with a different key describes different real-world facts.

Storage and representation

An active storage connection and private-memory consent are prerequisites for managed memory operations. The current managed adapter retains submitted text for the documented scope. BYO storage connections can be represented in Mind Platform, but v1 memory operations do not execute against them.

Retained text

Submitted text accepted by the managed path after authentication, storage, consent, and policy checks.

Representation

No customer-facing semantic embedding is created by the current v1 mock path. Dimensions are not available.

Retrieval

Deterministic lexical ranking over retained text. The score is not vector similarity or model confidence.

Downstream model

The application may pass returned context to its own model. That model is outside Mpalo attribution for the current contract.

See Storage and providers for the control-plane and future adapter boundary.

Caller-attested event provenance

A write may include event.source with an origin type and optional opaque source ID. This lets an application distinguish direct input, imports, generated summaries, and future device events. The declaration is carried through the current runtime, export, SDK, and CLI, but Mpalo does not independently verify it.

Field	Meaning	Limit
`source.type`	The submitting application’s declared origin category.	One documented v1 enum, including `direct_user_input`, `imported_archive`, `external_application`, `model_inference`, or `sensor_or_device_input`.
`source.id`	An optional opaque source identifier for correlation.	At most 255 characters. Do not place raw text, secrets, or credentials here.
Verified identity	Tenant, user, organization, and API-key scope derived by the service.	Cannot be replaced by source metadata or a caller-provided identity.

Source provenance is not a consent record, authorization decision, person identity, verified fact, or proof of provider processing. The full application, actor, subject, authorization, inference, and source-verification model remains planned.

Operational records, usage, and billing

The backend keeps specialized records for request history, measured operation units, charges, and platform activity. They share request correlation but have different purposes.

Record	Contains	Current boundary
Memory state	Retained text, memory identifiers, event time, supersession state, sanitized metadata, and source metadata.	Tenant and user scoped. Removed by the documented memory deletion operation.
Infrastructure event	Request correlation, operation, scope, status, model attribution, consent, latency, retry, and redacted metadata.	Does not contain submitted text or raw request bodies.
Usage event	Accepted customer activity and measured request quality.	Source of request volume and operation attribution for the selected period.
Charge event	Operation, quantity, pricing version, billing environment, and charge basis.	Test-environment charges are recorded in the mock pilot. Offline SDK fixtures create no charge.
Alert delivery	Safe anomaly signal, channel, delivery status, attempts, and delivery timing.	Pending work remains available for delivery and investigation. Terminal delivery rows are pruned after 90 days. Memory deletion does not remove the anomaly or billing history.

A model-only substitution can therefore be present inside a backend request that still records durable storage, metering, billing, and observability. An unspecified or not-invoked model means no model-dependent stage ran for that operation.

`data_policy` in an operation response

The response also carries a versioned data-boundary receipt. It describes what happened to this operation, not who authorized it and not whether the model output was learned.

Field	Current value or meaning
`input`	`submitted_text` for write, `recall_cue` for recall, or `none` for delete.
`private_memory`	`retained`, `read`, `deleted`, or an explicit blocked state.
`derived_representation`	`not_created` in the current v1 mock. No customer-facing semantic embedding is produced.
`operational_record`	`retained_redacted` on the backend path. The explicit SDK fixture reports `not_recorded`.
`aggregate_learning` and `external_processors`	`not_staged` and an empty list in the current runtime. No external processor is attached.
`deletion`	States whether private memory was removed and whether operational history remains.

Export and deletion

The current infrastructure export returns retained private-memory records, recorded supersession relations, consent history, and redacted operational history for the verified scope. Private-memory deletion removes retained memory, supersession relations, and idempotency state for the requested namespace. The minimum redacted operational history remains for billing, security, and operational accountability. Anomaly records and alert-delivery history are separate operational records and are not removed by memory deletion.

Scope matters.

This is not a universal export or a cryptographic proof of erasure across every future provider, cache, backup, or account system. The current runtime does not offer customer-controlled encryption keys. Read the applicable policy and contract for legal retention requirements.

Not available in the current contract

These subjects require a new implementation and evidence. Their names in Mpalo architecture or research materials do not make them active API capabilities.

Subject	Status	Required before promotion
Semantic embeddings and vector search	`not_deployed`	Versioned representation, dimensions, metric, portability, isolation, deletion, and evaluation.
BYO vector execution	`control_plane_only`	Allowlisted adapters, credentials, transient-data rules, timeouts, partial failure, deletion, and billing.
Managed external LLMs	`not_available`	Provider, privacy, terms, subprocessor, liability, secret, billing, and security controls.
Learned surprise, traversal, mapping, and personalization	`contract_stage` or `research`	Model evidence, provenance, correction, conflict, consent, deletion, and measurable quality.
Multimodal, physical, and robotics inputs	`research`	Modality-specific consent, subject handling, provenance, retention, failure, and safety contracts.

The capability registry is the source of current status. The internal implementation plan remains in the repository and is not a public promise.

Was this page helpful?

Your feedback helps us improve our documentation.