Governed software action
YAI is aimed at software action that carries consequence, records and review, not generation alone.
White Paper
Doctrine for governed software action.
This route packages the product problem, the architecture stance and the commercial-runtime model behind YAI: local-first, online-authorized, account-backed, case and evidence oriented, client and runtime separated, and prepared for future release and access integration without pretending those integrations are already live.
Local-first, online-authorized
Runtime stays near the machine while authorization remains a separate online boundary around capability and operation.
Account-backed operation
Account posture matters, but the website does not pretend account state, Open Preview, Preview Plan or release eligibility already exist live.
Cases, evidence and lineage
Meaningful work should stay anchored to case boundaries with evidence and reviewable continuation, not loose chat history alone.
Runtime and client separation
CLI, Loom and VS Code are client entry points. They do not become account, release or runtime authority surfaces.
Commercial runtime posture
Release access, entitlement, machine posture and runtime authorization can exist later without turning the public website into pricing or billing software.
Problem
Why this model exists
YAI is not trying to be just another assistant chat box, a workflow glue layer or an observability log surface. The problem is how to let software take meaningful action while keeping the action anchored to runtime truth, account posture, reviewable records and a durable work context.
That leads to a split architecture. The public site can explain and route. The external account and release platform can later project safe account and eligibility state. The runtime and clients can later consume those decisions while remaining the place where real operational behavior happens.
Core separations
The boundaries that keep the public story honest
| Boundary | Public meaning | Where live state comes from | What the public site does not claim |
|---|---|---|---|
| Website vs runtime | The public website explains and routes. The runtime executes and governs operational behavior later. | Public site now; runtime layer later | No live runtime health, no live jobs and no operational telemetry from the website. |
| Account vs runtime | Account posture and auth context can shape operation without making account UI the runtime itself. | Account platform for state, runtime layer for use | No fake session, no active Open Preview state and no live runtime authorization claim. |
| Source vs release | Public source visibility can differ from future packaged release access and from runtime authorization after install. | Public site now; release services later | No fake repo URL, artifact, version, checksum, installer or release date. |
| Download vs operation | Getting source or a package later does not by itself authorize runtime operation. | Release services + runtime layer | No account-gated download state, no live eligibility and no runtime grant from this route. |
| Client vs authority | Clients are entry surfaces into governed work, not the owners of account, release or machine truth. | Runtime and client layer | No client-owned identity, plan assignment or release policy. |
| Docs vs live state | Public docs package the system model so the route layer stays coherent before contracts become live product state. | Public docs layer | No product guarantee that contract language already equals implementation. |
Public docs boundary overview
Public site
What the website is doing here
The public site explains the product surface and keeps the routes aligned without pretending to be the runtime or the account system.
- Public routes, labels and navigation
- Docs, whitepaper and route cross-links
- A coherent public explanation layer
Account and release
Where account and eligibility state later comes from
Account creation, sign-in, account posture and release decisions belong to the account and release platform, not to this docs route.
- Account and auth state
- Open Preview, Preview Plan and account projections
- Release eligibility and entitlement projections
Runtime and clients
Where operational truth later lives
The runtime and its clients remain the place where execution, authorization and governed work actually happen.
- Runtime and client behavior
- Sealed operation and authorization checks
- Case, job, flow, machine and license consumption
Reading path
Follow the public surface from doctrine into routes
DocsHub for runtime, deploy, patterns and SDK boundary reading.AccountCreate-account-first entry for future account-backed operation.DownloadSource visibility, release structure and authorization boundary.InterfacesCLI, Loom and VS Code as client entry surfaces.StatusReadiness framing instead of fake uptime monitoring.YAI HomeFuture signed-in home on the technical `/dashboard` route.
Supporting legal context remains on Privacy, Terms and Pre-release context. Those routes support the boundary; they do not stand in for account, release, billing or runtime implementation.