Operations

Inspectable Infrastructure

The infrastructure surface answers a practical question: what happened to a request, where did it run, what did it use, and can the result be trusted? The API, SDK, and CLI expose the same status model so a developer can move from a local test to a deployed service without changing the meaning of telemetry.

Partly available.

The memory routes are available on the reference runtime, which stores text and ranks recall by word overlap without running a model. The infrastructure routes are part of contract v1 but are not served yet, so calls to them return an error. The HTTP reference shows each route's status and is updated as routes ship.

The request path

1. Verify

Resolve the API key or session, tenant scope, role, and request identity.

2. Authorize

Check route permission, storage attachment, consent, rate limits, and simulation policy.

3. Execute

Run the enabled memory operation. The current hosted path provides deterministic text persistence, lexical retrieval, stored-text rendering, deletion, or an explicit contract fixture.

4. Record

Persist request, provenance, operations, usage, charge state, anomaly inputs, and audit information.

5. Respond

Return a stable response envelope with request ID, state, retryability, and operation-specific fields.

A control-plane operation such as listing keys uses the Mind Platform routes. A data-plane memory operation uses the memory contract. Infrastructure routes report the state of both paths without giving a caller a way to invent tenant scope.

Runtime modes and capability truth

Do not infer implementation from a command name or a successful HTTP status. Read execution_mode, provider, model_version, and capability_status from the response. The capabilities endpoint is the source of truth for what the deployment can currently execute.

Field	What it answers	Reference example
`execution_mode`	Which runtime path accepted the request.	`mock`
`provider`	Which runtime provider produced the response.	`mpalo-local-mock`
`model_version`	Which implementation version was attributed.	`deterministic-lexical-v1`
`capability_status`	Whether the result is a live capability, contract fixture, or unavailable operation.	`contract_fixture`

The health response repeats the deployment identity as provider, model_version, deployment_version, and environment. This makes a direct readiness check self-describing instead of requiring a second status request to identify which runtime answered.

An unspecified model variant means that no model was invoked for that operation, such as deletion or an explicit offline fixture. On the hosted backend path, model-dependent stages are reported as a deterministic substitution in provenance.execution. It is not a hidden model selection. When a learned model executes, its variant and measured operation units belong in provenance and usage.

Capability status

The deployment status and the API contract are related but not identical. A response shape can exist before the implementation it describes. Check the capability status before treating a field as evidence of model execution.

Capability	Status	Current evidence
Text persistence	`available_mock`	Submitted text can be retained after storage, consent, and policy checks.
Lexical retrieval	`available_mock`	Deterministic tenant-scoped ranking over retained text.
Stored-text rendering	`available_mock`	Selected retained text can be returned as context.
Embeddings and vector search	`not_deployed`	No customer-facing vector representation or index is attached.
Traversal and mapping	`contract_stage`	Response and attribution shapes exist for wiring, not learned behavior.
BYO storage execution	`control_plane_only`	Connections can be configured, but memory requests do not dispatch to them.
Mpalo-managed external LLM	`not_available`	The integration route is disabled. Applications manage downstream models.
Physical inputs	`research`	No public capture, subject-consent, or safety contract exists.

Memory operations

The v1 infrastructure contract covers the current memory path used by the SDK and CLI. Write returns the retention decision and representation status. Recall returns related retained records, a rendered context when available, and the ranking basis. Delete reports the affected namespace and retained state. Traversal and mapping have contract-stage fields for compatibility, but are not learned capabilities in the current runtime.

Recall

Find related memories and return the retrieval outcome.

Traversal

Follow related memory structure when the runtime enables it.

Mapping

Relate memory representations to the operation that produced them.

curl https://api.mpalo.com/api/v1/infrastructure/status \\
  -H "Authorization: Bearer $PALO_API_KEY"

palo infra status
palo infra health
palo infra metrics
palo infra anomalies

Deterministic status fixture:

Health, metrics, anomalies, and events

Use health for service availability and deployment metadata. Use status for the combined snapshot. Use metrics or usage for measured request quality and ledger state. Here, request quality means request count, errors, timeouts, latency percentiles, and blocked rate. Use anomalies for thresholded signals. Use events for redacted history and pagination. These views share a backend record but answer different questions: health describes readiness, metrics aggregate request history, anomalies interpret thresholds, and events preserve individual operational records. A saved browser session is sufficient for these read-only inspection surfaces. Memory writes, recalls, and deletion require a customer API key attached to an active Palo Managed Memory connection. A configured BYO connection is rejected before the current runtime can touch data or ledgers.

Surface	CLI	Use it when
Capabilities	`palo infra capabilities`	You need to discover enabled operations and declared limitations before calling.
Health	`palo infra health`	You need to know whether required services and storage are reachable.
Metrics	`palo infra metrics`	You need deployment attribution, latency percentiles, request quality, and operation mix.
Anomalies	`palo infra anomalies`	You need thresholded signals with severity, observed value, and threshold.
Events	`palo infra events --limit 100 --offset 0`	You need redacted request history beyond the first page.
Export	`palo infra export`	You need a JSON snapshot for an incident, audit, or offline analysis.

Events are paginated. The default page is limited for terminal safety. Increase --limit up to the API maximum, use --offset for the next page, or request JSON and paginate in a script. The CLI interactive view supports keyboard navigation where a full-screen event browser is available. Automation should use JSON rather than scraping designed terminal output.

Usage and billing are part of the infrastructure path

An operation is not complete from an infrastructure perspective until its usage and billing state are explainable. The request record is the source for accepted calls. Operation records explain units. Charge records explain recorded, invoiced, unbilled, or void state. Pricing is resolved at request acceptance and must remain attributable to its pricing version.

Model substitution, real service path.

The current backend substitutes only model-dependent Palo Bloom computation. Storage, usage metering, charge records, and observability still run through the service path. Simulated-model charges are recorded against the versioned ledger and settle only in the configured Stripe test environment. A response with no operation units means that no billable model operation was measured for that request.

palo infra usage --lookback-minutes 15 --json
palo mind usage summary --json
palo mind billing subscription --json

Readiness and declared limitations

Limitations should be returned by the deployment capability and status contract, not treated as permanent folklore in a client. A client may present them in a friendly design, but it must preserve the machine-readable values. When the runtime changes, its provider, version, capabilities, limitations, and readiness state change together.

Readiness signal	Interpretation
`available: true`	The required service answered the health check. This does not prove model quality or billing readiness.
`state: no_data`	The selected window has no measured records. It is not the same as a healthy zero-volume production period unless the window and source are known.
`anomaly_count: 0`	No configured signal crossed its threshold in the selected history. It is not a security or correctness guarantee.
`production_ready: false`	The documentation or deployment is not authorized to represent itself as public paid production.

For a release review, record the status snapshot, contract version, deployment version, schema version, test results, and database health result together. A green reference smoke test is valuable for wiring and regression detection. It is not a production launch gate by itself. Read Evaluation and capability evidence for the promotion boundary and the evidence required before a model-dependent claim changes status.

Was this page helpful?

Your feedback helps us improve our documentation.