The whole application is one program.

01

One program contains the parts that belong together

A kanban board, complete: a manifest, a login, two entities with their rules, the workflow that drives a card's review, two pages, the functions they call, a theme, and the tests. The files are organisation for the person reading them. The compiler reads them as one application model, so a name in one file means what another file declares it to mean: the second page asks CardFlow, declared in board.osy, where a card may go.

02

One component can use different parts of that program

The board page, which chapter 08 read as a component. Read it again for what each line touches: lanes is a live query over two entities; moved and picked are local state; moves asks the workflow; SeedBoard(), TakeMove() and AddCard() are the application's own functions. The colour beside a line is where the compiler resolved it to execute, from what it touches.

  runs in the browser  runs on the server

component BoardPage() {
1  live var lanes = Lane.Include(l => l.Items).OrderBy(l => l.Ordinal).Take(50);

2  on mount { SeedBoard(); }

3  string moved = "";

  action Move(Card card, Lane from) {
    var next = lanes.Where(l => l.Ordinal > from.Ordinal).FirstOrDefault();
    if (next == null) { return; }
    moved = card.Title + " → " + next.Name;
    card.Lane = next;
  }

  action Save() { UnitOfWork.Commit(); }

  Card? picked;

4  live var moves = CardFlow.For(picked).Transitions;

  action Pick(Card card) { picked = card; }

  // ⚠ `picked` IS OPTIONAL — nothing is picked when the page opens — so both actions say so rather than reading
  //   a title off nothing. The render only offers them once a card is picked; that is a guard in the RENDER, and
  //   an action is reachable by a keyboard, a test and a restored page state that the render never gated.
  action Take(Osysharp.Workflow.TransitionView m) {
    if (picked == null) { return; }
5    TakeMove(picked, m);
    moved = picked.Title + " → " + m.Target;
  }

  action Sign() {
    if (picked == null) { return; }
    picked.Signed = true;
    UnitOfWork.Commit();
  }

  string newTitle = "";
6  action Add() { AddCard(newTitle); newTitle = ""; }

The component says what it does. The compiler resolves where each part runs.

03

The data, its rules and its workflow are part of the same program

The entities the page queried, with the rules that decide who may touch them, and the workflow it asked. The rule is part of the entity, so every query over Lane anywhere in the program is compiled under it, the live query in §2 included. That is chapter 05, paying off. The workflow is bound to a field of the entity, so the state a card is in is a value the page can show and the workflow can move.

entity Lane {
  [MaxLength(40)] string Name;
  int Ordinal;
1  [ForeignKey(Lane)] Card[] Items;
2  security { allow read, create, update, delete when IsAuthenticated; }
}

entity Card {
  [MaxLength(80)] string Title;
  [MaxLength(40)] string Owner;
  Lane Lane;
3  CardReview Review;
  bool Signed;
  security { allow read, create, update, delete when IsAuthenticated; }
}

enum CardReview { Drafting, [Label("In review")] InReview, Approved }

workflow CardFlow {
4  Tracks    = Card.Review;
5  Autostart = true;
  Initial   = Drafting;

  event Submit();
  event Approve();
  event Reject(string why);      // takes an argument, so a one-click move cannot complete it — `NeedsInput` says so

  state Drafting {
    subscribe Submit();
    on Submit { goto InReview; }
  }

  state InReview {
    subscribe Approve();
    subscribe Reject(string why);
6    on Approve { when (this.Item.Signed) { goto Approved; } }
    on Reject  { goto Drafting; }
  }

  terminal success Approved { }
}

void TakeMove(Card card, Osysharp.Workflow.TransitionView move) {
1  Workflow.Raise(card, move);
}

void AddCard(string title) {
  if (title == "") { return; }
2  var first = Lane.OrderBy(l => l.Ordinal).First();
3  var card = new Card { Title = title, Owner = "You", Lane = first };
4  UnitOfWork.Commit();
}

04

The compiler resolves where execution belongs

Execution location is a property the compiler derives from the program, and the resolved model is a command away. It is the same resolved program chapter 07's editor reads.

$ osy model --json      # in demo/kanban · abridged

"name": "BoardPage", "route": "/",
"members": [
  { "name": "lanes",    "kind": "query", "side": "server", "live": true  },
  { "name": "moved",    "kind": "state", "side": "client", "live": false },
  { "name": "picked",   "kind": "state", "side": "client", "live": false },
  { "name": "moves",    "kind": "query", "side": "server", "live": true  },
  { "name": "newTitle", "kind": "state", "side": "client", "live": false }
]

"name": "AddCard",
"effects":    { "reads": ["Lane"], "creates": ["Card"], …, "writesData": true, … },
"transitive": { …, "startsWorkflows": ["CardFlow"], … }

moved, picked and newTitle are component state, so they are client. lanes is an entity query and moves asks the workflow, so both are server, and live. AddCard reads and creates entities, so it is a server function. And it never names the workflow, yet the compiler reports that it starts one: it creates a Card, and CardFlow starts on every card. These are facts the compiler derives from the program, and osy model exposes the resolved result. Captured 2026-10-16.

Execution location, and what a line sets in motion, are properties the compiler derives from the program.

05

Those relationships are what one program buys you

The chapters before this one each showed one of these relationships from its own side. Here are five of them at once, as the compiler holds them: each one exists because both of its ends are declared in the same program.

These parts know about each other, because they are declared in one program.

Security can govern a query, a test can run as a person, an agent can be bound by the same rule, and a screen can stay current with the data, because those relationships are inside the program.

06

The same model runs a real application

The board is small enough to read in one sitting. The platform's own control plane, the application that registers, deploys and operates every other application, is written the same way, and the compiler counted it when this page was built.

252 entities · 3,529 functions · 196 components (67 pages) · 38 workflows
1,896 tests in 223 files · 153,458 lines of Osy#, model and tests together

Screen