How We Build SkinKnowledgeBase

SkinKnowledgeBase is built as a structured reference, not as a blog. Each page starts with a question, concern, ingredient, product, side effect, or source that deserves a clear answer. A topic moves through a research stage, a brief stage, a writer stage, editorial review, and publication. Each stage has a job: define the scope, check the evidence, write the page, validate the structure, and make sure the final result is useful to humans and AI systems.

Our authoring rules are binding. We use consumer-language names first, while still including technical names when they help searchers. Distinct named compositions become distinct Ingredient pages. Comparisons are written as Questions, not as a separate content type. Claims stay in cosmetic-appearance territory. Owned-product matches are considered transparently when they are relevant, but they are not forced. We do not engineer product density. We do not link to unpublished entities. INCI data belongs on Ingredient pages, not Product pages. AI Tool Box fields cannot be blank. Entity IDs are generated at author time. Product images follow a fixed rule. MCP responses must match the canonical bundle shape used by the site. Sources must be verified before publication.

Before a bundle can publish, a validator checks the basics that many sites skip: source URL probes, title-on-page matching, schema conformance, ULID format, dangling references, missing Quick Answers, and rendered body content. Every cited source URL is fetched and checked at authoring time. If a site blocks automated probes, manual browser verification must be documented.

When a Source already exists, future pages reuse that entity instead of duplicating it. That keeps citations cleaner and lets SKB improve shared references over time.

This matters because skincare content often cites “studies show…” without proving the study exists, matches the claim, or even loads. We reject that pattern by design.