OGAS SDK

A guide for those who write modules and build programs by script: what OGAS SDK holds, how to write a module in Python and in Rust, how to check it and try it without the platform, how to build a program and put a thing on a showcase. Here, too, is how the platform itself is extended: a function, a kind of node, an element of the pulpit, a window.

Introduction

Everything needed to write a part of the platform without looking into finished ones is gathered here. If the work made you look into someone else's module, that is a flaw of this document, and it is the document that gets fixed. The contract of the messages — Methods of modules, the format of the manifest — File formats, section 4, the notions — Modules. Anything new is agreed with Rules of development, 4.7.

What OGAS SDK holds. The folder sdk/ of the installation:

sdk/
  ogas-sdk            the command, with nothing to install
  python/             the code of a module in Python and the package ogas
  rust/               the package ogas-module for a module in Rust
  templates/          templates of modules
  networks/           networks of the assistant — ready modules
  examples/           examples
  tests/              checks of the SDK and test modules

A module in Python writes from ogas_runtime import …: the platform puts sdk/python on the PYTHONPATH of every module. The package ogas is for programs that talk to the platform from outside: build scripts, editors, checks. To install it as a Python package — pip install -e sdk/python, and the command is then simply ogas-sdk.

Table 1 — The command ogas-sdk

With the key --json the command answers with one JSON document: that is how another program calls it.

Table 2 — What is written in what

1 A module in Python: the first module

1.1 The folder

The template is made by module.create; by hand, a folder is put into modules/<id>/ (Modules, section 2):

modules/shout/
  manifest.json          ports and parameters: the only source of the contract
  main.py                the code
  requirements.txt       Python dependencies, each with its version: name==1.2.3
  locales/ru.json        words for the person
  locales/en.json

1.2 The manifest

{
  "format": "ogas.module/1",
  "id": "shout",
  "version": "1.0.0",
  "name_key": "module.shout.name",
  "description_key": "module.shout.description",
  "runtime": "python",
  "entrypoint": "main.py",
  "inputs": [{ "name": "input", "required": true, "type": "text" }],
  "outputs": [{ "name": "success", "type": "text" }],
  "input_policy": "all",
  "parallelism": 1,
  "process": "step",
  "execution_semantics": "idempotent",
  "retry": { "max_attempts": 1, "delay_ms": 0, "exponential": false },
  "parameters": {
    "times": { "type": "integer", "default": 2, "min": 1, "max": 10 },
    "loud": { "type": "boolean", "default": true },
    "mark": { "type": "string", "default": "excl", "choices": ["excl", "dot"] }
  },
  "permissions_info": { "network": false, "filesystem": "module-and-run-only" },
  "timeout_ms": 10000,
  "runtime_python": ">=3.11"
}

Types of a parameter: string, integer, number, string[], color, boolean — yes or no, model — a neural network of one kind ({ "type": "model", "kind": "llm", "default": "name" }). choices is a closed set of codes. In process: step — an OS process for a step, ending after the step; long — lives on and keeps the network in memory; service — lives while the program is on and gives data by itself. resources.gpu_mb is how much video memory the module takes together with its neural network: by it the function of modules unloads those that stand idle, and the library tells the person whether the module, and a program with it, will start on their video card; a module that takes the video card names it honestly (1.9). suspend: true — the module keeps the memory of its node and saves it before it is unloaded (1.8).

1.3 The code

from ogas_runtime import Refusal, extract_text, parameters, reply, run_step

MARKS = {"excl": "!", "dot": "."}


def handle(params: dict) -> dict:
    options = parameters(params)
    text = extract_text(params.get("input"))
    if not text.strip():
        raise Refusal("Nothing to shout", code="no_text")
    said = (text.upper() if options["loud"] else text) * options["times"]
    return reply("success", {"text": said + MARKS[options["mark"]]})


if __name__ == "__main__":
    run_step(handle)

stdout belongs to the protocol: a module writes its own things to stderr or with send_log. print in a module breaks the exchange.

1.4 Parameters: one default

A default lives only in the manifest: the platform puts it in before the step, and a parameter is read by its name.

A closed set comes as a code, not a word. The word lies in the dictionary of the module; on the pulpit the element «Choice» keeps the code in options and the word in titles (File formats, table 6). There are no tables of pulpit words in the code of a module. A pulpit switch comes as true or false into a parameter of type boolean.

A value from a variable ({ "variable": "id" }) is put in by the platform at the moment of the step and is not checked against choices. The module gets the code the pulpit put there.

1.5 What comes in

params["input"] depends on the inputs of the node (The program: graph and runs, section 6):

• one hot input — the data as it is;
• there is a cold input, or the rule all gathered several — a record by the names of the inputs: { "request": …, "image": … }; there is no field input_port then;
• several links to one input are waited for only with the rule of the node input_policy: "any" or through «Merge»: otherwise the second piece of data is not taken.

The data come from someone else's node and are sometimes deeper than the module expects: the answer of a question — { "question": <data>, "answer": <answer> }, a selection — a record with mask, cutout and picture, a button of the pulpit — a record by the names of the fields of carries. So a file and a value are searched for, not addressed:

picture = find_file(given, "picture", "image", media="image/")
mask = find_file(given, "mask", media="image/")
path = file_path(params, picture)
words = find_value(given, "words", "target")

find_file first looks for the named fields at any depth, then for any file. Only file_path gives the path to a file; a file from someone else's step is only read (The program: graph and runs, 24.4).

A folder or a file the person typed on the pulpit is read through person_path(said): D:\Photos becomes /mnt/d/Photos.

1.6 What a step gives

name = "frame.png"
picture.save(new_file(params, name))
made = file_ref(name)
return reply("image", {"picture": made, "width": picture.width}, [made])

A result file is written only into the work folder (new_file) and named in the third argument of reply: so it becomes a result of the run, and the reference in the output a real one. Writing into a folder of the person does not count as a result.

1.7 Refusal and words

Refusal("a text for the journal in English", code="no_face") — a refusal with its reason; the text for the person lies in module.<id>.error.no_face of both dictionaries. retryable=True — repeat by retry.max_attempts. Any other exception is a failed step.

The words a module shows in data are taken from the dictionary: say("said.remove", target=target) reads module.<id>.said.remove in the language of the interface and fills the places {target}.

Table 3 — Keys of the dictionary of a module

Each dictionary speaks its own language in the person's words: the name of a sampler is written with an explanation — «Euler a — lively, with scatter».

1.8 A long module and the memory of a node

run_long(handle, on_suspend=save) keeps the module up; the handler gets cancelled as well — a threading.Event. It is looked at between parts of the work, raising Cancelled. send_progress(share) moves the bar on the pulpit.

A module is one for all its nodes, so memory is kept by node:

memories = NodeMemories(lambda folder, was_saved: Node(folder, was_saved))

def handle(params, cancelled):
    node = memories.of(params)
    ...

def save():
    for node in memories:
        write_memory(node.folder, node.values, mark)

run_long(handle, on_suspend=save)

Rules of memory:

• memory lies in state_dir(params) and is read only when resumed(params): otherwise it may be someone else's or half-written;
• what depends on the weights is checked by model_mark(path): other weights give another mark, and read_memory returns None;
• writing is only whole: write_memory or with whole_file(path) as aside:;
• suspend: true in the manifest is a promise: a module without memory does not set this field;
• at on_suspend the module is no longer in the middle of a step: the platform does not unload a working module.

1.9 Neural networks

A model is chosen by a parameter of type model; chosen_model(params, "network") gives the path or None. Neural networks lie in models/<kind>/<name> — a file, a folder or a link (Modules, section 11).

A module is written for a family of models, not for a version: the family is recognised by the files of the network (model_index.json, the keys of the weights), common loaders are taken, and anything unfamiliar is refused in words: Refusal(…, code="unknown_network"). Heavy libraries are imported inside functions, so that the module comes up and answers ping quickly. At the start of the file stands os.environ.setdefault("HF_HUB_OFFLINE", "1"): a step downloads nothing.

Where to get the default neural network, a module says in the field sources of its parameter — then the library of the program shows that it is missing and downloads it at a button (Modules, section 11):

"network": {
  "type": "model", "kind": "llm", "default": "Qwen2.5-7B-Instruct-bnb-4bit",
  "sources": [{ "source": "huggingface", "id": "unsloth/Qwen2.5-7B-Instruct-bnb-4bit" }]
}

source is the kind of source: huggingface, civitai or ogas; id — how the source names the thing; the optional files — which files to take; without it, those the source offers itself: .safetensors and what comes with them. The default name is the one under which the network will stand in the folder of networks. The form of the field is checked by the platform when it accepts the module (module.validate).

ogas_models gives what is common: TensorMemory — memory with tensors, drawing_progress — the bar and cancelling for diffusers pipelines, thumbnails — thumbnails of pictures from disk for the pulpit, hub_snapshot — weights from the Hugging Face cache, text_network, chat_prompt, layers_of and Light — for text networks. Its dependencies (torch, safetensors, pillow, transformers) the module names in its own requirements.txt.

1.10 What a module brings with it

A program — in bin/, the path to it is given by module_dir(); licences — in licenses/. What was built on your own machine must not keep the home folder: Rust is built with RUSTFLAGS="--remap-path-prefix=$HOME=/build".

1.11 The check

sdk/ogas-sdk check modules/shout
sdk/ogas-sdk try modules/shout --input '{"text": "hello"}'

The check reads the files of the module without starting it and names the place and what to do (table 4). The same for all modules of the repository is asked by make ci.

Your own tests lie in test_<id>.py beside main.py. ogas_check.execute(folder, input, parameters) carries one step from start to stop, putting in the defaults of the manifest as the platform does; for a function of the module called directly, the parameters are given through with_defaults(manifest, parameters).

Table 4 — What ogas_check.py names

2 Reference of the SDK for Python

It lies in sdk/python, on the PYTHONPATH of a module.

Table 5 — ogas_runtime: the loop and the exchange

Table 6 — ogas_runtime: reading a step

Table 7 — ogas_runtime: the answer, memory, words

Table 8 — ogas_models

Table 9 — ogas_check

3 A module in Rust

A module in Rust is an executable file with "runtime": "native" and "entrypoint" — the path to it in the module folder. The SDK is the package ogas-module in sdk/rust; it depends only on serde_json and is built apart from the platform:

[dependencies]
ogas-module = { path = "../runtime/rust" }
serde_json = "1"

use ogas_module::{reply, run_step, Refusal, Reply, Step};
use serde_json::json;

fn handle(step: &Step) -> Result<Reply, Refusal> {
    let text = step.input()["text"].as_str();
    let text = text.ok_or_else(|| Refusal::new("Nothing to shout").code("no_text"))?;
    let said = text.repeat(step.integer("times")? as usize);
    Ok(reply("success", json!({ "text": said }), &[]))
}

fn main() {
    run_step(handle);
}

The manifest, dictionaries, folder, memory and rules are the same as in section 1; rules 1.4–1.10 do not depend on the language. A panic in a step is a failed step, not a fallen module. A full example — a step module and a long one with the memory of a node — is sdk/rust/examples/double.rs. The example above is the file sdk/rust/examples/shout.rs, the example of section 5 — core/protocol/examples/function.rs: cargo test builds them, and make ci compares the text here with these files word for word.

Table 10 — The SDK for Rust beside the SDK for Python

The check: cargo test in the package of the module; the contract by files — the same ogas_check.py (the manifest, dependencies, what is brought along). How the SDK checks itself — sdk/rust/tests/protocol.rs.

4 A module in another language

The protocol is read in Methods of modules, section 1: lines of JSON through stdin and stdout, init with { "status": "ready", "protocol": 1, "capabilities": […] }, execute, cancel, ping, suspend, configure. The model of behaviour is the sources of the SDK; a conversation with a module is checked by ogas_check.start, send and read_json.

5 A function of the platform

A function is a separate OS process and a Cargo package; the folder of a new function enters the workspace by itself. The rules — Rules of development, 2.3–2.6. The make-up of the folder — The make-up of the platform, Appendix A, A.3.

1. The folder functions/<id>/ with Cargo.toml, src/main.rs, src/state.rs, src/codes.rs, src/constants.rs, locales/{ru,en}.json.
2. function.json — what the function is (File formats, section 3): requires, optional, contract, restart.
3. An entry in the register core/data/functions.json.
4. main.rs only starts and hands out:

use ogas_protocol::{run_function_loop, RpcError, StartedFunction};
use serde_json::{json, Value};

fn handle(method: &str, _params: Value) -> Result<Value, RpcError> {
    match method {
        "function.health" => Ok(json!({ "status": "ok" })),
        _ => Err(RpcError::domain(
            ogas_protocol::codes::METHOD_NOT_FOUND,
            format!("Unknown method {method}"),
            false,
        )),
    }
}

fn main() {
    let StartedFunction { client, .. } =
        ogas_protocol::start_function(env!("CARGO_PKG_VERSION"), |spec, _| {
            spec.queries = vec!["function.health".into()];
            spec.commands = vec![];
            spec.events = vec![];
        });
    run_function_loop(
        client,
        move |method, params, _| handle(method, params),
        |_| {},
    );
}

start_function reads the environment, connects to the kernel and introduces itself; if that fails, the function ends with its reason. The line spec.commands = vec![…] is read by the check of the contract too, so the names are listed here and not gathered by code. The description gets spec and the installation folder: spec.locales, spec.surfaces, spec.capabilities are added there as well.

The handler of each request runs in its own thread. Other functions are called through client.request(method, parameters, QUERY_TIMEOUT): there are no direct ties between functions. A refusal is RpcError::domain(code, text, retryable); codes are declared in src/codes.rs, and given their text in Error codes and the dictionaries. Settings — settings.schema.json and its registration at the start of main; without the function of settings, the defaults of the schema work.

Every method and event is written into the contract, docs/contract/: make ci compares the list of the function with the documents. Code common to two functions goes into core/protocol, not copied.

6 A kind of node

A kind is justified only if it is a primitive: that is rule ЗС-10 in Kinds of nodes. The folder functions/graph/src/kinds/<id>/ holds:

• the description kind.json — what the kind says of itself: family, inputs, outputs, template.parameters — what a new node begins with, fields — what the person sets, the icon glyph; the engine, the checks and the window ask it and keep no tables;
• the code mod.rs — pub(crate) const KIND: Kind = Kind { id: ID, description: include_str!("kind.json"), step: Some(step), ..NOTHING }; and the function of the step; check — the node's own check, hand_out — the value of a cold input;
• the words of the kind in locales/{ru,en}.json and the checks in tests.rs.

A kind is entered by a line in KINDS of the file kinds/mod.rs, the only list, and by a card in Kinds of nodes.

7 An element of the pulpit

The set is closed and is extended by the platform (The workshop, 6.2).

1. The folder functions/canvas/src/elements/<id>/: element.json — kind, family (input, show, action, decoration), bindings, parameters, size, min_size, states; locales/{ru,en}.json. A parameter has how: number, text, choice, list, image, model_kind.
2. An entry in ELEMENTS of the file elements/mod.rs.
3. The drawing — functions/ui/window/ui/pulpit/elements/<id>.js with draw(state, element, { name }) and a line in index.js; what it shows for a look — shows.
4. A row in table 6 of File formats and a description of the element in the stub functions/ui/window/ui/tests/fixtures.js: otherwise the page tests draw it as unsound.

A binding to a container is declared as "objects": ["group"]: the check, the mark and the carrying over into a piece work by the description of the kind. A label and a hint (label, hint) are there on every element except a decoration.

8 A window of the workshop

A window is the folder functions/ui/window/ui/host/<id>/ with index.js (WINDOW: kind, drawing, the view, the panel, fields, tests), words locales/{ru,en}.json, a style and checks; a line in host/index.js, the only list of windows. Colours and sizes are tokens of style.css, words go through t(key), requests through rpc of lib/rpc.js, writing the state through commit(). The page is built into the window program: after a change make window is needed. The page tests run in the window itself: in the stub stubbedPlatform the page calls the platform by itself as well, so a call is looked for by its method, not taken as the last one.

9 A program by script

A script builds a program in a working platform through the door for programs. The door is closed until the person opens it in the settings of the platform («Door for programs» → «Open»); the platform writes the port and the key into gate.json of the data folder, and Platform.connect() finds it by itself — in the data folder of the installation where the SDK lies, or in the one named by the variable OGAS_DATA_DIR. A program with the key of the door can do in the platform everything the person does in the workshop, except stopping the platform and changing the door itself (Methods of the platform services, section 5).

from ogas import Platform, Program

program = Program("Hello", "Writes the name into the answer.")
program.variable("name", "text", "")
program.variable("said", "text", "")
program.event("go", source="pult")
program.node("say", "write", {"variable": "said", "mode": "replace"})
program.edge("go", "say", target_port="value")
window = program.window("window_1", "Hello", sheet=(560, 300))
box = program.group("g_main", "Hello", window)
program.element("field_name", "field", box, {"value": "var:name"}, "Name", "Whom to greet.", (24, 48, 480, 52), writes="typing")
program.element("button_go", "button", box, {"act": "event:go", "carries": {"text": "var:name"}}, "Say", "Write the name into the answer.", (24, 112, 200, 52))

with Platform.connect() as platform:
    print(program.save(platform))

sdk/ogas-sdk run build.py

Table 11 — The package ogas

What to remember in the graph:

• a node of a module has one hot input; the rest are cold ones from «Variable» nodes, or parameters { "variable": "id" };
• a write where several paths meet — with input_policy: "any";
• what the next step reads is written in a chain: the output of a «Write» node carries the same data, and a choice comes after the write;
• a button carries data in the field carries; input fields write their variable themselves;
• a step after which what it was about must be read again gives that in its output too — a number, a key: the next step gets the data of its output, not of the button.

What to remember when building and trying:

• a program that is on is not saved: process.save answers process_running — first process.program.off (Program.save does it itself);
• the module was changed after the program was saved — save the program again: a module that differs from what is written in modules.lock.json is not started by the platform, and the window says that the files of the module changed;
• an open face of a program keeps the pulpit read when it was opened: what a script wrote shows when the face is opened anew;
• a «Label» is one line: a paragraph is made of several labels one under another;
• the frame of a group on the page is counted by the function of the pulpit — a head and margins around what lies in the group (File formats, section 7) — so groups side by side are placed with a gap wider than two margins, or the frames run into one another; Program.save looks at them before writing, by the box of the containers in the answer of canvas.preview (Methods of the workshop and the pulpit).

10 The rules of the platform in a module

A module is a part of the platform and keeps its rules (Rules of development, 1.2.1); how each rule applies to a module is shown by Appendix A of the Rules of development, and the threats a module guards against — by Protection, section 3. Table 12 says what follows from them for the author of a module and who keeps it: what can be seen by the files is named by ogas_check.py (table 4), the rest is kept by the author. The check only names a breach and changes nothing in the module.

Table 12 — The rules of the platform and a module

Sections 4 and 5 of the Rules of development — the order of development and the documentation — are kept by whoever runs the platform; for a module, of them follows only the confirmation of readiness by a check (4.5).

11 What is checked by itself

Table 13 — Checks

12 The program: documents, nodes and the pulpit

A reference of what a program is built of — by hand in the workshop or by script (section 9). Everything there is is named here, with its form in the document; the exact rules of each are where the link leads.

12.1 The documents of a program

A program is the folder data/processes/<process_id>/ (File formats, section 5):

• the graph — process.json, format ogas.process/4: id, name, description, nodes, edges, variables, groups; the owner is the function of the graph, it is written by process.save and the workshop (File formats, 5.1);
• the pulpit — workspace.json, format ogas.workspace/3: groups — containers, elements — elements, the optional theme and bindings; the owner is the function of the pulpit, it is written by canvas.save and the workshop (File formats, section 7);
• the settings of this process over the common ones — settings.json (File formats, section 8); the versions and prints of modules — modules.lock.json (File formats, section 9);
• the remembered values of variables (remember: true) — state.json, written by the platform (File formats, 5.2); the files of the process, pictures and looks of the pulpit lie beside (File formats, 16.3, 7.2).

A program is handed over as an export folder (File formats, 10.1): with the modules it takes and the processes it calls. A showcase hands out programs, modules, neural networks and pieces of interface as things ogas.catalog/1 (File formats, 17.1); a piece is a container of the pulpit with everything in it, the document ogas.piece/1 (File formats, 7.4).

12.2 Node, link, variable

{
  "nodes": [
    { "id": "go", "kind": "event", "x": 0, "y": 200, "parameters": { "source": "pult", "overlap": "skip" } },
    { "id": "read", "kind": "module", "module_id": "cdr_svg", "x": 280, "y": 200, "parameters": { "precision": { "variable": "precision" } } },
    { "id": "keep", "kind": "write", "x": 560, "y": 200, "parameters": { "variable": "parts", "mode": "replace", "path": "count" } }
  ],
  "edges": [
    { "id": "go.event-read.drawing", "source_node": "go", "source_port": "event", "target_node": "read", "target_port": "drawing" },
    { "id": "read.drawing-keep.value", "source_node": "read", "source_port": "drawing", "target_node": "keep", "target_port": "value" }
  ],
  "variables": [
    { "id": "precision", "type": "number", "initial": 1, "remember": true },
    { "id": "parts", "type": "number", "initial": 0, "remember": false }
  ]
}

• A node — id, kind (12.3), its place x, y, parameters; a module also has module_id; optional are name, description, input_policy (all — wait for all inputs, any — work with each), region — the frame the node stands in (The program: graph and runs, sections 4, 6, 11).
• A parameter is taken from a variable by the record { "variable": "<id>" }: the value is put in at the moment of the step (The program: graph and runs, section 15).
• A link goes from an output to an input: source_node, source_port, target_node, target_port; the ports are named by the kind of the node (12.3) or the manifest of the module, and a module has one more output, failed (The program: graph and runs, 12.4).
• A variable — id, type — one of the kinds of data: text, number, boolean, time, list, image, audio, video, file, json; initial, remember, the optional scope: "run" — its own for each run (The program: graph and runs, section 7).
• A group is a layer over nodes with a face of its own (The program: graph and runs, section 17); a call of another program by a process node is unfolded before the run (The program: graph and runs, section 18).

12.3 Kinds of nodes

Each kind of node is described by a card in the catalogue — Kinds of nodes, Appendix A: what it does, the inputs and outputs with what comes to each, what the person sets, how many ports there are and where the rules are. An overview of the catalogue is there too, tables 4–13. What a kind gets when it is placed and what choices its fields have is its description functions/graph/src/kinds/<kind>/kind.json: inputs, outputs, template.parameters, fields with choices; the workshop shows the same on the node.

Five kinds are enough for a first program: event — the work begins with it (for a button of the pulpit source: pult), module — the work of a module, write — put data into a variable the pulpit shows, variable — take the value of a variable as a cold input, show — show data on the node and on the pulpit.

12.4 The pulpit: containers and elements

{
  "groups": [
    { "id": "window_1", "name": "Site", "holds": "tabs" },
    { "id": "tab_waiting", "name": "Waiting for a look", "parent": "window_1", "screen": { "sheet": [1240, 900] } },
    { "id": "g_list", "name": "List", "parent": "tab_waiting" }
  ],
  "elements": [
    { "id": "button_refresh", "kind": "button", "group": "g_list", "label": "Refresh", "hint": "Ask the server what is waiting.",
      "bindings": { "act": "event:refresh" }, "screen": { "place": [24, 48], "size": [240, 52] } }
  ]
}

• A container — id, the optional name, parent; holds: together — all at once (the default), tabs — one at a time, as tabs; screen.sheet — the sheet of the page [width, height]; bindings: shown — a variable of type boolean, open — for tabs: which is open; look — the look (File formats, section 7). A window is a container without parent.
• An element — id, kind, group, label — its label, hint — its hint: what it sets and which way to turn it, bindings, parameters, screen — place and size in units of the sheet, look.
• A label and a hint are there on every element except a decoration: the window shows the hint when the pointer is held over it and reads it to a screen reader.

The elements with their bindings and parameters — table 6 of File formats, their states for looks — table 7 there; what a kind of element takes is its description functions/canvas/src/elements/<kind>/element.json. A binding names an object of the graph: var:<id> — a variable, event:<node_id> — an event of the pulpit, cancel:, retry: — stop and retry it, status: — how the run goes, progress: — the course of a step of a module, out:<node_id>/<output> — the last thing an output gave, show: — what «Show» showed, ask: — an open question, signal: — a signal a node waits for, program — whether the program is on; what each object means and what the pulpit does with it — The program: graph and runs, table 5.

12.5 A parameter of a module on the pulpit

A parameter of a module on the pulpit is a variable the node takes into the parameter by the record { "variable": "<id>" }, and an input element bound to it. The element is chosen by the type of the parameter in the manifest; the limits, the choices and the first value come from there too, the label and the hint from the dictionary of the module (module.<id>.param.<name>.title and .help): the person sees on the pulpit the same words as on the node.

A long set of settings is written by the script itself — from the manifests of the modules: so a field does not drift from its parameter when the module changes. A button with the binding resets returns the fields of its container to their first values.

12.6 The requests a program is built and tried with

A script and a check call the platform with the same requests as the workshop; each is described in the contract of its function:

• the graph — Methods of the graph: process.list, process.create, process.open, process.save, process.validate, process.group.wrap — gather nodes into a group, process.export and process.inspect — hand over and look at what was brought; to switch on and try — process.program.on, process.program.off, process.event.fire, process.variable.set, process.variable.list, process.run.status, process.snapshot, process.runs.list, process.run.stop, process.run.retry, process.run.resume, process.ask.list, process.ask.answer, process.signal.send, process.message.send, process.program.list;
• the pulpit — Methods of the workshop and the pulpit: canvas.get, canvas.save;
• modules — Methods of modules: module.install — install the Python environment of a process;
• settings and the journal — Methods of the platform services: settings.set, settings.reset, observe.logs.query.

13 A network of the assistant

The assistant of the workshop thinks with the network the person chose. A network is a module with "role": "assistant_network": the input request, the output reply. Ready networks come with OGAS SDK (sdk/networks): by the OpenAI protocol — spoken by OpenAI, DeepSeek, OpenRouter, Mistral, Groq, Qwen, xAI and the local servers Ollama, LM Studio, llama.cpp, vLLM — Anthropic, Gemini, GigaChat, YandexGPT and a local network from the folder of networks. The panel of the assistant puts the chosen one into the folder of modules. Another provider is added by a module of your own with the same contract.

The request that comes to the module:

{ "system": "…",
  "messages": [ { "role": "user", "text": "…" },
                { "role": "assistant", "text": "", "calls": [ { "id": "c1", "name": "programs_list", "arguments": {} } ] },
                { "role": "tool", "call_id": "c1", "name": "programs_list", "text": "…" } ],
  "tools": [ { "name": "draft_create", "description": "…", "schema": { "type": "object" } } ],
  "limit_tokens": 4000 }

The answer of the module — reply("reply", { text, calls, usage: { input_tokens, output_tokens }, model }). What all networks share lies in ogas_assistant; the module only has to put the request into the language of its service and the answer back. The module reads the key of the service by secret("NAME") from its .env, and names its secrets in the field secrets of the manifest: by it the panel of the assistant asks the person for the key and writes it into .env.

Table 14 — ogas_assistant

The refusal codes of a network are no_key, no_model, unreachable, service_refused, bad_answer; their texts lie in the dictionaries of the module, as with any refusal (1.7).

14 Examples

sdk/examples/ holds modules and programs that run. word_count is a module with a parameter and a refusal, and a program for it built by script through the door:

sdk/ogas-sdk try sdk/examples/word_count/modules/word_count --input '{"text": "one two two"}'
cp -r sdk/examples/word_count/modules/word_count modules/
sdk/ogas-sdk run sdk/examples/word_count/build.py

Programs of several modules lie in sdk/tests/live/: a backup copy of a folder (backup), reading invoices (invoices) and others; networks of the assistant — in sdk/networks/.