Governance artifacts
Governance files brought into scope by this page
This page is anchored to published surfaces that declare identity, precedence, limits, and the corpus reading conditions. Their order below gives the recommended reading sequence.
Definitions canon
/canon.md
Canonical surface that fixes identity, roles, negations, and divergence rules.
- Governs
- Public identity, roles, and attributes that must not drift.
- Bounds
- Extrapolations, entity collisions, and abusive requalification.
Does not guarantee: A canonical surface reduces ambiguity; it does not guarantee faithful restitution on its own.
Site context
/site-context.md
Notice that qualifies the nature of the site, its reference function, and its non-transactional limits.
- Governs
- Editorial framing, temporality, and the readability of explicit changes.
- Bounds
- Silent drifts and readings that assume stability without checking versions.
Does not guarantee: Versioning makes a gap auditable; it does not automatically correct outputs already in circulation.
Public AI manifest
/ai-manifest.json
Structured inventory of the surfaces, registries, and modules that extend the canonical entrypoint.
- Governs
- Access order across surfaces and initial precedence.
- Bounds
- Free readings that bypass the canon or the published order.
Does not guarantee: This surface publishes a reading order; it does not force execution or obedience.
Evidence layer
Probative surfaces brought into scope by this page
This page does more than point to governance files. It is also anchored to surfaces that make observation, traceability, fidelity, and audit more reconstructible. Their order below makes the minimal evidence chain explicit.
- 01Canon and scopeDefinitions canon
Definitions canon
/canon.md
Opposable base for identity, scope, roles, and negations that must survive synthesis.
- Makes provable
- The reference corpus against which fidelity can be evaluated.
- Does not prove
- Neither that a system already consults it nor that an observed response stays faithful to it.
- Use when
- Before any observation, test, audit, or correction.
Structured data can help a system understand entities, relationships and page types. It does not by itself make a source legitimate, citable or governing.
Schema can be useful. It can make a name, organization, service, article, FAQ, breadcrumb or relationship easier to parse. But structured data is often overestimated in AI citation discussions because it feels like a machine-readable shortcut.
The real question is not “Is there schema?” The question is whether the structured signal matches the visible content, the canonical source, the page role and the authority boundary.
Schema is a clarification layer
Structured data works best when it clarifies what the page already makes true. It should reinforce visible, coherent and source-supported content.
It is weak when it compensates for a confused page, contradictory templates, ambiguous service names, unstable entity labels or missing internal source hierarchy.
A system can ignore schema, interpret it partially, combine it with other sources or resolve conflicts against other signals. That means structured data should be part of semantic architecture, not a substitute for it.
The governance gap
Structured data does not answer several governance questions:
| Question | Why schema alone is insufficient |
|---|---|
| Which source governs this claim? | Schema can identify a page, not always its authority role |
| What is excluded? | Exclusions often require explicit text and canon routes |
| Is the claim current? | Dates and versions need visible context |
| Is the source evidentiary or descriptive? | Page type does not equal proof status |
| Can the answer infer beyond the page? | Schema does not define response conditions |
That is why source hierarchy and proof of fidelity remain necessary.
When structured data helps citability
Structured data can contribute to citation readiness when it:
- reinforces stable entity names;
- aligns page type with visible content;
- clarifies authorship, organization and breadcrumbs;
- supports disambiguation between services, concepts and entities;
- reduces template-level ambiguity;
- avoids contradicting headings, titles and canonical text.
It becomes risky when the markup promises a category, service, relationship or role that the visible page does not support.
The practical test
For every structured-data element, ask:
- is it visible or supported in the page body?
- does it use the same entity names as the canon?
- does it describe the page’s actual role?
- does it avoid importing claims from templates?
- does it route toward the source that should govern the claim?
If the answer is no, schema may amplify ambiguity instead of reducing it.
Operational conclusion
Structured data is useful as a semantic reinforcement layer. It is not governance.
A source becomes stronger when structured data, visible content, internal links, canonical definitions and source hierarchy agree. It becomes weaker when schema is used to hide a lack of conceptual architecture.