Osy# · The proposition

Why a new language?

Because the hardest problems in business software are not features. They are failures at the boundaries.

Someone saw what they should not have.
The customer was charged twice.
The upgrade lost data.
Nobody could explain what the system did.

These look like four different problems. They are not.

They all happen because today's software is assembled from layers, products and conventions, and no one owns the behaviour of the whole application. And a system that cannot see the whole program cannot guarantee what the whole program will do.

Osy# changes that.

Someone saw what they should not have.

Today, the rules about who can see what are scattered across application code, APIs, queries, services and configuration. One missing check is enough to expose data.

In Osy#, access is a property of the data itself. Declare the rule once, and it governs every way that data can be reached. There is no convention for a developer to remember, and no hidden layer for an AI to accidentally bypass.

The security rule is part of the program, not a promise made by the programmer.

The customer was charged twice.

Today, if a process fails halfway through — a crash, a timeout, a restart or a deployment — the system can be left somewhere between states. Teams build retry logic, reconciliation jobs, queues and operational procedures to deal with it.

Osy# makes the execution itself durable. When an operation crosses the boundary between the application and the outside world, it is known that it must happen exactly once — and that guarantee survives failures, restarts and releases.

The system does not leave a mess for someone to reconcile on Monday.

The upgrade lost data.

Today, changing the shape of a database is a migration project. Developers write scripts, test them, take backups, and hope they have covered every path.

Osy# understands the application's data model and how it is evolving. A release that could destroy data is rejected before it runs, and where a safe transformation can be determined, the system generates it.

The application knows what its data means, so the platform can protect the data when the application changes.

The application cannot explain why it did what it did.

Today, when something important happens, the explanation has to be reconstructed — from logs, database records, application code, tickets and the memory of the people who built it.

Why was this customer allowed to see this?
Why was this payment made?
Why did the workflow approve that request?
Which rule was in effect?
What did the AI have permission to do?

In Osy#, the answer is part of the application itself.

The rules that govern data access are explicit, and the system can explain them in plain English. Changes carry their history. Workflows carry their execution history. Agent actions carry what the agent was instructed to do, which tools it used and what happened as a result.

This is not another audit product bolted onto the application. The same model that governs the application produces the evidence of what happened.

And that evidence is protected by the same rules as everything else: an audit trail cannot become a second way to leak the data it records.

“Why did it do that?” is no longer an investigation. The application can answer.

The reason it has to be a language

Nothing that sits beside the program can promise anything about the program.

These guarantees cannot be bolted onto the side of an application.

A security product can inspect some requests.
A database can enforce some constraints.
A workflow product can retry some operations.
A migration tool can check some schemas.
A cloud platform can manage some infrastructure.

But none of them sees the whole program. And if the system cannot see the whole program, it cannot guarantee what the whole program will do. The language is the layer that sees everything.

We did not add another product to the stack. We removed the joins between the products.

Why now

The one thing that made a better language unaffordable has gone.

A new programming language used to face one enormous obstacle: people had to learn it. That made radical improvements expensive to adopt even when the underlying ideas were better.

People are no longer the primary authors. AI is becoming the author of software, and an AI does not need years of experience with a language: give it the language, its documentation and its constraints, and it is productive in an afternoon. Osy# is deliberately familiar, because it builds on the language business software is already written in — but underneath that familiar surface is a fundamentally different execution model.

And the value runs both ways. The more software is generated, the more it matters that the language itself makes unsafe and operationally fragile patterns difficult or impossible to produce.

And no, you are not trapped

Everything you build is yours to take.

The source is yours. The applications we publish are yours to fork, under the MIT licence. Run it on our platform, or on your own server, on the same runtime either way.

The ecosystem is not ours to ration either: the web's own controls are yours to bring, declared in a few lines and checked by the compiler like anything we wrote.

What you are actually buying

Not another SaaS product.

Own itYou own the software. Run itRun it yourself, or let the managed platform run it for you. Pay for usePay for the resources it takes to run — not rent for every person who logs in.

Software ownership. Managed operations. Usage-based economics. That is the proposition.

Osy# is a new language because the old stack makes it impossible to guarantee the things that matter most.

We are not trying to make programmers write software faster. We are trying to make the software itself fundamentally harder to get wrong.

←Back to the front page →Why Osy#, chapter by chapter →Twenty complete applications