Skip to main content
Inspect

Inspecting the pipeline

Before anything leaves your machine, after you build, and when the platform compiles. Three instruments cover the loop.

1DebuggerYour machine
before deploy
Inspect each HomValue for tensor_shape, n_axis, n_slots, pt_scale, and levels
2GraphYour machine
after build
The compiled operator tree: where each op runs, and how shape, scale, and levels change
3ReportPlatform
during compile
accuracy · latency · memory, or error in case of failure
adjust, print, deploy again

Before deploy: inspect the state locally​

Before anything leaves your machine, use Python's debugger against your pipeline. Inspect each HomValue for tensor_shape, n_axis, n_slots, pt_scale, active_rows, and active_cols. Look for a shape or a block size that doesn't line up, a scale that outgrows, or a level budget running dry. internal_n belongs to HomParams, so look for it there rather than on the value. The printed graph below is the visual view of the same state on every node at once.

After build: print the compiled graph​

After you build, you can print the compiled graph without sending anything to the server. Add --print_graph to lattica-build.
bash
# build the MNIST example and print the compiled graph
lattica-build --pipeline-module lattica_build.examples.example_mnist_fc --out /tmp/quickstart_mnist.zip --print_graph
After you run with --print_graph, you will see output like this. The tree depends on the pipeline; below is the MNIST example from Build the pipeline.
Reshape stays on the client. The two MatMuls and the Mul (the square) run encrypted. Softmax runs after decrypt. Scale grows after each multiply.
Sections

client_pre, hom, client_post: where the op runs.

Node ids

[0], [0.1.0]: composition and execution order.

Op names

The primitive that ran: Reshape, MatMul, Mul, Softmax.

Value ids

v0, v2: how data flows from one node to the next.

shape and @

Traced shape. @ marks the slots / n axis.

n_slots

The block this value is packed into. It may be smaller than the ring's physical internal_n.

scale

pt_scale at that point in the graph.

q=[…]

Remaining modulus-chain state: the q-list still active on that value.

From the compiler: accuracy, latency, memory​

Compilation gives you feedback regardless of the outcome. If it fails, it tells you exactly what broke. If it passes, it reports metrics you can't measure locally: accuracy, latency, and worker memory usage. Accuracy comes from the trial encrypted run configured by the pipeline's verification_data and its optional expected output and tolerance. A pipeline with skip_verification=True compiles without that trial run or accuracy check.

The loop​

Use the debugger on a single HomValue. Print the graph when you want the whole tree. Then deploy. If the compiler rejects the pipeline, the error sends you back to Build. The debugger shows the HomValue that broke; the graph shows where shape or scale changed. Fix it, print again, deploy, and read the report.

The debugger and the printed graph stay on your machine. Use them after any change to the encrypted body (between preprocess and postprocess). Deploying triggers a compile, so don't deploy on every small change. Treat the report as the final word on verified accuracy, latency, and memory.

Next​

Stage 4

Run Queries

The pipeline checks out. After Key generation, start the worker and send encrypted queries.

→