Patterns

A pattern is a reusable subgraph packaged as a single node. From the outside it looks like any other node — named input and output ports. Internally it contains its own graph of nodes and threads.

Creating a pattern

Add a pattern node to the canvas. Select it and click Open pattern (or double-click the node) to enter the pattern's inner canvas.

Inside the pattern you define:

• Input ports — shown as port-in nodes on the inner canvas. Data arriving at the outer input port flows into these.
• Output ports — shown as port-out nodes. Data arriving here is emitted from the outer output port.
• Internal nodes and threads — anything you can build at the root level can be built inside a pattern.

Patterns are nestable — a pattern can contain other patterns.

Defining ports

Inside the pattern, use the right panel to add input and output ports. Each port needs a name and a type. The ports you define become the pattern's external interface — other nodes connect to them just like any built-in port.

Pattern IDs and titles

Like all nodes, a pattern has an ID (its unique identifier in scope) and an optional title. The ID is used to reference the pattern in thread targets; the title is displayed on the canvas.

Inline patterns in .kti source

In the .kti text format, inline patterns are defined using { } blocks:

pattern:adder | Adds two numbers
<- a[number]
   b[number]
-> result[number]
{
    <- a[number] -> core:a
       b[number] -> core:b

    add:core
    <- a[number]
       b[number]
    -> result[number] -> adder:result
}

Sharing patterns as .ktip files

A pattern can be extracted to a standalone .ktip file and published to GitHub. Other programs can then reference it by URL.

Example reference in a .kti program:

pattern:adder:github.com/kitengi/contrib-patterns/adder.ktip@v1.0.0 | My adder instance
<- a[number]
   b[number]
-> result[number] -> printer:value

The node ID (adder) is declared before the : separator. The ref after the second : is the GitHub URL. The { } body is omitted for external patterns — the implementation is fetched from GitHub at load time.

Versioning

Patterns use the @version suffix at the end of the ref. Use @latest during development, then pin to a specific version for stability:

Version range	Path convention
v0.x, v1.x	github.com/owner/repo/adder.ktip
v2.x	github.com/owner/repo/v2/adder.ktip
v3.x	github.com/owner/repo/v3/adder.ktip

Breaking changes — port renames, removed ports, type changes — require a major version bump.

Test cases

A .ktip file can include test cases after the closing }. Each test case has a name, input values (using <-), and expected output values (using ->):

test | two plus three
<- a = 2
<- b = 3
-> result = 5

test | negative numbers
<- a = -1
<- b = 4
-> result = 3

Tests can be run with the Go or JavaScript runtimes from the command line to validate pattern behaviour.

Running tests in the app

The visual editor also supports test cases directly. When a pattern node is selected, the right panel shows a Tests section where you can:

• View existing test cases defined in the pattern.
• Create new test cases by specifying input values and expected outputs.
• Run individual tests or all tests at once. The pattern is executed in isolation with the specified inputs, and results are compared against expected outputs. Passing tests are shown in green; failures show the expected vs actual values.

Test cases are saved as part of the pattern and are included when you export to a .ktip file.