Collecting information is only the first step of a presentation system.
Once content has been discovered and converted into normalized cards, it still needs to be organized into something the rest of the application can understand.
That responsibility belongs to the Knowledge Builder.
Rather than returning a collection of unrelated arrays, the builder produces a single structured object describing an entire body of knowledge.
The Problem
Imagine a portal that references books, songs, artists, quotes, excerpts, and images.
A collector could simply return six independent arrays.
[
'books' => [...],
'songs' => [...],
'artists' => [...],
'quotes' => [...],
...
]
While technically functional, this structure provides very little information about the collection itself.
- Which sections should be displayed?
- In what order?
- Which sections are empty?
- How many total entries exist?
- What labels should appear in the interface?
- What context produced this collection?
Every presentation layer would need to answer these questions independently.
The Knowledge Object
Instead, the builder creates a richer object describing both the content and its structure.
Knowledge Object
├── sections
├── active_sections
├── total_entries
├── section_order
├── section_labels
├── context
└── metadata
This becomes the single contract between data collection and presentation.
Sections
The sections property contains the normalized cards grouped by content type.
sections
├── books
├── songs
├── artists
├── quotes
├── excerpts
└── images
Each section contains only cards belonging to that type.
Presentation templates iterate these sections without knowing how they were assembled.
Active Sections
Not every content type is present for every portal or taxonomy.
The builder determines which sections actually contain data.
active_sections
↓
books
songs
quotes
images
The Presentation Engine can use this information to avoid rendering empty headings or placeholder containers.
Section Order
Presentation order is defined independently from the data itself.
section_order
↓
Concepts
↓
Books
↓
Movies
↓
Songs
↓
Quotes
Collectors remain free to gather information in any order while the builder guarantees consistent presentation.
Section Labels
Content type identifiers are useful for software but not necessarily for readers.
The builder separates internal identifiers from presentation labels.
book
↓
Books
movie
↓
Movies Referenced
artist
↓
Featured Artists
Changing a heading no longer requires modifying presentation templates.
Context
A Knowledge Object also records the context that produced it.
context
├── type
└── post_id
For example:
Portal
↓
context.type = portal
↓
context.post_id = 1523
Future collectors could produce identical Knowledge Objects for search results, taxonomy archives, user collections, or external APIs while preserving the origin of the data.
Total Entries
The builder calculates useful aggregate information during construction.
Books 18
Songs 24
Movies 7
Images 12
──────────────
Total 61
Presentation layers no longer need to perform their own counting logic.
The Build Process
Conceptually, the workflow looks like this:
Collector
↓
Grouped Cards
↓
Knowledge Builder
↓
Knowledge Object
↓
Presentation Engine
Each stage performs a single responsibility before passing the result to the next layer.
Why Build an Object?
An obvious question is why not simply return the grouped arrays directly.
The answer is consistency.
A structured object provides far more than content—it provides meaning.
- Ordering
- Labels
- Counts
- Context
- Metadata
- Rendering hints
Every presentation layer receives exactly the same interface.
Supporting Multiple Collectors
One of the most important consequences of the Knowledge Builder is that collectors become interchangeable.
Portal Collector
↓
Knowledge Builder
↓
Knowledge Object
Search Collector
↓
Knowledge Builder
↓
Knowledge Object
Taxonomy Collector
↓
Knowledge Builder
↓
Knowledge Object
The Presentation Engine cannot tell which collector produced the object.
Nor does it need to.
Extending the Object
Because every presentation layer depends on a single contract, additional metadata can be introduced without modifying templates.
Future versions might include:
- pagination metadata
- sorting information
- filter state
- relationship graphs
- relevance scores
- performance metrics
The builder becomes the natural place to enrich the object before presentation begins.
Knowledge Before Presentation
The Knowledge Builder represents an important conceptual shift within the architecture.
Pages no longer render directly from WordPress queries.
Instead, they render from a complete description of a body of knowledge.
WordPress
↓
Collector
↓
Cards
↓
Knowledge Builder
↓
Knowledge Object
↓
Presentation Engine
↓
Templates
This separation allows the same rendering pipeline to support portals, taxonomy archives, search results, directories, and future interfaces without changing presentation code.
Key Design Principle
Collect data. Build knowledge. Present knowledge.
The Knowledge Builder is the architectural boundary where collections of individual content become a coherent Knowledge Object. By enriching normalized cards with ordering, labels, metadata, and context, it provides every presentation layer with a stable contract that remains independent of how the underlying information was gathered.