The Web Content System on ARC: Not Understanding Your Content Is What Makes It Simple
Much of the complexity in a website system comes from its trying to understand your content.
WordPress asks you to register a post type. Astro asks you to define a collection in src/content.config.ts. They are not bad examples. They are mature and useful answers to a real problem: tell the framework that a site has articles, products, or docs, and it can help with routes, validation, queries, and the editing experience. [1][2]
The question here is not whether a configuration file counts as code, or whether a directory is somehow better than a schema. The real boundary is this: when a site gains a new noun, must the runtime gain a new built-in type as well?
“Not understanding” has a narrow meaning here: the shared runtime does not own domain nouns. It knows how to read content, organize pages, and render an interface; it does not decide what counts as a product, an event, or a term for every site. Semantics, validation, and querying are still needed. They belong with the layer that actually owns them.
That is the boundary Web Device is meant to move.
AFS (Agentic File System) gives content a filesystem abstraction. AUP (Agentic UI Protocol) describes an interface. Web Device turns the two into a website. They all run on ARC. I covered the names and basic mechanics in an earlier piece; this one is about where their combination lets a content model live.
How to read the WordPress and Astro comparison
In WordPress, the usual way to add a custom post type is to call register_post_type() on the init hook. Its name, URL behavior, capabilities, and query behavior thereby become part of the site's runtime. [1]
Astro's collections are not just directory names either. They have loaders and may have schemas; the framework uses those declarations to provide type checking, validation, queries, and content APIs. [2]
Both systems solve something real: they help a site state its content model clearly and give tooling a reliable surface around it. Neither prevents two sites from sharing a product definition, and neither means that every content edit requires a data migration. Saying otherwise would only make my own story easier to tell.
The useful contrast is narrower. In both, the site's content categories become part of a model the framework recognizes. “Product” is not only data; it is also a thing the framework knows about.
ARC can divide the work differently. Web Device can discover directory names under content/, but a routable collection is still declared by the site; discovery is not a hidden second type system. Even then, it need not know what product means in a business sense. An object's material, metadata, and declared interface can travel with data and a declarative UI contract. The component that understands “this is a product reference” or “this is an event status” belongs at the application level, not in AFS.
A directory does not automatically create a product feature. The site today has articles and docs; docs even have their own navigation behavior. If we decide to build products, a glossary, and events, they will be the next real test; they are not finished capabilities. The test is whether those objects can arrive without making Web Device grow another runtime path for every new noun.
Web Device is not here to draw directories
If the idea stopped at “put files in a directory,” there would be no reason to have Web Device. Every application could read its own files, assemble its own pages, handle localization, build navigation, lists, search, and archives. It would still become a website. It would just make every site learn the same lessons again.
Web Device earns its place by making that common work a reusable runtime: it reads content made available through AFS, arranges pages through AUP and site declarations, and gives common web structures one implementation. It should not define what “product” or “event” means for every site. It should give the components that do understand those things a place to present them.
The layers are simple, but they should not be blurred:
| Layer | Responsible for | Not responsible for |
|---|---|---|
| AFS | Making data available and moving it | Rendering pages or deciding business meaning |
| AUP | Declaring interface structure | Deciding the actual meaning of a business object |
| Web Device | Reading content, then organizing and rendering common website structure | Turning every new noun into a built-in runtime type |
Suppose we add a product object. Web Device should only provide the generic collection and detail-page mechanism; the site declares how the collection reaches a route; the product object carries its own data and schema; and a product-reference component decides how an article displays it. If that division holds, AFS never needs to know the business word “product.”
That is also why “the substrate does not understand semantics” does not mean “the system has no semantics.” If a product is renamed, an old article's product card should show the new name. But the fact that a field is a product reference belongs to the product-reference component or the object's declaration, not to the filesystem. The semantics have not disappeared; they have been placed where that knowledge is actually owned.
What we get by not putting semantics in the substrate
First, a clearer boundary. AFS does not need to know why an article cites a product, and Web Device does not need a core data model for every relationship a site invents. A site can evolve its semantics in components and object declarations without casually turning one site decision into a low-level rule that every application must inherit.
Second, a more honest test of reuse. This is not a capability we have proved yet; it is an acceptance criterion we should use. When an object directory carries public data and a declared interface, it should still be understandable and renderable on another site with a compatible collection and standard components when it does not depend on private components. If it cannot, we should not call it a generic object. It is a site template.
Third, build dependencies do not have to guess at business relationships. A renderer can record the objects, collections, and templates it actually reads, then use that record to decide which output needs rebuilding. That mechanism need not understand “partner,” “product,” or “event.” But it also does not invent a relationship model for us. How dependencies are recorded and invalidated remains Web Device's implementation responsibility; a directory alone does not guarantee it.
The cost cannot be hidden
Taking content categories out of the core runtime does not make validation and querying disappear.
Validation has to come from an object's own schema or declaration. Queries need indexes. Cross-object references need explicit contracts. Without those things, directories are merely files that happen to be readable, not a maintainable content system.
That is why HyperCard is still a useful image. A card could carry material, appearance, and behavior together; the author decided whether it represented an address book, a guide, or a game. But it is not the template we want to reproduce. A HyperCard stack was a private binary format, and Apple never left a definitive specification. One reverse-engineered description cited by the Library of Congress also acknowledges that it is not complete enough to reliably update or create stacks. [3]
The lesson is not “put everything in a card.” It is that portability cannot be added later. Directories, plain text, and declarative interfaces do not themselves solve semantics, validation, or querying. They do make the material available to more tools that can read, generate, inspect, and change it in bulk. The remaining contracts still have to be written down.
Back to Web Device
Web Device is not a tool for painting AFS directories into web pages. It is a line of responsibility: a reusable runtime takes care of common web work, while object data, declarations, and components express the meaning of concrete things.
That boundary is still being tested. If we choose products, a glossary, and events as the next objects, they will be the first real cases. They need clear schemas, usable interfaces, and verifiable references and queries, while not requiring Web Device to grow a dedicated runtime branch for every noun. If that works, the layering earns its value. If it does not, we should be willing to admit where semantics are still sitting in the wrong layer.
That is what Web Device should actually provide: shared common web work, with the meaning of concrete objects kept explicit and able to evolve.