# Osyrin, the runtime

> Osy# is the language. Osyrin is the runtime it executes on, and it is the half of your app you did not write.
> 
> This is what it holds itself to — six principles that decide how your program runs — and what stands behind them.

<!-- id: project-runtime · area: project · stability: stable · html: https://osysharp.com/reference/project/runtime/ -->

## Summary        {#summary}

**Osy# is the language. Osyrin is the runtime.**

You write Osy#. Osyrin is what runs it — the database, the web server, the client, the query your security is
compiled into, the durable engine that keeps a workflow alive across a deploy. It is not a framework you call and
not a host you configure. It is the other half of your app, and it is the half nobody has to maintain.

[Hosting an Osy# app](https://osysharp.com/reference/project/hosting/) is about where it runs. This page is about **what it promises while it does**.

## The six principles   {#description}

### 1. You do not place code. The compiler does.   {#placement}

Every function body has a side — browser or server — and it is INFERRED from what the body touches, not declared.
A body that reads a keyboard is the browser's. A body that reads an entity is the server's. A call that leaves
its side is a round trip, and the compiler knows which ones those are even when the source gives no hint.

The consequence: there is no API between your halves, because there are no halves to bridge. See [How an Osy# app works (the execution model)](https://osysharp.com/reference/project/index/).

### 2. Security is part of the query, not a step before it.   {#security}

`security { }` is compiled INTO the read — a row filter and a field mask inside the SQL, under every query your
program can express. Not middleware, not a guard clause, not a repository that remembers.

This is why no Osy# code can bypass it: there is no code path that reaches rows another way. A read returns your
rows because the query only ever asked for yours. See [The security model](https://osysharp.com/reference/security/index/).

### 3. A function is a transaction.   {#unit-of-work}

The writes a function makes land together or not at all. You do not open a transaction, you do not batch, and you
do not think about the ordering — the unit of work is the function.

### 4. Effects that leave the platform run exactly once.   {#exactly-once}

A database rollback does not un-send an email or un-charge a card, so the calls that reach outside are classified
and made durable: they survive a crash and a deploy, and they do not run twice. There is no retry policy to
author. See [Automatic durability (steps you do not have to write)](https://osysharp.com/reference/workflow/automatic-durability/).

### 5. A run outlives the code that started it.   {#versions}

Deploy while a three-day approval is mid-flight and that run finishes on the model it began under, while new runs
use the one you just shipped. Nothing is drained and nothing is replayed against a shape it never saw. See
[Deploying while workflows are running](https://osysharp.com/reference/project/app-versions/).

### 6. What the tool says is what the compiler did.   {#one-answer}

`osy model`, `osy explain`, the editor's diagnostics and the build all read the same front end. A page cannot
disagree with a hover, and a hover cannot disagree with the error you get on compile — not because they are kept
in step, but because there is one of them.

## What stands behind it   {#evidence}

Principles are cheap. These are the numbers, measured on this commit rather than remembered:

| | |
|---|---|
| **Server tests** | **10,768** test methods across **1,644** classes. A `[Theory]` expands to many cases, so the count a run executes is higher still. |
| **Client tests** | **37,628** across 263 files — the browser runtime, the interpreter, the render walker, the durable bridge. |
| **Osy# tests** | **1,086** `[Test]`s in **130** `.test.osy` files — the language's own test framework, testing real apps against a real database. |
| **Documented examples** | **829** fenced examples compiled through the real compiler into a real app by the docs gate. A page cannot teach a spelling the compiler refuses. |
| **Security invariants** | **675** tagged sites — each naming what must hold, its failure mode, and the test that guards it. |
| **Apps in the tree** | **34**, validated on every merge. They are the samples, the demos and the platform's own control plane. |

⚠ **Read that as coverage, not as a maturity claim.** The language and the runtime are early; what these numbers
say is that the surface is exercised, not that it is finished. [[project-hosting#today]] is the honest account of
which hosting shapes ship today.

## What it is not   {#not}

- **Not an interpreter of your source at runtime.** Client code is lowered and runs as client code; server bodies
  execute as resolved trees against the database.
- **Not a framework.** You do not call it, register with it, or implement its interfaces. You declare, and it
  runs what you declared.
- **Not configurable infrastructure.** There is no host to tune, no pool to size, no scheduler to configure. The
  absence is the design, not a gap waiting for a settings file.

## See also   {#see-also}
- [Hosting an Osy# app](https://osysharp.com/reference/project/hosting/) — where it runs, and what you never set up.
- [How an Osy# app works (the execution model)](https://osysharp.com/reference/project/index/) — what you write, and what is already done for you.
- [Automatic durability (steps you do not have to write)](https://osysharp.com/reference/workflow/automatic-durability/) — the exactly-once guarantee, in detail.
- [The security model](https://osysharp.com/reference/security/index/) — the rules that end up inside the query.