Hold these terms as boundaries, not as synonyms.
| Term | Think of it as | Do not treat it as |
|---|---|---|
| AFS | A path-addressable filesystem of resources and capabilities | A single physical database or cloud bucket |
| Provider | A module that owns a mount path and implements operations it declares | Proof that every operation exists on every path |
| AFS UI | An architecture lens: UI work expressed relative to AFS paths and devices | A third public authoring product equal to AUP and Web Device |
| AUP | A declarative semantic UI tree (nodes, events, bindings, degradation) | HTML, CSS, or a site content model |
| Web Device | An AFS provider that reads site trees and renders static HTML | An interactive AUP session or a general app runtime |
| Blocklet | A package you author and an instance you run | Only a website, or only a UI file |
| DID / caller | Verified identity context the runtime attaches to a request or session | A path string that happens to look like a DID |
| DID Space | DID-scoped persistent storage mounted through AFS | A second parallel filesystem protocol |
| Data Space | A documentation term for caller data context and views | A separate public SDK or lifecycle API |
| ARC | The runtime and CLI shell that hosts AFS, sessions, and Blocklets | The same thing as AFS |
How the pieces connect
- AFS answers “where is the resource, and which operations does its provider support?”
- AFS UI answers “when that resource is shown or edited, which device and UI contract applies?”
- AUP answers interactive presentation: semantic trees, sessions, device capabilities, degradation.
- Web Device answers site presentation: pages, content objects, themes, static HTML.
- Blocklet answers packaging: what you ship, how you run it locally, and how it binds surfaces to AFS.
- Identity and data spaces answer “who is acting, and which data view do they receive?”
- ARC CLI is the operational entry for inspecting and driving those layers from a machine.
Reading order
| If you are… | Read first |
|---|---|
| New to ARC and need vocabulary | This page, then ARC and AFS |
| Choosing which guide owns a task | Product layers |
| Connecting UI work to AFS paths | AFS UI, then AUP or Web Device |
| Implementing resources or providers | AFS |
| Shipping an application unit | Blocklets |
| Handling sign-in, membership, or user data | Identity & Data Spaces |
| Checking whether a sentence is a product promise | Contracts and evidence |
| Chasing an old product name | Product lineage and boundaries |
Contract vs explanation vs lineage
- Public contract — behaviour you can depend on after source, tests, and a local run agree. Sibling boards own these.
- Architecture explanation — how layers fit; useful for orientation, not a substitute for types and commands.
- Lineage — why an older name still appears; never a full feature-equivalence claim.
Internal ARC materials also use AOS for portable operating-system semantics (session, HTTP surface, scheduling) that ARC hosts. This public board does not treat AOS as a separate developer documentation product. When a task needs session or caller detail, use Identity & Data Spaces and the AUP session pages.