Development Workflow

This page is a high-level map of how you actually use SiMa.ai Neat day to day. Each step links into a deeper page when you are ready.

The Loop

A typical Neat development cycle looks like this:

1. Install — get the sima-neat package (and optionally the pyneat Python bindings) on your host or device.
2. Try Hello Neat — confirm the library is wired up by compiling a minimal example.
3. Pick a compiled model — Neat consumes a compiled model archive (.tar.gz, often called an MPK). Use one from the Model Zoo or compile your own with the Model Compiler.
4. Author a Model / Graph / Run — load the model, compose the graph, and execute it with the smallest runtime path that fits the job.
5. Run and inspect — feed inputs, pull outputs, and use GraphReport / MeasureReport to verify behavior.
6. Iterate with tutorials — graduate from a single inference to pipelines, multi-input models, multi-stream graphs, and production-grade error handling.
7. Deploy — link your application against the installed Neat library on the target device.

Choose Model, Graph, or Run

Start with the smallest surface that solves the job. You can always level up when the app earns more moving parts.

If you need to...	Start with	Why	Next stop
Run one compiled model once	Model.run(...)	Smallest path from artifact to output tensors.	Run Your First Model
Inspect a model contract or route	Model	Specs, metadata, and route info tell you what the model accepts and emits.	Model
Add a model to application flow	Graph	Names inputs and outputs, composes nodes, and keeps topology explicit.	Graph
Reuse a graph over time	graph.build(...) → Run	Gives you push/pull, close/drain control, measurement, and queue policy.	Run a Graph
Push several streams or chase max throughput	RunOptions + measurement	Throughput tuning needs queue policy, drop counters, and per-stream evidence.	Tune Throughput and Queue Depth

If this is your first hands-on path, start with the Tutorials preflight checklist, then run one model before adding graph machinery.

Core Concepts at a Glance

The Development Workflow pages break each of these down in depth. At a glance:

• Model — load a compiled model package and expose it as a runnable unit.
• GenAIModel — the generative-model counterpart to Model.
• Tensor and Sample — the payload and metadata envelope passed between stages.
• Run / Inference — execute synchronously (run) or asynchronously (push / pull).
• Graph — compose model stages, nodes, inputs, and outputs into an application graph.
• Run a Graph — build a graph into a live Run, then push, pull, drain, measure, and tune throughput.
• Node — the atomic building block of a graph.

If you only learn one page first, start with the Run / Inference overview — it ties Model, Graph, and Run together end to end.

Where to go next

Step-by-step entry points for new users:

• Neat Development Environment — install the Palette SDK, pair a DevKit, and run on hardware with dk.
• Build — build Neat from source with build.sh (contributor workflow).
• Hello Neat! — minimal CMake application that links against the installed library.
• Tutorials — guided chapters that scale from "first model" to "production pipeline".

Reference material for when you need depth:

• Run / Inference — concept-by-concept breakdown of Model, Graph, Run, nodes, and I/O.
• C++ Reference — full API surface for the installed headers.
• Python Reference — pyneat bindings reference.

What you write vs. what Neat provides

Neat owns the runtime: model loading, validation, pipeline construction, scheduling, teardown, and diagnostics. You own the application code that wires inputs to outputs and reacts to results. The boundary is the public API in include/, which is treated as stable — you can upgrade Neat without rewriting your application.

If you only remember three lines of code from Neat, remember these:

simaai::neat::Model      model(mpk_path);
simaai::neat::TensorList outputs = model.run(input_tensors, /*timeout_ms=*/2000);
simaai::neat::Mapping    view = outputs[0].map_read();  // inspect the output bytes

Everything else in this documentation — graphs, run handles, async queues, and multistream apps — is a controlled expansion of that core three-line story.