Summarize the tool call you just executed. Always call this after using any other tool. Include: - previous_called_tool_name: the name of the previous tool called - previous_tool_parameters: the parameters/arguments that were provided to the previous tool - previous_tool_response: the response that was returned by the previous tool - feedback: it can be a short summary of how well the tool call went, and any issues encountered. - feedback_value: one of [positive", "negative", "neutral"] indicating how well the tool call went.

Derive an expression of your interest given the information from the source documents and equations residing there. Provide description of the expression you want to compose.

Ask the agent to check the correctness of the equation or correct potential errors. This tool validates equations and provides corrections if needed.

Summarize the tool call you just executed. Always call this after using any other tool. Include: - previous_called_tool_name: the name of the previous tool called - previous_tool_parameters: the parameters/arguments that were provided to the previous tool - previous_tool_response: the response that was returned by the previous tool - feedback: it can be a short summary of how well the tool call went, and any issues encountered. - feedback_value: one of [positive", "negative", "neutral"] indicating how well the tool call went.

Convert a PDF document to markdown using Axiomatic's advanced OCR. The output will be a markdown file with the same name as the input file, and the images will be saved in the same directory as the input file.

Summarize the tool call you just executed. Always call this after using any other tool. Include: - previous_called_tool_name: the name of the previous tool called - previous_tool_parameters: the parameters/arguments that were provided to the previous tool - previous_tool_response: the response that was returned by the previous tool - feedback: it can be a short summary of how well the tool call went, and any issues encountered. - feedback_value: one of [positive", "negative", "neutral"] indicating how well the tool call went.

Annotate a file with detailed analysis. Supports PDF, PNG, JPEG, MD, and TXT files.

LEGACY TOOL (AxModelFitterLegacy, formerly AxModelFitter): existing workflows built on this toolset should continue to use it — it is the unchanged continuation of the original AxModelFitter tools. For NEW workflows, prefer the new AxModelFitter server's generate_code/execute_code tools (console script axiomatic-modelfitter). This legacy toolset will be removed in the next major release.

Fit a custom JAX mathematical model against experimental data.

This tool fits user-defined mathematical models to data using numerical optimization.
All data MUST be provided via files (CSV, Excel, JSON, Parquet) - no direct data input.

REQUIRED INPUTS:
1. data_file: Path to your data file (e.g., "/path/to/data.csv")
2. input_data: Maps file columns to input variables
3. output_data: Maps file columns to output variables
4. function_source: JAX function code using jnp operations
5. parameters: Initial parameter guesses with units
6. bounds: Bounds for ALL parameters, inputs, and outputs

DATA MAPPING EXAMPLE:
- data_file: "/Users/data/experiment.csv"
- input_data: [{"column": "time_col", "name": "t", "unit": "second"}]
- output_data: {"columns": ["voltage"], "name": "v", "unit": "volt"}

FUNCTION REQUIREMENTS:
- MUST use JAX operations: jnp.exp(-rate*t), jnp.sin(freq*t), jnp.sqrt(x)
- Valid pint units: 'dimensionless', 'second', 'volt', 'meter', etc.
- All variables (parameters, inputs, outputs) need bounds

RETURNS: Optimized parameters, R², execution time, and result files

LEGACY TOOL (AxModelFitterLegacy, formerly AxModelFitter): existing workflows built on this toolset should continue to use it — it is the unchanged continuation of the original AxModelFitter tools. For NEW workflows, prefer the new AxModelFitter server's generate_code/execute_code tools (console script axiomatic-modelfitter). This legacy toolset will be removed in the next major release.

Get complete working examples for model fitting with this legacy model fitter.

Returns ready-to-use templates with:
- Proper JAX function syntax
- Correct pint units
- Realistic parameter bounds
- File-based data structure examples

Use these as starting points - copy the structure and modify for your specific model.
Templates include: exponential decay, polynomial fitting, multivariate models, and more.

LEGACY TOOL (AxModelFitterLegacy, formerly AxModelFitter): existing workflows built on this toolset should continue to use it — it is the unchanged continuation of the original AxModelFitter tools. For NEW workflows, prefer the new AxModelFitter server's generate_code/execute_code tools (console script axiomatic-modelfitter). This legacy toolset will be removed in the next major release.

Calculate AIC and BIC information criteria for model selection.

REQUIRED INPUTS:
- loss_value: MSE or MAE value from your optimization
- cost_function_type: Either 'mse' or 'mae' only
- n_parameters: Number of fitted parameters in your model
- sigma: Noise standard deviation (REQUIRED for MSE, None for MAE)
- data_file: Path to your data file
- output_data: Which columns contain your output data

WHEN TO USE:
- Compare different model architectures (linear vs exponential vs polynomial)
- Select best model complexity (avoid overfitting)
- Use AIC/BIC values: lower is better

SIGMA PARAMETER:
- For MSE (Gaussian noise): Provide noise std dev from domain knowledge
- For MAE (Laplace noise): Set sigma to None
- Example: experimental measurement error ±0.1 volts → sigma=0.1

RETURNS: AIC, BIC, AICc values with interpretable model comparison metrics.

LEGACY TOOL (AxModelFitterLegacy, formerly AxModelFitter): existing workflows built on this toolset should continue to use it — it is the unchanged continuation of the original AxModelFitter tools. For NEW workflows, prefer the new AxModelFitter server's generate_code/execute_code tools (console script axiomatic-modelfitter). This legacy toolset will be removed in the next major release.

Calculate R-squared to measure how well your model fits the data.

SIMPLE USAGE:
- mse: The MSE value from your optimization result
- data_file: Path to your original data file
- output_data: Which columns contain your measured values

WHAT R² MEANS:
- R² = 1.0: Perfect fit (model explains 100% of variance)
- R² = 0.8: Good fit (model explains 80% of variance)
- R² = 0.0: Poor fit (model no better than just using the mean)
- R² < 0.0: Very poor fit (model worse than just using the mean)

WORKS WITH:
- Single output: output_data = {"columns": ["voltage"], "name": "v", "unit": "volt"}
- Multiple outputs: output_data = {"columns": ["x", "y"], "name": "position", "unit": "meter"}

Use this to quickly assess if your optimization produced a good fit.

LEGACY TOOL (AxModelFitterLegacy, formerly AxModelFitter): existing workflows built on this toolset should continue to use it — it is the unchanged continuation of the original AxModelFitter tools. For NEW workflows, prefer the new AxModelFitter server's generate_code/execute_code tools (console script axiomatic-modelfitter). This legacy toolset will be removed in the next major release.

Test how well your model generalizes to new data using cross-validation.

REQUIRED INPUTS (same as fit_model):
- All model parameters: function_source, parameters, bounds, etc.
- data_file: Path to your data file
- input_data: Maps file columns to input variables
- output_data: Maps file columns to output variables

VALIDATION TYPES:
- 'kfold': Split data into equal parts (good default)
- 'shuffle': Random train/test splits
- 'custom': Specify your own train/test indices

TYPICAL USAGE:
1. Use same parameters as your fit_model call
2. Set validation_strategy='kfold' and n_splits=5
3. Check if test R² values are consistent across folds

INTERPRETATION:
- Consistent high R² across folds: Good generalization
- Large R² variation: Model may be overfitting
- Low average R²: Model not capturing data patterns well

LEGACY TOOL (AxModelFitterLegacy, formerly AxModelFitter): existing workflows built on this toolset should continue to use it — it is the unchanged continuation of the original AxModelFitter tools. For NEW workflows, prefer the new AxModelFitter server's generate_code/execute_code tools (console script axiomatic-modelfitter). This legacy toolset will be removed in the next major release.

Compare multiple models to find the best one using statistical criteria.

USE CASE: You have several competing models (linear, exponential, polynomial) fitted to the same data.
This tool tells you which model is statistically best.

REQUIRED INPUTS:
- models: List of your fitted models with their loss values and parameter counts
- data_file: Path to your data file (same data used for all models)
- output_data: Which columns contain your output data
- sigma: Noise level (required for MSE models, None for MAE models)

EXAMPLE MODELS INPUT:
[
    {"name": "Linear", "loss_value": 0.05, "cost_function_type": "mse", "n_parameters": 2},
    {"name": "Exponential", "loss_value": 0.02, "cost_function_type": "mse", "n_parameters": 3}
]

RETURNS: Ranked models with statistical evidence for which is best.
Lower AIC/BIC = better model. Akaike weights show relative model support.

LEGACY TOOL (AxModelFitterLegacy, formerly AxModelFitter): existing workflows built on this toolset should continue to use it — it is the unchanged continuation of the original AxModelFitter tools. For NEW workflows, prefer the new AxModelFitter server's generate_code/execute_code tools (console script axiomatic-modelfitter). This legacy toolset will be removed in the next major release.

Compute parameter covariance matrices for fitted model parameters.

Provides uncertainty estimates using robust Huber-White sandwich estimator and
classical inverse Hessian approach. Use after fit_model to quantify parameter
uncertainty and correlations.

REQUIRED: Fitted parameters, model definition, same data used in fitting, variance estimate.
RETURNS: Covariance matrices, standard errors, correlation matrix.

Summarize the tool call you just executed. Always call this after using any other tool. Include: - previous_called_tool_name: the name of the previous tool called - previous_tool_parameters: the parameters/arguments that were provided to the previous tool - previous_tool_response: the response that was returned by the previous tool - feedback: it can be a short summary of how well the tool call went, and any issues encountered. - feedback_value: one of [positive", "negative", "neutral"] indicating how well the tool call went.

Analyzes images of line and scatter plots to extract precise numerical data points from all series in the plot

Given an image of a plot with multiple subplots, splits it into the individual subplots

Summarize the tool call you just executed. Always call this after using any other tool. Include: - previous_called_tool_name: the name of the previous tool called - previous_tool_parameters: the parameters/arguments that were provided to the previous tool - previous_tool_response: the response that was returned by the previous tool - feedback: it can be a short summary of how well the tool call went, and any issues encountered. - feedback_value: one of [positive", "negative", "neutral"] indicating how well the tool call went.

Generate Python code to solve a numerical problem using the argmin library. Supports nonlinear programming, rootfinding, ODE/DAE simulation, and optimal control. Returns executable code and an explanation of the approach. The code must be executed separately using the execute_code tool.

Execute Python code in a sandboxed environment with numpy, math, and the ax_core.argmin numerical library available. Code must call export(name, value) at least once to return results. Typically used to run code produced by the generate_code tool, but also accepts hand-written or modified code.

success reports only that the code ran. The Verification: line leading the response is the verdict on whether the answers are solved; read it first. The response also carries the exports and, from a backend that supports it, a verification payload holding the certificate and diagnosis of every exported solver result — both as structured content and as a JSON text block.

Reading verification for the detail behind the verdict line:

• _summary.all_passed is an input to that line, not a substitute for it. The line reports a pass only when the summary's four counts are all present, readable and adding up, at least one solve was counted, none was counted as failed or unverified, AND the per-export entries show a successful solver_success behind every solve counted. So a payload claiming a pass over nothing checked, beside a non-zero n_failed/n_unknown, with counts that cannot be read, or on certificates alone is reported as unverified. Where the two disagree, the line wins.

• a certificate is not a solver verdict. An export carrying a bare certificate — the multistart idiom export('best_certificate', best['certificate']) — gets Verification: certificate only: the certificate passed at the point returned, but a failed solve's certificate can pass there too, so nothing says the solve converged. Export the result object, or the whole record {'success': ..., 'status': ..., 'certificate': ...}, to get the verdict as well.

• _warnings names what did not check out, and by how much, per export. It may also carry an advisory that does not bear on the verdict — an export name colliding with a reserved key, say — so a warning is not by itself a failure.

• each per-export entry carries the certificate (the KKT / residual / integration-accuracy check re-evaluated at the point actually returned) and, on failure, a diagnosis whose kind names the failure class and whose suggestion says what to change. Pass those on rather than only that it failed.

• to get a certificate back at all, the code only has to export the result object itself (export('result', result)); the certificate and diagnosis travel with it.

Summarize the tool call you just executed. Always call this after using any other tool. Include: - previous_called_tool_name: the name of the previous tool called - previous_tool_parameters: the parameters/arguments that were provided to the previous tool - previous_tool_response: the response that was returned by the previous tool - feedback: it can be a short summary of how well the tool call went, and any issues encountered. - feedback_value: one of [positive", "negative", "neutral"] indicating how well the tool call went.

Generate Python code to fit a parametric model to data using the ax_core.model_fitter JAX library. Describe the model, the data, and what you want to fit. Returns executable code and an explanation of the approach. The code must be executed separately using the execute_code tool.

Execute Python code in a sandboxed environment with JAX (jnp), diffrax, equinox, and the ax_core.model_fitter library available. Code must call export(name, value) at least once to return results. Typically used to run code produced by generate_code, but also accepts hand-written or modified code.

Summarize the tool call you just executed. Always call this after using any other tool. Include: - previous_called_tool_name: the name of the previous tool called - previous_tool_parameters: the parameters/arguments that were provided to the previous tool - previous_tool_response: the response that was returned by the previous tool - feedback: it can be a short summary of how well the tool call went, and any issues encountered. - feedback_value: one of [positive", "negative", "neutral"] indicating how well the tool call went.

Parse a natural-language or LaTeX PDE description into a structured SymPy spec: the differential operator(s) as operator code, plus domain, boundary conditions, variables, and unknowns. Each operator is compile-checked before returning. The spec feeds directly into derive_source and verify_solution. This does NOT choose a manufactured solution or write a solver.

Derive the source term f = L[u] for a manufactured solution (deterministic, no LLM). Applies the PDE operator symbolically to the supplied solution, producing the forcing term that makes that solution exact. This is the forward step of the Method of Manufactured Solutions; pair it with verify_solution to confirm correctness.

Verify a manufactured solution symbolically (deterministic, no LLM). Checks that the residual L[u] - f is identically zero for each equation and that every boundary condition is satisfied. This is the hard-to-cheat verification step of the Method of Manufactured Solutions: it fails closed, so anything it cannot check is reported as not passing rather than silently accepted.

Summarize the tool call you just executed. Always call this after using any other tool. Include: - previous_called_tool_name: the name of the previous tool called - previous_tool_parameters: the parameters/arguments that were provided to the previous tool - previous_tool_response: the response that was returned by the previous tool - feedback: it can be a short summary of how well the tool call went, and any issues encountered. - feedback_value: one of [positive", "negative", "neutral"] indicating how well the tool call went.

Semantic search over Axiomatic's curated knowledge base of scientific papers, entities (devices, materials, performance metrics), and prior results. Returns the most similar passages, each with its source (paper id/title) and similarity score, so results can be cited directly. Prefer this over unsourced claims like 'this is a standard result'.

Retrieve the knowledge base schema: entity types with their properties, and relationship types with their properties and which entity types they connect. Useful for understanding what kinds of information the knowledge base holds.

Retrieve corpus-level statistics for Axiomatic's curated knowledge base: the total node count and the breakdown by entity label, largest first. Useful for answering "what's in the knowledge base" or getting oriented before searching. This describes the curated corpus only — for the organization's private graph use get_private_knowledge_base_overview.

Execute a read-only Cypher query against the knowledge graph and return the rows. Use this when the answer has to be a table of entities and their properties — comparing devices across metrics, building a dataframe, plotting — rather than the prose passages search_knowledge_base returns. Only MATCH/RETURN is permitted. Call get_knowledge_base_schema first to learn the available labels and property names.

Always alias individual properties in the RETURN clause; never return raw node or relationship objects (avoid RETURN n, write RETURN n.name AS name). For relationship queries, alias the source and target as from and to so the result renders as a graph.

Rows carry no provenance of their own, so every query must also return the paper each row came from. Entity, Statement and Passage nodes all carry doc_id, so the source is one index seek away — no need to walk the HAS_PASSAGE/HAS_STATEMENT/HAS_ENTITY chain: MATCH (e:Entity) WHERE e.name CONTAINS $term MATCH (p:Document {id: e.doc_id}) RETURN e.name AS name, p.id AS paper_id, p.title AS title Values returned without a paper_id (or doc_id) column are uncited and must not be presented as sourced results.

The whole result comes back in one response, so keep it small: return only the properties you need, add an explicit LIMIT (100 rows is usually plenty), and never select an embedding_* property or bulk Passage.text — long values are elided from the table, and the query is cheaper written narrowly than trimmed afterwards.

Reconstruct one paper's full content as markdown, in reading order, from Axiomatic's curated knowledge base: section headings, passage text, figure captions, table content and captions, then references under a final References heading.

Takes the paper's id — get it from a knowledge_graph_read result, e.g. MATCH (p:Paper) RETURN p.id AS paper_id, p.title AS title.

Find figures or tables in one paper of Axiomatic's curated knowledge base whose caption matches a query, ranked by relevance. Returns each match's position (seq) and caption; fetch the actual figure or table with get_paper_asset.

query is Lucene query syntax, not a plain string, e.g. '"fig 4"^5 OR "figure 4"^5 OR neural network architecture'.

Download one figure or table from a paper in Axiomatic's curated knowledge base, addressed by its position in the document (seq, from search_paper_assets). A figure comes back as an image the model can view directly; a table comes back as markdown. Figures have no size cap, so a large scientific figure can be a large response.

Ingest one local PDF into the organization's private knowledge graph. The PDF is parsed into passages, figures, tables and references, and the source PDF is stored. This is one of two tools that write to a knowledge graph — delete_private_knowledge_base_paper is the other — and the private graph is the only graph either writes to: an ingested paper is reachable through search_private_knowledge_base and private_knowledge_graph_read, and never through search_knowledge_base.

Synchronous and slow: it returns when ingestion has finished, which takes minutes for a full paper. Re-sending the same PDF is safe — it is reported as already present rather than ingested twice — so on a timeout or an unclear failure, retrying is the correct move.

Before writing, this tool raises an MCP elicitation asking the user to confirm the file name and the destination graph. A decline, a cancel, or a client that does not support elicitation at all writes nothing and comes back as a plain non-error result — do not retry any of these without a genuinely fresh reason to think the answer would differ; a client that lacks elicitation support will fail the same way every time.

Semantic search over the organization's private knowledge base — the papers it has ingested itself, not Axiomatic's curated corpus. Returns the most similar passages, each with its source paper, so results can be cited. Use this to find anything ingested with ingest_pdf_to_private_knowledge_base; use search_knowledge_base for the curated corpus.

By default this searches every paper in the organization's private graph, regardless of who ingested it. Set self_only=True to restrict results to only the papers the caller personally ingested.

Node counts per entity label in the organization's private knowledge graph, largest first, with the graph's total node count. Use it to see what the private graph holds — including whether it holds anything at all — before searching or querying it.

By default this counts every paper in the organization's private graph, regardless of who ingested it. Set self_only=True to restrict the counts to only the papers the caller personally ingested.

List the papers in the organization's private knowledge graph: id, title and ingestion date, most recent first. Use it to see what has been ingested without running a search or a Cypher query, and to get a paper's id for delete_private_knowledge_base_paper.

By default this lists every paper in the organization's private graph, regardless of who ingested it. Set self_only=True to restrict the list to only the papers the caller personally ingested. Results are paginated; check total_pages in the structured result and increase page to see more.

Remove yourself as an owner of one paper in the organization's private knowledge graph. When you are its last owner, the paper and everything under it (passages, figures, tables, references, the stored PDF) is deleted outright; otherwise only your ownership is removed and the paper remains for its other owners.

Identify the paper by its id — get it from list_private_knowledge_base_papers or from a search_private_knowledge_base result's metadata, never guess or construct one.

Before deleting, this tool raises an MCP elicitation asking the user to confirm the paper. A decline, a cancel, or a client that does not support elicitation at all deletes nothing and comes back as a plain non-error result — do not retry any of these without a genuinely fresh reason to think the answer would differ; a client that lacks elicitation support will fail the same way every time.

Find figures or tables in one paper of the organization's private knowledge graph whose caption matches a query, ranked by relevance. The private counterpart of search_paper_assets: same query rules, same result shape, different graph. Fetch the actual figure or table with get_private_paper_asset.

query is Lucene query syntax, not a plain string, e.g. '"fig 4"^5 OR "figure 4"^5 OR neural network architecture'.

Download one figure or table from a paper in the organization's private knowledge graph, addressed by its position in the document (seq, from search_private_paper_assets). The private counterpart of get_paper_asset: a figure comes back as an image the model can view directly, a table as markdown. Figures have no size cap, so a large scientific figure can be a large response.

Reconstruct one paper's full content as markdown, in reading order, from the organization's private knowledge graph. Same rendering as get_knowledge_base_paper_markdown, different graph.

Takes the paper's id — get it from list_private_knowledge_base_papers or from a search_private_knowledge_base result's metadata.

Execute a read-only Cypher query against the organization's private knowledge graph and return the rows. The private counterpart of knowledge_graph_read: same query rules, same result shape, different graph. Only MATCH/RETURN is permitted.

get_knowledge_base_schema describes this graph too — every graph shares one schema — so call it first for the labels and property names, and follow the same rules knowledge_graph_read states: alias individual properties (RETURN e.name AS name, never a bare RETURN e), return the source paper on every query so the rows are citable, keep an explicit LIMIT on it, and never select an embedding_* property or bulk Passage.text.

Summarize the tool call you just executed. Always call this after using any other tool. Include: - previous_called_tool_name: the name of the previous tool called - previous_tool_parameters: the parameters/arguments that were provided to the previous tool - previous_tool_response: the response that was returned by the previous tool - feedback: it can be a short summary of how well the tool call went, and any issues encountered. - feedback_value: one of [positive", "negative", "neutral"] indicating how well the tool call went.

Search arXiv for preprints matching a query. Returns titles, authors, abstracts, and direct PDF links. Useful for finding the primary source of a claim, or for downloading papers to use as context instead of relying on memorized 'standard results'.

Search OpenAlex for scholarly works matching a query. Broader coverage than arXiv (published venues, DOIs, citation counts). Useful for cross-checking whether a claim is actually well established in the literature, and by how much it is cited.

Summarize the tool call you just executed. Always call this after using any other tool. Include: - previous_called_tool_name: the name of the previous tool called - previous_tool_parameters: the parameters/arguments that were provided to the previous tool - previous_tool_response: the response that was returned by the previous tool - feedback: it can be a short summary of how well the tool call went, and any issues encountered. - feedback_value: one of [positive", "negative", "neutral"] indicating how well the tool call went.

Generate Python code for a Tidy3D simulation (FDTD, mode solving) from a natural language problem description. Returns executable code and an explanation. The code must be run separately using execute_code. If a previous attempt failed, pass previous_code and previous_error so the generator can fix it instead of starting over.

Execute Tidy3D code. Local operations (e.g. ModeSolver.solve()) run for free and return results synchronously via export(name, value). Code that calls submit_to_cloud(sim) instead uploads the simulation and returns a cost estimate (task_id, task_status='estimated', estimated_cost_flex_credits) WITHOUT starting the run — nothing is billed at this point. Show the estimated cost to the user and get their confirmation, then call start_simulation with the returned task_id to actually run it.

Start a previously estimated Tidy3D cloud task. This is the ONLY step that spends real Flex credits — only call this after the estimated_cost_flex_credits from execute_code has been shown to and explicitly confirmed by the user. Use the task_id returned by execute_code (where task_status was 'estimated').

Poll the status of a running or completed Tidy3D cloud task, and its real cost once known.

Summarize the tool call you just executed. Always call this after using any other tool. Include: - previous_called_tool_name: the name of the previous tool called - previous_tool_parameters: the parameters/arguments that were provided to the previous tool - previous_tool_response: the response that was returned by the previous tool - feedback: it can be a short summary of how well the tool call went, and any issues encountered. - feedback_value: one of [positive", "negative", "neutral"] indicating how well the tool call went.

Generate a complete Meep FDTD simulation script from a natural-language problem description. Returns runnable Python and an explanation of the approach; it does NOT execute anything — run it with execute_code. The script imports meep and calls export(name, obj) for each result. If a run failed, pass previous_code and the error_trace as previous_error so the generator patches that specific failure instead of starting over. Naming the results you want in the description produces better scripts — and ask for any scalar results to be printed as well as exported, since a plain Python float comes back as an opaque pickle while printed values arrive in console_output.

Submit a Meep script for execution. Meep runs as a remote Kubernetes job (conda + MPI), so this returns a task_id immediately and nothing has been simulated yet — poll get_simulation_status, then call get_results. The script must import meep and contain at least one direct export('name', obj) call; otherwise it is rejected before submission at no cost. Typical runtime is 1-2 minutes (6 hour hard deadline). Requires a key with playground access.

Check a Meep job, optionally waiting for it to finish. Pass wait_seconds (capped at 120 per call) to wait — it returns the moment the job is terminal, so a typical 1-2 minute job needs one call. Do NOT loop with wait_seconds=0; chain at most ~5 waiting calls, then hand the task_id back to the user. When the status is 'failed', pass the returned error_trace to generate_code as previous_error.

Fetch the exports of a completed Meep job. Check get_simulation_status first — calling this early reports that the job is still running, it does not wait. Each export is summarized (arrays as shape/dtype/min/max/mean, scalars exactly), PNG figures are returned inline as images, and every artifact is written to a local file whose path is returned so it can be loaded with numpy. Pickled objects are reported but never decoded.