permixaDocs

PERMIXA DOCUMENTATION

Recovery & troubleshooting

Preserve evidence first. An uncertain payment is not permission to send again.

Sign-in or dashboard problems

  • No account: the demo is invite-only. An administrator must provision access.
  • MFA required: complete your own enrolled authentication ceremony. Never share the code or let an agent substitute for you.
  • Failed to fetch: reload once and check that you are at the expected demo hostname. If it persists, report the time and page without credentials. Do not repeatedly submit a payment.
  • Some conversion details unavailable: the dashboard may load its core records before optional evidence. Unavailable details do not mean no transaction occurred.

Signer not ready

Wallet connected, but spending disabled: the ownership proof only associates an account with your agent. Check its separately enrolled execution source and local spending permission. Budget succeeds, but no purchase tool: call permixa_connection_status in connector 0.2.0 to inspect local settings. The connector is read-only unless purchases and exact resources are configured. This diagnostic does not verify credentials, funding or Signer health. Restart an existing agent session after a reviewed connector update to refresh tools. Missing API key: hosted access uses a saved dedicated connection; use its recovery instructions or assisted setup, not legacy key replacement.

Inspect read-only local status and readiness output. Check enrollment, credential expiry, exact organization, network, local policy and wallet availability. Do not weaken a hard limit to get past an unexplained denial.

For Bitcoin Core initial block download, allow local validation to complete under the operation's preflight requirements. An explorer may provide advisory information; it does not replace authoritative local wallet checks.

If a passphrase or recovery reference is missing, inspect configured secret-file or secret-manager references without displaying values. Do not overwrite the wallet or reset its journal. Recovery depends on the customer's wallet-specific backups.

Stop new execution safely

The customer-local emergency lock disables automated execution without moving wallet funds. Use the reviewed local CLI and its configured data directory. Unlocking requires the separate authorized local administration workflow.

Revoking an agent key stops new requests, but does not cancel already-authorized work. The dashboard's Signer enrollment listing is not an emergency-lock control.

When signing or submission may have happened

Reconciliation only.

Preserve the operation, authorization, journal and transaction identity. Do not re-quote, create replacement authority, sign again, rebroadcast as a retry, or create a second source payment.

  1. Read the customer-local journal without modifying it.
  2. Query the recorded transaction on the exact network.
  3. Query the existing provider transfer identity where relevant.
  4. Compare destination receipts and accounting evidence.
  5. If safe progress is unavailable, report the exact blocker and needed recovery action.

A terminal refund is different from successful destination delivery. Preserve both the original source and refund evidence. Never manually patch financial state to make the dashboard look complete.

What to include in a support report

Share the time, test network, public operation/intent/transaction IDs, visible state and redacted error. Exclude API keys, MFA codes, wallet passwords, mnemonics, signed payloads, macaroons and preimages.

If Permixa is unavailable, governed automation fails closed. Wallet funds not committed to a transfer remain accessible through the customer's own wallet tools, not a Permixa-held recovery key. Funds in an in-flight conversion may already be at a provider vault; follow the recorded transaction and provider recovery path rather than assuming they are still in the source wallet.

For completed capabilities, assisted setup and remaining work, see the current roadmap.