Reference Guided Tasks

Guided tasks

Open Guided tasks in the Panel Help area to search for an available task. Read its steps, supply the required inputs, run a step, confirm manual actions, and use Undo completed actions for reversible operations. Your progress is saved to your signed-in account.

Overview, navigation and help

Serve your first model

Set up access, download a file, create and start an instance, verify health, then open Chat.

This task requires administrator permissions.

1. Set up the administrator — On a new install, complete the one-time setup page and sign in as administrator; existing installations can skip this step.
2. Download a model — Submit the exact file URL to the existing download owner; a queued download is not yet a completed file.
3. Verify the local model — Wait for the download to finish, then refresh the model library; do not continue until a model file is listed.
4. Create an instance — Bind the chosen local file, installed engine, device, backend and port. Creation does not start the process.
5. Confirm starting — Starting a runtime allocates compute resources. Confirm that the correct model and instance are selected.
6. Start the instance — Send the start request to the existing instance owner; an accepted request is not a health check.
7. Confirm runtime health — Refresh until the instance reports that it is running and its health status is ok; a process identifier alone is insufficient.
8. Open Chat — Select the running instance in the conversation workspace and send a message.

Find any Panel feature

Search feature names, routes, help text, and commands, then open the linked page.

1. Open feature discovery — Search the complete feature registry by term, route, page, or command.
2. Check registration — The registry API returns the same records used to render tooltips and links.

Instances and launch parameters

Serve a model on your chosen GPU or CPU

Review devices, create an instance, choose a model and start it with real admission checks.

This task requires administrator permissions.

1. Inspect available devices — Read reported GPU identifiers and host CPU before choosing a device.
2. Review the new instance — Preview the chosen engine and device; this never launches the model.
3. Approve instance creation — Creation writes a separate instance directory; verify the identifier and memory budget.
4. Create with defaults — Use the existing instance owner to create the chosen device-backed instance.
5. Select the new instance, its model and limits — Select the newly created instance in Instance controls, then open Launch parameters to choose an installed model and save its parameters before starting service.
6. Start serving — Starts the selected instance after configured admission and available-memory checks.

Measure coding or agentic performance and apply a profile

Measure trials, inspect quality, save a winner and apply it with rollback-aware configuration.

This task requires administrator permissions.

1. Inspect goal and budget choices — Read supported optimizer goals before using compute time.
2. Approve measured trials — Trials may restart inference multiple times and will restore saved settings at the end.
3. Run optimization — Start actual launch, context, sampling and specification trials; no result is applied automatically.
4. Examine completed trial evidence — Wait for measured candidates and quality margins; select only a completed, validated candidate.
5. Save measured result as a named profile — Save the chosen candidate to a reusable profile; do not change the running instance yet.
6. Review winning profile before activation — Inspect saved parameters and launch costs before changing the running service.
7. Approve applying the profile — Applying a winning profile updates saved configuration and may require a safe restart.
8. Apply measured profile — Apply the measured candidate to saved parameters with a durable rollback journal; restart separately when required.

Drain and restart without abruptly dropping requests

Configure gateway hold and drain, verify the replacement and inspect the outcome.

This task requires administrator permissions.

1. Inspect instance and running traffic — Verify that the selected instance is the one to restart.
2. Configure hold, drain and verification — New requests are held and active requests have a bounded grace period; verification adds delay. The settings replace the previous settings until changed again.
3. Approve traffic hold — Bounded holds and drains reduce risk, but cannot guarantee that every client survives a timeout.
4. Start safe restart — The canonical restart owner drains, holds and verifies the new process, rolling back when required.
5. Inspect restart outcome — Read actual restart evidence before claiming availability; a started job is not proof of a clean restart.

LexiChat

Start a chat with a document and instructions

Upload one private document, create a saved conversation with instructions, then select a running model to send the first message.

1. Upload and create conversation — Store the document privately and create a saved conversation with instructions and its file reference.
2. Choose a running model and send — Open the new conversation by its returned ID, choose a running model, and send the first question.

Safely prune expired chats

Inspect retention policy, preview eligible saved conversations, and confirm deletion.

This task requires administrator permissions.

1. Review retention policy — Ensure retention days is not zero and reflects the desired age threshold.
2. Dry-run candidate scan — Count eligible saved conversations without deleting anything.
3. Confirm destructive action — Review the candidate count; deleting expired saved conversations cannot be undone.
4. Apply retention — Run the existing validated retention owner after explicit confirmation.

Models, downloads and library

Download and verify a model

Fetch the exact artifact, inspect transfer verification, then refresh its library entry.

This task requires administrator permissions.

1. Review source and digest — Check the link points directly to the artifact and compare the digest and byte size with a trusted source.
2. Start checked transfer — The registered download owner stages the file and will refuse mismatched bytes.
3. Inspect SHA-256 result — Reload transfer status until the exact job is done and its verified field reports SHA-256; never infer verification from the queue response.
4. Inspect model in library — Refresh the inventory and check the new artifact and its provenance before selecting it.

Import verified model from another disk

Copy from a mounted volume, poll the exact job, then check the published library artifact.

This task requires administrator permissions.

1. Prepare offline source — Mount the second disk using the system storage tools; copy only a trusted regular GGUF and obtain its digest independently.
2. Authorize copy — The original disk remains unchanged; any digest mismatch refuses publication.
3. Copy and verify — Begin the registered asynchronous import to an unused model filename.
4. Poll exact import job — Paste the returned job ID and check that status is done and verified is true; a running response is not completion.
5. Review library artifact — Confirm the file and provenance in the library after the job has finished.

Use verified-only mode and admit a model

Require verified provenance, then verify and register an already-local GGUF.

This task requires administrator permissions.

1. Enable verified-only inventory — Unverified files disappear from model listings until their exact provenance is admitted.
2. Check the local file — Use the upload or offline-import controls to put a regular GGUF in the models directory, then independently verify its source digest.
3. Admit exact bytes — The registered owner reads and hashes the file, checks size and magic, and only then writes verification provenance.
4. Inspect verified inventory — Refresh and check admission is reflected in the library listing.

Fit lab

Fit a model to this GPU

Explain, plan, calibrate, build, evaluate, and use a smaller GGUF.

This task requires administrator permissions.

1. Inspect Fit readiness — List sources, conversion tools and calibration requirements before work begins.
2. Explain the existing GGUF — Inspect tensor types to understand which source and calibration data must match.
3. Inspect the target GPU — On the Fit lab, review the selected instance and its free memory, not an assumed card capacity.
4. Create plans — Generate estimated plans for speed and precision, then inspect the saved plan IDs.
5. Review and build — Check the selected plan, optionally capture an importance matrix and confirm the new output before starting a build.
6. Verify measured quality — Compare on-device behavior and run a held-out CPU KLD evaluation; only measured results may be accepted.
7. Use the candidate — Save its instance profile and review it in Parameters before activating the model.

Replicate a published recipe

Recover a layout, check source and calibration, rebuild, then verify.

This task requires administrator permissions.

1. Find the recipe — Inspect the built-in or imported recipe list and its calibration requirements.
2. Explain source layout — Recover tensor-specific format choices from the published GGUF and matching source.
3. Import the published recipe — Validate and save the published JSON. The newly saved recipe can be undone by deleting that same ID.
4. Review recipe and importance matrix — Check that recipe metadata, the original revision and the importance matrix match.
5. Dry-run the selected recipe — Check the quantizer's proposed tensor layout without creating output.
6. Build the replica — Confirm the name, calibration file and compatibility warning, then build a new file.
7. Validate fidelity — Run the same held-out evaluation on both artifacts and compare measured KLD.

Benchmarks, evals and engine tools

Benchmark fairly against the newest reference build

Install and identify the current reference build, confirm both endpoints are idle, then run repeated paired tasks and review confidence bounds.

This task requires administrator permissions.

1. Inspect endpoint inventory — Find the two installed, reachable endpoints. Verify model, quantization, context, backend and exact build versions outside the score.
2. Review measurement controls — Check idle hardware, cache policy, prompt seed and power limits; the endpoint owner does not independently attest all parity settings.
3. Run paired comparison — Run at least three rounds with the same graded task pack; result is only a measurement, not a release gate.
4. Read evidence — Refresh status and examine actual sample counts, confidence intervals, failed requests and endpoint identity.

Measure a decode depth curve

Use an idle running instance and collect multiple decode measurements at specified context depths.

This task requires administrator permissions.

1. Inspect baseline curves — Review the existing curve; note any active workloads or missing depth buckets.
2. Check idle state — The active instance must answer its status and slots probes before measurement starts.
3. Start three repeated depth measurements — The curve owner refuses busy hosts; stopping preserves any partial evidence.
4. Inspect depth-by-depth result — Refresh the curve until its owner records a final status; do not replace missing buckets with estimates.

Plan a model launch for this hardware

Probe a model, inspect available runtimes, preview a launch and estimate hardware fit without changing the running server.

This task requires administrator permissions.

1. List capabilities — Read the installed inference runtime inventory.
2. Probe and inspect model — Use the model-probe form to inspect the file and select an installed runtime.
3. Preview the launch — The plan returns an executable and argument array but never starts a process.
4. Review memory and device estimates — Supply actual hardware capacity on the tuning form and inspect warnings and proposed settings.

Run a local engine benchmark

Measure a local GGUF with warmup and three repeats; examine the saved JSON and check uncertainty before comparing.

This task requires administrator permissions.

1. Check host and model — Verify the model is on local storage and competing work is paused.
2. Start a bounded engine job — Runs the selected engine command without an operator shell and saves the measured output.
3. Inspect results — Check the job status, failures and JSON rows before drawing any performance conclusion.

Profile and calibrate a running instance

Review whether the server is idle, profile saved settings, then inspect the evidence and measured noise.

This task requires administrator permissions.

1. Inspect active work — Check active work and stop conflicting jobs before using the server slot.
2. Inspect form choices — Choose an instance, preset, repeat count and response interruption policy.
3. Start reproducible profile — The owner refuses a busy or unavailable server; profile does not request a restart.
4. Review actual saved results — Wait for the owner to finish. Check medians and intervals before changing any settings.

Check behavior across endpoints

Inspect available endpoints, run real interoperability checks and review the saved check matrix.

This task requires administrator permissions.

1. Check available endpoints — Read the live inventory to find an actual endpoint ID.
2. Review selected endpoints — Confirm the endpoint is reachable and safe to test without disturbing users.
3. Start endpoint checks — Submit one selected endpoint to the real specification-test owner.
4. Review behavior check results — Read the owner's per-feature checks and failures; a successful capability check is not a speed verdict.

Review and compare qualification evidence

Read the qualification inventory, export exact saved evidence, and compare two records using the owner.

This task requires administrator permissions.

1. Read saved qualifications — Check provenance, integrity state and missing identity before promoting a claim.
2. Select evidence — Open the qualification page to select record IDs and export originals.
3. Review owner comparison — Submit two IDs on the qualification page and inspect the owner's result; unverified evidence stays unqualified.

Builds and engines

Install a release and serve a model

Inspect an upstream archive, stage and verify it, then create and start a model instance after choosing an active build.

This task requires administrator permissions.

1. Inspect offered releases — Confirm that a compatible release is listed; an offline response is not a successful catalogue.
2. Approve a download — Inspect the published size and digest; a size-only download is not a verified archive.
3. Stage the release — Start the registered installer; its response identifies the live download job.
4. Wait for verification — Check that the job says ready and records its verification evidence; do not start an incomplete build.
5. Select the ready build — Activate the verified build for the next start in the Builds tab; existing servers are not restarted.
6. Create the serving instance — Create a separate instance for the selected model and exact execution device; start only when the build is ready.
7. Start the serving instance — Request an instance start; a positive response acknowledges the launcher request, not a measured running process.
8. Verify the model is exposed — Inspect the gateway model list; this list alone does not prove that inference is answering, so test the new instance in chat.

Add an engine to a media instance

Inspect engine availability, stage a supported media build and create a separately managed instance.

This task requires administrator permissions.

1. Inspect engine catalogue — Check installed builds and available flavours first.
2. Approve engine installation — Only select a published engine release matching the chosen backend.
3. Stage engine build — Start installation through the registered engine owner and track the job ID.
4. Verify the installed engine — Inspect job completion and executable capabilities before creating an instance.
5. Create the media instance — Create a separate media instance without starting or replacing any existing instance.
6. Serve and check the media instance — Inspect the instance launch plan, choose an installed model and test the matching media route after starting.

TokenGate

Import and bind a checkpoint

Convert checkpoints and attach the resulting adapter.

This task requires administrator permissions.

1. Import — Convert and validate both checkpoints.
2. Review output — Check the job result before selecting the new adapter.
3. Use in instance — Bind the verified adapter using the instance configuration.

Train a gate on local data

Start training and inspect the adapter.

This task requires administrator permissions.

1. Train — Start training on local rows.
2. Review training — Verify that training finished and inspect its artifact.

Compare gated and ungated

Compare accuracy and latency using real served inference.

This task requires administrator permissions.

1. Evaluate — Run evidence-checked served comparisons.
2. Inspect results — Check accuracy and time to first token in the report.

Decisions and DLM strategy

Train, verify, select and use a D3 yes/no head

Stage a head from real captured features, independently evaluate it, select by exact digest and run a bound reference decision.

This task requires administrator permissions.

1. Open candidate inventory — Confirm a managed resident engine and read its durable revision and candidate list.
2. Train a yes/no candidate — Supply captured binary-label features, an independent capture digest and split seed; this only stages an unqualified candidate.
3. Re-evaluate independent data — Compute held-out accuracy, loss and sample count from persisted captures, not from the training examples.
4. Select exact artifact — Verify the exact artifact digest and current revision, then explicitly type PROMOTE; engine-side checks may refuse.
5. Run the selected head — Submit a typed yes/no question with a fresh code seed through the live selected binding, then inspect probabilities.

Calibrate decision mode and check the quality gate

Fit independently identified label samples, compare against full-text output, and evaluate deployability.

This task requires administrator permissions.

1. Check capabilities — Inspect supported typed tasks and calibration requirements.
2. Fit a calibration profile — Provide four or more labeled training and holdout examples with distinct stable source identities, then review saved profile binding.
3. Compare full text — Record real paired answers and agreement observations for the named profile.
4. Evaluate the quality gate — Evaluate deployment floors against the persisted independent validation and comparison evidence.
5. Inspect persisted result — A returned result can be a failed gate; only an explicitly passing gate permits calibrated deployment.

Review, approve, activate and deactivate a strategy

Propose from measured paired evidence, ask an independent administrator to approve, activate with launch authority, then deactivate.

This task requires administrator permissions.

1. Inspect strategy status — Confirm the experimental strategy service is available; the read does not change runtime.
2. Propose measured candidate — Submit paired case-by-case performance and non-inferiority evidence bound to the actual model, hardware and configuration.
3. Independent review — A different administrator must supply verified signed capture receipts; the proposer cannot self-approve.
4. Confirm launch request — Activation changes the experimental launch authorization and requires explicit consent and live owner authority.
5. Activate the reviewed strategy — Apply only the independently approved current proposal through the real launch owner.
6. Deactivate after the experiment — Return the instance to normal strategy selection and verify the live owner state.

Training

Fine-tune a LoRA, evaluate it and deploy

Choose managed inputs, start a low-rank training job, wait for a verified receipt, measure held-out loss, and attach the adapter to a compatible instance.

This task requires administrator permissions.

1. Confirm data and resource use — Verify that your local data may be used and that training will consume resources.
2. Start LoRA training — Create a managed low-rank run with held-out examples and durable checkpoints; the response supplies the run ID.
3. Wait for a verified finish — Refresh the native run record until its state is done; a missing receipt, failure or active worker must not advance.
4. Verify native receipt — A completed run without a bound native receipt must not advance to evaluation or deployment.
5. Evaluate the trained checkpoint — Select a verified managed checkpoint from Training to measure the trained adapter on held-out examples.
6. Confirm instance restart — Attaching the verified adapter restarts the selected instance and may interrupt inference.
7. Deploy the verified adapter — The existing controller verifies the receipt, model identity and LoRA format before restarting the instance.
8. Review the attachment — Verify that this exact adapter is still attached to the selected instance and inspect the live report in Training.
9. Inspect final progress and results — Review the recorded run, loss, export evidence and instance state.

Lexify a model on its instance

Select a compatible instance, launch bounded local measurements, wait for a complete job with receipt evidence, and inspect qualified candidates.

This task requires administrator permissions.

1. Confirm bounded measurement — The search may restart local inference and does not automatically deploy its findings.
2. Start local Lexification — Use the normal eligibility gate and topology-verified route to create a separate local job.
3. Wait for completed measurements — Recheck the durable job; unfinished searches keep this step open.
4. Check recorded receipts — A completed search without a qualifying receipt cannot be treated as validated.
5. Inspect exact receipt evidence — Compare measured candidates and verify local hash binding before considering a separate apply action.

Inference fabric

Register two workers and plan a deployment

Register two worker snapshots, inspect heartbeat state and plan two replicas without launching them.

This task requires administrator permissions.

1. Register the first worker — Record the first worker's advertised snapshot. A registry entry does not start a process.
2. Register the second worker — Record another independent worker using a separate endpoint.
3. Inspect heartbeats and worker state — Read the registered worker list from the real state route before planning capacity.
4. Plan two replicas — Calculate where replicas fit using operator-supplied representative device slots, not measured live memory.

Find a prefill bottleneck and apply a routing hint

Attribute request latency, confirm a verified cached prefix, advertise it and inspect scheduling.

This task requires administrator permissions.

1. Attribute the slow request — Check the real telemetry route; stop if prompt processing is not the largest contributor.
2. Apply a cache-locality hint — Record the verified cached prefix on a ready worker; this changes routing metadata, not the worker's cache.
3. Check routing after the change — Ask the real scheduler to consider this cache hint with registered workers; a plan never sends a request.
4. Inspect updated worker state — Confirm the cache metadata is visible; check real response times separately before claiming improvement.

Files, terminal and passwords

Upload a model into the library

Use the guarded file manager to place a model in the models folder and verify its presence.

This task requires administrator permissions.

1. Prepare the models folder — Open Files and select Models. Create the folder if missing, using Create folder in the writable home area.
2. Check the destination is unused — Refuse to proceed if a file with this name already exists, so undo cannot delete a pre-existing file.
3. Stream the selected model — In Files, upload the local model file to models without replacement, then confirm the browser upload result.
4. Verify the imported file — Check the real home-rooted listing for a regular file with this exact name; reject links, directories and out-of-home entries.

Store and copy a secret

Unlock a personal store, save an encrypted entry, then copy without displaying the secret.

1. Unlock your store — Use Passwords to unlock with your account password; the guide never records that password.
2. Save the encrypted entry — Save the provided secret in the current user's encrypted store. A new random entry identifier is returned.
3. Confirm stored metadata — Confirm that the store can list entry metadata without exposing any saved secret.
4. Copy without displaying — Find the new entry on Passwords and select Copy secret; check the secure clipboard result, then lock when finished.

Network, firewall, users and access

Issue and later rotate a client token

Review scoped credentials, create a least-privilege secret and rotate it when the client is updated.

This task requires administrator permissions.

1. Review existing tokens — Check for an existing credential before issuing a new one.
2. Create client credential — Copy the secret immediately; its plaintext cannot be retrieved later.
3. Rotate on the client cutover — Rotation invalidates the old credential; install the returned secret on the client before it makes the next request.

Open access safely with a firewall preview

Inspect the host firewall, preview the policy, apply with automatic revert and confirm only after reconnecting.

This task requires administrator permissions.

1. Inspect firewall owner — A managed firewall refuses Panel-owned changes; do not override a different policy owner.
2. Preview policy difference — The owner validates the policy and returns a plan token bound to the current ruleset.
3. Apply after confirming lockout risk — A pending change reverts automatically unless you confirm it before the deadline.
4. Confirm only after reconnecting — If connectivity is lost, do not confirm; use the transaction's revert option or allow its timeout.

Add a user with limited permissions

Create a human account without instance control and verify its role from the auth owner.

This task requires administrator permissions.

1. Review account policy — Check the current authentication mode before adding a user.
2. Create read-only user — The account begins with no instance control or instance assignments.

Storage, backup, updates and attestation

Back up and move Panel configuration

Back up this Panel, export portable settings, preview changes and restore to another stick.

This task requires administrator permissions.

1. Inventory current backups — Confirm the backup catalogue is available.
2. Create protected source backup — Save a full archive on the source before exporting portable settings.
3. Export and copy portable configuration — Download portable JSON from the source. On the destination, paste the exact file, checksum and preview plan into this guide.
4. Preview on the destination — Verify checksums and destination changes without writing files.
5. Approve exact destination diff — Compare the returned plan checksum with the value entered here and inspect affected files before proceeding.
6. Restore portable settings — Apply only the already reviewed portable archive on the destination stick.

Preview and restore a sealed full backup

Inventory a full backup, preview its exact plan and restore it on this same appliance only after confirmation.

This task requires administrator permissions.

1. Inspect sealed backup inventory — Check that the selected full backup exists in the local verified catalogue.
2. Preview sealed backup changes — The owner decrypts and verifies the appliance-bound backup, then computes a change-bound restore plan.
3. Review the exact change plan — Compare the before/after file list and copy the returned plan SHA-256; re-preview if state changes.
4. Restore only the reviewed sealed backup — The owner rechecks the catalogue, checksum, current files and exact plan before any changes; it makes a pre-restore backup.
5. Verify restored backup status — Check the owner status and recovery journal; a published restore cannot be cancelled.

Check, verify and safely update A/B slots

Inspect the authenticated release, stage only to the inactive slot and recover to known-good if necessary.

This task requires administrator permissions.

1. Inspect slot status — Read active, known-good, candidate and next-boot slots.
2. Check signed update source — Check for an eligible signed release without modifying boot slots.
3. Preview inactive-slot update — The slot owner verifies the selected signed release and target before commit.
4. Confirm boot plan — Check target slot, rollback floor and next boot before staging the release.
5. Stage to inactive slot — Root-only commit; an interrupted or failed stage must not be reported as successful.
6. Verify or recover after reboot — Check the new boot; if it fails, use known-good slot verification and the recovery preview and commit controls.

Create and undo a disabled maintenance window

Rehearse a reversible backup schedule without running any jobs.

This task requires administrator permissions.

1. Inspect existing maintenance windows — Review the exact owner state and select a new unique window ID.
2. Create disabled backup window — Write a disabled, non-executing backup window; remove it with Undo after testing.
3. Verify disabled schedule — Inspect the disabled window in the owner-maintained schedule; it will not run until enabled elsewhere.

Install LexiOS on an internal disk

Select an eligible internal disk, review destructive actions and require typed serial and root approval.

This task requires administrator permissions.

1. Inspect disk eligibility — Read the protected inventory, live source and any refusal reasons.
2. Review selected target — Use the installer to preview exact partitions, labels, boot policy and secure-boot evidence.
3. Confirm irreversible erasure — Root must type the exact serial and commit the owner's fresh install review in the Storage page.
4. Commit reviewed installation — Use the root-only serial confirmation and observe the running install job before rebooting.
5. Inspect progress and prepare first boot — Check that the protected installer finished before removing the live stick.

Power, GPU tuning and telemetry

Cap a GPU and measure the speed cost

Baseline the workload, apply one validated cap, measure again and restore the exact old cap.

This task requires administrator permissions.

1. Inspect supported GPU and current cap — Confirm the device, supported limits, write permission and saved versus live cap before making a change.
2. Record uncapped speed and heat — At GPU & Power run the same quick benchmark with an idle running GPU instance; wait for the finished record and note decode t/s, mean W and peak junction temperature.
3. Stop the baseline inference instance — Stop the test instance after the finished baseline run; the cap owner refuses mutations while inference is running.
4. Approve lower sustained watts — Confirm reduced sustained watts can lower throughput and does not prevent transient spikes.
5. Set and verify the device-bound cap — Change only the chosen AMD card; the owner validates its bound identity, allowed range and idle state and reads the live cap back.
6. Restart the same inference workload — Start the original test instance with unchanged workload settings after the cap applies.
7. Measure capped speed — Re-run the exact same benchmark on the restarted instance; compare finished measured runs, not estimated watt-to-speed ratios.
8. Compare two completed measured runs — At Power and hardware enter both finished, reset-checked benchmark IDs. Verify the same workload and device, then review measured percent speed cost, watts and peak heat; missing sensor data stays missing.
9. Stop inference again before restore — Stop the test instance and confirm no active inference before returning the hardware cap to its exact prior value.
10. Restore the exact previous limit — Use the saved original microW value and bound device identity; refuse a changed live cap or device.

Switch this box to stable maximum performance

Review thermal consequences, apply the built-in stable performance preset and retain exact-value undo.

This task requires administrator permissions.

1. Review available settings — Inspect the stable-performance profile, hardware helper, current values and existing boot profile.
2. Approve performance and heat trade-offs — Performance governor and shallower idle states may increase sustained idle draw and temperature; this does not persist a new boot policy.
3. Capture, apply and verify — Save current values for just the affected targets, apply the registered stable-performance preset and check per-setting readback.
4. Compare steady-state behavior — Observe CPU governor, live temperature and workload speed under the same load; avoid claiming gains without repeated measurements.

Diagnostics and debug kits

Collect a debug kit and send it

Review the configured HTTPS destination, create a scrubbed bundle, verify its saved record, then explicitly upload its ID.

This task requires administrator permissions.

1. Review destination and existing kits — Verify retention, configured HTTPS destination and enrolled fleet collection state.
2. Create scrubbed archive — Collect a local support archive with a SHA-256 digest and saved record.
3. Review saved archive — Locate the new ID and digest on the debug-kit page before sending anything.
4. Confirm HTTPS transfer — Only send a bundle after reviewing the destination and approving disclosure.
5. Upload saved kit — Submit the chosen saved ID; check the resulting upload status, not merely HTTP success.

Investigate a crash: journal, evidence and logs

Examine the recorded crash report, journal refresh coverage, correlated stops, capture readiness and bounded logs.

This task requires administrator permissions.

1. Review prior boot — Read the last recorded crash analysis; current health cannot explain a past stop.
2. Check journal coverage — A pending or stale refresh must be disclosed before drawing conclusions.
3. Inspect capture readiness — Read available pstore, watchdog, netconsole and crash-dump capture status.
4. Correlate hard stops — Do not treat an absent capture marker as a confirmed cause.
5. Review bounded logs — Compare engine and launch logs against the previous boot history.
6. Review findings — Inspect timeline and parameter history; request refresh manually if evidence is stale.

Fleet

Join a box and sync a model

Enroll a second box, check peer readiness and transfer a verified model.

This task requires administrator permissions.

1. Verify primary — Inspect fleet role before issuing enrollment credentials.
2. Create one-time join code — The primary produces a short-lived code; copy it to the second box.
3. Join the second box — On the second box, choose Member and submit the code, then report to the primary.
4. Inspect peer readiness — Verify that the new member is joined and sync-ready before transferring.
5. Authorize model sync — Confirm file creation on the destination before dispatch.
6. Transfer selected model — The existing signed transfer owner checks identities, manifests and full-file hashes.
7. Follow transfer — Review progress, integrity failures and the destination result before loading the model.

Run and follow a fleet campaign

Inspect signed policy and member history, confirm dispatch and follow signed receipts.

This task requires administrator permissions.

1. Inspect signed policy and progress — The primary must have a provisioned campaign with verifiable signed receipts.
2. Inspect member history — Unsigned local diagnostic events do not prove an update; inspect signed receipts separately.
3. Confirm controller dispatch — A tick may queue signed remote work, and already-dispatched work cannot be undone automatically.
4. Run guarded controller — Dispatch revalidates protected policy and live admission gates before queuing work.
5. Follow authenticated progress — Check member signed receipts instead of treating queue acceptance as installation.

Virtual machines

Boot an installer with GPU passthrough

Create a guest with a validated GPU group and existing installer image; inspect output and undo safely.

This task requires administrator permissions.

1. Check host and device eligibility — Check KVM, firmware, disk and the selected complete IOMMU group; leave the host GPU unassigned to active workloads.
2. Prepare guest — Choose the eligible GPU group and installer image, then save the new configuration through the VM supervisor.
3. Confirm boot — Boot may transfer the assigned GPU group away from host workloads; proceed only after checking eligibility.
4. Boot installer — Start through the VM supervisor and confirm its actual running state.
5. Review installer output — Use the guest console to complete installation; remove the ISO in the VM editor before future installed-disk boots.

Run a model server inside a guest

Start an installed guest, authenticate through serial console and submit the service start command.

This task requires administrator permissions.

1. Prepare installed guest — Supply a disk with a preinstalled guest system and firmware; do not attach an installer image.
2. Boot guest — Start the installed guest and verify the supervisor reports it running.
3. Sign in to guest — Open the live serial console and authenticate within the guest before sending a service command.
4. Start server inside guest — Confirm guest sign-in and send your chosen startup command to its serial terminal, not the host shell.
5. Check guest output — Inspect the serial output to verify that the service itself started; supervisor state alone is not proof.

Image, video and audio generation

Generate an image with a local model

Check local capability, submit image settings, observe the job and review its result.

This task requires administrator permissions.

1. Inspect bound image models — Check the live model inventory; a model without the requested task cannot start.
2. Generate an image — Open the native image form, set its model and per-job values, then submit to the running instance.
3. Inspect the job — Use the submitted job ID; keep refreshing until an output or an explicit error is shown.
4. Review the result — Inspect the retained result, generation receipt and model-license notice; an unfinished job is not a usable image.

Transcribe audio and speak a reply

Transcribe a local WAV, review the transcript, then synthesize a spoken reply.

This task requires administrator permissions.

1. Inspect audio models — Check the live inventory for independent transcription and speech executors.
2. Transcribe the recording — Put a WAV file in the instance-owned input directory; submit the transcription form and copy the job ID.
3. Check the transcript — Refresh the job until a transcript appears, review it, and compose a reply.
4. Speak the reply — Enter the reviewed reply, voice and language in the speech form; submit and copy its job ID.
5. Check the reply audio — Refresh the speech job; listen to the retained WAV result only after the engine reports success.

Agents, MCP and LexiGuard

Connect an MCP client and allow a tool operation

Check the transport, inspect tools, confirm the permission scope, save it and restore it when finished.

This task requires administrator permissions.

1. Check transport — Confirm the authenticated tool transport exists; this is not an autonomous task runner.
2. Inspect catalog — Read the live tool catalog, then choose one tool on the connection page.
3. Review affected tools — Use the guided preview to see all tools sharing the chosen operation; per-tool grants are not supported.
4. Confirm permission change — Allowing an operation can authorize more than the selected tool; use the confirmed page form for exact scope.
5. Apply reviewed permission — Apply the operation reviewed in the connection page; it may cover more than one tool.
6. Verify policy — Check the operation selected in the scope preview is persisted, then try its tool; guarded actions may still require approval.
7. Inspect guard — Check whether a tool call requires approval or has been refused.

macOS platform

Set up LexiPanel on a Mac and serve a model with Metal

Check the host, install a verified Metal runtime, select a local model and start an instance with a reversible action.

This task requires administrator permissions.

1. Verify the Mac — The host must report macOS before attempting Metal inference.
2. Install panel services — Use the macOS installer and verify the LaunchAgent status before continuing.
3. Check the Metal engine — The runtime must be installed and its recorded checksum must match; do not activate unverified binaries.
4. Review available engines — Confirm the Metal runtime is installed and verified on the Engines page.
5. Choose a local model — Import or download a compatible model and configure the instance to use it on the Instances page.
6. Check unified memory — Review the model-fit estimate and memory pressure before allocating a graphics working set.
7. Review the selected instance — Choose the instance and its Metal engine in the instance controls before starting.
8. Check instance readiness — On the setup page, choose Check readiness with the exact instance ID; only a positive host, checksum and model preflight allows proceeding.
9. Confirm service startup — Starting an instance opens its inference service; stop it to undo this step.
10. Start serving — Start the selected instance through the existing instance-control route; a failed response does not count as success.
11. Inspect running instances — Inspect the instance inventory and test the selected service's health endpoint from the Engines page.

LexiOS console, first boot, Secure Boot and LexiKernel

Enable Secure Boot with the development certificate

Verify the public certificate, append it to firmware db with physical presence, and confirm the firmware report.

This task requires administrator permissions.

1. Verify development certificate — The offered download must match the documented image fingerprint; another certificate is refused.
2. Enroll with physical presence — Download the verified certificate. Restart into firmware setup, append it to Authorized Signatures (db), preserve existing keys, then enable Secure Boot. Confirm only after saving.
3. Verify Secure Boot — After reboot, check the firmware SecureBoot and SetupMode variables. This does not prove that the certificate is in db.
4. Inspect firmware Authorized Signatures — Confirm the development certificate appears in db alongside the original trusted keys; remove only that appended entry to undo.

Enroll the first administrator from another computer

Use the one-time console code only at the unauthenticated first-boot setup form.

1. Read the one-time console code — At the machine console, obtain the six-word code. Do not put the code in a guide, URL, log, or API request.
2. Complete the protected setup form — From the other computer open /setup. Enter the code, root password and administrator credentials there. Loopback is the only code exemption.
3. Verify enrollment completed — Sign in as the new administrator and check the owner has closed first-boot enrollment. The one-time code cannot be reused.

Check LexiKernel support on this machine

Identify the running kernel and review measured subsystem availability and release-gate evidence.

This task requires administrator permissions.

1. Read owner kernel identity — The native kernel status owner distinguishes Linux from LexiKernel; missing telemetry stays unknown.
2. Review subsystem reasons — The capability console lists every reported subsystem with the reason for missing evidence.
3. Review qualification gates — Check the protected release-gate owner, which remains NO-GO until qualification proves otherwise.

API and integrations

Point an existing client at LexiSuite

Check the gateway, API document and model list, then configure client credentials.

This task requires administrator permissions.

1. Discover gateway — Read the gateway's live base URL and blocked status.
2. Confirm schema — Read the route-generated API document.
3. Discover serving models — Read the actual gateway model list; an empty list is not success for inference.
4. Configure the existing client — Use a key from Access and the gateway URL; test a real request in the client.

Call a typed decision from a script

Inspect profiles and invoke the registered decision owner using supplied input.

This task requires administrator permissions.

1. Discover decision profiles — Find a profile with an active validated artifact.
2. Prepare the script — Select the profile and decision text; no inference is assumed until the owner replies.
3. Run typed decision — Call the registered typed-decision owner with the requested profile and text.