BCP 1.x and earlier to 2.0
Migration changes a package’s protocol contract, never its ownership or prior approval. Retain the original bytes, signatures, tree version and publication identity. Publish changed bytes as a new signed revision through the existing authorized workflow. A label change alone is insufficient.
- Validate the old package under its original version. Record source hashes, missing files, provenance, owner, tree version and revision before editing.
- Preserve all useful brand content and evidence dates. Normalize frontmatter
to the 2.0 schema. Remove
agent_first_actiondeclarations from frontmatter and fenced YAML, recording the removed lines. Do not claim arbitrary equivalent prose can be detected. Do not rewrite historical source files. - Retain the seven established core documents. Add the required onboarding companion and declare all supplied daughters in the root map. If a core document is absent, record an explicit gap in that document; do not invent brand rules. Additional anti-AI, commerce, audience, product and campaign documents remain optional and retain their content.
- Add a
source_coveragerecord in the root:status,sources,gapsandresearch_refreshed. List actual sources and limitations. A format-only migration usesresearch_refreshed: false; do not reset evidence dates. - Migrate each claim explicitly using the table below. Retain its old status
as
legacy_proof_status. Preserve evidence, caveats, exact wording, dates, scope and owner. Review unknown or conflicting records rather than guessing. - Validate every file and claims block. Record the full diff and new tree version. Prepare and approve the exact resulting bytes where required.
- Publish under the existing handle, independently verify source hashes and signatures, and verify HTML, JSON, raw sources and MCP share that revision. A saved draft, Git merge or HTTP success alone does not close migration.
| Old proof_status | New use_status | evidence_status | brand_approval |
|---|---|---|---|
| approved | permitted | unknown unless evidence was assessed | unknown unless explicit accountable approval is retained |
| requires_caveat | conditional | unknown unless evidence was assessed | unknown unless explicit accountable approval is retained |
| forbidden | prohibited | unknown unless evidence was assessed | unknown unless explicit accountable approval is retained |
| expired | expired | unknown unless evidence was assessed | unknown unless explicit accountable approval is retained |
| aspirational | aspirational | unknown unless evidence was assessed | unknown unless explicit accountable approval is retained |
| unknown or absent | unknown | unknown unless evidence was assessed | unknown unless explicit accountable approval is retained |
approved formerly mixed evidence and approval. Neither a source URL nor the
old field alone establishes evidence assessment or brand approval. permitted
preserves the publisher’s use classification; it does not establish legal
approval or endorsement. Conditional claims require the original caveat; missing
caveats are a validation failure requiring review. Expired, aspirational,
prohibited and unknown claims are retained in the forbidden structured bucket
and are unavailable as factual marketing claims. In 2.0, approved_at_launch
is renamed permitted; the other buckets remain requires_caveat and
forbidden. Old canonical-claims.v1 projections remain historical v1 contracts;
they MUST NOT silently acquire these new semantics.
Duplicate names do not establish shared ownership or supersession. Select a current handle only from ownership, provenance, content and intended example links. Alias/archive decisions must be reversible and recorded; unresolved duplicates remain open and are never bulk-deleted.