As the service that brings customers to every other service, its intended architecture must guarantee a few things end-to-end:

• Sell on behalf of others, attribute back to them. Each win must be tied to the Carolverse service it was sold for, so the commission and the credit land correctly.
• Regional reach. Demand differs by region, so the team is structured around regional support agents who carry the local context.
• Commission accounting. What the service earns has to be measured against what it sells, which makes it a cost-center with its own ledger.
• Accountable by construction. Every customer interaction and every booked win should be tagged to the agent that drove it.

Most of this is still intended rather than implemented — the service is wip.

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

• Python 3 on FastAPI/Flask behind nginx for any future sales surface or API.
• SQLite (WAL) datastores for the customer/commission ledger when it is built.
• The registry and the design store as the binding sources of truth for which services exist to be sold and who owns them.
• Claude (Sonnet/Opus) for outreach and qualification copy as AI steps are added.
• systemd/cron for any recurring follow-up or pipeline-refresh job, once such droids exist.

No sales-specific datastores, endpoints or droids are wired yet.

The intended pattern is a direct instance of Carolverse's agent-centric modular architecture: the customer-win work splits into distinct activities, each owned by an agent and carried out by that agent's droids. Today there are no blocks defined — the Blocks section of the service page is empty — so the pipeline is still on the drawing board.

• Owner-led control plane. Aurora owns the mandate and sets direction.
• Regional support layer. Support agents Arwen, Atlas, Carol and Kiran carry regional reach (see the service's team above).
• Attribution as the spine. Every win must point back to the service it was sold for, so commission and credit flow to the right place.

The step-by-step blocks that realise this are still to be defined.

• Single source of truth. The catalogue of sellable services, their owners and their commissions come from the live registry and design store — the shared principle on the Carolverse Architecture page — never hand-copied.
• Agent-centric modular architecture. Each future sales activity gets an accountable agent and a doing droid.
• Attribution first. A win is meaningless until it is tied to the service it was sold for.
• Observability first. When the pipeline exists, no booked win counts unless it shows on a monitor with a deterministic state.

• New customers are won for Carolverse services and attributed to the right service.
• Commission earned is measured against what was sold, in a ledger that reconciles.
• Regional demand is covered by the regional support agents, not bottlenecked on the owner.
• Once built, the sales pipeline runs without manual nudging in the common case.

These are target criteria — the service is wip and does not meet them yet.

• Owner is an agent, never a human. Aurora owns the service; support agents stay within their support role.
• Sell only registered services. A win must reference a service that exists in the registry, with its real owner and commission.
• Stay in lane. Sales wins and grows customers; it does not change another service's scope or own its delivery.
• Cost-center accounting. Earnings and commission are tracked as a cost-center; the ledger is the record, not ad-hoc notes.
• Changes to this service follow the standard Carolverse build path — bypass skips the planner, not the standards.

Current

Today this is a thin, owned mandate rather than a running system:

• A defined service owned by Aurora with a clear purpose — win and grow customers for every Carolverse service for a commission.
• A regional support team — Arwen, Atlas, Carol and Kiran — carrying regional reach.
• A cost-center identity for tracking what the service earns.

No sales pipeline, droids or tools are built yet.

Future (on demand)

Most of this service's capability is still ahead of it:

• A sellable-service catalogue read live from the registry — what exists to be sold, who owns it, what commission it carries.
• A lead and win ledger that attributes each win to the service it was sold for and reconciles commission.
• Region-aware outreach driven by the support agents, with AI-assisted qualification and copy.
• A monitor showing the sales pipeline with deterministic states, once blocks are defined.
• Recurring follow-up droids scheduled durably, registered and emitting run-audit so they stay observable.

This service has no agent-facing tools yet — the tools list in its packet is empty — so there is no API or droid to call today.

Operator / owner path

• Direction and any new sales activity go through the owner, Aurora; regional questions go to the support agent for that region (Arwen, Atlas, Carol, Kiran).
• Changes to the service are filed as a standard Carolverse build initiative against the sales service and built via bypass or planner — same standards either way.

When the pipeline is built

• The intended surface is a Python/FastAPI app behind nginx with a SQLite (WAL) ledger; this runbook will gain its tool and HTTP paths once those exist.