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 pt_shape, 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 object represented by a HomValue for pt_shape, pt_scale, and levels (active rows and active columns on the q-list). Look for a shape that doesn't line up, a scale that outgrows, or a level budget running dry. The printed graph below is the more visual view of the same three fields, on every node at once. See Ciphertext state → Visualizing it yourself for how to read them.

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.

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.

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 accuracy, latency, and memory.

Next

Stage 4

Run Queries

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