The whole application is one program.

Access belongs to the data.

Who may see or change a record should not depend on which page, function or other part of the application happens to ask. So the rule is declared once, on the entity, and the compiler puts it inside every query and every write over that entity.

apps/spendflow · identity.osy and expenses.osy · abridgedpolicy IsFinance(Organization o) =>
  RoleGrant.Any(g => g.User == user && g.Role == Role.Finance && g.Organization == o);
policy IsController(Organization o) =>
  RoleGrant.Any(g => g.User == user && g.Role == Role.Controller && g.Organization == o);

entity ExpenseReport {
  [Required("An organisation is required.")] Organization Organization;
  [Required("An employee is required.")] Employee Employee;
  [Required("Give the report a name."), MaxLength(140, "Keep the title under 140 characters.")] string Title;
  ReportStatus Status = ReportStatus.Draft;
  DateTime? SubmittedAt;
  …
  security {
    allow read where Employee.User == user;
    allow create where Employee.User == user;
    allow update where Employee.User == user && (Status == ReportStatus.Draft || Status == ReportStatus.Rejected);
    …
    allow delete where Employee.User == user && Status == ReportStatus.Draft;
    allow read where Employee.Manager.User == user;
    allow read where IsFinance(Organization) || IsController(Organization) || …;
  }
}

The entity from SpendFlow, an expense app built on kits, with two of the policies its rule names. Abridged where marked: more fields, the per-column rules for the moments a report is submitted, and two more roles. RoleGrant is an entity the app declares too: a row per person, role and organisation. The Required and MaxLength messages are what a person sees when the rule is broken.

You write LINQ. It becomes one statement.

An application reads its data in many shapes: a filtered list, one row, a total, a page of results. It also changes sets of data at once: close every stale order, purge what is finished. In Osy#, they are all expressions over the same entity model.

from the query reference, where each is compiled and run// a filtered, ordered, bounded list — one SELECT
List<Order> BigOpenOrders(decimal floor) {
  return Order.Where(o => o.Total > floor && !o.Cancelled)
              .OrderByDescending(o => o.Total)
              .Take(20)
              .ToList();
}

// one number, computed by the database
decimal Revenue() {
  return Order.Where(o => !o.Cancelled).Sum(o => o.Total);
}

// a live read — the same query, kept current as data changes
live var open = Order.Where(o => !o.Shipped);

// a bulk write — one statement; it answers how many rows
int CloseStale() {
  return Order.Where(o => o.Status == "Stale")
              .Update(o => { o.Status = "Closed"; });
}

Four chains from the query reference, where each is compiled and run against a real database by the gate that checks this site; the live read is the hero's. The rule on Order is applied to all four by the platform: the caller's rows, and only those. Grouping, projections, paging, Include, Delete and Insert are in the query reference.

The compiler checks the parts against each other.

Add a second page and make it public, so visitors can see the open orders without signing in. On its own, that page is fine. On its own, the rule on Order is fine. Together they contradict what the application is trying to do: the page will render, and its query will return nothing, because Order grants anonymous visitors no read.

model/open.osy[AllowAnonymous]
[Route("/open")]
component OpenOrders() {
  live var open = Order.Where(o => !o.Shipped);
  render {
    foreach (var o in open) { Text(o.Reference); }
  }
}

$ osy lint · abridgedSHOULD
  • OpenOrders → Order — 'OpenOrders' is `[AllowAnonymous]`
    and reads 'Order', but 'Order' grants no anonymous read,
    so for a visitor with no credential the page renders and
    its query returns ZERO ROWS — no error, just an empty page.
    `[AllowAnonymous]` opens the element surface; the row read
    is gated separately at the entity by its own `security { }`
    block, and the two do not inherit.
    model/open.osy:1:2
    security-anon-page-reads-ungranted-entity · fix: add
    `allow read when IsAnonymous;` to 'Order's `security { }` …

Above, the public page, added to the application from the hero. Below, what osy lint says about the whole application: the linter is part of the compiler's toolchain, judges the whole program as the compiler sees it, and reports each finding by name, with where it is and what to write. This one is a warning, because the page is legal; it is just not what anyone meant.

A process that waits three days for a person is still just source.

A support ticket is opened, answered, sometimes parked on the customer, resolved, occasionally reopened. Different people act at different stages, there are promises about how quickly, and the desk waits hours or days for someone. After a deploy or a restart, every open ticket must still mean the same thing.

a support ticket's lifecycle · compiles as printedworkflow SupportTicket {
  Tracks    = Ticket.Status;
  Autostart = true;
  Initial   = Open;

  event Respond(string reply);
  event AskCustomer();
  event CustomerReplied();

  state Open {
    subscribe Respond(string reply) as FirstReply {
      Candidates = u => u.Team == Team.Support;
    }
    on FirstReply(string reply) { goto Working; }
  }

  state Working {
    subscribe AskCustomer();
    on AskCustomer { goto AwaitingCustomer; }
  }

  state AwaitingCustomer {
    subscribe CustomerReplied();
    on CustomerReplied { goto Working; }
  }

  terminal success Closed { }
}

A support ticket's workflow, reduced to its shape; it compiles as printed (re-validated 2026-10-16). subscribe declares that a state waits for an event; Candidates says who it is offered to. Harbour, the helpdesk built from kits, runs the full version.

Test the application as the people the rules are about.

The order-lifecycle sample says only a manager may cancel an order, and only fulfilment staff may ship one. Does the application behave that way for the actual people? A test signs in as them, drives the real page, and asserts what each one can see and do.

demo/wf-order-saga/tests/board.test.osy · abridgedprincipal Fael => Staff.Single(s => s.Name == "Fael");
principal Mona => Staff.Single(s => s.Name == "Mona");

[TestFixture]
void OneOrderAndTwoTiers() {
  var fael = new Staff { Name = "Fael" };
  var mona = new Staff { Name = "Mona" };
  new RoleGrant { Grantee = fael, Level = AppRole.Fulfillment };
  new RoleGrant { Grantee = mona, Level = AppRole.Manager };
  …
}

[Test(OneOrderAndTwoTiers)]
void only_a_manager_may_cancel() {   // name shortened
  Ui.SignInAs(Fael);  Ui.Visit("/");
  …
  Assert.Hidden("Cancel order");

  Ui.SignInAs(Mona);  Ui.Visit("/");
  …
  Assert.Visible("Cancel order");
}

A test file from the order-lifecycle sample, abridged where marked (the email each row also carries, and the test's longer name). The fixture writes the rows every test in it starts from; a test runs against a database that starts for it, with the real application on top. Assert.Visible and Assert.Hidden look at the real page.

Kits are finished pieces of an application.

Data, security, workflows, screens and tests, done once. An application inherits them with one line, and writes only what makes it different.

What kits are, and every kit Harbour The online shop All 147 packages, with the line that uses each

Apps/harbour/app.osy · the kits, comments removedapp Helpdesk {
  use Osysharp.Identity@0;
  use Osysharp.UserAccounts@1;
  use Osysharp.CustomFields@1;
  use Osysharp.Organizations@0;
  use Osysharp.Organizations.ServicePlans@0;
  use Osysharp.Invitations@2;
  use Osysharp.UserManagement@0;
  use Osysharp.Mail@0;
  use Osysharp.Mail.Receiving@0;
  use Osysharp.Mail.Gmail@0 { egress "oauth2.googleapis.com"; egress "gmail.googleapis.com"; }
  use Osysharp.EmailTemplates@0;
  use Osysharp.Conversations@0;
  use Osysharp.Presence@0;
  use Osysharp.WorkQueues@1;
  use Osysharp.LoadingOrbs@0;
  use Osysharp.ReplyComposer@0;
  use Osysharp.Automations@0;
  use Osysharp.Notifications@1;
  use Osysharp.SatisfactionSurveys@0;
  use Osysharp.KnowledgeBase@1;
  use Osysharp.MarkdownEditor@1;
  use Osysharp.Seo@0;
  use Osysharp.Webhooks@0 { egress "*"; }
  use Osysharp.ProblemReports@0;
  use Osysharp.Privacy@0;
  use Osysharp.Reports@1;
  use Osysharp.Charts@1;
  use Osysharp.Csv@0;
  use Osysharp.TimeZone@0;
  use Osysharp.Llm@2;
  use Osysharp.Models.Anthropic@1 { egress "api.anthropic.com"; }
  use Osysharp.MachineTranslation@0;
  use Osysharp.Agents@1;
  model "model/**/*.osy";
}

An agent is part of the program, and it obeys the same rules.

An agent is given real work: estimate a repair, vet a supplier, take a step of a process that runs for days. The question is never whether the model is clever enough. It is what the agent may touch, who decides, and what it costs.

Agents in an Osy# app The developer's guide: four shapes, each a whole app

from reference/agent/agents · abridged · its tests run in CIentity Repair {
  [Required, MaxLength(200)] string Fault;
  decimal Price;
  security {
    allow read, update when IsMechanic || IsManager || IsHelper;
    deny update Price when IsHelper;
  }
}

public class EstimateRepair : Skill<Repair, Estimate> {
  public override string Description => "Estimate one repair.";
  public override List<ActionInfo> Tools =>
    [Actions.Of(PartsFor), Actions.Of(NoteRepair), Actions.Of(SetPrice)];
  public override string? Check(Estimate e) =>
    e.Hours <= 0 ? "An estimate takes some time." : null;
}

[Actor(Roles = [ShopRole.Helper])]
public class Estimator : Agent {
  public static Person Principal => new Person { Email = "[email protected]" };
  public override string Purpose => "You estimate bicycle repairs for a small workshop.";
  public override List<SkillBase> Skills => [new EstimateRepair()];
  public override Permits May => Permits.ChangesAlone();
}

// give it work — the answer is an Estimate, checked, or how the work ended
var outcome = await Agents.Of<Estimator>().Do(new EstimateRepair(), repair);

One agent from the agents reference, abridged. The mechanic Mia may set a price; the agent holds Helper, and a helper may not, so when it works for Mia its SetPrice tool is refused and the model is told. The reference page runs that as a test, with the model scripted.

More of your code is written by something that cannot ask a colleague.

It has the source and the toolchain, and no way to ask what was meant or how something is spelled. Everything this page has shown is explicit in the program, so the toolchain can answer.

$ osy docs snowflake · abridgedmatched on alias: snowflake → config-snowflake

The Snowflake kit — warehouse tables as entities, and exports back  (config-snowflake)
An optional package that makes Snowflake tables ordinary Osy# entities: your app reads them with LINQ, and each query runs in Snowflake as one statement already carrying the reading person's access rule. The other direction sends your own entities into Snowflake tables as they change.
sections — ask for any number with osy docs config-snowflake#<name>: #summary #signature #install #credentials #entities #queries #writes #exports #limits …

── app.osy — the dependency, and the grant it cannot work without  {#install}
app Revenue {
  model "**/*.osy";
  use Osysharp.Warehouses.Snowflake {
    egress "*.snowflakecomputing.com";
    secret "SnowflakePrivateKey";
  }
}

── one table, one entity — the access rule travels with every query  {#entities}
[DataSource(DataSource.Warehouse), ExternalName("PUBLIC.ORDERS")]
entity Order {
  [Key, ExternalName("ORDER_ID")] string Number;
  [ExternalName("REGION")] string Region;
  [ExternalName("TOTAL")] decimal Total;
  security { allow read where Region == user.Region; }
}
…

The reference page for the Snowflake package, as the toolchain prints it: what to declare, the grant it needs, and a warehouse table as an entity with the same kind of rule as in 01, applied to every query the same way. Every compiled example on the page is checked by the same gate that compiles this site's reference, which is why the answer can be trusted without a person to check it.

From an empty folder to a running application.

Give your agent a project it understands, and watch it build, check and run an application on your machine. The toolchain goes to the people in the beta first.