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] -> core:a
    <- b[number] -> core:b
    -> result[number] -> adder:result

    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/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 }:

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

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