Thx for the pointer to showInDiscover 
I think it solves a different problem than what we’re dealing with though.
For Barazo, discovery is one of the reasons to align with standard.site in the first place. If I set showInDiscover: false, I’ve done all the work of aligning schemas and then opted out of the benefit. I want forum content to be findable across the ATmosphere (within the appropriate fields if these exist).
The problem I raised in my earlier post is that forum threads (help requests, bug reports, heated debates) are a different kind of content than blog posts/ articles (which seem to be what the content field on site.standard.document is currently manly used for). Putting forum discussions (the first post that is) in a general reading feed might not be helpful (or outright annoying) if that is indeed the intention behind that content field.
So my ask is basically how generic this content field really is.
contentfield definition from standard.site:
Open union used to define the record’s content. Each entry must specify a$typeand may be extended with other lexicons to support additional content formats.
That leaves it open for pretty much everything? 
If the intention is indeed that we can use it for whatever, what probably needs to happen is some kind of content-type awareness on the consuming side. If an indexer could tell “this is a forum thread” from “this is a blog post” (based on the content union’s $type, or a field on the publication, or some other signal), then discovery works for everyone. Blog apps show blog content, forum apps show forum content.
I think it makes the most sense for me to restructure forum.barazo.topic.post to align with site.standard.document where possible:
- Switching content to an open union (useful for future richtext support regardless)
- Adding a site field pointing to a site.standard.publication record
- Renaming
createdAtto standard.sites’spublishedAt
These changes are worth doing on their own. But I should probably be holding off on dual-write (creating an actual site.standard.document per thread) until there’s a way for consuming apps to filter by content type. Otherwise I’d be creating exactly the feed pollution problem I just described.