CAMPAIGN
CAMPAIGN
SERVICE CONTRACT · VIEW: GOV
Axiom
CAMPAIGN is the repeatable event-to-emission framework. One event. All platforms. Governed cascade.
Constraints
MUST: Follow EVENT → ROLES → CASCADE → HIERARCHY → EXECUTE → LEARN pipeline MUST: Assign each platform exactly one role (LEAD, AMPLIFY, DEEPEN, DISCOVER) MUST: LEAD emits first — no platform publishes before LEAD MUST: Maintain paper hierarchy consistency across all platforms MUST: Record every emission as governed artifact with draft contract MUST: Write post-campaign metrics to LEARNING.md MUST: Ledger every emission — CAMPAIGN:EMIT event on LEDGER MUST: Monitor LEAD emissions for comments within T+24h MUST: Respond to substantive comments within T+48h MUST: Connect with commenters (LinkedIn connect, Twitter follow, HN reply) MUST: Ledger every comment response as CAMPAIGN:ENGAGE event MUST NOT: Duplicate content across platforms — each adds unique angle MUST NOT: Contradict LEAD content on any platform MUST NOT: Publish without PREFLIGHT (links 200, char count, platform rules) MUST: Every platform channel instance at CAMPAIGNS/ inherits these constraints MUST: Instance trees carry all state (CANON, INTEL, LEARNING, COVERAGE, ROADMAP, VOCAB) MUST NOT: Nest instance directories under SERVICES/CAMPAIGN/ (service contract is the class, not the instance)
Capabilities
CONTENT_ADAPT, EVENT_CASCADE, LEAD_EMIT, PLATFORM_ROLE
COVERAGE: 223/255
SPEC
Purpose
CAMPAIGN is the repeatable event-to-emission framework. One event. All platforms. Governed cascade. Capture once, execute forever.
Framework
Every campaign follows six steps:
EVENT → ROLES → CASCADE → HIERARCHY → EXECUTE → LEARN
1. EVENT
Define the triggering occasion.
| Field | Description |
|---|---|
| name | Event name |
| dates | Start and end dates |
| venue | City + venue |
| talk | Talk title (if presenting) |
| competition | Competition name (if applicable) |
| audience | Primary audience profile |
2. ROLES
Assign each platform a single job.
| Role | Job | Cadence | Rule |
|---|---|---|---|
| LEAD | Primary emission. Full depth. Always publishes first. | Daily or event-driven | LinkedIn (default) |
| AMPLIFY | Real-time moments. Condensed content. Event arc. | Event-driven only | Twitter/X |
| DEEPEN | Community-specific depth. Platform-native. Substance. | 1 per community | |
| DISCOVER | Product demo + research. Max 2 posts. | Mid-event + post-event | HackerNews |
Platform-to-role mapping can change per campaign, but the roles are fixed.
3. CASCADE
Schedule emissions with cross-platform timing.
LEAD emits first (T+0)
AMPLIFY follows same day or T+0 (real-time)
DEEPEN follows T+0 to T+2 (community-specific angle)
DISCOVER follows mid-event and post-event (max 2)
Arc shape: Pre → Live → Debrief
| Phase | Timing | Purpose |
|---|---|---|
| Pre | T-3 to T-1 | Set narrative. Build anticipation. Drop the primary paper. |
| Live | T+0 (event days) | Capture moments. Stage photos. Real-time proof. |
| Debrief | T+4 to T+7 | Synthesize learnings. Link to depth content. Drive next action. |
4. HIERARCHY
Rank content assets for every campaign.
| Rank | Definition | Rule |
|---|---|---|
| PRIMARY | The main paper or artifact. The proof. | Every platform. First link when discussing the problem. |
| COMPANION | Supporting paper. Same framework, different angle. | Academic contexts only. Never alone — always after primary. |
| FOUNDATIONAL | Origin paper. Historical context. | Product-focused posts only. Clinical history. |
| PRODUCT | Live demo or working platform. | Show HN, product posts. The proof that runs. |
| CLINICAL | Trial registration. Evidence of real-world execution. | Credibility anchor. Include when claiming scale. |
5. EXECUTE
For each emission:
DRAFT → PREFLIGHT → PUBLISH → TRACK → ENGAGE
| Step | Action |
|---|---|
| DRAFT | Write governed draft in platform POSTS/DRAFTS/ |
| PREFLIGHT | Verify: links live (HTTP 200), char count, platform rules, paper hierarchy |
| PUBLISH | Emit. Move from DRAFTS/ to SENT/. Record timestamp. |
| TRACK | Capture metrics: impressions, reactions, reposts, comments |
| ENGAGE | Respond to comments. Capture INTEL. Feed back to LEARNING. |
6. LEARN
After every campaign:
METRICS → ANALYSIS → LEARNING.md → NEXT CAMPAIGN
| Question | Source |
|---|---|
| Which platform drove the most engagement? | TRACK metrics |
| Which paper/blog got the most clicks? | Link analytics |
| What content angle resonated most? | Comment sentiment |
| What should we do differently next time? | Team debrief |
Write findings to LEARNING.md. Feed into next campaign.
Campaign Instance Template
Every event gets a file in EVENTS/. Copy EVENTS/TEMPLATE.md and fill in.
Required sections:
- Event metadata (name, dates, venue, talk)
- Paper hierarchy (ranked for this event)
- Platform roles (which platform does what)
- Cross-platform schedule (the cascade table)
- Content assets (papers, blogs, products linked)
- Emission count (totals per platform)
Cross-Platform Rules
1. LEAD always emits first. No platform publishes before LEAD.
2. No platform contradicts LEAD content.
3. Each platform adds a unique angle — never duplicates.
4. Paper hierarchy is consistent across all platforms.
5. Every emission is a governed artifact with a draft contract.
6. Post-campaign: metrics → learning → next campaign.
Routes
web_docs: https://hadleylab.org/
web_surface: https://hadleylab.org/SERVICES/CAMPAIGN/
magic: magic://hadleylab.org/SERVICES/CAMPAIGN/
Privacy
privacy: PUBLIC
All campaign governance documents are public. Draft content is internal until PUBLISH.
INTEL
Cross-Scope Evidence
| Framework Claim | Evidence Source | Reference | Status |
|---|---|---|---|
| Repeatable event-to-emission pipeline | CAMPAIGN.md §Framework | EVENT → ROLES → CASCADE → HIERARCHY → EXECUTE → LEARN | ANCHORED |
| Four platform roles (LEAD, AMPLIFY, DEEPEN, DISCOVER) | CAMPAIGN.md §Roles | Role table with cadence and rules | ANCHORED |
| Paper hierarchy governs citation order | CAMPAIGN.md §Hierarchy | PRIMARY, COMPANION, FOUNDATIONAL, PRODUCT, CLINICAL | ANCHORED |
| Three-phase arc (Pre, Live, Debrief) | CAMPAIGN.md §Cascade | T-3 to T+7 timeline | ANCHORED |
| LEAD emits first — no platform before LEAD | CANON.md constraints | MUST: LEAD emits first | ANCHORED |
| Post-campaign metrics feed LEARNING.md | CAMPAIGN.md §Learn | METRICS → ANALYSIS → LEARNING.md | ANCHORED |
Content Inventory
| Section | Content | Status | Gap |
|---|---|---|---|
| Service page | /services/campaign/ | PENDING | Verify surface 200 |
| Event instances | EVENTS/ directory with per-event files | PENDING | Verify template exists |
| Platform emission archive | SENT/ directories per platform | PENDING | Verify governed pipeline |
Domain Architecture
| Layer | Current | Target |
|---|---|---|
| Service page | hadleylab.org/services/campaign/ | Same (governed) |
| Build | CANONIC pipeline | Same |
| Design | _TOKENS.scss authority | Same |
Test
| prompt | expect | cross |
|---|---|---|
| What pipeline does CAMPAIGN follow? | EVENT → ROLES → CASCADE → HIERARCHY → EXECUTE → LEARN | CAMPAIGN.md |
| What are the four platform roles? | LEAD, AMPLIFY, DEEPEN, DISCOVER | CAMPAIGN.md |
| Which role emits first? | LEAD | CANON.md |
| What is the paper hierarchy order? | PRIMARY, COMPANION, FOUNDATIONAL, PRODUCT, CLINICAL | CAMPAIGN.md |
LEARNING
Lessons
PMWC 2026 (first campaign)
- LinkedIn soft launch (Feb 28) already referenced both papers — established the hierarchy before the campaign started
- The $255 Billion Wound (“the 255 bleed”) is the primary paper — always leads
- The €344 Billion Euro Wound is the companion — only surfaces in academic or EU-specific contexts
- LinkedIn leads, other platforms cascade — never the reverse
- Each platform has one job: lead, amplify, deepen, or discover
- Twitter Day 1 timing must match actual presentation day — “tomorrow” vs “Thursday” matters
- HackerNews tolerates maximum 2 posts per event — volume gets penalized
- Reddit posts must be platform-native — cross-posting gets downvoted
AlphaGo at 10 (second campaign — 2026-03-15)
- Anniversary-driven campaigns need same-day execution — the hook expires at midnight
- LinkedIn posted manually via Chrome DevTools MCP — works but ungoverned (no preflight, no ledger, no timeline event)
- Twitter/Reddit/HN drafts written but not posted — held for governed pipeline rather than manual hack
- OG card infrastructure was broken: og.png deleted by build GC because it wasn’t in GOV source. Fixed by adding design assets copy step to build-surfaces and updating BUILD/CANON.md runtime boundary to allow .png
- Blog compiler now emits description in frontmatter for OG cards (all 51 posts updated)
- Branding assets (og.png, favicon.svg, canonic-logo.svg) now compiled from design theme — survive every build
- IP barrier validated: original draft leaked dimension names too close to kernel codes. Fixed to match existing blog narration (History, Community, Practice)
- “CANONIC is not a player. CANONIC is the game.” — strongest marketing line, emerged from game theory framing
- Campaign needs a compiler phase: EVENTS/*.md → preflight → emit → TIMELINE → LEDGER. Manual posting doesn’t scale and doesn’t prove governance.
- LinkedIn Post Inspector confirms OG tags compile correctly (title, description, image, type=article)
The Lawyer Who Won (third campaign — 2026-03-24)
- Highest hit rate yet (71%): 5/7 posted. LinkedIn 3/3, Twitter 1/1, HN 1/1. Reddit 0/2.
- Content-driven campaigns (blog launch) outperform event-driven campaigns (PMWC, anniversary) because the hook doesn’t expire
- HN succeeded with factual title and author comment within 10 minutes — validated the DISCOVER role
- Reddit r/MachineLearning explicitly rejected governance framing (“keep community focused on ML/stats”). Governance posts must target r/artificial, r/LegalTech, r/healthIT instead.
- Reddit spam cascade: 3 removals in 30 minutes triggered site-wide filter. Account silently flagged. Even comments auto-removed. Recovery requires 24-48h cooldown minimum, then karma-first strategy.
- Reddit links to hadleylab.org and canonic.org auto-removed. Links must go in comments after post body survives moderation, not in post body.
- REPOSTED status (CANONIC + HadleyLab pages) is a valid emission type for company pages — reshare personal LEAD post rather than writing new content
Cross-campaign patterns (2026-03-26 audit)
- LinkedIn + Twitter is the reliable execution pair. 10/10 across both campaigns that shipped.
- Reddit is zero-for-everything. Platform requires karma rehabilitation and API access before next attempt.
- HN is viable but needs API access for governed posting and comment monitoring.
- Engagement loop is completely unexecuted. CANON requires T+24h monitoring, T+48h response. Zero governed engagement events across all 10 posted emissions.
- LinkedIn calendar aspirational vs actual: 22 scheduled for March, 7 confirmed posted. Calendar without execution ledger is fiction.
- Analytics infrastructure (GA4, OG, Pixel, sitemap) still missing from Feb 28 PREFLIGHT. Shipping blind.
- Manual posting works and should continue until pipeline exists. Don’t hold posts for an unbuilt pipeline.
| Date | Signal | Pattern | Source |
|---|---|---|---|
| 2026-03-25 | FEEDBACK_PROMOTED | CANONIC.org branding: Use CANONIC.org (uppercase) as the branded link in social replies and comments, not canonic.org lo | intake:feedback_canonic_branding.md |
| 2026-04-02 | PROJECT_INTEL | Campaign Syndication Pipeline: CAMPAIGN LEARNING contract, temporal metrics, multi-channel emission pipeline (LinkedIn L | intake:project_campaign_syndication.md |
ROADMAP
VOCAB
| Term | Definition |
|---|
INHERITANCE CHAIN
SERVICES
SERVICES compose primitives — INTEL + CHAT + COIN. Every service governed. Every scope discovered.
MUST: Maintain TRIAD integrity (CANON.md + VOCAB.md + README.md)
MUST: Treat SPEC as scope identity (`{SCOPE}` directory), not as a file
MUST: Every SERVICE scope include ROADMAP.md, COVERAGE.md, LEARNING.md, and `{SCOPE}.md` as governed content surfaces
MUST: Discover SERVICE scopes from filesystem only (no manual catalog)
MUST: Keep http:// and magic:// on the same namespace (transport differs, scope path matches)
MUST: CANON.md = axiom + universal constraints (no service names, no paths, no implementation)
MUST: README.md = how to run the CANON (nothing else)
MUST: {SCOPE}.md = SPEC — the interface (purpose, routes, projections, ecosystem)
MUST: SHOP.md = public projection file (per scope, filesystem-discoverable)
MUST: VAULT.md = private projection file (per scope, filesystem-discoverable)
MUST: Runtime implementation remains under ~/.canonic; this workspace is governance-first
MUST NOT: Hardcode service names in CANON constraints (law speaks universals)
MUST NOT: Define ungoverned terms outside VOCAB.md
MUST NOT: Treat `{SCOPE}.md` as SPEC identity
MUST NOT: Move architecture/lifecycle into README
MUST NOT: Leak private projections to public surfaces
MUST NOT: Maintain duplicate mapping tables outside generated manifest outputs
MUST NOT: Add runtime jargon to governance contracts
MUST: Ledger-consuming services declare source ledgers, scope filters, and closure gates
MUST: Learning governance remains live — closure claims require fresh DISCOVER → GENERATE → RELINK evidence
hadleylab-canonic
HADLEYLAB ships software. Every app, book, paper, deal, and patent is PROOF that MAGIC works. COIN = WORK. LEARNING = COMPUTE.
MUST: Every app, book, paper, deal, or patent is evidence of MAGIC MUST: All scopes inherit canonic-canonic/CANONIC.md governance MUST: All users governed under USERS/ via SERVICES/USER MUST: Cross-index INTEL across users (INTEL.md) MUST: Shared events propagate to ALL affected user dashboards MUST: Maintain governance workspace purity (.md files only) MUST: Ledger all COIN (validated work) through MAGIC 255 MUST: Compile all INTEL from governed sources MUST: Keep frontend/runtime implementation under ~/.canonic (hidden runtime) MUST: Surface governed TALK, Library, and SERVICES scopes (no orphan content) MUST: Derive nav labels from governed scope names (no hardcoded strings) MUST NOT: Publish without governance (CANON.md required) MUST NOT: Duplicate primitives — compose from INTEL, CHAT, COIN MUST NOT: Silo intelligence inside a single user when multiple are affected MUST NOT: Expose VAULT contents outside NDA scope MUST NOT: Store runtime artifacts in governance workspace
canonic-canonic
SPEC is governance. `canonic-canonic/` is the spec root.
MUST: Keep this repo governance-only (.md/.pdf) MUST: Publish workspace mapping in CANONIC.git (no hardcoded repo lists) MUST: Preserve three primary lanes: FOUNDATION, INDUSTRIES, MAGIC MUST NOT: Commit runtime artifacts here (runtime belongs in ~/.canonic/) MUST: Sell MAGIC tiers — the product, not the proof (proof is hadleylab-canonic) MUST NOT: Embed beta-test app URLs in platform page content
CAMPAIGN · SERVICE CONTRACT · CANONIC ∩