# Publishing the education centre

The centre is a static, manually curated publication. Its source of truth is `content/resources.json`, Markdown under `content/articles/`, and `content/gateway-research.json`. Generated HTML lives under `www/`; edit sources and rebuild, not generated articles.

## Regular publication

1. Copy a template from `content/templates/`, or run `npm run content:new -- article-slug "Article title"`. New articles begin as drafts.
2. Research the exact product, edition, artifact, version, feature and deployment. Prefer vendor advisories, official documentation, release notes and incident notices. Save URLs and reviewed dates in the research record.
3. Write original client-facing analysis: business consequence, prerequisites, vendor response, limits and questions. Keep exploit payloads and unsupported accusations out of the article.
4. Complete the manifest, including topic, related cases/guides, summary and takeaways. Set status to published only when ready. Drafts never enter HTML, Markdown, feeds, structured data or public research downloads.
5. Run `npm run content:build`, then `node scripts/check-resources.mjs`. Review the affected article and filters in a browser. Check the specific links and download that changed.
6. Update publication dates only for first publication; update modified dates for substantive edits. Rechecking a source updates its reviewed date without inventing an article edit.
7. Publish the main site with `npm run deploy:main`. Verify the affected public URLs after deployment.
8. Run `npm run search:notify -- https://onequill.dev/resources/article-slug` for the changed canonical pages, including updated collections. With no URLs, the command submits the current main sitemap's URLs. Preview the list first with `--dry-run`. The command checks that the verification file is live and records the receipt locally; submission does not confirm indexing.

## Evidence policy

Use one of security-advisory, incident-report, release-fix or documented-behaviour. A release correction is not automatically a security advisory. A vendor claim is attributed to the vendor, not represented as an independent certification.

Record source-specific version and identifier differences in identifierNotes. Where CVE mappings conflict, retain the primary GHSA as the finding identifier. Never merge uncertain ranges or count uncertain mappings as separate flaws. Scope findings to their prerequisites; do not infer managed-service exposure from an open-source package notice.

Provider profiles are alphabetical and descriptive. Selected case totals do not measure vendor safety. The directory is a researched snapshot rather than an exhaustive inventory of everything available.

OneQuill develops OneVir. Preserve this affiliation and the evidence limits in every relevant article. Local source review does not equal a release audit or a freshly executed test.

## Corrections

Edit the affected research record and article together. Add a dated corrections entry to the article manifest (date and text), explain the changed identifier, scope or recommendation, and retain the appropriate original publication date. Build and inspect only the affected resource behaviour.

To report a correction, use the [public support route](https://onequill.dev/support) and identify the page, primary source and proposed correction. Source updates can change applicability after the last review.

## Search discovery

The builder generates HTML available without JavaScript, canonical metadata, Article and collection schema, sitemap entries, RSS, public Markdown and llms.txt links. Social images are original diagrams.

Reader links open formatted HTML. Links labelled **Download Markdown**, **Markdown worksheet** or **research records (JSON)** intentionally provide reusable files. Agents can start with [the document index](https://onequill.dev/agents.json), [full website text](https://onequill.dev/llms-full.txt) or [the discovery guide](https://onequill.dev/llms.txt), without browser automation.

The main [sitemap](https://onequill.dev/sitemap.xml) is listed in robots.txt and submitted through the verified Google Search Console and Bing Webmaster Tools properties. Resubmit it after a substantial publication when appropriate. Google recommends [Search Console, its API or robots.txt for sitemap discovery](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap).

The local `search:notify` command uses [IndexNow](https://www.indexnow.org/documentation) to notify Bing and other participating engines of changed canonical URLs after deployment. HTTP 200 means received; HTTP 202 means received with key validation pending. This command does not submit to Google. Keep publication dates, modification dates and source-review dates distinct, and assess actual impressions and indexing in the search consoles.

[Google's AI search guidance](https://developers.google.com/search/docs/appearance/ai-features) says no special AI optimisation is required and inclusion is not guaranteed. Maintain useful, accessible, original and well-sourced content; do not promise traffic or use fabricated author expertise or review scores.