Deconstructing the Concept of a "Page"

OS iXanagi solves this problem structurally.

One principle governs everything: separate the container (structure) from the content (meaning) completely.

The "container" is the layout structure on a page. A hero section, a three-column feature grid, an FAQ accordion, a CTA banner. These are patterns for how meaning gets placed — not meaning itself. In OS iXanagi, this is a Structure Object.

The "content" is the actual meaning: explanatory copy, knowledge, FAQs, calls to action. In OS iXanagi, this is a Meaning Object.

What connects the two is a Relation — an explicit link that says: place this content, in this container, in this role.

Container (Section) ── Relation ──→ Content (Meaning Object)

All three are always independent. That means you can place the same Meaning Object in different containers. You can swap different Meaning Objects into the same container. One unit of meaning, positioned freely anywhere.

Here is how that principle works inside a blog article.

When you structure the article "Giving AI Knowledge Doesn't Govern It" in OS iXanagi, you start by building a hierarchy of containers.

article_container (the whole article)
  ├── article_chapter (chapter 1)
  ├── article_chapter (chapter 2)
  │     ├── article_section (chapter 2, section 1)
  │     ├── article_section (chapter 2, section 2)
  │     └── article_section (chapter 2, section 3)
  ├── article_chapter (chapter 3)
  └── cta_band (call-to-action at the end)

This is a nested structure. An article_container holds article_chapter nodes, which in turn hold article_section nodes — the same hierarchy as HTML's <article> → <section> → <section>.

But at this point, there is no meaning here yet. Only empty containers.

Next, you attach meaning to those containers.

article_chapter "The Separation of Powers in AI"
  │
  ├── labeled_by → "The idea of AI's three branches" (copy — chapter title)
  ├── contains   → "Definition of fail-closed" (knowledge — reusable knowledge)
  └── text_block
        └── labeled_by → Explanation of legislative / executive / judicial (copy — body text)

labeled_by is the relation that supplies the heading for a container. contains is the relation that places content inside it. Because every relation type is explicit, AI can read this structure precisely.

And here is the key point: the Knowledge Object "Definition of fail-closed" does not exist only for this article. That same object is referenced by the pillar_grid on a product page and the faq_list on a FAQ page. The container changes. The meaning stays identical.

Separating container from content immediately raises the next question: how fine-grained should you go?

Do you create one Meaning Object per paragraph? Per sentence? Per word? The answer: split at the boundary where meaning gets reused.

Three criteria guide the decision.

Will anything outside this article reference it? "fail-closed — the principle that says stop if you cannot decide" is knowledge used across the entire site. It belongs as a standalone Knowledge Object. By contrast, "picture this as a human institution" is a storytelling metaphor unique to this article. It lives inside a chapter-level copy Object.

Does this belong in the Knowledge App? If a concept should be managed as a company-wide knowledge asset, isolate it. "AI's separation of powers: Knowledge App = legislature, Kernel = executive, Obligation = judiciary" is a core idea for this company. Don't bury it in an article — manage it as a standalone Knowledge Object.

Do the English and Japanese versions need independent narrative structures? If you cut Meaning Objects too finely, you lose freedom for locale adaptation — the ability to restructure content for different cultural contexts. Keeping things at chapter granularity lets the English and Japanese versions each carry their own narrative arc.

Apply these three criteria and you will never second-guess granularity decisions, even when you have a hundred articles.

WordPress, Notion, and Contentful all achieve a partial version of container-content separation. Component libraries, block editors, reference fields — each takes a step in that direction. But none of them fully abandons the assumption that content lives inside a page.

OS iXanagi is different because the design philosophy runs in reverse.

A traditional CMS starts from the page. There is a page, and content sits inside it. Content is subordinate to the page.

OS iXanagi starts from meaning. A Meaning Object exists first. Then a Route (the URL), a Projection (the rendering layout — how content gets drawn on screen), and a Section (the placement structure) bring it to the surface at a specific location. Meaning comes first; the page comes after.

That reversal is why editing the Knowledge Object "Definition of fail-closed" in one place automatically updates every blog article, product page, and FAQ page that references it. No copy-paste. Consistency of meaning is guaranteed by the structure itself.

Containers cannot be combined freely.

An article_container can hold article_chapter nodes. An article_chapter cannot hold an article_container. A text_block cannot have children at all. These rules are defined at the OS iXanagi platform layer.

Whether nesting is allowed (nestable). How deep nesting can go (max_depth). Which child types are permitted (allowed_children). All of this is defined explicitly — which means that when AI generates article structure, it cannot produce structural violations like placing an entire article inside a chapter.

This is a concrete example of "governance" from the first article in this series. When you ask AI to "write a blog post," the structure of meaning has rules too. Those rules are enforced. That is what makes safe automation possible.

"Build a blog article."

That single instruction set off a chain of decisions.

First: build a dedicated table, or fit it into the existing structure? The answer was the latter. A blog article is not special. It is just another page in OS iXanagi — expressed through Route + Projection + Section + Meaning Object.

Next: at what granularity do you cut Meaning Objects? Cut at reuse boundaries. Concepts that belong in the Knowledge App get their own objects. Narrative that is unique to this article stays inside chapter-level copy Objects.

Finally: how do you control nesting in containers? The platform defines it. nestable, max_depth, allowed_children — these are platform-level definitions that both AI and humans follow.

This chain of thinking is the OS iXanagi design philosophy in action.

Don't start from features. Start from meaning. Don't build pages. Structure meaning. Structure has rules, and rules are enforced.

This is what OS iXanagi means by separating containers from content.

CloudEffects LLC — OS iXanagi: the OS that structures meaning