# 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. ## 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. A resume does not repeat what it already did. {#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: each one records its result as it completes, and a resume after a crash or a deploy replays that record rather than making the call again. There is no retry policy to author. What remains is the last inch — an effect that reached the other system in the instant before its result was recorded. No runtime can close that window, because the effect happened somewhere else. What closes it is an idempotency key the receiver can recognise, and the platform derives one from the step so you only have to hand it over. 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/) — durable steps, the resume, and the key for the far side, in detail. - [The security model](https://osysharp.com/reference/security/index/) — the rules that end up inside the query.