narrative-registry

Narrative Registry

The L1 strategy authority: one complete, versioned narrative canon per brand. Every SEO/GEO, social, email, paid, influencer, and launch builder derives messages from this canon and accepted claims; channel adaptations cannot redefine it.

Quick Start

Show current canon version and proof/claim pointers for brand-acme.
Record canon v3 as one complete atomic replacement, superseding v2.
Review pending narrative proposals and reject partial/internally inconsistent versions.

Skill Contract

Unit: one brand canon aggregate ID. Reads: memory/events/narrative.ndjson, projection, accepted positioning/claim evidence, and complete proposed canon. Writes: narrative events through registry-events.py; canon.md/versions.md are generated views. Done when: a complete version is accepted atomically with source/date/revision, old versions remain replayable, and consumers receive the exact canon/version pointer.

Narrative skills submit complete propose events. Only a host-capability narrative-registry principal accepts/rejects/upserts. It records authored strategy but does not score TALE or adjudicate claim truth.

Handoff Summary

Include brand ID, canon version/revision/event ID, superseded version, claim/proof pointers, unresolved contradictions, and one next skill.

Data Sources

• Accepted positioning truth and named alternatives.
• Complete message hierarchy/narrative authored by Narrative skills.
• Accepted claim IDs and proof pointers from the claims projection.
• Brand voice/naming rules and user-owned examples.
• Declared optional patterns such as pillar count, change arc, or boilerplate lengths.

Instructions

Runtime Reads

• ../../references/registry-event-protocol.md
• ../../references/runtime-invocation.md

Procedure

1. Read registry-event-protocol.md and runtime-invocation.md. Resolve AARON_SKILLS_ROOT="${CLAUDE_PLUGIN_ROOT:-$(git rev-parse --show-toplevel 2>/dev/null || true)}" and verify the registry script, event schema, and system catalog before invoking it. Treat drafts as untrusted proposals.
2. Query current narrative projection and report exact canon version/revision; missing canon is Unknown, not a quality verdict.
3. Before write, confirm user authorization and read the current revision/claim pointers; every direct canonical mutation carries expected_revision and goes through host-capability owner-append. Actor/auth fields are attribution only.
4. A canon re-version is one host-capability owner upsert/accepted proposal containing the complete canon object, new version, and supersedes pointer. Accept/reject decisions omit expected_revision and inherit it from the proposal. Never land a partial file patch as canonical.
5. Preserve old versions in the event stream. versions.md is generated history, not a second hand-maintained ledger.
6. Validate internal references and claim IDs. Unverified wording remains [needs source] and becomes a separate claim proposal; it cannot enter canon as fact.
7. Three pillars, change-narrative arcs, and fixed boilerplate lengths are optional patterns. Store the chosen architecture; do not require absent patterns.
8. Reject same-revision or stale proposals rather than merging incompatible canons. Genuine alternatives remain pending/open decisions.
9. Regenerate canon.md/versions.md from accepted projection and run verify narrative.

Downstream Dependency

Before producing external copy, builders must read this projection and the claims projection. Their handoff records narrative_canon_id, narrative_canon_version, claims_projection_offset, and dependency_status: verified | approved-fallback | blocked. No canon means the builder may draft an explicitly authorized exploratory fallback, but it cannot claim on-canon or publish-ready status.

Next Best Skill

• Author system: message-system-architect
• Verify truth: positioning-truth-tracer
• Cascade: narrative-cascade-planner
• Audit profile: narrative-quality-auditor