Summary
How does a recurring / seasonal campaign live, recur, and archive as a project under a brand — such that past instances stay findable but a reader can tell at a glance what's active?
The project type (§2, §2.3) already covers most of this: a campaign is a project, nests under the brand, carries status: active | shipped | archived, and on archive freezes & crystallizes (durable design/voice assets fold up into the parent brand). This issue is about the edges that model doesn't fully pin down.
Motivating real case
Collier Simon runs Klaviyo as a brand (style guide, voice/tone). Klaviyo also runs BFCM every year as a campaign — its own design rules and a voice shift off the base brand, and it's different each year. Other campaigns come and go. Two things must be true at once: (a) I can pull up "what were BFCM 2025's rules" a year later; (b) the knowledge is unambiguous about which campaigns are active right now.
Modeled today: klaviyo (brand) → klaviyo-bfcm-2025 (project, status: archived), klaviyo-bfcm-2026 (project, status: active), each frozen at ship.
Open edges (the actual questions)
-
Recurring lineage. BFCM'25 and BFCM'26 are distinct frozen projects but one series. Does the format express "this is the 2026 instance of a recurring campaign" — a series: / recurs: field on the manifest, or just a naming convention + related:? (Matters for "show me how this campaign evolved year over year.")
-
Active-surfacing / the archive-with-pointers pattern. A brand may accumulate many nested projects. Should a brand bundle carry an index of its active projects (a pointer list the console reads) so a reader sees "active campaigns" without scanning every nested capsule and reading each status? Or is scanning status: the intended mechanism?
-
Campaign voice/design as a delta on the brand. A campaign's rules are an override/extension of the brand's base voice + design tokens, not a from-scratch set (BFCM voice = seasonal shift on Klaviyo's core voice). How does a project's design/ + voice layer compose over the parent brand's? This overlaps SPEC §9's existing open question ("how subject-specific skills compose with shared/agency skills") — same composition problem, applied to design//voice.
Notes
- Not blocking any consumer yet — surfaced while designing the CoSi Platform's knowledge/broker layer. Capturing so it's decided at the format level (here) before per-client instantiation conventions harden in
client-knowledge-template / cosi-knowledge.
- Related: SPEC §2.3 (project lifecycle — freeze & crystallize), §9 (open questions).
Summary
How does a recurring / seasonal campaign live, recur, and archive as a
projectunder abrand— such that past instances stay findable but a reader can tell at a glance what's active?The
projecttype (§2, §2.3) already covers most of this: a campaign is a project, nests under the brand, carriesstatus: active | shipped | archived, and on archive freezes & crystallizes (durable design/voice assets fold up into the parent brand). This issue is about the edges that model doesn't fully pin down.Motivating real case
Collier Simon runs Klaviyo as a
brand(style guide, voice/tone). Klaviyo also runs BFCM every year as a campaign — its own design rules and a voice shift off the base brand, and it's different each year. Other campaigns come and go. Two things must be true at once: (a) I can pull up "what were BFCM 2025's rules" a year later; (b) the knowledge is unambiguous about which campaigns are active right now.Modeled today:
klaviyo(brand) →klaviyo-bfcm-2025(project,status: archived),klaviyo-bfcm-2026(project,status: active), each frozen at ship.Open edges (the actual questions)
Recurring lineage. BFCM'25 and BFCM'26 are distinct frozen projects but one series. Does the format express "this is the 2026 instance of a recurring campaign" — a
series:/recurs:field on the manifest, or just a naming convention +related:? (Matters for "show me how this campaign evolved year over year.")Active-surfacing / the archive-with-pointers pattern. A brand may accumulate many nested projects. Should a brand bundle carry an index of its active projects (a pointer list the console reads) so a reader sees "active campaigns" without scanning every nested capsule and reading each
status? Or is scanningstatus:the intended mechanism?Campaign voice/design as a delta on the brand. A campaign's rules are an override/extension of the brand's base voice + design tokens, not a from-scratch set (BFCM voice = seasonal shift on Klaviyo's core voice). How does a project's
design/+ voice layer compose over the parent brand's? This overlaps SPEC §9's existing open question ("how subject-specific skills compose with shared/agency skills") — same composition problem, applied todesign//voice.Notes
client-knowledge-template/cosi-knowledge.