88 lines
2.9 KiB
Markdown
88 lines
2.9 KiB
Markdown
# EDUT Public Content Standard (v1)
|
|
|
|
This standard defines how EDUT publishes public content so humans and AI systems resolve the same meaning.
|
|
|
|
Rule: if a top model explains EDUT incorrectly from our public page, the content is incorrect.
|
|
|
|
## Core Principle
|
|
|
|
1. Public content must be authored for dual readers:
|
|
1. Human reader on page.
|
|
2. AI model consuming URL content for summary/explanation.
|
|
|
|
## Canonical Source Model
|
|
|
|
1. Author one canonical source per public topic.
|
|
2. Render three synchronized outputs from the same source:
|
|
1. Human page (`/about`).
|
|
2. Machine markdown (`/about.md`).
|
|
3. Machine JSON (`/about.json`).
|
|
3. No manual drift between formats is allowed.
|
|
|
|
## Required Content Shape
|
|
|
|
1. Server-rendered semantic HTML for all canonical facts.
|
|
2. No JavaScript dependency for core meaning.
|
|
3. Stable heading structure:
|
|
1. `What EDUT is`
|
|
2. `What EDUT is not`
|
|
3. `How EDUT works`
|
|
4. `Current status`
|
|
4. Explicit negation boundaries are required in `What EDUT is not`.
|
|
5. Publish `last_updated` and `version` on every canonical page and machine endpoint.
|
|
|
|
## Boundary Negations (Required)
|
|
|
|
Each canonical public page must carry explicit negative statements that prevent model misclassification.
|
|
|
|
Minimum baseline:
|
|
|
|
1. `EDUT is not a subscription SaaS.`
|
|
2. `EDUT is not an AI chatbot.`
|
|
3. `EDUT is not a crypto exchange or broker.`
|
|
4. `EDUT is not an investment product.`
|
|
|
|
## Structured Data Requirements
|
|
|
|
1. Include JSON-LD on canonical pages.
|
|
2. Use schema types that match the page purpose (`Organization`, `SoftwareApplication`, `Product`, `FAQPage`).
|
|
3. Keep schema claims identical to visible canonical text.
|
|
4. Do not place canonical claims only in hidden script-only data.
|
|
|
|
## Language and Style Requirements
|
|
|
|
1. Factual, direct, low-ambiguity copy.
|
|
2. Avoid metaphor-only explanations for core definitions.
|
|
3. One concept, one term (aligned with `docs/vocabulary-registry.md`).
|
|
4. Remove marketing filler that can distort model summaries.
|
|
|
|
## AI-Answer Conformance
|
|
|
|
1. Every public canonical page must pass `docs/ai-answer-conformance-checklist.md`.
|
|
2. Required model set:
|
|
1. Claude
|
|
2. GPT
|
|
3. Grok
|
|
4. Gemini
|
|
3. A single-model factual miss is a content bug.
|
|
|
|
## IP and Exposure Boundary
|
|
|
|
1. Public canonical pages may explain model, policy, and value framing.
|
|
2. Public canonical pages must not expose protected implementation internals.
|
|
3. Internal architecture details stay in private repositories/docs.
|
|
|
|
## Launch Sequencing
|
|
|
|
1. Finalize canonical human page content first.
|
|
2. Generate `.md` and `.json` from the same source after canonical content freeze.
|
|
3. Publish machine endpoints only after the canonical source passes conformance checks.
|
|
|
|
## Governance Hooks
|
|
|
|
1. Content changes touching canonical definitions require:
|
|
1. Vocabulary alignment check (`docs/vocabulary-registry.md`).
|
|
2. AI-answer conformance run.
|
|
3. Release-gate acknowledgement in `docs/release-gate.md`.
|
|
2. Failing any step blocks release.
|