Foundations

The eight stations describe how work moves. They do not describe who is allowed to see it, where its records live, or how the system reaches the outside world. Those three concerns cut across every station, and WilsonOS treats them as foundations — planes the whole loop stands on — rather than as stations of their own.

flowchart TB
  loop["The work loop<br/>Trigger → Context → Capability → Execution → Artifact → Review → Learn → Measure"]
  loop --- I["Identity & access<br/>who may see and do what"]
  loop --- D["Data governance<br/>one canon, one writer"]
  loop --- N["Connections<br/>how the outside world is reached"]

Each foundation has exactly one architecture contract. This page explains what each one governs and the rules they have in common.

Identity & access

Who is acting, what do they own, and what may they see or do?

Users, brand ownership, roles, conversation membership, and the scope of any action. A personal workspace shows the brands a person can access; it does not grant access to every private conversation inside them. Agents act on behalf of a person or a brand and inherit that scope — an agent working one brand’s task cannot reach another brand’s files, and an agent’s runtime session is an execution detail, not a conversation identity.

The design principle is default deny with explicit grants: every record carries an owner, every read and write is checked against a grant, and multi-user operation follows from that rather than being bolted on.

direction The identity model is defined; the system today runs for a single operator, and access rules are being extended table by table ahead of multi-user use. See Release scope.

Data governance

Which record is authoritative, and who is allowed to write it?

Every class of data — a task, a brand document, a generated image, a memory entry, a measurement — has exactly one place it canons and exactly one path that writes it. Some classes canon on disk as files (prose that people edit, brand documents, code); some canon in the database (tasks, media, memory, measurements). Nothing is written to a table by hand, and nothing is edited in a mirror expecting the canon to follow.

Governance also covers versions, retention, backup, and recovery. Shared business records — product, offer, campaign, and the rest — connect work across surfaces precisely because their identity and their writer are governed.

The registry owns identity

For artifacts specifically: the registry identifies a record; durable storage retains its bytes; isolated working copies exist so agents can edit safely. A name or a location is a label on an artifact, never its identity, so files can be renamed or moved without breaking the links that point at them.

live The one-canon, one-writer rule is enforced for tasks, media, and memory; a drift detector runs nightly and flags anything that shipped outside its writer path.

Connections

How does the system read from and act in the outside world?

External applications are reached through APIs, connector protocols, or command-line tools. Each connection has an account scope, a set of permissions, and a declared list of what it can read and what actions it can take. Publishing to Pinterest, generating an image, reading advertising performance, or sending a document all go through a named connection with those properties.

Two rules make connections safe to build on:

• Same operations, two interfaces. A person clicks Save or Publish; an agent calls a tool. Both use the same underlying service and the same permission checks. Exposing an operation to an agent never creates a second source of truth.
• One door per capability. Generation, editing, registration, and publishing each have one gateway. A skill that needs an image calls the image gateway, never a provider directly; that is what makes cost caps, receipts, and attribution reliable.

live The gateway pattern is enforced for media generation and editing; connections are catalogued with their scopes.

Rules the three share

Storage and search have different jobs. The registry identifies records; durable storage keeps bytes; working copies support editing; version control remains useful for authored files and code history. Search — keyword or semantic — finds relevant records, and retrieval hands authorised context to the model. Search does not replace storage, source versions, or access control.

Every station names its foundation dependencies. When something changes — a new table, a new external data source, a new cron, anything user-visible — the architecture’s what changes together table says which foundation contracts must be checked. That is how three cross-cutting concerns stay coherent across eight stations.

Multi-user is the test. Each foundation is written for the case where more than one person, and more than one tenant, uses the system. A rule that only holds because a single operator is the only user is treated as a known gap, listed, and scheduled — not assumed away.

Related

The work loopThe eight stations these foundations support.

Shared business recordsThe governed records that connect the five product areas.

Extending WilsonOSWhat a new connection or data source has to do before it is trusted.

Release scopeHow far each foundation has shipped.