Marketing is an internal demand-and-brand service, so its architecture is shaped by what it must guarantee:

• Honest positioning. Whatever it says about a service must come from that service's own source-of-truth records, not hand-written claims.
• Attributable demand. Because the service charges other services for the demand it generates (cost center CC-009), every campaign and its effect must be traceable back to a service so the charge is defensible.
• Consistent brand. Promotion and brand for the whole of Carolverse must stay coherent across surfaces.
• Accountable by construction. Every action is owned by an agent — today that is Loki.

These are the guarantees the architecture is being built toward; the mechanisms below are mostly intended, not yet shipped.

Grounded in the shared Carolverse stack; only the parts that plausibly apply here:

• Python 3 on FastAPI / Flask behind nginx for any service surface.
• SQLite (WAL) datastores for campaign and demand records.
• The registry and the design store as the binding sources of truth Marketing reads service facts from.
• systemd / cron to schedule recurring campaign or reporting jobs once they exist.
• Claude (Sonnet/Opus) for drafting copy and brand content.

No Marketing-specific datastore, scheduler, or AI step is wired yet.

Marketing is intended to be an instance of Carolverse's agent-centric modular architecture: the work is broken into blocks, each owned by an agent and carried out by that agent's droids. Today the service has no blocks and no droids defined — it is a single owner agent, Loki, with a stated purpose.

The intended shape:

• A positioning step that pulls each service's facts from the registry / design store rather than inventing claims.
• A campaign step that runs promotions and records what was run.
• A demand-accounting step that attributes generated demand back to a service and produces the charge against cost center CC-009.

These are described here as direction; the control plane and droids are still being built.

• Single source of truth. Positioning copy is derived from the live registry and design store, never hand-copied — the org-wide principle on the Carolverse Architecture page.
• Agent-centric modular architecture. Each future block has an accountable agent and a doing droid.
• Attributable demand. Every charge traces to a service and a campaign.
• No fluff. Promotion states what a service actually does.

• A service can be positioned and promoted from its own true records, with no invented claims.
• Demand generated by a campaign is attributable to the campaign and the service it served.
• Charges to other services (cost center CC-009) are defensible from the recorded demand.
• The Carolverse brand stays consistent across surfaces.

Most of these are targets for the wip build, not yet met.

• Owner is an agent, never a human — currently Loki.
• Claims must be grounded in the promoted service's source-of-truth records.
• Charges are internal and attributed to cost center CC-009; a service may only be charged for demand it actually received.
• Standard Carolverse governance applies — changes to this service go through the build pipeline (planner or bypass), never hand-edited.

Current

This is a thin wip service. It currently delivers little beyond its definition:

• An owned place in the catalogue for Carolverse's demand-and-brand function, owned by Loki.

No campaigns, demand-accounting, or brand droids are built yet.

Future (on demand)

The bulk of this service's capability is still ahead:

• Positioning pages that promote each Carolverse service from its true registry / design-store records (enabling agent: Loki).
• A campaign runner that executes and records promotions.
• Demand accounting that attributes generated demand to a service and charges it against cost center CC-009.
• A consistent Carolverse brand kit applied across surfaces.

Each of these will be built as its own block with a named agent and droids, per the agent-centric pattern.

This service has no agent-facing tools yet. Interact with it through its owner and the standard pipeline:

• Owner path. Loki owns Marketing; demand-and-brand requests are directed to Loki.
• Change path. To add a block, droid, or capability, file a build initiative against this service through the build pipeline (planner or bypass) — the service is not hand-edited.

An operator/HTTP runbook will be added once the service has surfaces and tools.