Documentation / Web Models
Build focused intelligence into your website.
Use focused models for search, moderation, and prompt expansion. Find integration guides, runtime details, model development notes, and the Robotron IR reference in one place.
01 / Web model
Website search
Map a visitor’s natural language request to a small, explicit search schema. Keep the final query construction and access control in your application.
input: “waterproof hiking boots under €150”
output: {
"category": "hiking boots",
"waterproof": true,
"max_price": 150
}
User controls / Search
Search in your own words.
Type or speak what you need. The search model returns a structured tool call that becomes editable search controls. Review the query, budget, categories, compatibility, sizes, exclusions, and tags before using the updated JSON with your catalog.
A little detail. A better search.
Sample loaded · explore the filters below, or build a search from your prompt.
Your search, refined.
Edit any value. Add or remove chips to refine your filters.
This sample needs a few corrections
The sample changes 16 GB RAM, 16 inches, and $2,100 to 15 GB, 15 inches, and $1,900. It also adds student compatibility and excludes Chromebook. Review these suggestions; RAM and storage are part of the query.
This demo prepares your search request. Connect it to a catalog to return products.
Developer details Prompt, response & JSON
Prompt sent to the agent
Paste an agent response
Render a search tool-call array, with or without the framing tokens.
Updated search JSON
The prompt uses the browser search model. Voice input uses the browser’s speech recognition service. To integrate the generated result, strip the framing tokens, validate the search tool-call schema, and map the fields to controls while preserving their value types.
02 / Web model
Content moderation
Classify submitted content against a versioned policy taxonomy. Use explicit categories and a review path so policy decisions remain inspectable.
input: title + body
output: {
"category": "needs_review",
"reason": "possible personal information",
"confidence": 0.81
}
03 / Web model
Prompt expansion
Expand a short request into a reusable task prompt that supplies missing context and output constraints. Preserve the user’s intent and avoid adding unsupported facts.
input: “summarize this return policy”
output: “Summarize the return window, item conditions,
refund method, and any exclusions. Use bullets.”
Keep the expanded prompt visible to the next stage as ordinary text. Apply length limits, template boundaries, and policy checks before sending it to another model or service.
04 / Get started
Installation
Run inference in a private backend service. The service loads a Robotron IR model artifact once at startup and reuses the engine for incoming requests.
// src/inference.js
import { RobotronInferenceEngine } from "../cmir-web/backend.js";
export const inference = await RobotronInferenceEngine.load({
modelPath: new URL("../models/search-model.ir", import.meta.url),
task: "generation",
backend: "js",
});
This project currently exposes the JavaScript backend from its cmir-web source. See the backend quick start for request validation and API route examples.
05 / Execution
Runtime
The runtime validates the model artifact, prepares memory, and executes its operations on a target. The application contract and model task stay stable while execution is adapted to the deployment hardware.
Robotron IR sits between training and execution: it carries the graph, tensors, tokenizer, task metadata, limits, and integrity records. Read the IR and backend guide →
06 / Model development
From task contract to model
A model begins with a repeated decision and a precise promise. Define accepted inputs, valid outputs, error costs, confidence policy, and human fallback before choosing an architecture.
For the deeper architecture and export explanation, see the model build guide →
07 / Runtime and format
Robotron IR and backend integration
Use Robotron IR as the boundary between a trained model and its target runtime. These guides cover backend setup, service lifecycle, deployment targets, the artifact contract, and production checks.
01 / Intermediate language
IR is the boundary, not the interface.
Training frameworks are good at creating models. Target runtimes are good at executing them. Robotron IR keeps those two concerns separate by describing the model graph, tensors, tokenizer, task metadata, labels, limits, and integrity records in a versioned artifact.
Architecture, task data, learned weights, and selected checkpoint.
Graph, tensors, tokenizer, metadata, and integrity.
JavaScript, C/ARM, CUDA, or a custom-chip runtime.
02 / Node.js backend
Load the engine when the service starts.
Import the server-facing wrapper, load the IR artifact from a private local path, and reuse the same engine for every request. The JavaScript backend is the portable default for Node.js; select another target runtime when deploying to ARM, CUDA, or custom silicon.
// src/inference.js
import { RobotronInferenceEngine } from "../cmir-web/backend.js";
export const inference = await RobotronInferenceEngine.load({
modelPath: new URL("../models/content-model.ir", import.meta.url),
task: "generation",
backend: "js",
activationQuantization: "int8",
});
console.log("Robotron inference ready", inference.health());
Do this once
Read and validate the artifact, allocate model state, initialize the target backend, and warm the engine.
Do this per request
Validate input, call the loaded engine, shape the result, record metrics, and return an application response.
03 / HTTP integration
Expose a narrow backend endpoint.
The endpoint owns validation and generation policy. The caller sends business input—not engine configuration—and receives only the fields the application contract allows.
// src/server.js
import http from "node:http";
import { inference } from "./inference.js";
const server = http.createServer(async (request, response) => {
if (request.method !== "POST" || request.url !== "/api/content/analyze") {
response.writeHead(404).end();
return;
}
try {
const chunks = [];
for await (const chunk of request) chunks.push(chunk);
const { title, body } = JSON.parse(Buffer.concat(chunks));
if (typeof title !== "string" || typeof body !== "string") {
throw new TypeError("title and body must be strings");
}
if (!body.trim() || body.length > 20_000) {
throw new RangeError("body must contain 1 to 20,000 characters");
}
const prompt = `title: ${title}\nbody: ${body}\nlabels:`;
const result = inference.generate(prompt, {
maxNewTokens: 64,
temperature: 0,
topK: 1,
});
response.writeHead(200, { "Content-Type": "application/json" });
response.end(JSON.stringify({ output: result.continuation }));
} catch (error) {
const status = error instanceof TypeError || error instanceof RangeError ? 400 : 500;
response.writeHead(status, { "Content-Type": "application/json" });
response.end(JSON.stringify({ error: status === 400 ? error.message : "Inference failed" }));
}
});
server.listen(3000);
04 / Service lifecycle
One engine, many requests.
- 1Start
Resolve the model version, load the IR artifact, verify integrity, and initialize the selected execution backend.
- 2Warm
Run a representative request before the instance enters the load balancer so initialization cost never reaches a user.
- 3Serve
Validate inputs, bound work, execute inference, and publish latency plus task metrics without logging sensitive content.
- 4Drain
Stop accepting new work, finish in-flight requests, call
inference.close(), and then terminate the process.
async function shutdown(signal) {
console.info(`${signal}: draining inference service`);
server.close(() => {
inference.close();
process.exit(0);
});
}
process.on("SIGTERM", () => shutdown("SIGTERM"));
process.on("SIGINT", () => shutdown("SIGINT"));
05 / Content model
Use classification for structured decisions.
For classification models, load the taxonomy beside the IR artifact. The backend returns a task result and runtime metrics; your API should map that internal result into the smaller public schema used by the content-management system.
const contentClassifier = await RobotronInferenceEngine.load({
modelPath: new URL("../models/content-classifier.ir", import.meta.url),
taxonomyPath: new URL("../models/content-taxonomy.json", import.meta.url),
task: "classification",
backend: "js",
});
const { result, metrics } = contentClassifier.classify(articleText);
// Keep metrics internal; return only the application contract.
const response = {
category: result.primary_label,
confidence: result.confidence,
action: result.action,
};
| Layer | Owns | Should expose |
|---|---|---|
| IR artifact | Graph, weights, tokenizer, model limits | Nothing directly to users |
| Inference service | Engine lifecycle, model version, runtime policy | Health and task endpoints |
| Application backend | Authentication, authorization, business rules | Stable domain objects |
| Frontend | User interaction and presentation | Only user-approved inputs and results |
06 / Target runtime
Keep the API stable while the engine changes.
The backend contract remains the same when the execution target changes. Package the IR artifact with the engine built for the destination hardware, run target-specific parity tests, and switch traffic only after the new service passes its health gate.
JavaScript backend
Portable server integration and development on Node.js. Use a long-lived process and keep artifacts outside the public directory.
C / ARM backend
Link the target runtime into a native service or sidecar for CPU-first edge and embedded deployments.
CUDA backend
Run GPU kernels behind the same application endpoint when throughput or model shape justifies acceleration.
Custom silicon
Map supported IR operations to the device SDK, memory model, and native kernels through a target adapter.
Sidecar process
Keep application code independent of runtime language by calling a local inference process over a private socket or loopback port.
Dedicated service
Scale inference separately, centralize model rollout, and place authentication plus rate limits at the service boundary.
07 / IR contract
What the intermediate language carries.
Identity
Model name, architecture, task, version, labels, input contract, and maximum sequence length.
Graph
Typed values, ordered operations, inputs, outputs, attributes, tensor shapes, and symbolic dimensions.
Storage
Aligned tensor bytes, data types, quantization records, scales, offsets, and integrity digests.
Text interface
Tokenizer payload, vocabulary, special token IDs, normalization rules, and decoding behavior.
Runtime limits
Supported context, task constraints, operation requirements, and compatible engine version.
Integrity
Container checks, metadata checksums, tensor hashes, and a release manifest supplied with the deployment.
Runtime compatibility
EmbeddingRMSNormLayerNormLinearSplitReshape
TransposeRoPEScaledDotProductAttentionAddMulGELU
PositionIdsSequencePool
An exporter must target the operation subset, tokenizer implementation, data types, and quantization schemes supported by the deployed engine. Unsupported operations fail during loading or execution; they are never silently approximated.
08 / Production gate
Ship the model and service as one release.
- Pin the artifact. Deploy an immutable model version and record its digest in the service release.
- Keep it private. Store IR files outside public static roots and grant read access only to the inference process.
- Validate parity. Compare the exported model with its PyTorch checkpoint on a held-out fixture set.
- Bound requests. Enforce body size, sequence length, generation length, timeouts, concurrency, and rate limits.
- Separate readiness from liveness. Readiness requires a loaded model; liveness only proves the process can respond.
- Protect data. Avoid logging prompts and documents by default; record identifiers, timings, model version, and error class.
- Roll back atomically. Keep the prior engine and artifact pair available until the new release passes live checks.
GET /health/live
200 { "status": "alive" }
GET /health/ready
200 {
"status": "ready",
"model": "content-model@2026-08-30",
"task": "classification",
"backend": "js"
}
09 / Diagnostics
Troubleshooting
| Symptom | Likely cause | Check |
|---|---|---|
| Service never becomes ready | Missing artifact, incompatible IR version, or failed integrity validation. | Check the resolved private file path, release manifest, and startup error class. |
| Unsupported operation | The exported graph exceeds the deployed engine's operation subset. | Export for that engine version or add and test the required target kernel. |
| Unsupported tokenizer | The artifact uses a tokenizer implementation absent from the runtime. | Align exporter and engine releases; never replace tokenization at request time. |
| Results differ from PyTorch | Quantization, precision, tokenizer, or operator semantics differ. | Run layer-level parity fixtures before comparing complete task outputs. |
| First request is slow | The service entered rotation before model loading and warm-up completed. | Gate readiness on a successful representative inference. |
| Memory grows under load | Unbounded concurrency, contexts, outputs, or retained request state. | Add queue limits and inspect memory per in-flight request. |
| Backend returns 500 | Internal engine error was correctly hidden from the caller. | Correlate the request ID with structured server logs; do not return stack traces. |