Two foundations that work together
REZICS models what content is separately from where it appears.
- Block Schema defines the typed blocks in a renderable document and how each retains stable identity, versioning, and validation rules.
- Content Structure defines content occurrence, parent/child relationships, order, destinations, and published revisions.
The separation lets a chapter or Post be reused in several places without copying its body, while every occurrence has its own node ID, order, and navigation meaning.
Block Schema: not raw JSON
Nearly every saved JSON document needs an identifiable base object rather than an arbitrary Portable Text array put directly in a field. The most basic Portable Text document has these semantics:
{
_type: "portable-text",
_key: "6-byte / 12-character hexadecimal key",
content: PortableText,
}_type selects the parsing and rendering protocol; _key preserves block identity during revisions, paragraph comments, and structural operations; document versions set clear migration boundaries. Format validation is followed by reference, permission, and visibility checks: an identifier’s shape alone never proves its target is readable.
Implemented block families
The shared Block Schema currently represents Portable Text, Unit references, full Post views, Unit lists, search-driven feeds, menus, and other controlled content surfaces. Every variant belongs to a closed union, so an unknown block never silently passes a renderer.
Zones, Docks, wiki navigation, and future reusable documents build on this foundation. A block document becomes an independent Unit only when cross-owner reuse, independent authorship, publication history, or visibility proves the need.
What Content Structure can do now
- Build typed structures for books, media, Posts, Realm classification, and navigation.
- Preserve large ordered trees with stable node IDs, parent nodes, and fractional positions.
- Let nodes reference reusable content Units and distinguish content, Unit destinations, and external URLs.
- Edit complete book/media drafts, then compile bounded changes into atomic requests.
- Preserve revisions, compare differences, and restore an older state by creating a new revision.
- Project structures into a table of contents, previous/next chapter navigation, and reading-progress positions.
Large serials and imports
One structural change compiles to at most 10,000 logical commands. That caps an atomic change, not a book’s total node count. A large web novel can write a complete tree through recoverable batches, each carrying committed nodes and a bounded set of new nodes; a successful batch returns the revision token needed by the next one.
Works with more than 10,000 chapters therefore need neither an unbounded transaction nor weaker conflict detection. An import can resume after interruption and validate the complete snapshot at the end.
In development and planned
More block variants, cross-owner block Units, strong-reference indexes, paragraph comments, complete large-import workflows, and GameContentStructure are in development or planned. Every block must define saving, publishing, reading, deletion, caching, and failure states.
Relationships and boundaries
Block Schema is not an editor, and Content Structure is not the body text. The editor produces validated documents; Posts and chapters own content; Content Structure places it; History preserves published revisions.