Reference — Jonomor
Layer: Schema Graph · All References
Schema Governance
Why Schema Governance Matters
Schema governance is the set of rules that keeps structured data consistent across every page and every domain in an entity ecosystem — preventing type drift, @id fragmentation, and relationship contradictions that degrade AI retrieval quality.
Incorrect schema produces worse outcomes than no schema. A schema declaration that assigns the wrong type, uses an inconsistent @id, or contradicts the page copy introduces a contradiction that AI parsers must resolve — typically by reducing confidence in the entity's representation rather than building it.
Schema governance is not a one-time audit. It is a set of rules applied to every new page before publication. The rules below govern how structured data is declared across the Jonomor ecosystem.
Stable @id Rules
- One @id per entity
Each entity has exactly one canonical @id. That @id is assigned in the entity registry before any schema is written and does not change without an explicit governance decision.
- Fully qualified URLs only
All @id values must be fully qualified: https://jonomor.com/#organization, not #organization, not https://www.jonomor.com/#organization, not https://jonomor.com/. The protocol, domain, path, and fragment must all be present and consistent.
- No trailing slash variation
https://jonomor.com/#organization and https://jonomor.com/#organization/ are different strings. The canonical @id must be used without trailing slash unless the canonical form explicitly includes one.
- Fragment signals entity category
#organization for organizations, #app for software applications, #work for creative works, #method for methodology entities, #person for person entities. Fragment choice is consistent with Schema.org type.
- No alternate IDs in any schema
Schema declarations on any page or domain must use only the canonical @id from the entity registry. There are no 'local' @id variations. Every @id must be the canonical one or omitted.
Type Consistency Rules
The following table is the locked type assignment for every entity in the Jonomor registry. These types must not vary across domains, pages, or schema declarations.
| Entity | Schema.org type | Note |
|---|---|---|
| Jonomor | Organization | Parent organization. Not LocalBusiness, not Corporation. Organization is the correct root type. |
| Ali Morgan | Person | Founder entity. Not Employee, not Role. Person schema only. |
| XRNotify | SoftwareApplication | Web-based monitoring platform. Not WebApplication, not Service. SoftwareApplication with applicationCategory: Monitoring. |
| MyPropOps | SoftwareApplication | Operational workflow platform. Not Service, not Organization. SoftwareApplication with applicationCategory: Productivity. |
| The Neutral Bridge | CreativeWork | Research and analysis publication. Not Article, not Blog, not Periodical. CreativeWork is the correct entity-level type. |
| Guard-Clause | DefinedTermSet | Software reliability methodology — a collection of defined terms and practices. Not CreativeWork, not SoftwareApplication. DefinedTermSet is correct for a methodology entity. |
sameAs Rules
- 01sameAs must point only to real, verifiable identity profiles for a Person entity — Wikidata, GitHub, LinkedIn, or other established identity surfaces where the person is present.
- 02sameAs must never include product domains owned by the same organization. https://xrnotify.io is not an identity profile for Ali Morgan — it is a product entity in the same ecosystem.
- 03sameAs must never include placeholder values, fake profile URLs, or URLs that do not exist.
- 04If no real identity profiles exist for a Person entity, sameAs must be omitted entirely — not left empty, not filled with placeholder text.
- 05For Organization entities, sameAs may reference established directory profiles (Wikidata, Crunchbase, etc.) if they exist and are confirmed accurate.
- 06sameAs entries must be validated before being added. An incorrect sameAs creates a false identity claim that is worse than omitting it.
Page-Level Schema Extension Rules
- Article pages (TechArticle)
Use @type: TechArticle. author must reference the canonical Person @id — not an inline {name: 'Ali Morgan'} object. publisher must reference the canonical Organization @id. Do not re-declare the entity definition inside the article schema — reference the @id only.
- Collection pages
Use @type: CollectionPage with mainEntity as ItemList. Each ListItem must include name and url. The collection page @id should use the page URL with a descriptive fragment such as #collection.
- Definition pages
Use @type: DefinedTerm. Include inDefinedTermSet referencing the definitions collection @id. author and publisher must reference canonical @ids. No datePublished unless the date is accurate and known.
- Concept reference pages
Use @type: TechArticle. Same author/publisher rules apply. No dates unless known. mainEntityOfPage should reference the page URL.
- Case study pages
Use @type: TechArticle with an about field referencing the subject entity's canonical @id. Do not re-declare the entity schema inside the case study — use @id reference only.
- Checklist and governance pages
Use @type: TechArticle. Same author/publisher rules apply. The page's subject matter does not require special schema beyond TechArticle — the content is the reference, not a typed entity.