Knowledge Hub
CITAQ documentation should connect architecture, trust, evidence, and public verification into one navigable knowledge surface.
This docs hub is the public entry point for method and system explanations. It will grow into a structured knowledge layer where platform docs, trust docs, verification docs, and category docs all reinforce the core public route graph.
Rather than acting like a disconnected help center, the documentation surface needs to push readers into the relevant platform pages, trust pages, and solution pages depending on what they are trying to understand.
It exists for readers who need definitions, boundary explanations, system detail, and a durable place for future knowledge clusters.
Doc Families
How the documentation surface is organized
Pages explaining canonical records, evidence models, verification logic, and public route systems.
Pages covering disclaimers, verification interpretation, trust surfaces, and responsible public framing.
Pages mapping how teams use the system, how evidence moves, and how verification states are maintained.
Pages designed to answer high-intent questions around evidence-bound claims, public verification, and AI-commerce readiness.
Priority Topics
The first documentation clusters this hub should feed
A plain-language explanation of status, evidence dependence, point-in-time interpretation, and what verification does not imply.
Documentation for the relationship between product records, claim objects, source artifacts, and trust surfaces.
A route-level explanation of verify pages, trust pages, disclaimers, breadcrumbs, and connected public navigation.
Documentation on why machine-readable, inspectable, evidence-linked product data matters more in AI-mediated commerce.
Why It Matters
Docs are part of the public trust architecture
Clear, crawlable, linked documentation helps discovery systems understand how the category and trust model fit together.
Boundary docs and method docs make it harder for users or AI systems to over-read what verification output means.
Docs should act as connective tissue between marketing pages, solution pages, and public trust pages.
A strong docs hub is one of the main ways the future few-hundred-route public system stays organized and internally linked.
Connected Routes
Open the adjacent public routes from the docs hub
Move into the current workflow explanation for the product lifecycle view.
Route into the public trust system and verification boundaries from the docs surface.
Use the core category page if you need the strategic why behind the documentation topics.
Jump into the audience and use-case hub for who the system is built to serve.
Move into the dedicated hub for credentials, identifiers, provenance, and revocation topics.
Move into the dedicated hub for evidence models, claim lifecycle, proof objects, and status change.
Use the core data hub for canonical product records, canonical product surfaces, and the evidence vault layer.
Use the dedicated hub for MCP, public agent access, schema discovery, feeds, and crawler-facing surfaces.
Move into the governance hub for schema policy, discovery rules, disclosure language, and verification vocabulary.
Use the workflow hub for onboarding, evidence renewal, claim submission, revocation handling, and trust-page governance.
Move into the API-facing public hub for verification access, trust-surface APIs, and evidence-model routes.
Use the category-guide hub for industry-specific verification, trust, and disclosure patterns.
Move into the reference hub for evidence types, claim types, identifiers, schema maps, and route-taxonomy materials.
Move into the legal hub for disclosure language, privacy, terms, and verification-boundary routes.
Use the verification directory when you want a broader map across docs, trust, resources, and machine-readable surfaces.
Next Step
Start with the operational explanation if you want a step-by-step view.
The architecture route is the best next page if you want to understand how the CITAQ system moves from ingestion toward verification output.