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.

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	Mock 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`

An unspecified model variant in a mock response means no Palo model executed. It is not a hidden model selection and it must not be billed as model usage. When a deployed 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. 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.

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.

Mock billing.

The mock runtime can exercise ledger aggregation with sandbox records. No live customer charge should be inferred from a mock response. 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 --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 mock smoke test is valuable for wiring and regression detection. It is not a production launch gate by itself.

Was this page helpful?

Your feedback helps us improve our documentation.